+- vThings Forums (http://forum.vair-monitor.com)
+-- Forum: vThings (http://forum.vair-monitor.com/forumdisplay.php?fid=1)
+--- Forum: vAir Monitor (CO2, Dust, Tempereature, etc..) (http://forum.vair-monitor.com/forumdisplay.php?fid=2)
+--- Thread: Device sends %CO2% instead of the actual value (/showthread.php?tid=7)
RE: Device sends %CO2% instead of the actual value - admin - 01-03-2017
About LED staying magenta
This happens when the device restarts - usually - once it goes into deep sleep (between 1 minute and 5 minute) depending on the firmware version (latest is 5 min) the led turns off and does not turn on.
But with the new feature, that was restarting the device in the beginning, if there is problem with I2C - it may have interferred with it.
About the images - i am Really Sorry!
I made those photos a month ago, but somehow was too lazy to upload them to the forum
This is what you need to do - the idea is to drop 0.1-0.2 v from the 5+v comming to the 5V of the CO2 sensor
and the CAP fits nicely in the holes for the USB Male Plug - just take a look on the polarity - GND is the hole that is farther away from the Micro USB plug
And now that you open it - try to connect and disconnect all jumper wires. Up to now my assumption is that those connections are stable and would not cause such problems - but this will be only until the first problem with them pops up.
![[Image: cap.jpg]](https://s29.postimg.org/7s2cr9bn7/cap.jpg)
![[Image: diode.jpg]](https://s29.postimg.org/nrplojx2r/diode.jpg)
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-03-2017
I was away for New Year but left the device logging. Last night I wrote a little program to list the periods of time when there was a gap of more than 180 seconds between MQTT reports from the monitor. The pattern is pretty obvious: it stops from about 7 minutes before the hour until about a quarter past with occasionally a small glitch just after it comes back. Debug output also stops during that time though when I watched it stop at 10:53Z just now it continued to give output to the config utility so it's rather looking like a problem logging on to the WiFi or something. I'll also leave a ping -a going on it at the next opportunity.
Columns are date/time of last report before the gap, date/time of first report after the gap and length of the gap in seconds.
I'll update to the new firmware and start it all again then see what the lights do at 11:52Z today. I'll probably do the diode and capacitor tomorrow - let's change one thing at a time.
Code:
2016-12-31T01:53:42Z 2016-12-31T02:13:58Z 1216.0
2016-12-31T02:52:32Z 2016-12-31T03:15:03Z 1351.0
2016-12-31T03:53:38Z 2016-12-31T04:13:54Z 1216.0
2016-12-31T04:52:31Z 2016-12-31T05:15:02Z 1351.0
2016-12-31T05:36:29Z 2016-12-31T05:41:04Z 275.0
2016-12-31T05:53:55Z 2016-12-31T06:14:10Z 1215.0
2016-12-31T06:52:45Z 2016-12-31T07:15:18Z 1353.0
2016-12-31T07:53:49Z 2016-12-31T08:14:04Z 1215.0
2016-12-31T08:52:38Z 2016-12-31T09:15:09Z 1351.0
2016-12-31T09:53:40Z 2016-12-31T10:13:59Z 1219.0
2016-12-31T11:52:33Z 2016-12-31T12:15:05Z 1352.0
2016-12-31T12:17:14Z 2016-12-31T12:21:50Z 276.0
2016-12-31T12:53:59Z 2016-12-31T13:14:17Z 1218.0
2016-12-31T13:52:53Z 2016-12-31T14:13:11Z 1218.0
2016-12-31T14:53:53Z 2016-12-31T15:14:12Z 1219.0
2016-12-31T15:52:46Z 2016-12-31T16:15:17Z 1351.0
2016-12-31T16:53:51Z 2016-12-31T17:14:08Z 1217.0
2016-12-31T17:52:42Z 2016-12-31T18:15:13Z 1351.0
2016-12-31T18:53:49Z 2016-12-31T19:14:08Z 1219.0
2016-12-31T19:52:43Z 2016-12-31T20:15:14Z 1351.0
2016-12-31T20:53:49Z 2016-12-31T21:14:07Z 1218.0
2016-12-31T21:52:41Z 2016-12-31T22:15:16Z 1355.0
2016-12-31T22:53:48Z 2016-12-31T23:14:05Z 1217.0
2016-12-31T23:52:37Z 2017-01-01T00:15:08Z 1351.0
2017-01-01T00:53:41Z 2017-01-01T01:13:58Z 1217.0
2017-01-01T01:52:31Z 2017-01-01T02:15:01Z 1350.0
2017-01-01T02:53:34Z 2017-01-01T03:13:51Z 1217.0
2017-01-01T04:52:23Z 2017-01-01T05:14:53Z 1350.0
2017-01-01T05:53:24Z 2017-01-01T06:13:39Z 1215.0
2017-01-01T06:52:15Z 2017-01-01T07:14:50Z 1355.0
2017-01-01T07:53:23Z 2017-01-01T08:13:38Z 1215.0
2017-01-01T08:52:15Z 2017-01-01T09:14:49Z 1354.0
2017-01-01T09:53:24Z 2017-01-01T10:13:40Z 1216.0
2017-01-01T10:52:16Z 2017-01-01T11:14:51Z 1355.0
2017-01-01T11:53:23Z 2017-01-01T12:13:38Z 1215.0
2017-01-01T12:52:10Z 2017-01-01T13:14:43Z 1353.0
2017-01-01T13:53:17Z 2017-01-01T14:13:33Z 1216.0
2017-01-01T14:52:09Z 2017-01-01T15:14:42Z 1353.0
2017-01-01T15:53:13Z 2017-01-01T16:13:32Z 1219.0
2017-01-01T16:52:06Z 2017-01-01T17:14:36Z 1350.0
2017-01-01T17:53:10Z 2017-01-01T18:13:27Z 1217.0
2017-01-01T19:52:02Z 2017-01-01T20:14:35Z 1353.0
2017-01-01T20:53:11Z 2017-01-01T21:13:27Z 1216.0
2017-01-01T21:52:04Z 2017-01-01T22:14:32Z 1348.0
2017-01-01T22:53:03Z 2017-01-01T23:13:21Z 1218.0
2017-01-01T23:51:56Z 2017-01-02T00:14:28Z 1352.0
2017-01-02T00:53:06Z 2017-01-02T01:13:22Z 1216.0
2017-01-02T02:51:55Z 2017-01-02T03:14:25Z 1350.0
2017-01-02T03:52:55Z 2017-01-02T04:13:11Z 1216.0
2017-01-02T04:53:53Z 2017-01-02T05:14:07Z 1214.0
2017-01-02T05:52:40Z 2017-01-02T06:15:15Z 1355.0
2017-01-02T06:53:50Z 2017-01-02T07:14:09Z 1219.0
2017-01-02T07:52:46Z 2017-01-02T08:15:18Z 1352.0
2017-01-02T08:53:52Z 2017-01-02T09:14:11Z 1219.0
2017-01-02T09:52:43Z 2017-01-02T10:15:15Z 1352.0
2017-01-02T10:53:53Z 2017-01-02T11:14:10Z 1217.0
2017-01-02T11:52:43Z 2017-01-02T12:15:14Z 1351.0
2017-01-02T12:53:51Z 2017-01-02T13:14:10Z 1219.0
2017-01-02T13:52:42Z 2017-01-02T14:15:12Z 1350.0
2017-01-02T14:53:48Z 2017-01-02T15:14:07Z 1219.0
2017-01-02T15:52:44Z 2017-01-02T16:15:19Z 1355.0
2017-01-02T16:53:53Z 2017-01-02T17:14:09Z 1216.0
2017-01-02T17:52:41Z 2017-01-02T18:15:16Z 1355.0
2017-01-02T18:15:17Z 2017-01-02T18:19:53Z 276.0
2017-01-02T18:52:01Z 2017-01-02T19:14:36Z 1355.0
2017-01-02T19:53:12Z 2017-01-02T20:13:31Z 1219.0
2017-01-02T20:52:09Z 2017-01-02T21:14:45Z 1356.0
2017-01-02T21:53:19Z 2017-01-02T22:13:37Z 1218.0
2017-01-02T22:52:08Z 2017-01-02T23:14:41Z 1353.0
2017-01-02T23:53:15Z 2017-01-03T00:13:31Z 1216.0
2017-01-03T00:52:05Z 2017-01-03T01:14:37Z 1352.0
2017-01-03T01:53:13Z 2017-01-03T02:13:29Z 1216.0
2017-01-03T02:52:01Z 2017-01-03T03:14:33Z 1352.0
2017-01-03T03:53:07Z 2017-01-03T04:13:25Z 1218.0
2017-01-03T04:51:58Z 2017-01-03T05:14:31Z 1353.0
2017-01-03T06:52:58Z 2017-01-03T07:13:21Z 1223.0
2017-01-03T07:51:55Z 2017-01-03T08:14:29Z 1354.0
2017-01-03T08:53:09Z 2017-01-03T09:13:26Z 1217.0
2017-01-03T09:52:01Z 2017-01-03T10:14:31Z 1350.0Updated to vESPrino v1.16 build20170103.
So, of course, now it works through the turn of the hour: I missed the start of the expected gap but it just logged at 11:58:14Z then at 12:00:41Z.
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-03-2017
Just noting that at 14:23 it's now gone through a number of turns of the hour without missing any reports. The LED has been off all the time as far as I've noticed. I'll leave it on the USB hub it's on now (powered hub plugged into my laptop) for the afternoon then put it on the hub which originally was OK but saw problems the other day.
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-04-2017
It's looking good - I don't know what you changed exactly (more robust I²C handling?) but it seems to be working well.
As above, I ran it yesterday afternoon on the Staples hub plugged into my laptop (which previously had been fine). For the evening I put it in the kitchen (a bit further from the router) on the Hudl wall wart which was originally fine but had problems a week or so ago. Late evening I did a factory reset mostly to turn off the debug output. Overnight I put it back on the Staples hub but only running off its mains power supply, not plugged into the laptop, which previously had been a very flakey combination with %CO2%s and just stopping logging.
All went well with no non-numeric values (e.g., %CO2%) and no gaps of more than 180 seconds.
I'll continue testing but for the moment I'll hold off putting the diode or capacitor in.
RE: Device sends %CO2% instead of the actual value - admin - 01-04-2017
hmm this is not so good
))I rather expected the %CO2% and %TEMP% to return, but to have more logs
let's see further
there may be also some hardware issue that pops up from time to time, e.g. bad connections or so
RE: Device sends %CO2% instead of the actual value - joshi04 - 01-04-2017
I've update my two sensors now also to vESPrino v1.16 build20170103.
Let's see and I cross my fingers.
@ Ed, did you take any actions to limit the supply voltage by now for your application?
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-04-2017
@Joshio, no I haven't done anything to limit the supply voltage; e.g., haven't yet added the diode that Vladimir sent. I wanted to characterize the new firmware on the different supplies I use first before making further changes.
I left the testing on the Staples hub not plugged into my laptop as noted above for most of today. It was fine.
Early evening I put it on a Lidl power bank. That was also fine for a couple of hours (which surprised me) although some of the readings were a bit more than 2.5 minutes apart - I assume it was doing some retrying. About 19:30 I took the combination upstairs without deliberately replugging anything at which point it immediately started behaving erratically. E.g., the next pressure reading was 10 hPa higher when, going upstairs, I'd expect a slightly lower pressure. Further ones were all over the place (e.g. pressure 1731.86 but I didn't feel my ears popping).
After about 45 minutes when it obviously wasn't going to settle down I put it, still upstairs, on the Staples hub. It gave one sensible set of readings. After that it only gave temperatures. After a while I went and power cycled it (unplugged from hub, count to 10, plug it back in).
I've just opened the box up to see if there's a loose wire or anything. There isn't anything obvious.
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-04-2017
While in there I added the capacitor and diode. it's now working fine off the Staples powered hub not plugged into my laptop. I'll leave it logging overnight and see how that goes.
RE: Device sends %CO2% instead of the actual value - Ed Davies - 01-05-2017
Laptop hung around 08:20 but otherwise all seemed find overnight - no gaps or %CO2%s. A bit unsatisfying, really, not getting a decent conclusion here.
RE: Device sends %CO2% instead of the actual value - admin - 01-05-2017
(01-05-2017, 11:53 AM)Ed Davies Wrote: Laptop hung around 08:20 but otherwise all seemed find overnight - no gaps or %CO2%s. A bit unsatisfying, really, not getting a decent conclusion here.
Now i checked and in fact it seems like i didn't disable the feature that will not send %CO2% etc if they appear. So still in case the CO2 sensor does not report data - the device will abort sending.
What puzzles me a bit is that your prevoius configuration was
mqtt_msg_arr0=sophie/temperature:%TEMP%
mqtt_msg_arr1=sophie/humidity:%HUM%
mqtt_msg_arr2=sophie/co2:%CO2%
mqtt_msg_arr3=sophie/pressure:%PRES%
mqtt_msg_arr4=sophie/altitude:%ALT%
and my assumption is that it is impossible to have Temperrature w/o Humidty, as they come from the same sensor.
In case after you reset your device you didn't add humidity - this would explain why it was sending only Temperature yesterday. If the next data is the CO2 - and the sensor failed - then it would simply silently fail.
As for the Pressure giving some random values - i have no idea yet