Inovelli Switches not updating

I have several LZW30-SN (red) switches, and this is how they appear in habmin. They all report local status correctly.

Are your LZW30 items setup in openhab as dimmers or switches? Your first post mentions “dimmers” but the LZW30 is a binary switch. That might explain why status isn’t updating correctly.

image

Gaa…I had the incorrect model listed (I have a different issue going on with a switch). These are LZW31 black dimmers and I edited my original entry.
The items are set up correctly as dimmers and I can send them commands and they respond. But they are not transmitting their state back to the z-wave controller when I change them locally

Yeah, those model numbers are easy to mix up. I often run into the same problem.

Here’s what my items file looks like for the LZW31-SN (red) dimmers. If you haven’t yet, you can try setting up the other channels to verify if status for those are being reported correctly (i.e. scene or effect. I think black series doesn’t report energy use).

Dimmer	    FamilyRoomLightsDimmer "Family Room Lights  [%d %%]"			            (FamilyRoom,gLights,gIntLights) {channel="zwave:device:057c652b:node15:switch_dimmer"}
Number		FamilyRoomLightsWatts "Family Room Lights Watts [%.1f W]"		        	(gEnergy)	                    {channel="zwave:device:057c652b:node15:meter_watts"}
Number		FamilyRoomLightsScene "Family Room Lights Scene"				        				                    {channel="zwave:device:057c652b:node15:scene_number"}
Number		FamilyRoomLightsEffect "Family Room Lights LED Effect"		            				                    {channel="zwave:device:057c652b:node15:config_decimal_param16"}

With the black dimmers, the only channel I have is the dimmer itself. But my item looks nearly identical (in terms of the channel).
I also have a LZW30 black switch installed, and it updates its status back to OpenHAB. I’m just having issues with the dimmers.

Really odd. Wish I could offer more simple answer.

The next step I can suggest is to turn on debug logging for the zwave binding and running the results through the log viewer on Chris’ website: https://www.cd-jackson.com/index.php/openhab/zwave-log-viewer

1 Like

When the documentation clearly says to turn on debug logging when things do not go as planned, why it that the last thing people try?
Only the system knows what it happening. Ask it.

When turning on the switch locally, the following is logged:

2020-06-17 20:23:43.235 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 1B 03 20 03 63 AA 
2020-06-17 20:23:43.236 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=27, callback=0, payload=00 1B 03 20 03 63 
2020-06-17 20:23:43.236 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=27, callback=0, payload=00 1B 03 20 03 63 
2020-06-17 20:23:43.237 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2020-06-17 20:23:43.237 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Application Command Request (ALIVE:DONE)
2020-06-17 20:23:43.237 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: resetResendCount initComplete=true isDead=false
2020-06-17 20:23:43.237 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2020-06-17 20:23:43.237 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: SECURITY NOT required on COMMAND_CLASS_BASIC
2020-06-17 20:23:43.237 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 27: Received COMMAND_CLASS_BASIC V1 BASIC_REPORT
2020-06-17 20:23:43.237 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 27: Basic report, value = 99
2020-06-17 20:23:43.237 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2020-06-17 20:23:43.237 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BASIC, value=99
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Commands processed 1.
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@28b3f6a1.
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-06-17 20:23:43.238 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

Turning off the switch locally yields the following:

2020-06-17 20:29:53.396 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 1B 03 20 03 00 C9 
2020-06-17 20:29:53.398 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=27, callback=0, payload=00 1B 03 20 03 00 
2020-06-17 20:29:53.398 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=27, callback=0, payload=00 1B 03 20 03 00 
2020-06-17 20:29:53.398 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2020-06-17 20:29:53.398 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Application Command Request (ALIVE:DONE)
2020-06-17 20:29:53.398 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: resetResendCount initComplete=true isDead=false
2020-06-17 20:29:53.398 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: Incoming command class COMMAND_CLASS_BASIC, endpoint 0
2020-06-17 20:29:53.398 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 27: SECURITY NOT required on COMMAND_CLASS_BASIC
2020-06-17 20:29:53.399 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 27: Received COMMAND_CLASS_BASIC V1 BASIC_REPORT
2020-06-17 20:29:53.399 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - NODE 27: Basic report, value = 0
2020-06-17 20:29:53.399 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2020-06-17 20:29:53.399 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_BASIC, value=0
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Commands processed 1.
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 27: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@1adee742.
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2020-06-17 20:29:53.399 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

