Home-built sensor: which way to collect the data?

I’ve just homebuilt a wifi-connected temperature/humidity sensor, so now I have to decide what’s the best way to get the data to OH.

Is it better for OH to poll the sensor for its data, or for the sensor to send the data straight to OH via REST?

I could do it either way, and can see advantages/disadvantages with both - so I wondered what experienced opinion was? I’d love to hear what you think, and why.

It is always better to push the data. Latency is lower and the code is easier to write and handle. As a result, the system is more responsive and more efficient because it doesn’t have to implement polling logic. When one has a choice, always choose push over polling.

2 Likes

:100:

Pushing: let OH2 do the math of item calculation *)
Pulling: you could miss some important changes in between the intervals

*) of course: better yet, be sure to push on every (significant) changes.

PS: I can only pull my heating controller for sensor data, and it would be soooo much better, if I just got the Information on changes. So I pull every sensor (68 of it) every minute and only a bunch have different values. Next thing: If my boilers start, I only get those temperature spikes in intervals - real-time would be better, but then again, I had to further shorten the interval…

Thanks. I can understand that the sensor pushing the data makes sense from the OH side of things (and only pushing on changes is a good idea, too).

The biggest downside of doing it that way is that the sensor wouldn’t be ‘portable’ (as it would have the OH server details hardcoded to it). Am I likely to regret that at a later date?

What do you mean with that? You have a battery powered sensor and fear too fast battery drains? Then you should set your sensor’s logic to deep sleep for xx interval, wake up, collect the data and push the data to OH2, deep sleep again; instead of letting the wifi be connected and waiting for polls…
then again: use static IP or a long DHCP lease to further shorten the time (and energy) needed for reconnecting the Wifi. => or try to wire the sensor with power! :wink:

It doesn’t have to be tied to OH. Most home automation systems use MQTT for this purpose. Depending on what you built your sensors using there exist base level firmware like the ESPEasy for ESP8266 et al that let you configure things like server IP addresses and such through a web API. For something that is custom but still on wifi, you can either add in a way to configure it remotely to tell it where to push to and set other parameters. Or you can just live with the fact that you have to reflash the sensor if you ever change your MQTT broker or OH IP address or the like. This is not likely to occur very often.

Thomas makes a good point as well. Push can be better for the sensor too as it lets the device be much more energy effecient.

I was trying to avoid using MQTT as it’s not something I’m using currently.

A web interface for a bit of config-ing is a good idea, although I went into making these because it would be (cheap and) easy, and the list of possible features is expanding rapidly! I’ll have a look at ESPEasy, which i didn’t know about so thank you for that.

Thanks to you both for your input, you’ve given me a few useful things to add to my considerations.

If you use the ESP route, and if you use a module with more memory (D1, NodeMcu, etc) don’t forget to implement an OTA-based firmware update strategy. You’ll thank yourself later. I have a few ESPs mounted on the ceiling so updating their software through OTA is a must.