WD200+ instant status not reporting

[Rupp]

So due to some other issues, I switched controllers to a zwavejs2mqtt implementation recently and it has the same issue there apparently. I raised an issue with them to see if they have any idea of how to deal with this too: https://github.com/zwave-js/zwavejs2mqtt/issues/1847

I did notice one new peculiarity... if I reinterview the switches, I can control them and they report state just fine via targetValue / currentValue... but as soon as I operate them MANUALLY, they begin only reporting state changes when operated manually, and stop reporting on zwave based state changes.

That's two controllers, and three different zwave implementations that can't make heads or tails of the HomeSeer implementation here, and its been quite some time since a firmware update. Any chance we can get an update?

I'd recommend running HS4 as it seems to work just fine

You will want to put in a support ticket if you want the HS devs to see this request as they do not frequent this message board.
https://dev.homeseer.com/servicedesk/customer/portal/2

[i8beef]

I see. Support ticket created. Will see what they say.

Unfortunately, I'm not a fan of HomeSeer's software, and frankly I'm losing faith in their hardware efforts at this point too... The appeal of a ZWave solution is standardization, and this isn't the first time some new fancy feature has had detrimental effects to "standard" features. I'm about to rip em all out and replace with something bog standard ZWave instead.

[Rupp]

I see. Support ticket created. Will see what they say.

Unfortunately, I'm not a fan of HomeSeer's software, and frankly I'm losing faith in their hardware efforts at this point too... The appeal of a ZWave solution is standardization, and this isn't the first time some new fancy feature has had detrimental effects to "standard" features. I'm about to rip em all out and replace with something bog standard ZWave instead.

Yes, the devs are very busy and it may not be a priority so it could be a while before you hear back from them. I can assure you that there aren't many developers that have more experience with Z-Wave than Rich and Rick in the past was on the Z-Wave alliance board. If your that close to removing the switches you may as well try another brand.

[i8beef]

Well I wish I knew the zwave spec better to be able to debate with you, but all I have to go on is a number of issues I've tracked down to various OSS zwave implementations discussing this switch (and later WD100's apparently) and its non-standard implementation of S2 / Supervision causing this issue... when its just one implementation (zway), ok, maybe they're doing something wrong... when its three (openzwave, zwavejs, etc.) the evidence doesn't seem to really lend itself to the HomeSeer implementation being standard...

Im asking here in hopes others who have had this issue have found work arounds (it looks like a lot of the zwave stacks implement a "HomeSeer specific" hack to strip out Supervision as a supported feature post interview since it doesn't work right, and when ZWay had me hand edit the NIF and reinterview that did fix the issue, but Im not sure thats an option with all stacks).

Plus I don't really want to trash a $1000 worth of equipment or spend another weekend replacing and reintergrating 17 different switches if I have any other options. I spose its just my fault for trying to buy something a little more on the bleeding edge here.

[i8beef]

So I went and read the spec.

https://www.silabs.com/documents/log...cification.pdf

Section 3.7.5.1 gives examples, and states as such: A supporting node MUST return the Supervision status of solitary Set type commands for all its supported Command Classes.

If I understand the ZWay developers comments about what the switch is returning, whats happening is the ZWave stacks all see this switch saying "I support supervision, please encapsulate your MultiLevel Set in a supervision frame"... so they do. As per spec, the switch which advertises this is supposed to respond with 0xFF for success along with the associated Get response for the new level... but it isn't its responding with 0x00 which is "unsupported for this command class (MultiLevel set)".

My uneducated interpetation here is that is clearly out of spec... and its also interesting to note that the 200 FAN controllers respond to these commands CORRECTLY and work just fine.

The fix the various ZWave stacks are using is to REMOVE Supervision from the switch's reported supported command classes so that the ZWave stack doesn't attempt to use Supervision encapsulation, and falls back to the NORMAL MultiLevel Set command classes which work ok apparently... except in S2 security mode for some reason (meaning I think if I reinclude here WITHOUT S2 secure, it'll actually work with their hacks, as it did with my original ZWay install).

Ill put all this in my ticket for HomeSeer to hopefully get a fire lit for a firmware update, but will also try a non-secure inclusion for now as ZWaveJS DOES seem like its taken a few swings at fixing this by removing the Supervision command class from the interview NIF.

[i8beef]

3.7.2.2 has some interesting caveats to it though... partially because it seems to be written in broken English so maybe thats part of the disconnect.

It is OPTIONAL for a receiving node to return an answer to a Set type Command which requires a response to be returned if received with Supervision encapsulation.

Though considering the 200 Fan controllers return state here, and other switches return state here, etc.... it still seems wrong / odd...

[i8beef]

Update from support for anyone else that comes across this: HomeSeer will not be fixing this. These switches are indeed doing something incorrectly with Supervision, but as ZWaveJS has put in a work around for this, thus satisfying most HASS users, they don't seem to feel it is worth fixing anymore. They did however point out that they didn't think their new 300 level switches had this issue and that I should upgrade because "WD200's are now discontinued".

At this point the only reason I'm not ripping these out of the wall is sunk cost because the ZWaveJS devs and other open source zwave stacks are picking up HomeSeer's slack here... here's hoping they don't have to rollback those workarounds because it starts effecting other devices because it doesn't sound like we're likely to get any support from HomeSeer here unfortunately.