Thanks this looks really interesting, the Wifi thermometer is just the thing for around the house.
In terms of power consumption, how does the BME280 and SI7021 compare or are difference negligible?
Admittedly I’m not sure why I would want to measure pressure inside the house, but I may be missing a trick.
Power consumption for both sensors is the same - the actual sensor does not make any difference. In fact the main power consumer when powered via 5 V USB is the USB2Serial (ch340g) chip, which consumes ~12 mA and for some reason, does not go to sleep. It is possible to dedicate some USB cable to the device, carefully cut through the shielding and disconnect the green and white wires (D+/D-). Also some USB Power Banks (the one i have) do allow it to go to sleep. This way the energy consumption will drop to ~4 mAh (2 min send interval) or 2 mAh (4 min send interval) or 1 mAh (10 min interval).
Actually, due to the low power consumption, most USB Power banks would shut down after several minutes, so I added an option to keep alive the USB Power bank by short bursts of power consumption each minute (configurable), which also adds ~1-2 mAh
About the Pressure - well I offer choices Some people take one with pressure and several SI7021. In fact, in terms of accuracy - I tested 5 BME280, and they are ~ +/- 0.3 °C from each other, compared to the SI7021 which are < 0.1 °C from each other (but for some reason all BMEs measure ~0.5 °C more than the SI, so I added a temperature calibration option to add whatever calibration factor you like in the firmware)
Just a side remark, I am almost out of Si7021 sensors, and am expecting the next bunch to arrive within 1-2 weeks (ordered them ~3 weeks ago but it takes time)
That’s exactly what I want, a sensor which won’t over saturate; I want to use it to drive indoor lighting, and at a later date, curtains. Temp & Humidity are a bonus.
No problem, I can try another if need be - it’ll be easier (neater) to mount externally rather inside a window (which is influenced by curtains/blinds).
That’s interesting, I could power these by cabling back to a 12v feed I have internally and then stepping down to 5v for USB - which could be easy if I can mount externally.
I’ll place an order for one (maybe two) this week!
Thanks for the reply, I’d already ordered two Si7021 just in case
I think I’ll need to pickup some power banks, as the one we have is only 2800mAh, so with an average consumption of 10mAh it won’t last two weeks.
I’ll have a look for ones that allow to go to sleep.
Look forward to receiving them and integrating them with emoncms!
@Vladimir_Savchenko sent me a CO2 unit to test. Posting to Emoncms works great
Config is done via a ChromeApp which then communicates with the device via serial
By default (if ‘host’ is left blank) the Emoncms integration posts to Emoncms.org. See example below setting the ‘Host’ to post to a local emonPi Emoncms
I also tested MQTT wich also worked great. Posting data via MQTT is supported on the emonPi and would be my preferred way to post data to local emonPi Emoncms, as it’s easier to share the data between other services e.g openHAB. Using emon as the base-topic the MQTT messages are automatically converted to Emoncms inputs on the emonPi
Thanks @Vladimir_Savchenko received them the other week and got them feeding data back to emonhub perfectly!
I am having this exact issue with one of the power banks, but not sure where I can configure this, is it in the vThings - Device Configuration Tool?
All I can see in Settings is Update Interval, but I’ve no idea what point this power bank shuts down.
hmmm, you can try updating to the latest firmware (from the settings menu), but i belive i added this longer time ago
in general the device wakes up every 30 seconds by default, for 1-2 seconds and then goes to sleep.
you can try to increase the update interval to 30 seconds - then it will wake up for ~8 seconds, and see if this will keep the powerbank alive - then each time it wakes up, it will also send data
Hi.
I buy an v.air monitor with temperature, humidity and CO2 (CM1106), and I am trying to send the information to my EmonHub via MQTT.
I write in the vThings device configuration tool
emon/vthings/temp:%TEMP%
emon/vthings/co2:%CO2%
emon/vthings/hum:%HUM%
and when I tested only send the last line, (in this case Humidity).
It is necesary to add something like & or {} or “”
Providing there is no sensitive data, it would be nice to try and keep the info in the forum so that the thread is complete (doesn’t just jump from “I’ve got a problem” to “thanks it’s sorted”) then others can benefit from the support and we can also, all get some insight into how the device works and integrates with emoncms.
yeah… of course, just that there are some URLs and IPs in the log files, which might be considered private, this is why i mentioned the private message. Of course in any case i would post later some details, once the issue is resolved
hmm this is weird, seems like the MQTT sending complets w/o errors
if you try to send only temp or co2, does it succeed?
have you made sure that they are correctly configured in emocms?
And eventually test it standalone ?
maybe you can try also the log file, to see what arrives there
$ tail /var/log/emonhub/emonhub.log
in general this is the correct way of sending multiple values, and the fact that in the device log there is
MQTT Connected]
[Mqtt Dest: sending: to topic:emon/vthings1/temp, msg: 22.58]
[Mqtt Dest: sending: to topic:emon/vthings1/co2, msg: 564]
[Mqtt Dest: sending: to topic:emon/vthings1/hum, msg: 59.30]
[MQTT : 1346ms
means that they have been parsed and the messages sent
what is more weird, is that you are receiving the “hum” value, but not the others
If you are publishing to emoncms directly there will be no related info in emonhub.log as it is not part of the route and therefore unaware of that traffic.
That’s precisely why I suggested checking the published MQTT via the commandline, there is a known issue with the mqtt input to emoncms, If the Pi has not been rebooted, this behaviour is unsurprising, See the first link I posted, the issue is comprehensively documented and as yet unresolved.