I'm playing around with this 1-wire server driver which gets temperature and humidity readings. The server is LAN based.
The driver only gets sensor updates from the server when a refresh command (which results in a httpGet command sent to the driver) is done. So in order to get regular updates, a rule must be set up to do the refresh on a timed basis (which is not a big deal).
The server supports pushing data to clients, i.e., I can use the server's web UI to tell it to push data to a specified IP address every x seconds. The data pushed to the client is the same XML data returned as a result of the refresh command.
When these two options (poll and push) exist for a device, what's the determining factor(s) for which design is used to obtain data? Is one usually "better" than the other?
I don't think one is universally better than the other, so it depends on the use case. In most cases, I'd say "push" is better, both because then your driver doesn't do anything unless the device actually does something and because it gets you events the fastest, making them possibly more useful for automation. In some cases, this matters (e.g., contact or motion sensors, sometimes switches or dimmers, etc.). In other cases, likely including temperature and humidity, the "delay" inherent with polling is unlikely to matter as much.
The flip side I'd consider is how "chatty" the device is if left to push. With polling, you could possibly make that less frequent. (On the other hand, that could also make driver activity more frequent--depends on how often you poll compard to how often the device sends things on its own.) In general, the less driver activity, the better, but most of the time even this is a negligible concern.
4 Likes
Separate question. The pushing of data. Does this require websocket. If so, then, is there an overhead with keeping the socket open and waiting for data?
It probably depends on the approach used. The EcoWitt drivers just accept a push via http on port 39501, so there is no active connection.
1 Like
@sburke781 It was your Ecowitt driver that got me wondering about this. A month ago, I started using Ecowitt hardware and your driver for monitoring temp/humidity inside freezers. I am also playing with the OW-Server 1-wire hardware to monitor crawl space temp/humidity because I don't want to mess with changing batteries in the crawl space.
The 1-wire sensors have relays that will close when temp/humidity go "out of normal range". Those relays' states will be available to HE via some other path (e.g., detected by an Elk security panel zone which HE will see), so I don't need the sensor data on a frequent basis.
My preference is pushing data instead of polling for data.
I know it may depend on the hardware, but are poll and push likely to be mutually exclusive? For example...
Assume the server pushes data on an hourly basis. In between pushes, humidity gets too high and closes the relay, which ultimately drives an HE rule. Can that rule then drive a refresh command to do a httpGet to retrieve the current sensor data?
So do you get feedback from the relay to HE when it closes? I.e. that is not part of the hourly push, in your example?
@sburke781 The XML data returned contains a boolean representing the state of the relay. However, I haven't seen anything in the manufacturer's doc that suggests that an alarm and/or relay closure will result in an immediate push to the client. That's the reason for my previous post question about a driver using a combined poll and push design.
I plan on contacting the manufacturer to find out if an alarm and/or relay closure will trigger an immediate push to the client, but haven't done so yet.
Looking back at @bertabcd1234 's original comment, and the fact that the push of date is unlikely driven off activity in the sensors, I don't think it would make a lot of difference in this case whether you have the data pushed or pulled. You could trial both, if only as an exercise in how to do it.
If you can get the relay status change via other means, I can't see why it couldn't trigger a poll of the sensor data.
@sburke781 to be honest, I'm looking at your Ecowitt drivers and the OW-Server drivers to figure out how to write a new OW-Server driver that uses push instead of polling. I've made a few minor changes to other drivers, but this is my first attempt at a "semi-new" one. I've got a lot of experience writing code, but none writing in an OO language like C++, Jave, or Groovy, so it's a challenge. I don't have any problems understanding the "procedural code", but getting comfortable with the OO aspects of the language is taking some time.
Question... where does your driver get the port number (39501) that it listens on? I searched both Ecowitt drivers and didn't find that port number. Any reason why it isn't a preference on the parent driver in case I want to listen on a different port, or want to have multiple gateways?
For anyone who's wondering, this document is new. 
You'll see the answer is "yes" to there being a reason, but this shouldn't really be a problem as long as each real-world device has its own "installed"/added device on your hub.
4 Likes
@bertabcd1234 Timing couldn't b better. I was reading the driver development doc today, read the Driver Overview, then the "Building a Z-Wave Driver", and was about to post a message asking if a "Building a LAN Driver" was on the todo list because the "Recommended Next" topic on this doc page...
https://docs2.hubitat.com/developer/driver/overview
...still shows the "Building a Zigbee Driver" as "coming soon", and I figured it would be done before a LAN Driver topic. Someone may want to change that.
As far as the port number... I just thought it was a little odd because both the Ecowitt Gateway and the OW-Server allow a port number to be assigned by the user. I will read the doc, but I still wonder what will happen if two devices (maybe completely different types of devices) are pushing data to the same HE port. I've written some TCP/IP client/server products, but that was about 20 years ago and I've long forgotten a lot of the details.
Thanks, both have been changed.
Afraid to put "new" on the LAN document since someone is unlikely to remember if/when to remove that... 
2 Likes
Most of the OOP parts of Groovy aren't even allowed in Hubitat Apps and Drivers. We can't make classes. There's no inheritance, implementations, etc.
Totally fine. That port takes whatever hits it and directs it to a device with a matching Device Network ID, based on the sending devices MAC address or IP.
So for a device with IP of 192.168.3.18 and MAC of 34:94:54:77:35:37, you can have a DNI of 192.168.3.18, C0A80312:769E, 349454773537 or C0A80312 on your device and you'll get the data arriving at port 39501 sent to the parse() method on that device.
