Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Device stops sending data after a while
#1
Exclamation 
A couple of you reported an issue that the device stops sending data after a while.
Since the CDM7160 ones and the Dust sensors, connect to the WiFi each 30-120 sec, i suspect that at some point of time the module stops being able to connect to the router. To help me clean this up I would need your help to identify if this is the root cause.
I've implemented a simple eventing mechanism in the firmware that allows to schedule a list of commands to be executed on certain times. It can be used in the following ways

First - Update to the latest version (with command "otah")
And then

Option 1 - disable the going of the device into sleep mode and then connecting to wifi again
Code:
prop_jset "event.setupEnd"##nop 0##

Have in mind that this will increase the heat in the device so Temperature and Humidity will be higher by 5-6 degrees

Option 2 - Change LED color when the device connects to Wifi or searches
If my theory is right, at some point of time, the LED will not become blue any more. If this happens - i will try to make some changes in the FW to somehow retry harder to connect to Wifi
Code:
prop_jset "event.wifiSearching"##ledcolor orange##
prop_jset "event.wifiConnected"##ledcolor cyan##

If the LED is too dim to be seen, you can use
Code:
prop_jset "event.wifiSearching"##ledbrg 90##ledcolor orange##
prop_jset "event.wifiConnected"##ledbrg 90##ledcolor cyan##
you can play with the value of ledbrg command 100 is off, by default it is 97
(there is also a Photoresistor on the board that should match the light of the LED according to the ambient light, but i haven't yet integrated it)
Reply
#2
Enabled both options, will watch it for a while now.
Reply
#3
Until now the device still sends data. Temp looks still ok, despite the nop 0 setting.

I will leave it like this for a couple of days.
Reply
#4
Looks like it started sending rubbish now. In my logging (Homeseer) I see "JSON controldevicebyvalue caused an error:".

Error is something like characters are unrecognized.

LED is still blue.

Will now try to unplug and restart the device. -> after restart it looks like it works fine again.

Should I test other things for you to find out what this issue is?
Reply
#5
hmm can you tell me how the device is sending data to homeseer ?
by http or mqtt and what kind of data is sent

up to now i haven't tested the firmware with the CDM7160 sensor to work continously, so there may be some memory leak that after several days of working causes such issues
Reply
#6
I use HTTP to send the data.

For now I am not able to see what kind of data was sent, will wait until it happens again.
Reply
#7
Haven't been able to pay much attention to this for a couple of weeks - device has been happily running and logging off a good USB power supply in the mean time. I updated the firmware late yesterday evening then tried to run it overnight (from a Lidl power bank and Staples hub as described in another post) which stopped, as before, after about an hour. I've run it again today and it has been fine all day. So it goes. I wonder if it's that the power bank is less full so the output voltage has dropped a bit?

Anyway, I'd like to try the coloured LED option to see what happens.

One question before I do: is there an easy way to set it back to the default (“factory”) state once I'm done messing with it? Turn on with the button pressed or something? I don't mind setting up the WiFi and MQTT again.
Reply
#8
Hi Ed,

sorry i didn't answer you earlier. Seems like when i get one notification for new stuff in the forum, I do not get new notifications about other comments until i read this one. And since i usually read them from my mobile, i sometimes forget to check if there is something else. I have to find where this is configured in the forum software.

To get back to factory, just type command "factory" Smile
I have just finished another project which was due (http://vair-monitor.com/2016/11/02/vespr...roduction/), and now i will have some time to integrate all those commands into the Config Utility (and perhaps make it available over HTTP)
Reply
#9
Thanks Vladimir, I'm doing some humidity experiments for the next day or so but will try the LEDs later.

http://www.greenbuildingforum.co.uk/newf...onID=14682
Reply
#10
Set up the colour LEDs last night. Brightness level 93 seems to be a good compromise.

It only connects to the router for a second or so: I had a ping -a running which usually beeped once, sometimes twice, occasionally not at all. Just as an experiment I tried the command “prop_jset "event.wifiDisconnected"##ledbrg 93##ledcolor red##” just to see if that would give more status information but it didn't.

I then left it running overnight with a nominal 30 second sample interval. This was off the Staples powered hub which gave problems before but with the “uplink” USB port plugged into my laptop and also my mouse, a USB to serial adapter for a Current Cost meter and a 1-wire adapter with a few temperature sensors plugged in. Power to the hub was from mains. This combination has been running well for a few days and continued to operate nominally overnight.

The LED was off for a few seconds, on orange for a few seconds then turned to cyan. A second or so later MQTT data was logged which seemed reasonable. The LED remained on cyan for about 30 seconds then the cycle repeated.

The only untoward event noted overnight was a single “%CO2%” reading.

This morning I disconnected the other devices connected to the hub and also disconnected the hub's upstream USB connection from the laptop leaving just the mains supply and the CO₂ monitor plugged in to it. This was one of the combinations which caused problems before.

For about half the cycles the LED operated as before. For the remainder it didn't come on at all. I.e., it either stays off completely or goes through the whole off/orange/cyan sequence as above. I didn't notice any where it just stayed orange or cyan or anything like that.

It's been running for quite a few hours now but has not stopped as it did before.

The data for temperature, pressure and humidity seem sensible. There was a short run of CO₂ readings of 2147483649 (i.e., a 32-bit signed -1 interpreted as unsigned, I assume). Since then there have been quite a lot of %CO2% readings. I've not watched it all the time (of course) but I have seen valid-looking CO₂ readings in cycles with the LED on and with it off. I've also seen %CO2% with the light on. I haven't noticed any %CO2% readings with the LED off.

When the LED is on I think the %CO2% readings are much more common; I've only seen a few valid looking readings with the LED on.

In addition, the CO₂ reading is not updating much. For example it was stuck on 795 for quite a long time then suddenly jumped to 1383 and stuck on that. Log file attached.


Attached Files
.txt   mqtt-2016-11-16T14:28:04Z.log.txt (Size: 18.73 KB / Downloads: 2)
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)