Problem With Multiple ZWave Switches

I have two issues that appear related to the Zwave binding.

  • Platform information:
    • Hardware: Raspberry Pi 3, Openhabian v1.4-377(f5061f6)
    • Java Runtime Environment: Zulu Embedded
    • openHAB version: 20180310 Snapshot
    • ZWave Binding:
    • HomeSeer ZWave+ USB Stick

My entire config is in Paper-UI (I don’t edit config files, but I’m comfortable doing so if this is just a UI issue). Paper-UI Gives “ERROR: 500 - Internal Server Error” Updating Zwave Thing Properties. The error does not occur updating properties of other Things.

I’m not sure if this is related, but I also am having trouble communicating to either switch. This all started occurring within the past week after adding a 2nd HS-WD200+ HomeSeer Dimmer switch to my Zwave network. Prior to adding the 2nd zwave switch, I had the first switch working well (turning off at sunrise via Astro binding and on at sunset) via the experimental Rule Engine. I’ve looked in the Zwave logs and found what’s shown below? Is it normal to see 0 neighbours? Are the two switches too far apart (i.e., do they need to see one another or just the controller?). I’m a newbie to OH so any tips on troubleshooting would be appreciated. I’ve tried deleting/rediscovering the Zwave Things (i.e., the switches), deleting the Things + uninstall Zwave binding + hard reset of Zwave controller and both HS-WD200+ switches + rebooting RPi + reinstall Zwave binding + rediscovery. One of the switches always ends up Offline and the other won’t respond to commands in my rules.

Thanks in advance for any help you can offer.

I was able to successfully get both HomeSeer Zwave switches initialized and working properly. I changed Configuration->System->Item LInking->Simple Mode Off, reinitialized everything (hard reset controller, reset both switches), then discovered and configured one switch at-a-time. I then manually created/linked just the DImmer channel for both switches. My suspicion is that one of the other channels is what was causing the problem and these other channels were added more recently (which is why I didn’t have the problem when I initially connected the first switch). @chris - I have logs that may help determine the root cause if you’re interested. I notice there are two "Scene Number channels shown - could this be the issue?

However, the “ERROR: 500 - Internal Server Error” still occurs whenever I edit/save the properties of a Zwave thing in Paper UI (e.g., just updating the Location). Note that this error does NOT occur when creating/linking an Item in Paper UI.

Any ideas on how to fix that? I don’t see any errors in openhab.log when the 500 error occurs.

Are any of the properties underlined in Red when you Save? That is a subtle, but good indicator of the offending parameter.

Install Habmin and see if you get the same behavior.

Thanks for taking the time to offer your suggestion Tony. No, nothing is underlined in red (but I’ll remember this tip). Also, the issue occurs when trying to change the Name or Location only. I can change/save paramaters with no issues.

Thanks Scott. I actually tried updating the location with Habmin late last night and found that although it says the Thing was saved successfully, if I click on a different Thing and then click back on the zwave switch, the location was empty (it didn’t actually save the changes). If I change the location for a non-Zwave Thing, it saves successfully in Paper UI (no 500 error) and Habmin.

I saw your comment on this device regarding duplicate channels - I’ve removed the scene_activation channel. I don’t think that’s going to cause any issues though.

This might mean that the device requires some configuration to use the central scene class though…

Thanks @chris. Do you think the duplicate channel is what caused the issue I had when I allowed the automatic item creation/linking? I’m just trying to confirm whether it is a valid configuration to have the duplicate (I’m still learning the rules here).

I don’t think it would cause a problem, but I’m not 100 % sure. I’ve now removed the duplication from the database but it might be a day or two before I get the update into the binding.

Thanks @chris for your assistance and for your contributions to the community. I’m not sure if you saw my other post about the 500 Errors when saving changes to Name or Location for a ZWave Thing in Paper UI, but if you have any ideas on that, I’d appreciate your insight. Do you think that’s an issue with the binding or in Paper UI itself (updating parameters works and updating Name/Location for non-ZWave Things also works with no error).

I’m also getting a 500 Error when trying to save any configuration change to my HS-WS200+ in the paperui. Fields like location never save. Though it does seem to actually save things like the led status color. Glad I’m not the only one experiencing it. I’ve noticed that I can control the on and off of the switch from the openhab android app, but I’m not seeing any update of the state when physically pushing the buttons in the logs. Nor am I seeing any updates for scene changes with the multitaps. I’ve only got 1 switch. So the issue might be unrelated to you having multiple.

@chris HS-WS200+ also needs the duplicate channel removed. I know I can add them, but I’m guessing it requires the super user to remove ones that are already there. Or I’m just blind and didn’t see where to do it.

