Testing Z-Wave binding on openHAB-2

mishakim · March 10, 2016, 6:58pm

I’ll look again when I get home, but I wasn’t seeing any controllers at all last night

chris · March 10, 2016, 7:00pm

The controller can’t really not be there - it’s called “Z-Wave Serial Controller”.

chris · March 10, 2016, 7:55pm

I’ve updated the binding to add support for scene classes (SCENE_ACTIVATION and CENTRAL_SCENE). These classes will provide a value provided by the device - so the linked item will need to be a number, and if you want to use it in a rule, then you need to act on any change to its value…

Currently I’ve just updated the database for two devices - the POPP WALL-C, and the Nodon controller.

Feedback welcome (which you can interpret as ‘essential’).

vespaman · March 10, 2016, 8:13pm

Chris will you be adding the zwave.me wall controller later?

chris · March 10, 2016, 8:16pm

Hi Brett,
I’ve updated your access so you can edit the database - it would be great if you can upload the file and make any necessary changes.

Thanks
Chris

chris · March 10, 2016, 8:21pm

I think it’s already added - it just needs the channel and command class adding. If you’re sure about the command classes that it needs (ie that it supports), then you can add this, and then add a single channel with the name ‘scene_number’.

vespaman · March 10, 2016, 8:34pm

Unless it has the same problem as my Everspring ST812 flood sensor, which refuses to show up as anything but unknown, I guess it is not in the last nightly?
Or are you talking about editing the database? (I never got access to do editing there)

Cheers,
Micael

chris · March 10, 2016, 8:44pm

This should be in the database…

Yes - I meant editing the database… I’ve given you access

vespaman · March 10, 2016, 8:50pm

Yes, it is the database, but you suggested that I might be seeing an issue that someone else also had seen, where known devices where not recognized properly. I emailed you a log some days back.
I have tried to create this node manually now, to see if it works. Automatically it will not work. I guess I will know tomorrow.

chris · March 10, 2016, 8:55pm

I don’t expect you can create this manually since it won’t have the information it needs (eg the node number).

mishakim · March 11, 2016, 2:02am

You’re right, I totally missed it. I even looked directly at the entry above it, as I have a slightly different model yale lock to try integrating soon.

In terms of usability, would it be possible to present just the serial controller first, since it has to be configured before any other device?

feens · March 11, 2016, 2:04am

I found this tricky as well when getting mine setup. There’s a big list of items and it’s hard to find the one item, which is pretty much a required item. What would be even more useful is if that “thing” was automatically “discovered”.

pnijsters · March 11, 2016, 2:16am

I’m using Aeon MultiSensor 6 in the US so they report scale=1 with temperature in Fahrenheit. However, OpenHAB2 keeps converting back to Celcius (as mentioned in the logs). I have tried configuring the channel multiple times; select Fahrenheit click save which results in a log message stating the Thing has been updated (Thing ‘zwave:aeon_zw100_00_000:c6398348:node7’ has been updated.) but temperature continues to be updated in Celcius…

2016-03-10 19:11:19.962 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 7: Application Command Request (ALIVE:DONE)
2016-03-10 19:11:19.962 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 7: Incoming command class SENSOR_MULTILEVEL
2016-03-10 19:11:19.962 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 7: Received Sensor Multi Level Request
2016-03-10 19:11:19.962 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 7: Sensor Multi Level REPORT received
2016-03-10 19:11:19.962 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 7: Sensor Type = Temperature(1), Scale = 1
2016-03-10 19:11:19.963 [DEBUG] [ss.ZWaveMultiLevelSensorCommandClass] - NODE 7: Sensor Value = 73
2016-03-10 19:11:19.963 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got an event from Z-Wave network: ZWaveMultiLevelSensorValueEvent
2016-03-10 19:11:19.963 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 7: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_MULTILEVEL, value = 73
2016-03-10 19:11:19.963 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 7: Sensor is reporting scale 1, requiring conversion to 0. Value is now 73.
2016-03-10 19:11:19.963 [DEBUG] [erter.ZWaveMultiLevelSensorConverter] - NODE 7: Sensor is reporting scale 1, requiring conversion to 0. Value is now 73.

bobmre · March 11, 2016, 3:51am

