Announcement

Collapse
No announcement yet.

WD200+ instant status not reporting

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    WD200+ instant status not reporting

    I have three WD200+ that I just installed. They report instant status just fine on manual interaction.

    However, if I send commands via ZWave to them, they DO turn on and off ok, but don't report their state change back.

    My older WD100+'s all do this just fine, so did something change?

    #2
    This seems similar to a problem I reported on a long time ago. See first paragraph of: https://forums.homeseer.com/forum/ho...em#post1322547

    Also see: https://forums.homeseer.com/forum/ho...ng#post1278992

    My guess is that the Z-Wave standards are vague on this point.

    Comment


      #3
      What firmware are you running on the WD200? And what zwave pugin version?

      Comment


        #4
        Well, if I remember right the 5.19 switch firmware update for the WD100+ switches fixed something with the state reporting too... I don't remember if those had this weird issue before that too... my new WD200+ are on 5.14 which is the latest for these listed on the site for those switches... I can't recall the exact nature of that fix, just the pain of having to update the firmware on that many switches :-)

        But my WD100+'s all function as expected here... so Im wondering if Homeseer is again doing something non-standard with their state reporting on the new switches or something. I'd hate to have to rip these all back out and downgrade to some WD100's. The fan switches I put in here all report their state wonderfully too, and the fact that manual interaction with the switches report state good makes me think that something must have changed in the rules about when the switches report state. If that's the case, this seems like a bad choice given that any given multi-controller setup is going to need the instant status report in order to keep things in sync...

        So Im hoping there's some user error here.

        Comment


          #5
          Switch firmware version is 5.14. I am not running Homeseer software, I'm using ZWay as a controller at the moment.

          Comment


            #6
            This seems odd as I just got one and it is reporting fine. Have you optimize it?
            Mine is also using firmware 5.14. I have a z-net for controller.
            HS3PRO 3.0.0.500 as a Fire Daemon service, Windows 2016 Server Std Intel Core i5 PC HTPC Slim SFF 4GB, 120GB SSD drive, WLG800, RFXCom, TI103,NetCam, UltraNetcam3, BLBackup, CurrentCost 3P Rain8Net, MCsSprinker, HSTouch, Ademco Security plugin/AD2USB, JowiHue, various Oregon Scientific temp/humidity sensors, Z-Net, Zsmoke, Aeron Labs micro switches, Amazon Echo Dots, WS+, WD+ ... on and on.

            Comment


              #7
              Note: I haven't completed the "secure" inclusion, only a regular one (electrician took all the boxes with him before I realized I needed some pin number off em). Since manual manipulation causes instant state publishes, the actual association seems to be good, it just seems like it is specifically NOT publishing on direct zwave manipulation...

              It could certainly be a bug in the ZWay app when a secure inclusion is started but not finished (i.e., it skipped over some necessary steps that are supposed to happen after it? Possible...). I did optimize the network after installing everything as one of my first debug steps here, as well as upgrade everything I could. If these switches are SUPPOSED to work ok with this, I can check with their forum to see if there's a possibility around that here...

              Comment


                #8
                I went through and got a secure inclusion done, and still have the same issue.

                I also posted this to the ZWay forums with the logs. There is a suspicious entry there:

                [2020-07-14 15:12:31.986] [D] [zway] SETDATA devices.17.instances.0.commandClasses.108.data.3.status = 0 (0x00000000)
                ...
                [2020-07-14 15:12:31.989] [W] [zway] Node 17:0 CC Supervision: Setter was not supported by the recepient: SwitchMultilevel Set

                Apparently that is the issue, and from what they can see it looks like a mistake on the HomeSeer side... though I have nowhere near the context to explain that much more. Near as I can tell his temporary workaround is to override the interview NIF to exclude the Supervision command class, which seems to work for switches included non-S2 secure, but not secure included ones... Still looking to see if theres a workaround for that... but is there a non-standard implementation around the Supervision command class here?

                Comment


                  #9
                  I would recommend researching if the zwave protocol expects a status update from the switch when it's value is set via a zwave command. I'm pretty sure there is an acknowledgement the command was received. but I'm not sure the level is also communicated.
                  HS4 Pro on Shuttle NC10U, Win10; Z-NET
                  Number of Devices: 1005
                  Number of Events: 293

                  Plug-Ins: BLLock, DirecTv, EasyTrigger, Honeywell WiFi Thermostat, Marquis monoprice Amp, MeiHarmonyHub, PHLocation2, Pushover 3P, UltraM1G3, rnbWeather, Worx Landroid, Z-Wave

                  External applications: Homebridge-homeseer, Geofency, EgiGeoZone.

                  Comment


                    #10
                    I elevated to HomeSeer support here, and they claim this should be supported just fine. The fact I can remove the Supervision command from the NIF and force an interview and it works just fine makes it pretty clear there is something wrong either in HomeSeer's implementation of the Supervision stuff in the WD200+ firmware, or the ZWay devs have implemented their side wrong in assuming that supervision should override whatever other report is happening. I don't know which side is wrong yet, but ping-ponging between support on both sides with both pointing the finger at the other right now... :-/

                    Nearest I have right now is "command class Supervision Setter (or Status) is set to 0 instead of 255" but I have no idea what that means.

                    Comment


                      #11
                      Just for anyone else that comes across this, the WF-200+ fan controllers, which are also S2 secure and support Supervision, return the correct "255" value and report their state fine. That suggests that the WD-200+ actually is returning the wrong value in this case for that command class. At this point I'm working with support to try and get this information to their engineers to rectify in a future firmware update for those of us with controllers that support a wider set of the ZWave spec and are effected by this on the WD-200+ switches on 5.14.

                      Comment


                        #12
                        Has there been any progress on this? I'm finding this is a problem when these devices are used on Home Assistant both with the OpenZwave implementation and on the ZwaveJS implementation, which does indicate it to be a problem on the device side, not the application side. There hasn't been a new firmware out for these devices in about a year.

                        Comment


                          #13
                          I'm a newbie, for sure and am hoping to borrow on the knowledge of the gurus here. In order to program a dimmer or fan switch to show a status light, based on a condition (like a garage door open/closed) does one need to write 2 events...one for the "not ready" condition that puts the switch in status mode and one for the "secure" condition that puts the switch back in normal mode? I've looked all over you tube and there's stuff there's stuff that's either really rudimentary or really advanced. Nothing that seems to be right on target. thanks in advance for any help you can offer.

                          Comment


                            #14
                            Z-wave Supervision is broken on a number of HomeSeer devices. I posted a specific description of the problem here: https://forums.homeseer.com/forum/ho...upervision-bug and contacted HomeSeer support. But no answer.

                            Comment


                              #15
                              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?

                              Comment

                              Working...
                              X