@sovapatr The problem also affects Habmin (it doesn’t show a 500 Error, but it fails to save location changes). Not having looked at the code (yet), it’s not clear to me whether the binding is responsible for the property update or some common code in OH2 is used regardless of the Thing type (I was thinking it was the binding since it only is affecting ZWave Things, but I’d like to know for sure). I was hoping @chris would weigh in when he gets a chance. I’m planning to peruse the code tonight to see what I can learn. As far as the log issue goes, are you looking in events.log? I see an event triggered when I turn off/on one of my HS-WD200+ lights locally:

2018-03-13 20:52:30.673 [vent.ItemStateChangedEvent] - OutsideLights_Dimmer changed from 45 to 0
2018-03-13 20:52:34.402 [vent.ItemStateChangedEvent] - OutsideLights_Dimmer changed from 0 to 45

I also see DEBUG messages (you have to set logging level to DEBUG for zwave to see them) when I did a double tap up on the switch:

2018-03-13 21:09:46.676 [DEBUG] [ve.internal.protocol.ZWaveController] - Event Listener org.openhab.binding.zwave.internal.protocol.initialization.ZWaveNodeInitStageAdvancer@12f9e82 already registered
2018-03-13 21:09:46.678 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 3: Incoming command class CENTRAL_SCENE
2018-03-13 21:09:46.680 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 3: Received CENTRAL_SCENE command V3
2018-03-13 21:09:46.682 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 3: Received scene 1 at key 3 [Single Press 2 times]
2018-03-13 21:09:46.684 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
2018-03-13 21:09:46.686 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-03-13 21:09:46.688 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Got a value event from Z-Wave network, endpoint = 0, command class = CENTRAL_SCENE, value = 1.3
2018-03-13 21:09:46.691 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 3: Updating channel state zwave:device:096834c4:node3:scene_number to 1.3 [DecimalType]

I set “log4j2.rootLogger.level = DEBUG” in /var/lib/openhab2/etc/org.ops4j.pax.logging.cfg so I would see debug messages from the OH2 Web server An excerpt from the logs with the problem bolded that leads to the 500 Internal Server Error is shown below. It appears related to the duplicate scene_number that I found in the database that @chris just removed. After this change is merged, I’ll upgrade to the latest snapshot and my guess is that it will correct the problem.

@chris - Rather than removing the one parameter, another option is to just create a unique name “activation_scene_number” for instance. I don’t need it, but perhaps someone else does. Perhaps it would be worth adding some code to check for duplicates (I noticed you have a TODO to check for duplicates in the binding source code, but perhaps it would be useful to check in the front-end interface to preclude saving an invalid entry.)

2018-03-13 22:48:33.431 [DEBUG] [y.internal.HttpServiceServletHandler] - handling request org.ops4j.pax.web.service.jetty.internal.HttpServiceRequestWrapper@25815b, org.ops4j.pax.web.service.jetty.internal.HttpServiceResponseWrapper@c0ba1a
2018-03-13 22:48:33.432 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - sendResponse info=null content=HeapByteBuffer@11c9d82[p=0,l=312,c=8192,r=312]={<<<{“error”:{“messag…cene_number”}}}>>>\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00…\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00} complete=true committing=true callback=Blocker@18fb010{null}
2018-03-13 22:48:33.435 [DEBUG] [org.eclipse.jetty.server.HttpChannel] - COMMIT for /rest/things/zwave:device:096834c4:node2 on HttpChannelOverHttp@1bab130{r=3,c=true,a=DISPATCHED,uri=//}
500 Internal Server Error HTTP/1.1
Content-Length: 312
Content-Type: application/json

I forget what the 500 error was caused by now, but it is almost certainly fixed in the development version.

It’s not that simple - you can’t just type in any name as the names are linked to channel names and these then need to be defined in a number of other places in the code. Ideally, this direct link needs to be more dynamic so we can have multiple channels with the same channel type, but generating unique channel IDs. This “just” needs some code in the database, but the unique id needs to be deterministic, which is not so simple. By this, I mean that each time the code generates the “unique” id, it much be the same id for the same channel. It needs to be able to cope with other channels being added, or the channel being deleted and re-added as people mess around with the database, and this makes it difficult to work out what to base this ID on.

For now, it’s easiest to simply remove the channel and avoid the conflict and I don’t see a downside with this other than the device will need to be configured (if needed) to use central scene class which is anyhow recommended for applications that involve a central gateway.

Makes sense - thanks for taking the time to explain and for your assistance in fixing the issue.