You can’t just switch back and forward between the master, and experimental bindings - it’s not possible. You have to delete everything and start again by adding all the things as it’s not compatible.
I did delete everything, I understand that. when I try to add the items back it throws that java error now.
Caused by: java.lang.IllegalArgumentException: Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!
at org.eclipse.smarthome.config.core.ConfigUtil.normalizeType(ConfigUtil.java:78)[98:org.eclipse.smarthome.config.core:0.9.0.201702100936]
at org.eclipse.smarthome.config.core.ConfigUtil.normalizeType(ConfigUtil.java:56)[98:org.eclipse.smarthome.config.core:0.9.0.201702100936]
at org.eclipse.smarthome.config.core.Configuration.setProperties(Configuration.java:184)[98:org.eclipse.smarthome.config.core:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateConfiguration(BaseThingHandler.java:475)[109:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
at org.eclipse.smarthome.core.thing.binding.ConfigStatusThingHandler.updateConfiguration(ConfigStatusThingHandler.java:65)[109:org.eclipse.smarthome.core.thing:0.9.0.201702100936]
you are correct, i noticed that my lights weren’t turning on and the error in the log:
17:29:28.714 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Command received zwave:device:3dfe58f3:node11:switch_dimmer --> ON
17:29:28.717 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 11: Command for unknown channel zwave:device:3dfe58f3:node11:switch_dimmer with OnOffType
made me think that the channel definition for my zwave devices changed like the Sonos had, so I deleted one of the ZW3003, GE 12724 In-Wall Dimmer Things and re-added it, now it’s status is:
Status: UNINITIALIZED - HANDLER_INITIALIZING_ERROR Invalid type ‘{org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSwitchAllCommandClass.SwitchAllMode}’ of configuration value!
So I updated this morning and now none of my zwave switches work, previously I had been using the Master binding from a few days ago, so the breaking change was recent.
Yep, in my trying to fix it I lost my entire network and proceeded into a apt-get purge openhab2!! So I’m going to try out homeassistant and may be back in a few days/weeks. Hopefully the devs figure out what they borked.
I seem to have messed up things in my setup and don’t really know why…
First a question about “feature:install openhab-transport-serial”, if I do and apt update, upgrade do I still have to do that?
If so is there a way I can avoid having to do so, like adding something to addons.cfg?
Secondly my switches/dimmers doesn’t react to any manipulation any more.
I do get warnings in my logs like:
18:49:27.645 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘node5_switch_dimmer’ received command 0
18:49:27.646 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate command ‘0’ for item ‘node5_switch_dimmer’ to handler for channel ‘zwave:device:158c530abd3:node5:switch_dimmer’, because no thing with the UID ‘zwave:device:158c530abd3:node5’ could be found.
18:49:27.647 [WARN ] [ome.core.thing.internal.ThingManager] - Cannot delegate update ‘0’ for item ‘node5_switch_dimmer’ to handler for channel ‘zwave:device:158c530abd3:node5:switch_dimmer’, because no thing with the UID ‘zwave:device:158c530abd3:node5’ could be found.
18:49:27.647 [INFO ] [marthome.event.ItemStateChangedEvent] - node5_switch_dimmer changed from 100 to 0
Anyone have a clue what has happend?
Thanks in advance
Tommy
Please see the link below. There was a change to the framework that exposed a config bug in the ZWave binding - the configuration of the SWITCH ALL class needs to be updated. I’m not sure if there are other issues yet, but as the binding hasn’t changed I’m trying to work this all out myself…
I saw some messages about updates and the unknown devices going away. I just pulled the latest snapshot JAR from the link, but I was not as lucky as the others. My Linear light bulbs are still not showing as a known device. I tried just seeing if the updated JAR would identify them. No luck, tried to re-initialize, nothing. Removed from the ZStick, re-added, and tried to discover again. No dice.
What are these devices- can you link to the database?
I just downloaded the snapshot from http://www.cd-jackson.com/downloads/openhab2/org.openhab.binding.zwave-2.1.0-SNAPSHOT.jar
and placed it in the addons folder, after removing the regular binding.
From my 33 Zwave devices, I got 20 up and running after some time. Remainder not yet, however most are battery operated devices.
However when I check the version in karaf I see:
237 | Active | 80 | 2.1.0.201702082223 | ZWave Binding
@chris Is this the latest snapshot, or is the above link no longer valid?
Other issue is that I cannot get the Network Viewer to display. If I click the link in Habmin it does not show. With previous 2.1.0 binding it did work. Do I need to upgrade more than only the binding ?
I think I found a more recent version here:
https://openhab.ci.cloudbees.com/job/openHAB2-Bundles/lastBuild/org.openhab.binding$org.openhab.binding.zwave/
After updating it shows current date as version, and my network view also works.
It is, but it’s not been updated with the latest changes yet. I’ll build a new version later.
This is the standard branch - not the test version with security.
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/8
I believe this is the right device. This time they didn’t get as far as last time where it actually had the details identified in the attributes section, but the 014F rings a bell, and that is the model of the bulb from my Amazon purchase. If it’s helpful I can try to dig thru some logs and see if the old log lines referencing the device when it did recognize the details but still listed as unknown device.
I’ll do a binding update of the test version this evening and then let’s take a look - just to make sure that there’s no hang-overs from the ESH update issues over the past day or three…
After that, if problems persist, then a debug log would be good.
The reason I wanted to change to the snapshot is to be able to use the network healing.
I don’t have any security enabled devices.
Is network heal now also included in the standard branch ?
No - only this branch as it relies on the updated transaction management. I’ll do an update of this branch this evening.
As an added update, here is a snippet of logs from a few days ago with the first download of the new security enabled binding. This discovery was able to fully identify the device (I believe) as seen from the log fully outlining the Thing type and matching to the DB entry provided above. But alas it still sat as an unknown device.
2017-02-07 22:43:18.285 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 24: Device discovery could not resolve to a thingType! 014F:4754:3038::5.8
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: ProtocolInfo
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Listening = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Routing = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Beaming = true
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Version = 4
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: FLIRS = false
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Security = false
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Max Baud = 40000
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Basic = BASIC_TYPE_ROUTING_SLAVE
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Generic = GENERIC_TYPE_SWITCH_MULTILEVEL
2017-02-07 22:43:29.067 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 24: Specific = SPECIFIC_TYPE_POWER_SWITCH_MULTILEVEL
I had the same issue with a Linear GD00Z garage door opener showing up as an Unknown Device. It’s:
http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/11
I downloaded the source and compiled my own to do some testing and found it had to do with the version check on the device. I noticed there was no min or max version in the database and that the device had no version. Not sure if it was correct, but I found if I modified ZWaveProduct to set versionMin and versionMax if they were null in the database, then the version checking code was skipped and it was matched. I can provide a patch if you would like. Now I just need to figure out how to make use of the Barrier command class.
I’m also looking into the Kwikset deadbolt ( http://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/283 )and figuring out how to detect lock/unlock using the Alarm command class. I have a hack that seems to work for me, but I’m sure isn’t the correct way of doing it. I can provide more information regarding what happens here if you would like.
Hope that helps,
I don’t quite understand this. I’ve got tests on this now and I just checked that with null for the version from the database, it should work ok as it sets the min/max to 0 and 255.255. Or, do you meant that this device actually doesn’t return a version, and this is what is causing the failure? That would be a bit strange as I think it’s mandatory, but then I’ve found a bunch of things that are meant to be “mandatory”, but devices are still certified 
Sure - I expect it’s similar to what I have here with the Yale where it’s sending alarms when state changes (I really don’t understand why they chose this strategy). I don’t think it is too hard to process this, but it’s not top of my list right now. What I’d suggest is to raise an issue on the issue list with your findings rather than discuss it here as it will likely get lost ;).
I wasn’t sure what was happening either. From looking at it, I agree the code should work. I got the following when I added in a debug line for the checks:
2017-02-10 12:02:33.506 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 26: Device discovery could not resolve to a thingType! 014F:4744:3030::0.0
and
2017-02-10 12:02:30.267 [DEBUG] [.binding.zwave.internal.ZWaveProduct] - Min Version didn’t match: 0.0.0 - 0.0.0
I think there is no version from the device. I don’t see a version an applicationVersion in the XML file for the Version command class for that device.
Thanks for all your work on this. 
I see comments in another thread saying it works ok -:
If there’s no version, then the node class will return 0.0 which should work fine (the test does actually test this case and it passes the test) -:
So, not so sure what’s up really, but it seems it should work ok. I’ll update this security branch later so it would be worth trying again with this.