search

OpenZWave / python-openzwave

Python wrapper for openzwave
Other
200 stars 141 forks source link

WD200+ still has major delay issues #186

Open iDVB opened 4 years ago

iDVB commented 4 years ago

I've been using WD200+ in HomeAssistant since shortly after they were released. Since that time there has been an ongoing issue with how OpenZwave handles post-request updates. This issue continues in the forums today https://community.home-assistant.io/t/z-wave-dimmer-switch-slow-to-respond-hs-wd200/53220

Would be amazing to have HA+OpenZWave support this device so that remote changes are instant and accurate. I've used this device with SmartThings hub/app and its ROCK solid... super instance feedback that is accurate. No idea why its not with HA/OpenZWave.

Is there anyone that might know what the issue might be?

Fishwaldo commented 4 years ago

It a weakness in the older versions of the Z-Wave Specifications where it was not clearly spelt out if a device should report the "instant" value, or final value when doing a Get. The fix(es) is : 1) to enable SetChangeVerified on the Level ValueID for this device. Unfortunately, I believe HA does not expose this despite me raising it several times with them (Z-Wave development in HA is non-existent unfortunately) 2) to Upgrade to Version 1.6 of OZW, and use a combination of "Level" and "Target" ValueID's to get both instant and final values.

iDVB commented 4 years ago

@Fishwaldo Thank you so much for taking the time. I'll admit that both options are a bit over my head. I am a fairly competent developer... but neither in hardware, nor python.

I've spoken to Homeseer a few times and they've been very helpful and willing to discuss this type of feedback. Is this something that a firmware update from them for the device might bring the handling of the specification up to norm and in-turn solve it for HA?

As a side question. would you know of a ZWave controller solution that does/might work well with WD200+?

Fishwaldo commented 4 years ago

It was a ambiguity in the specifications so you can’t say either way was “wrong”. In later versions of the CommandClass this has been addressed and OZW 1.6 supports the latest version there.

The problem is that HA is on a forked version of OZW and the Python Wrapper that is the old 1.4 version and there has yet to be any meaningful push from them to update. Until they either implement the ChangeVerified feature in 1.4 or upgrade to 1.6 your stuck unfortunately.

kdschlosser commented 4 years ago

we are working on the update right now. You can follow the chatter about it if you like. We felt it nice to use an instant messenger style application for communications then to use the forum style that is provided by GitHub. we are making really good progress I just finished hammering out multichannel/instances in python-openzwave along with associations and instance associations. The python-openzwave core seems to be really solid just working through some very minor glitches between openzwave and the python wrapper nothing major. There is an almost complete rewrite of the python code in python-openzwave this was done to improve performance and also to make it a little bit more application friendly.

This update includes all of the changes made to openzwave as well and also a whole new build system that is going to allow us to distribute wheels and eggs for debian (ubuntu, Raspbian ... etc) OSX, and Windows.

Part of the issue in performance you are seeing now is that HASS does take a while to react to notifications or events. This is because it is dealing with a whole mess of them all the time. and in the current python-openzwave the notifications from openzwave would run in the same thread all the way to HASS. and this gives the illusion of the ZWave lagging. when in fact openzwave may have already received the notification it is simply waiting for HASS to finish up doing what it's doing in order to kick out the next notification. This problem has been solved and we have provided an option the user will be able to select that will allow them to have a single notification queue for the entire network or have a queue for each node. the latter for a higher performance device running openzwave. (@Fishwaldo I have taken care of any dynamic data not being correct when allowing notifications to get processed in parallel)..

here is a link to that IM app.

https://join.slack.com/t/python-openzwave/shared_invite/enQtNzQyMzQ3MTM0MTQ1LWM0MDI5ZGRjMzQ2YjlhMzM2YzI2NjUxOGZlOTlmMjRjZTBiODQ1NTk5MjljNjIzMWVkODRhMWIzNzk2ODgyNDQ