I’d like to request a feature related to IP devices. It’s the IP equivalent to “Instant Status” which is a well documented capability in ZWave devices. Lutron held the patent for Instant Status long a ago but since the patent expired expired all ZWave manufacturers support it in their functionality.
In a nutshell, Instant Status is a mechanism whereby a device that changes state locally (i.e. the flip of a light switch lever) creates an unsolicited inbound message to the controller (hub) to update the status in the controller to match the device. I don’t know the exact message type and flow but the concept is straight forward enough.
In thinking about this I have been asking for a polling feature whereby the controller will periodically poll the nodes to compare local state vs controller state and resolve any differences. That will work and is better than nothing but polling has two problems; a) the inherent lag between the action and the next scheduled poll, and b) the message clutter that occurs when dozens of devices are polling on short intervals.
My thinking is if you define a universal inbound message type, say "poll request from node xyz" then a device with a local switch (state) change could send this poll request inbound and then the regular polling mechanism could just initiate a poll right away instead of waiting for the next scheduled poll.
There are maybe other ways to do this, but if you were thinking of adding interval polling then adding a single new message type that controllers always look for, you could then just trigger the rest of the logic to synchronize device state via an on demand poll.
Instant Status is an important feature in ZWave because folks would like to use a device to trigger scenes/meshbots. If there is a lag in status update it seriously hampers the usefulness of the triggering of scenes.
Sounds like a potentially good idea. However the IP device would have to support the sending out these poll requests to the Ezlo controller.
If its a custom IP device? could you not just have it send in a HTTP request to change the state of its associated virtual IP device on the controller, when the IP device has had its state changed locally / by some other means.
I’m trying to work within the functionality of the IP Device framework. How would I configure the IP Device template (master) to receive an unsolicited message from the device (slave)? All of my template functions depict the EzloPlus as the master and the device the slave. All returned messages thus far are in response to a query initiated by EzloPlus (master).
If there is a way to set up receipt of an inbound request from the slave I’d like to know how. Since I have the control the software at the device side it fairly easy to change that.
My work to develop a general purpose WiFi IO Module forced me to learn more about the IP Device generator in EzloPlus.
Through that exercise I was able to implement all the functionality I needed to read status (temperature probes and switches) and control elements (relays) via the IP Device construct. I had to do a couple unorthodox things to read binary inputs back due to yet unimplemented functionality on the IP Device generator but regardless I was able to implement all the functionality I wanted.
In that exercise all of the status inputs like temperature probes and switch closures to ground are updated via polling. I mention above what some of the pitfalls of polling are. Polling is probably OK for temperature readings because they don’t change rapidly in most cases. Switch inputs are more concerning. Often the closure of a switch will trigger downstream functionality and/or notification. Now the polling lag can be a detriment.
Then I mention the instant status capability of ZWave. This is well documented and supported by Ezlo already albeit maybe buried in a third party ZWave stack. Regardless, Instant Status is considered an important feature to most HA folks. I’m sure if you research the topic on your own forum you’ll find many threads on Instant Status. It’s not new and it hasn’t gone away in need. A simple example is a hallway light switch. When you turn it on you might want to trigger a scene to turn on other lights, if there is a long polling lag then the effect is diminished, or maybe even intolerable.
So my note above is just an urging that you come up with a scheme to implement instant status. My suggestion, to keep it simple, is to further enhance the polling capability that is interval based (as you have done today) AND add demand based polling. The demand mechanism would be allow the IP Device to signal the controller it has a state change and asks the controller to read (i.e. poll it) immediately. Then all the back end processing of the polling mechanism stays in tact. All that is required is the IP Template needs to be able to filter for a new unsolicited inbound message type, and if received, trigger the next poll to happen ASAP. At the device end any state change made locally would trigger the device to send inbound this poll request message and that the controller would receive such a message from a slave device.
This all presumes there is no IP Device Instant Status standard for WiFi switches as is now the case in ZWave. I am not familiar with the standards side of things. If there is an instant status functionality defined for IP devices then my request is just implement it and publish how it operates in the IP Device generator.
Curious can you expand on this a bit further? How you got the IP devices to update their status in the Ezlo controller if they were not initially controlled / state was changed, by the controller ?
1- I’m curios about the instant status and doing my research. Actually I haven’t seen a zwave switch which does not send an instant broadcast to the controller whenever it changed status. Maybe I’m working with new models lately.
2- To trigger the controller we need a message coming from where ? I believe you are assuming the IP template plugin also listens to messages hence includes an http server as well, which is not.
So how and from where you want to trigger the polling mechanism ? Do you want the IP device to send a message ? Or do you want an internal device capability to manually trigger polling of the virtual device created on the firmware, which then will poll the IP device ?
Some older Z-Wave devices didn’t support instant status. For example I have some old Duwi light switches that don’t. I have to wait for the controller to poll them for their state to be updated. All newer Z-Wave devices support instant status updates now.
1- I’m curios about the instant status and doing my research. Actually I haven’t seen a zwave switch which does not send an instant broadcast to the controller whenever it changed status. Maybe I’m working with new models lately. >> As clearly stated the Lutron patent expired and now all ZWave devices support Instant Status. So EzloPlus supports instant status on the ZWave side of things already.
2- To trigger the controller we need a message coming from where ? I believe you are assuming the IP template plugin also listens to messages hence includes an http server as well, which is not. >> Not assuming that, this would require some new functionality. The IP device needs to be able to send in an unsolicited message and the controller needs to receive that and then act on it. This is quite different that the IP Device model you have today.
So how and from where you want to trigger the polling mechanism ? >> Polling is controlled by the master, it polls the slave. The master is EzloPlus the slave is the IP Device.
Do you want the IP device to send a message ? >> I merely was suggesting if the IP Device could send an unsolicited inbound “poll request” message, then the controller (ie. master, ie EzloPlus) could then do an immediate poll and refresh its status.
Or do you want an internal device capability to manually trigger polling of the virtual device created on the firmware, which then will poll the IP device ? >> I wouldn’t expect there to be any virtual devices here. I only had virtual devices in my prototype because it was a workaround to deal with the IP Device generator not having binary switch closure input capability implemented yet. I think we are confusing two things here.
I really encourage you to look at how Vera handled instant status. You own the code so at the very least you can understand the messaging that goes on when a slave device (i.e. a wall light switch) notifies Vera of a status change. Whether that is a poll request or some other scheme is a secondary point. The fact is Instant status devices, albeit ZWave based, can initiate an immediate synchronization with the controller and bypass the polling mechanism. Further the older Vera forums have all kinds of history here of the problem with polling and the excess ZWave traffic it created. No need to repeat yesterdays mistakes.
I already see a flaw with the polling scheme that is implemented with IP Devices today. Since each device sets up a separate poll and I have 4 temp probes and 2 switches as input devices that means 6 polls per cycle and at 12 seconds poll duration that is 30 messages a minute just for polling . If you had an instant status scheme then polling either wouldn’t be required or the poll interval could be stretched out in time. Again this is well traveled territory in ZWave.
It is still unclear on the origin of this unsolicited inbound “poll request” message
to send any message from “IP Device” to controller, you need to connect to the API of the controller and then call API functions. So if you are referring to this then we need to add a new API to the controller to allow re-polling the status of a device.
I drew a diagram to better present the flow
There has to be a receiver for a message to be sent. So I am asking where is this receiver you are talking about. Only receiver on hub is the local hub API for now. Thats why I am referring to that.
Yes I understand what you are saying and agree. Perhaps I can clarify.
The IP device Generator seems to work fine for the most part. There are a few quirks and some missing functionality but it does enough as is to be useful. I’d say it is 80% complete.
The IP Device generator is a master-slave concept. EzloPlus is the master and the IP device is the slave. All queries of the IP Device are initiated by the master. There is no ability of the slave to initiate communications with the master.
Adding a polling capability to the IP Device should be straight forward because it is within the Master-slave construct. The master can have an interval timer and every time that period elapses the master will initiate poll and the slave will respond. In fact you already have a polling scheme with input devices like temperature probes and binary input switches (although the binary inputs are missing some hooks). It would just be nice if output devices like relays and wall switches could be polled as well to detect a change of state done at the IP Device (the flip of a switch handle) and not done by the controller. Today EzloPlus presumes the last command it sent to the IP device is the present state and it doesn’t contemplate the notion of a local action changing that state. Ironically your ZWave implementation handles this seamlessly today.
So adding polling for output devices would be a nice addition to the IP Device generator. That said it isn’t perfect as I mentioned earlier and listed the issues. So the next step of refinement is to add instant status as you have today with Zwave devices. If you flip a ZWave switch locally there is some sort of handshaking going on, initiated by the device, to update the controller of the status. It isn’t polled it is demand driven since the Lutron patent expired and now all ZWave devices support instant status.
My thinking on the IP Device to initiate a poll was that if you were going to add polling for output devices anyway why not use that mechanism to synchronize the device on demand. Leverage what you already designed in.
So my thinking is as thus:
Imagine a variable called “time to next poll for device yy”, it is say in seconds.
Upon receiving this message EzloPlus goes to the time to next poll for device yy and sets it to zero.
Then the normal polling function kicks off and uses the functionality you already implemented.
So yes this presumes you can design in some sort of message handler inbound to EzloPlus that detects a pattern of the query string parses it to the device in question and then zeros out the time to poll counter.
I don’t know what native messaging is embedded in the EZlo architecture but I suspect you have most of it already.
Only part I asked was the 6th item actually
Because there needs to be a receiver/server which is listening the messages coming in to the hub.
We already have our FW API. You can use that API to request an update on the device status itself actually. Instead of requesting a poll, you can go and directly update the status of the power item.
Check this thread to see how you can directly use the http api Ezlo platform - How to use HTTP API commands aka Luup Requests
Best Home Automation shopping experience. Shop at Ezlo!
