As you instructed, I download the almost latest SNAPSHOT #205. I still could not see my web GUI opearation can be directed to zwave binding, even though I open DEBUG switch for org.openhab.binding.zwave.
Moreover, I see you may be interested in openhab.log.
2016-03-25 17:10:01.081 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 1: Node found
2016-03-25 17:10:01.082 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 7: Node found
2016-03-25 17:10:01.082 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller using Controller API
2016-03-25 17:10:01.083 [INFO ] [age.SerialApiGetInitDataMessageClass] - ZWave Controller is Primary Controller
2016-03-25 17:10:01.083 [INFO ] [age.SerialApiGetInitDataMessageClass] - ------------Number of Nodes Found Registered to ZWave Controller------------
2016-03-25 17:10:01.083 [INFO ] [age.SerialApiGetInitDataMessageClass] - # Nodes = 2
2016-03-25 17:22:29.219 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 7: Timeout while sending message. Requeueing - 0 attempts left!
2016-03-25 17:22:29.219 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 7: Got an error while sending data. Resending message.
2016-03-25 17:22:29.237 [INFO ] [nitialization.ZWaveNodeStageAdvancer] - NODE 7: SECURITY_REPORT not supported, proceeding to next stage.
2016-03-25 17:12:21.825 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘Z_socket1’ received command ON
2016-03-25 17:12:21.827 [INFO ] [marthome.event.ItemStateChangedEvent] - Z_socket1 changed from OFF to ON
Hopefully you have some idea and shed some light on me?
Thank you very much.
I found a problem with Z Wave things. If the same thing (for e.g a fibaro wall plug with node id 23) is excluded and paired again with the Z Wave controller, and we get a new node id 24, Node id 23 is still shown as online.
Should’nt the old node id take a state other than online when it is paired again.
Hi Ramasamy,
Yes - you are right - I’ll take a look at why this didn’t show offline. This might be an issue where the zwave protocol layers don’t know about the device, so we don’t get any notifications to show the device isn’t there…
After updating OH today, I am unsuccessful getting binding to accept my things, it appears. Was there a change in configuration that I missed, or is this something to do with security?
14:58:08.059 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'beckasinen.things'
14:58:08.095 [INFO ] [smarthome.event.ThingAddedEvent ] - Thing 'zwave:serial_zstick:controller' has been added.
14:58:08.109 [WARN ] [mon.registry.AbstractManagedProvider] - Could not update element with key zwave:serial_zstick:controller in ManagedThingProvider, because it does not exists.
14:58:08.109 [WARN ] [.core.thing.binding.BaseThingHandler] - Error while applying configuration changes: 'IllegalStateException: Could not update thing zwave:serial_zstick:controller. Most likely because it is read-only.' - reverting configuration changes on thing 'zwave:serial_zstick:controller'.
14:58:08.110 [INFO ] [me.event.ThingStatusInfoChangedEvent] - 'zwave:serial_zstick:controller' changed from UNINITIALIZED to INITIALIZING
14:58:08.110 [ERROR] [ome.core.thing.internal.ThingManager] - Exception occured while initializing handler of thing 'zwave:serial_zstick:controller': java.lang.IllegalStateException: Could not update thing zwave:serial_zstick:controller. Most likely because it is read-only.
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: Could not update thing zwave:serial_zstick:controller. Most likely because it is read-only.
at java.util.concurrent.FutureTask.report(FutureTask.java:122)[:1.8.0_74]
at java.util.concurrent.FutureTask.get(FutureTask.java:206)[:1.8.0_74]
at org.eclipse.smarthome.core.common.SafeMethodCaller.callAsynchronous(SafeMethodCaller.java:179)[88:org.eclipse.smarthome.core:0.8.0.201603242116]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:72)[88:org.eclipse.smarthome.core:0.8.0.201603242116]
at org.eclipse.smarthome.core.common.SafeMethodCaller.call(SafeMethodCaller.java:56)[88:org.eclipse.smarthome.core:0.8.0.201603242116]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7.run(ThingManager.java:641)[94:org.eclipse.smarthome.core.thing:0.8.0.201603242116]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_74]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_74]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)[:1.8.0_74]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)[:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_74]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_74]
at java.lang.Thread.run(Thread.java:745)[:1.8.0_74]
Caused by: java.lang.IllegalStateException: Could not update thing zwave:serial_zstick:controller. Most likely because it is read-only.
at org.eclipse.smarthome.core.thing.internal.ThingManager$1.thingUpdated(ThingManager.java:227)[94:org.eclipse.smarthome.core.thing:0.8.0.201603242116]
at org.eclipse.smarthome.core.thing.binding.BaseThingHandler.updateConfiguration(BaseThingHandler.java:398)[94:org.eclipse.smarthome.core.thing:0.8.0.201603242116]
at org.openhab.binding.zwave.handler.ZWaveControllerHandler.initialize(ZWaveControllerHandler.java:108)[160:org.openhab.binding.zwave:2.0.0.201603260202]
at org.openhab.binding.zwave.handler.ZWaveSerialHandler.initialize(ZWaveSerialHandler.java:76)[160:org.openhab.binding.zwave:2.0.0.201603260202]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7$1.call(ThingManager.java:644)[94:org.eclipse.smarthome.core.thing:0.8.0.201603242116]
at org.eclipse.smarthome.core.thing.internal.ThingManager$7$1.call(ThingManager.java:1)[94:org.eclipse.smarthome.core.thing:0.8.0.201603242116]
at org.eclipse.smarthome.core.common.SafeMethodCaller$CallableWrapper.call(SafeMethodCaller.java:170)[88:org.eclipse.smarthome.core:0.8.0.201603242116]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_74]
I added some code to set some default configuration if it wasn’t already set. However, because you’re using a text file to configure the things, it throws an error . I guess if you try setting any configuration on these statically defined things, the same thing happens?
I’m not sure how best to handle this - I guess this stops the system working? To avoid this, I think you can set the network key in your text file…
Chris, I dont’ know much about the things file, how should it look like? zwave is totally absent after this error, so it would be nice to get this part working…
Here’s my simple things config: Bridge zwave:serial_zstick:controller "Z-Wave Serial Controller" [ port="/dev/ttyACM0" ]
OK, I tried adding that in various places in the things file, but could not get it to do any difference. I have tried to find some information about security in openhab 2/things file but without any success.
How do you perceive the future for this, i.e. are there any chances for my .things configuration to start working again, or is this non-security set-up not being part of the future?
If I let habmin create the bridge-thing, the binding starts up, but now of course my .items file are not working anymore.
My assumption, given it’s a configuration of the thing is the following (but it’s a guess) -:
Bridge zwave:serial_zstick:controller "Z-Wave Serial Controller" [ port="/dev/ttyACM0" security_networkkey="00 11 22 33 44 55 66 77 88 99 AA BB CC DD EE FF"]
It’s nothing to do with openhab 2 configuration - it’s a zwave security configuration…
@kai - any comments on how we should handle a case where the binding updates some configuration, and the thing is stored in the thing file? I can trap this exception and log the error, but I’m not sure that it’s something the binding should be concerned with and maybe it’s better if this is already handled like this in the updateConfiguration method?
Why not? they should work if you use the same thing name for the controller shouldn’t they?
I guess, if I knew how to change the thing name in habmin (is this possible?). Or do you mean that I do a search/replace in the item file, with the new controller name?
Tomorrows release will bring a new feature - the provision of a “pending” flag. This will print an orange “pending…” badge next to any configuration that has not been confirmed with the device. For mains powered devices, you may not notice the pending badge at all unless you update a number of configuration parameters at the same time - or it may flash up for a very short time…
For battery devices, it will linger around until the device wakes up - once the data has been written, and read back, the pending flag gets removed. You can see an example of this below…
This feature uses some new features in ESH, so you need to be running a version of OH2 from within the last day or so.
This feature is attached to configuration, associations, and a number of other configurations - if you spot any inconsistencies, please let me know…
One point to note is that if you restart OH while data is pending, then there will be a mismatch between the device and what you see in the GUI. I might add some sort of flag here as well - let’s see how it goes first…
The other main addition in the past day or two is to add interfaces for setting Door Lock configuration - including setting codes and timeouts.
my (second) Aeon ZW100 Multisensor now also shows I saw that device had a recent edit in the Db… mhh
10:49:01.690 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Size error 2<>1 from config_42_2
10:49:02.024 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@121bb36
10:49:02.039 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:device:15348538564:node9' has been updated.
10:49:02.723 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:device:15348538564:node9' has been updated.
10:49:02.737 [INFO ] [marthome.event.ConfigStatusInfoEvent] - org.eclipse.smarthome.config.core.status.events.ConfigStatusInfoEvent@848a24
10:49:02.880 [ERROR] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Size error 2<>1 from config_44_2
my Fibaro RGBW sometimes causes:
20:34:23.433 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing 'zwave:device:15348538564:node12' has been updated.
java.lang.ArrayIndexOutOfBoundsException: 1120:34:23.549 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2.
at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:337)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveMeterCommandClass.handleApplicationCommandRequest(ZWaveMeterCommandClass.java:136)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:118)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:240)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:207)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:201)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1072)
20:34:28.439 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 12: Timeout while sending message. Requeueing - 2 attempts left!
20:34:28.440 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 12: Got an error while sending data. Resending message.
java.lang.ArrayIndexOutOfBoundsException: 11
20:34:28.560 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2.
at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:337)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveMeterCommandClass.handleApplicationCommandRequest(ZWaveMeterCommandClass.java:136)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:118)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:240)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:207)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:201)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1072)
20:34:33.450 [ERROR] [ocol.ZWaveController$ZWaveSendThread] - NODE 12: Timeout while sending message. Requeueing - 1 attempts left!
20:34:33.451 [ERROR] [l.serialmessage.SendDataMessageClass] - NODE 12: Got an error while sending data. Resending message.
java.lang.ArrayIndexOutOfBoundsException: 11
20:34:33.568 [ERROR] [ve.internal.protocol.ZWaveController] - Exception during ZWave thread: Input 2.
at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:337)
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveMeterCommandClass.handleApplicationCommandRequest(ZWaveMeterCommandClass.java:136)
at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:118)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:240)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:207)
at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$6(ZWaveController.java:201)
at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveInputThread.run(ZWaveController.java:1072)
Well I guess it’s no surprise that it’s doing the same thing as the other… I guess this should be changed, but it would be really great if you can capture a debug log of this message so I can actually see the data…
This likely means that the device is sending corrupted data, which does happen occasionally. Again, a debug log of this would be very useful, although I am adding an exception into the code to better handle exactly this issue…
. I guess if you try setting any configuration on these statically defined things, the same thing happens?
to get this part working…
.
tested on a battery device