Sorry, but what is “that error” that you’re referring to? I looked back up this thread to see if I could find what you meant, but can’t see anything.
Sorry about that:
I use zwave.things for all my devices. So when I need to add a new device I simply discover it find the channel and then add it to my zwave.things. In this case I added:
Thing zwave:rtc_ct100plus_00_000:controller:node57 "Node 57: CT100 - First Floor" (zwave:serial_zstick:controller) [ node_id=57, binding_pollperiod=600 ] {
Channels:
Type sensor_temperature : sensor_temperature [ config_scale=1 ]
Type thermostat_setpoint : thermostat_setpoint_cooling [ config_scale=1 ]
Type thermostat_setpoint : thermostat_setpoint_heating [ config_scale=1 ]
}
When I do I get:
2017-12-10 13:27:40.510 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'zwave.things'
2017-12-10 13:27:40.719 [ERROR] [.core.internal.folder.FolderObserver] - Error handling update of file '/etc/openhab2/things/zwave.things': Duplicate channels zwave:rtc_ct100plus_00_000:controller:node57:battery-level.
java.lang.IllegalArgumentException: Duplicate channels zwave:rtc_ct100plus_00_000:controller:node57:battery-level
at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:162) ~[?:?]
at org.eclipse.smarthome.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:138) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.builder.ThingBuilder.withChannels(ThingBuilder.java:82) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.ThingFactory.createThing(ThingFactory.java:102) ~[?:?]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandlerFactory.createThing(BaseThingHandlerFactory.java:279) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactory(GenericThingProvider.java:483) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.getThingFromThingHandlerFactories(GenericThingProvider.java:466) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThing(GenericThingProvider.java:395) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$20(GenericThingProvider.java:884) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThingsFromModelForThingHandlerFactory(GenericThingProvider.java:886) ~[?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.lambda$3(GenericThingProvider.java:299) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) [?:?]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.createThingsFromModel(GenericThingProvider.java:301) [151:org.eclipse.smarthome.model.thing:0.9.0.201712011551]
at org.eclipse.smarthome.model.thing.internal.GenericThingProvider.modelChanged(GenericThingProvider.java:715) [151:org.eclipse.smarthome.model.thing:0.9.0.201712011551]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.notifyListeners(ModelRepositoryImpl.java:314) [134:org.eclipse.smarthome.model.core:0.9.0.201712011551]
at org.eclipse.smarthome.model.core.internal.ModelRepositoryImpl.addOrRefreshModel(ModelRepositoryImpl.java:127) [134:org.eclipse.smarthome.model.core:0.9.0.201712011551]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.checkFile(FolderObserver.java:247) [134:org.eclipse.smarthome.model.core:0.9.0.201712011551]
at org.eclipse.smarthome.model.core.internal.folder.FolderObserver.processWatchEvent(FolderObserver.java:311) [134:org.eclipse.smarthome.model.core:0.9.0.201712011551]
at org.eclipse.smarthome.core.service.WatchQueueReader.run(WatchQueueReader.java:209) [109:org.eclipse.smarthome.core:0.9.0.201712011551]
at java.lang.Thread.run(Thread.java:748) [?:?]
Just to make sure I did not have it as a auto defined thing I did:
rm -f /var/lib/openhab2/jsondb/*.json
Probably in the thread you linked to in your previous post 
Yeah - sorry, I was scanning back up this thread looking for messages from @sipvoip and of course that message was from me .
It looks like the database entry for this device has duplicated endpoint 0 and endpoint 1. I’ll delete the battery channel from endpoint 1 and it should sort this out. It looks like the database for the device could probably do with some TLC to remove some of the duplication, although it shouldn’t be a major issue for the most part.
You rock!
So I’ve been restarting the service a bunch of times and keep seeing different behavior. There seems to be a startup issue. I sometimes see the “polling started” debug, but not for all of my linked channels.
183:2017-12-10 20:20:31.806 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Channel zwave:device:93af1255:node45:meter_reset unlinked - polling stopped.
184:2017-12-10 20:20:31.820 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Channel zwave:device:93af1255:node41:time_offset unlinked - polling stopped.
185:2017-12-10 20:20:31.823 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Channel zwave:device:93af1255:node12:meter_reset unlinked - polling stopped.
186:2017-12-10 20:20:31.827 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Channel zwave:device:93af1255:node33:time_offset unlinked - polling stopped.
187:2017-12-10 20:20:31.826 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Channel zwave:device:93af1255:node78:alarm_general unlinked - polling stopped.
188:2017-12-10 20:20:31.828 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Channel zwave:device:93af1255:node78:notification_access_control unlinked - polling stopped.
189:2017-12-10 20:20:31.828 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 51: Channel zwave:device:93af1255:node51:time_offset unlinked - polling stopped.
190:2017-12-10 20:20:31.839 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 45: Channel zwave:device:93af1255:node45:meter_reset linked - polling started.
191:2017-12-10 20:20:31.840 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 41: Channel zwave:device:93af1255:node41:time_offset linked - polling started.
192:2017-12-10 20:20:31.843 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 12: Channel zwave:device:93af1255:node12:meter_reset linked - polling started.
193:2017-12-10 20:20:31.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Channel zwave:device:93af1255:node78:alarm_general linked - polling started.
194:2017-12-10 20:20:31.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 33: Channel zwave:device:93af1255:node33:time_offset linked - polling started.
195:2017-12-10 20:20:31.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Channel zwave:device:93af1255:node32:meter_reset linked - polling started.
196:2017-12-10 20:20:31.847 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 78: Channel zwave:device:93af1255:node78:notification_access_control linked - polling started.
197:2017-12-10 20:20:31.847 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Channel zwave:device:93af1255:node27:meter_reset linked - polling started.
198:2017-12-10 20:20:31.847 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Channel zwave:device:93af1255:node44:meter_reset linked - polling started.
199:2017-12-10 20:20:31.828 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 27: Channel zwave:device:93af1255:node27:meter_reset unlinked - polling stopped.
200:2017-12-10 20:20:31.829 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 44: Channel zwave:device:93af1255:node44:meter_reset unlinked - polling stopped.
201:2017-12-10 20:20:31.828 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 32: Channel zwave:device:93af1255:node32:meter_reset unlinked - polling stopped.
202:2017-12-10 20:20:31.846 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 51: Channel zwave:device:93af1255:node51:time_offset linked - polling started.
Workaround appears to be restarting zwave binding via karaf.
@dan12345, for me the Fibaro Universal sensor suddenly started working after I gave a test drive for hass.io.
E.g. all the same hw - with FGBS included to Aeon stick and attached to raspberry. Just inserted a fresh hass sd card with my wifi preconfigured … booted it up - it discovered the stick by itself and added all the nodes that where there … one of them was FGBS, which suddenly was correctly reporting both channels. Then I shut it down, put back my openhab card - w/out any other changes the FGBS kept working. I even put back a few weeks older binding jar and it still was OK. Still a mistery for me 
are you sure that’s the one with the new firmware? You can tell because the debug logs for the old one will show incoming command class COMMAND_CLASS_SENSOR_BINARY, but the new ones COMMAND_CLASS_BASIC.
Dan
I’m not sure about anything
at the beginning both are added, but, when the incoming message comes - looks to me that that it is the “class_basic”
2017-11-27 23:14:16.759 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
2017-11-27 23:14:16.770 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Creating new instance of command class COMMAND_CLASS_BASIC
2017-11-27 23:14:16.772 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Command class COMMAND_CLASS_BASIC, endpoint 0 created
2017-11-27 23:14:16.774 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
...
2017-11-27 23:14:26.570 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update request. Node information received. Transaction TID 1146: [WAIT_DATA] requiresResponse=true callback: 0
2017-11-27 23:14:26.570 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Creating new instance of command class COMMAND_CLASS_SENSOR_BINARY
2017-11-27 23:14:26.571 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Command class COMMAND_CLASS_SENSOR_BINARY, endpoint 0 created
2017-11-27 23:14:26.572 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update is adding command class COMMAND_CLASS_SENSOR_BINARY.
2017-11-27 23:14:26.573 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 15: Adding command class COMMAND_CLASS_SENSOR_BINARY to the list of supported command classes.
2017-11-27 23:14:26.574 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Creating new instance of command class COMMAND_CLASS_MULTI_CHANNEL
2017-11-27 23:14:26.575 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 15: Command class COMMAND_CLASS_MULTI_CHANNEL, endpoint 0 created
2017-11-27 23:14:26.575 [DEBUG] [essage.ApplicationUpdateMessageClass] - NODE 15: Application update is adding command class COMMAND_CLASS_MULTI_CHANNEL.
2017-11-27 23:14:58.366 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2017-11-27 23:14:58.368 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Got a value event from Z-Wave network, endpoint = 2, command class = COMMAND_CLASS_BASIC, value = 255
2017-11-27 23:14:58.370 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 15: Updating channel state zwave:device:zw:node15:sensor_binary2 to ON [OnOffType]
2017-11-27 23:14:58.380 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 15: Commands processed 1.
I’ll +1 on the Kwikset problem. I can’t get any of them to successfully join the network. (It aborted my attempt to switch from Homeseer to OH2 over the weekend, unfortunately.)
None of my Dome DMDP1 sensors were working, either. They actually even call out OH as compatible, so not sure what was up with those.
As far as I can see they arent in the database - unless they have a different name. Please feel free to add the device.
If/when I give the Z-wave interface another shot, I’ll look at doing that. The door locks are total blockers because the keypads are used to disarm the security system, so until I’m pretty confident they’ll work, its back-burnered. (I, somewhat unwisely, left the Z-wave testing for last because I assumed if all of my non-standard home automation gear worked – including writing a few bindings – the Z-wave would just work.)
Unfortunately because its replacing an existing HA system that needs to stay running, I need to do a complete cut-over, or parts of the house will be left not working. I may order another Z-wave stick to be able to do some testing at some point.
If you have a windows box, try using the Zensys tool as described here.
I do. Not sure if those would work with a non-Aeon controller, though. Regardless, the devices are all currently associated to the controller via Homeseer, and Homeseer (as they’re prone to doing) goes out of their way to obfuscate how they’re doing things, so I can’t share the security keys and move the stick to anything else. So I have to go around and re-associate the locks.I burned most of the weekend going from HS->OH2->HS. I don’t want to do it again. 
Right now I think I may just go the Z-Way route with a new Razberry in lieu of the Homeseer hardware, so the underlying Z-wave stack is fully certified. The latest posts on it make it sound like the binding is buggy and orphaned, but at least at that point it’d be debugging that binding’s interactions with Z-Way rather than the Z-wave binding and underlying Z-wave stuff I have no expertise in.
All controllers are fundamentally the same, and Zensys is not in any way related to Aeon, so it will be fine.
OK, good to know. I ordered a Razberry, as a way to do a staged migration of the network and have more flexibility with testing the OH environment while leaving critical bits on Homeseer until I know I can cut everything over. That’ll make it easier to test this – I can pull one of the locks that isn’t tied into any other events out and give it a shot, see if I can add it directly with the Z-wave binding. I’m a little concerned throwing another layer (Z-way) into the mix on there, as there’s already a shortage of memory, and one of the bindings I have installed seems to have a memory leak, so a bit more overhead on the system is a good thing.
The Homeseer zwave USB controller looks to be a rebranded Nortek/Linear/GoControl HUSBZ-2 (which is what they have for the product identifier). You shouldn’t need to exclude/reinclude your devices. Just put the stick into your server running OH. All the devices should work, except for the secure devices, which will need the key used in HS configured in OH. If the key can’t be found, then you would only need to exclude/reinclude your secure devices. But you should be able to move the stick back and forth between Homeseer and OH to switch back and forth while testing/migrating things. Sorry if you are completely aware of this… it just sounded like you spent a lot of time doing something that might not have been necessary, and hopefully you can save some headaches next time.
Also, if secure inclusion is failing for you, another option is OpenZwave (included in Domoticz, which is also open source).
Yeah, I knew that. It kinda/sorta worked – a bunch of devices didn’t show up (all of them the Dome sensors, I think).
The locks were purely the thing that tripped me up, and something about the process of doing it in OH2 screwed things up enough, it took a good bit of work to even get them to re-associate back with Homeseer. After I got them all working again, I think what happened was something triggered a partial network optimization, and a whole bunch of routes got lost, and the locks weren’t excluding properly, and thus weren’t re-including properly.
I ended up having HS do a full network rebuild (which took almost an hour!) After that I was able to re-associate the locks back with HS. It was the back-and-forth testing that was taking the time.
Its possible it might work if I de-associated all the secure devices first, then moved it to OH2, had OH2 optimize the network, and then tried re-adding them. But the process of “fixing” things if it doesn’t is too time consuming for me to screw around with again.
Replicating the security key doesn’t seem to help. I suspect HS is probably obfuscating the key or manipulating it in some way to keep from being able to go back-and-forth like that. (Either deliberately or accidentally, I can’t say – the software is a giant mess of horribly architected .NET code derived from a horrid VB base. So its hard to know what is deliberate vs just not done properly.) Given the problems with the way it does binary serialization, its possible its something stupid like an endian problem, but without decompiling the Zwave plugin and digging through the code, I have no idea. I just know a specific key set in there doesn’t interoperate with the same key set in OH.
Phew!
When I take my laptop to my locks, door openers, etc for secure inclusion, I always bring my laptop back to the office with the OH server and do some manual network healing before firing up OH again. Otherwise, I find the controller as a neighbor to nodes that it shouldn’t be. I’ve never seen this break my network, and it should resolve on it’s own, I just like to tidy up.
If you purchase a second stick, look into the HUSBZB-1. It is a combo zwave/zigbee controller (US frequency) and has worked well for me. Also, I’ve seen people report that the zwave security key is exposed in the log when using it to pair a secondary. I don’t remember, but I think this was how I got a key out of SmartThings. So, if you wanted to fiddle more with trying to get the key, you could try pairing another controller through Zensys Tools and you might be able to find it.
Back on topic… when you tried to do the secure inclusion in OH, are you sure you only had one zwave binding installed? bundle:list |grep -i zwave in the Karaf console
Just my 2 cents: I would prefer to see it in the master right now. Both versions have issues but the dev version already is very stable and offers full functionality. I use it for more than 8 months now with 3 controllers and 120+ devices.
I find it very hard at the moment that discussions in that forum alway need to circle around questions like “which version do you use”, “where can I download the dev binding”, “how can I install it” and so on.
@chris : I also assume that the parallel maintenance of several branches should be more work for you. If you can focus on one branch, the progress probably would be quicker?
And the moment for the “breaking” change is never good. If it is 2.2 or 2.3 it does not make any difference. And after all it is not that “breaking” to delete the Z-Wave things.
Just my thoughts…