I'm not sure if there is a better place to raise this, but I assume HomeSeer is working on coding for a HS4 version of the Z-Wave plugin and wanted to raise a few issues with the current version that I'm hoping HomeSeer might be able to address in the HS4 version.
The purpose here is not to call for new features, but rather to address a few issues I've run into with current operation where there are a number of non-obvious "errata" that seem like they would be hard for new users to identify / diagnose. I'm not looking for scripts or other ways to address this in the the current plugin - I already have some solution, the goal here is call out problems where there are reasonable fixes that could be implemented so the end-user does not have to detect that a problem exist and then figure out a way to solve the problem - i.e., these are problems where the fixes should be "invisible" to the user.
They relate to the following subjects (which are detailed below):
I. Startup Device Synchronization
II. Confirmation of Commands / "Lost" Commands
I'm assuming that a number of the issues may exist due to limitations in the HS3 plugin API, but as HS4 is still unreleased, maybe there's an opportunity to influence it and the plugin API to improve the operations.
Here are my thoughts:
I. Startup Device Synchronization
If HomeSeer is shut down or the plugin is turned off, and the user makes changes to devices during that time (e.g., turns them on or off) HomeSeer's internal device status can get out of sync with the actual device state. As a result, until at least a first activation of the device, they can remain out of sync which results in errors in event conditions due to mistaken states. This is a particularly bad problem if the devices aren't set to automatic polling, in which case, this problem can persist.
What I would like to see is that, each time the plugin is restarted, it should do a full poll of all Z-wave devices and re-establish proper state.
I currently address this issue using a script that is run at startup to poll all Z-wave devices. However, I find relying on end-users to implement scripting is a poor solution for this issue as "beginners" may not know the problem exists and should not have to resort to scripting -- the HomeSeer application / plugin should be responsible for ensuring it maintains proper synchronization of device state.
II. Confirmation of Commands / "Lost" Commands
I've found that Z-Wave has a problem in that it can fail to command devices, particularly when a large number of devices is controlled in a burst. For example, if I try to turn on/off 50 dimmers, some may not execute the command. I'm assuming packets are getting lost on the network and aren't being re-transmitted. Most network protocols have a "Send", "Receive Acknowledgement", "Resend If Not Acknowledged" protocol that I assume this may be lacking in the Z-Wave plugin. It seems that the Z-Wave plugin should implement its own re-transmission protocol so it has better protection against failure of commands to execute. I propose something along the following lines be included int he protocol:
I would appreciate someone from HS respond with thoughts on these proposals. Maybe HS is already hard at work on these issues and has better solutions.
The purpose here is not to call for new features, but rather to address a few issues I've run into with current operation where there are a number of non-obvious "errata" that seem like they would be hard for new users to identify / diagnose. I'm not looking for scripts or other ways to address this in the the current plugin - I already have some solution, the goal here is call out problems where there are reasonable fixes that could be implemented so the end-user does not have to detect that a problem exist and then figure out a way to solve the problem - i.e., these are problems where the fixes should be "invisible" to the user.
They relate to the following subjects (which are detailed below):
I. Startup Device Synchronization
II. Confirmation of Commands / "Lost" Commands
I'm assuming that a number of the issues may exist due to limitations in the HS3 plugin API, but as HS4 is still unreleased, maybe there's an opportunity to influence it and the plugin API to improve the operations.
Here are my thoughts:
I. Startup Device Synchronization
If HomeSeer is shut down or the plugin is turned off, and the user makes changes to devices during that time (e.g., turns them on or off) HomeSeer's internal device status can get out of sync with the actual device state. As a result, until at least a first activation of the device, they can remain out of sync which results in errors in event conditions due to mistaken states. This is a particularly bad problem if the devices aren't set to automatic polling, in which case, this problem can persist.
What I would like to see is that, each time the plugin is restarted, it should do a full poll of all Z-wave devices and re-establish proper state.
I currently address this issue using a script that is run at startup to poll all Z-wave devices. However, I find relying on end-users to implement scripting is a poor solution for this issue as "beginners" may not know the problem exists and should not have to resort to scripting -- the HomeSeer application / plugin should be responsible for ensuring it maintains proper synchronization of device state.
II. Confirmation of Commands / "Lost" Commands
I've found that Z-Wave has a problem in that it can fail to command devices, particularly when a large number of devices is controlled in a burst. For example, if I try to turn on/off 50 dimmers, some may not execute the command. I'm assuming packets are getting lost on the network and aren't being re-transmitted. Most network protocols have a "Send", "Receive Acknowledgement", "Resend If Not Acknowledged" protocol that I assume this may be lacking in the Z-Wave plugin. It seems that the Z-Wave plugin should implement its own re-transmission protocol so it has better protection against failure of commands to execute. I propose something along the following lines be included int he protocol:
- The plugin should maintain a table of Device, Command Sent, Send Time, Number of Tries
- When a command is sent, a row is added to the table identifying the device, command, when it was sent, and the number of retries
- I understand that most Z-Wave devices (or most Z-wave plus?) provide a response when a change of state occurs, so if a command is acknowledged - i.e., you receive back a conformation of a new value, the row described in #2 is removed from the table. If the plugin receives back a different value than was sent, it should still remove the row as some devices may respond to the command with a different result value - e.g., if you send the "last level" command 255 to a Z-Wave dimmer, you'll receive back the new level, e.g., "55".
- As I said in #3, I understand that "most" devices provide back a response. I think some older Z-wave devices may not. But the plugin should "know" whether a device does or not and this might be something the plugin could establish when the device is first added to the system - i.e., during the add/include procedure for a device, the plugin could send a command and check if it gets acknowledged and store this in its device database. If devices don't acknowledge their commands, then shortly after a command is sent the plugin should poll the device to determine if the value changed. Of course, for devices that already exist in a person's setup, this "determination of response" should be done for all devices during a first-time startup of the plugin having this feature.
- If an acknowledgement is not received after a period of time (2 seconds), a re-transmission is attempted and the plugin will increase the retries count for the device. If the number of retries has exceeded some amount, an error is generated.
- Maybe have a check-mark on a device's Z-Wave page allowing this to be turned on/off for a device and a box to set the transmission attempts allowed (Default would be to provide re-transmission service with 3 tries)
- A further enhancement would be to have a new Event trigger "Transmission failure" and set global variables identifying the device (e.g., Reference, Name, Location1, Location2, Failed Command / Value, Current Value, Retries, Time) which a user could then use in an Event to send a warning email or otherwise act on a device failure (e.g., send an email if a critical device has failed to respond)
I would appreciate someone from HS respond with thoughts on these proposals. Maybe HS is already hard at work on these issues and has better solutions.
Comment