When I try to add a Battery Level Channel to a thing, I get the following error when trying to save: Error saving item Battery Level HTTP 404 Not Found.

chris · March 11, 2016, 4:52pm

Shortly all devices other than the controller will be removed from the list, so that should make it easier

chris · March 11, 2016, 4:54pm

That’s not really possible unfortunately since it would require scanning serial ports and writing stuff to ports to see if it gets a response. In the meantime, depending on what’s connected, it might screw up another device connected to a COM port by writing some data that this device objects to!

chris · March 11, 2016, 4:57pm

This is a known issue as it’s currently not possible to set the channel properties. The binding supports the conversion, but until this is fixed, there’s not much I can do - sorry.

github.com/eclipse-archived/smarthome

Channel configuration updates

opened 04:22PM - 28 Feb 16 UTC

closed 09:45AM - 22 Apr 16 UTC

cdjackson

I don't seem to be able to update channel configuration (although I'm sure this …worked recently). Below shows the PUT request -: ![image](https://cloud.githubusercontent.com/assets/1041475/13380216/8ff89a6e-de35-11e5-926a-7f44ed44268a.png) And this is the response -: ![image](https://cloud.githubusercontent.com/assets/1041475/13380218/a5a079ae-de35-11e5-9a56-14e11cac9ff2.png) This clearly shows the channel parameter request goes out with config_scale = 1, but returns with config_scale=0. The channel config is defined as follows -: ``` xml <config-description> <parameter name="config_scale" type="integer"> <label>Scale</label> <description>Select the scale for temperature readings</description> <default>0</default> <options> <option value="0">Celsius</option> <option value="1">Fahrenheit</option> </options> </parameter> </config-description> ``` To me, everything looks fine - the type is an int in all cases, the values look correct, but it's not updated. If I look in the update method ([ThingResourceL320](https://github.com/eclipse/smarthome/blob/master/bundles/io/org.eclipse.smarthome.io.rest.core/src/main/java/org/eclipse/smarthome/io/rest/core/thing/ThingResource.java#L320)) and follow through the code, it's unclear how this can update the channel configuration. It updates the label and the thing configuration, but not the channel configuration... Below is the relevant code -: ``` java // ask whether the Thing exists at all, 404 otherwise Thing thing = thingRegistry.get(thingUIDObject); if (null == thing) { logger.info("Received HTTP PUT request for update at '{}' for the unknown thing '{}'.", uriInfo.getPath(), thingUID); return getThingNotFoundResponse(thingUID); } // ask whether the Thing exists as a managed thing, so it can get updated, 409 otherwise Thing managed = managedThingProvider.get(thingUIDObject); if (null == managed) { logger.info("Received HTTP PUT request for update at '{}' for an unmanaged thing '{}'.", uriInfo.getPath(), thingUID); return getThingResponse(Status.CONFLICT, thing, locale, "Cannot update Thing " + thingUID + ". Maybe it is not managed."); } // only process if Thing is known to be managed, so it can get updated thing.setBridgeUID(bridgeUID); updateConfiguration(thing, getConfiguration(thingBean)); // Update the label thing.setLabel(thingBean.label); // update, returns null in case Thing cannot be found Thing oldthing = managedThingProvider.update(thing); if (null == oldthing) { return getThingNotFoundResponse(thingUID); } ``` As above, I thought this worked previously using the same calls, but maybe not, or maybe I'm doing something wrong?

chris · March 11, 2016, 5:18pm

This is a bug in HABmin. Type removing the ‘-’ from battery-level and it should work. I’ll add some code to remove this automatically…

feens · March 11, 2016, 5:19pm

Good point. I’d forgotten about setting the serial port. As you noted though, when you remove the other items I think the issue will be pretty mell mitigated.

shorty707 · March 11, 2016, 7:00pm

@chris … hope this is something you find essential?

Nodon return values

Button 1 (Filled Circle)
Single Click = 10
Double Click = 13
Long Click = 11

Button 2 (Plus)
Single Click = 20
Double Click = 23
Long Click = 21

Button 3 (Emtpy Circle)
Single Click = 30
Double Click = 33
Long Click = 31

Button 4 (Minus)
Single Click = 40
Double Click = 43
Long Click = 41

Example Log for Button1 Single Click = Scene activation node from node 13: Scene 10, Time 0

19:51:13.459 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0A 00 04 00 0D 04 2B 01 0A 00 D8 
19:51:13.462 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:51:13.464 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0A 00 04 00 0D 04 2B 01 0A 00 D8 
19:51:13.465 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0A 00 04 00 0D 04 2B 01 0A 00 D8 
19:51:13.466 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 0D 04 2B 01 0A 00 
19:51:13.467 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Application Command Request (ALIVE:DONE)
19:51:13.467 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Incoming command class SCENE_ACTIVATION
19:51:13.468 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Received Scene Activation for Node ID = 13
19:51:13.470 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Scene Activation Set
19:51:13.471 [DEBUG] [.commandclass.ZWaveBasicCommandClass] - Scene activation node from node 13: Scene 10, Time 0
19:51:13.481 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveCommandClassValueEvent
19:51:13.482 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=13, payload=0D 02 84 08 
19:51:13.483 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 0D 04 2B 01 0A 00 
19:51:13.484 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=false
19:51:13.781 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 08 00 04 00 0D 02 84 07 7F 
19:51:13.784 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:51:13.785 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 08 00 04 00 0D 02 84 07 7F 
19:51:13.786 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 08 00 04 00 0D 02 84 07 7F 
19:51:13.787 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 0D 02 84 07 
19:51:13.788 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Application Command Request (ALIVE:DONE)
19:51:13.788 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 13: Incoming command class WAKE_UP
19:51:13.789 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Received Wake Up Request
19:51:13.789 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Received WAKE_UP_NOTIFICATION
19:51:13.789 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Is awake with 0 messages in the wake-up queue.
19:51:13.790 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveWakeUpEvent
19:51:13.791 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=13, payload=0D 02 84 08 
19:51:13.792 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=00 0D 02 84 07 
19:51:13.792 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=ApplicationCommandHandler, expected=SendData, cancelled=true
19:51:14.790 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: No more messages, go back to sleep
19:51:14.791 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Creating new message for application command WAKE_UP_NO_MORE_INFORMATION
19:51:14.792 [DEBUG] [ve.internal.protocol.ZWaveController] - Message queued. Queue length = 1. Queue=[Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=13, payload=0D 02 84 08 ]
19:51:14.792 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - Took message from queue for sending. Queue length = 0
19:51:14.793 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 0D 02 84 08 25 60 23 
19:51:14.795 [DEBUG] [ing.zwave.handler.ZWaveSerialHandler] - NODE 13: Sending REQUEST Message = 01 09 00 13 0D 02 84 08 25 60 23 
19:51:14.811 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 04 01 13 01 E8 
19:51:14.814 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:51:14.817 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 04 01 13 01 E8 
19:51:14.820 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 04 01 13 01 E8 
19:51:14.821 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 07 00 13 60 00 00 02 89 
19:51:14.823 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Response[0x01], priority=High, dest=255, payload=01 
19:51:14.825 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: Sent Data successfully placed on stack.
19:51:14.827 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
19:51:14.828 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 13 60 00 00 02 00 00 87 
19:51:14.830 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 13 60 00 00 02 00 00 87 
19:51:14.831 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, payload=60 00 00 02 
19:51:14.833 [DEBUG] [l.serialmessage.SendDataMessageClass] - NODE 13: SendData Request. CallBack ID = 96, Status = Transmission complete and ACK received(0)
19:51:14.834 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Sent message Message: class=SendData[0x13], type=Request[0x00], priority=Immediate, dest=13, payload=0D 02 84 08 
19:51:14.836 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Recv message Message: class=SendData[0x13], type=Request[0x00], priority=High, dest=255, payload=60 00 00 02 
19:51:14.837 [DEBUG] [.serialmessage.ZWaveCommandProcessor] - Checking transaction complete: class=SendData, expected=SendData, cancelled=false
19:51:14.838 [DEBUG] [.serialmessage.ZWaveCommandProcessor] -          transaction complete!
19:51:14.839 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveTransactionCompletedEvent
19:51:14.840 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Went to sleep
19:51:14.841 [DEBUG] [commandclass.ZWaveWakeUpCommandClass] - NODE 13: Is sleeping
19:51:14.842 [DEBUG] [ocol.ZWaveController$ZWaveSendThread] - NODE 13: Response processed after 46ms/4892ms.