I’m not savvy enough to interpret these…

Haha, neither am i.

It does seem everything is working correctly though. You’re getting a state report of 99 for ON and 0 for off, so at least you can rule out hardware.

Having said that, the next logical step would be to examine why the status isn’t being passed to your node channel. My best guess still comes back to the *.item file. Can you post a copy of that? What happens when you set it to a string item instead of dimmer?

Can you tell me what devices these are - ideally if you can provide the database reference for the devices it would be good. I’ll take a look to see if there’s an issue with the basic command class configuration in the database.

1 Like

Below are the two items. @chris the dbReference is 1171 (confirmed for both dimmers):

Dimmer Family_Room_W_Light "Family Room West Lights [%s]" <light> (gFamily_Room_Lights)          { channel="zwave:device:c57535c9:node27:switch_dimmer" }
Dimmer Family_Room_E_Light "Family Room East Lights [%s]" <light> (gFamily_Room_Lights)          { channel="zwave:device:c57535c9:node28:switch_dimmer" }

@roy_liao, what are the dbReference numbers for your switches? You have the Red, higher functioning switches where I’m using the Blacks. I wonder if there are differences in their commands?

Inovelli Red dimmers are db reference 1146

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1146

Looking at the entry for Inovelli Standard Dimmers (1171), it appears (to my untrained eye) the configuration is complete:
https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/1171

This device looks ok to me so I’m not sure why it wouldn’t have used the BASIC report that I see in the log for the dimmer item. You said you were running 2.5.5 - is this the first time you’ve included these devices or did you previously run an older version? It might pay to delete the thing and add it back to ensure that any changes are flowed into your system.

1 Like

Well, I tried deleting one of the things altogether and adding it back in. Removed it from the z-wave controller, deleted the thing, re-added. But still behaving the same way.

However, I then did a little more experimenting with the dimmers. If I just tap them to turn them completely on or off, they will not update in OH. If I dim the lights with the switch, to any percentage, they will update! It’s just a full-on or full-off (from any percentage) that does not update in OH.

It looks like for some reason the version of the device description that is in the binding is not the same as the database. I’ll update this later tonight, then you will need to remove the thing and add it back so that it picks up the new description. That should fix this for you.

2 Likes

They will need to update the binding too, correct?

Yes, sorry, that’s what I meant. I’ve already updated the database earlier today, and I will update the binding later tonight.

1 Like

Trying to find where the binding snapshot would be located; I’ve found reference to several locations but files seem old(er). What’s the correct link?

Update: I’ve found the github page, database update #1346. This is my first time making this sort of update; can I get a point to some directions on this? Thank you,

You can download the latest zwave binding from the OH build server:

https://ci.openhab.org/view/Integration%20Builds%20(2.5.x)/job/openHAB2.5.x-ZWave/lastSuccessfulBuild/artifact/target/org.openhab.binding.zwave-2.5.7-SNAPSHOT.jar

  • Once you have your new JAR file downloaded, copy the file to your addons folder where custom bindings go. The path will depend on your install, but typically this is /[openhab root]/addons
  • Login into karaf console on your openhab machine. Again, this will depend on your install, but the typical method is by running: ssh openhab@localhost -p 8101
  • In the Karaf console, verify the status of your zwave bindings by running: bundle:list | grep -i zwave
  • You will probably see two zwave bindings. Find the one that looks older and remove it by running: bundle:uninstall [ID number of the bundle you want to remove]
  • After removing duplicate bindings, it’s a good idea to restart your zwave binding with: bundle:restart [ID number of bundle you want to restart]
  • Last step optional. You can accomplish the same thing by restarting openhab.
1 Like

I usually use the upgrade script that handles that.
Zigbee and Z-Wave manual install script - Tutorials & Examples - openHAB Community

3 Likes

And that, as they say, is that! Works like a charm. Thanks everyone for the support!

3 Likes