Testing Z-Wave binding on openHAB-2

shorty707 · March 20, 2016, 11:00am

for the “item types” it seems ok to me.

for the options I wonder why
ON = ok
OFF = Alarm
shouldnt that be vice versa?

also for flood alarm OFF = Closed ? closed seems odd?

chris · March 20, 2016, 11:19am

Yes - I’ve just swapped them, thanks.

This is cut and paste error - it says flood and ok.

shorty707 · March 20, 2016, 11:28am

sorry another question about the fibaro flood sensor…

when I just “Tilt” the sensor (which is some kind of tamper alarm for fibaro)
also “sensor_flood” gets updated to ON… any way I can influence that?

For “Tilt only” and not “water” I would like to send “alarm_general” only.

Tilt only log:

12:25:12.205 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0D 00 04 10 10 07 9C 02 10 00 FF 00 00 80 
12:25:12.216 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
12:25:12.218 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0D 00 04 10 10 07 9C 02 10 00 FF 00 00 80 
12:25:12.219 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 10 10 07 9C 02 10 00 FF 00 00 80 
12:25:12.221 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, payload=10 10 07 9C 02 10 00 FF 00 00 
12:25:12.222 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 16: Application Command Request (ALIVE:DONE)
12:25:12.223 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 16: Incoming command class SENSOR_ALARM
12:25:12.224 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 16: Received Sensor Alarm Request
12:25:12.225 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 16: Alarm Report: Source=16, Type=General(0), Value=255
12:25:12.225 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmSensorValueEvent
12:25:12.226 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got an event from Z-Wave network: ZWaveAlarmSensorValueEvent
12:25:12.227 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 16: Got a value event from Z-Wave network, endpoint = 0, command class = SENSOR_ALARM, value = 255
12:25:12.227 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:15348538564:node16:alarm_general to ON
12:25:12.229 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:15348538564:node16:sensor_flood to ON

chris · March 20, 2016, 11:49am

It looks from the two logs that the device is sending exactly the same information for both conditions - if so, there’s no way to distinguish between the two conditions…

11:18:39.417 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 00 10 07 9C 02 10 00 FF 00 00 90 
12:25:12.219 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0D 00 04 10 10 07 9C 02 10 00 FF 00 00 80

shorty707 · March 20, 2016, 12:33pm

mhh I thought

flood thats the log when “watering” the sensor
11:18:40.200 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 16: Alarm Report: Source=16, Type=Flood(5), Value=255

tilt when only tilting it:
12:25:12.225 [DEBUG] [ndclass.ZWaveAlarmSensorCommandClass] - NODE 16: Alarm Report: Source=16, Type=General(0), Value=255

however both Types always result in updating both devices…
12:25:12.227 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:15348538564:node16:alarm_general to ON
12:25:12.229 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:device:15348538564:node16:sensor_flood to ON

chris · March 20, 2016, 12:36pm

Ok - you’re right. I just looked at the first alarm in the log that you said was a flood alarm - I didn’t realised you’d triggered both alarms in that log so missed the one further down.

feens · March 20, 2016, 10:19pm

My Doorbell sensor seems to no longer work since upgrading to the latest build (that required everything to be setup again). That node is showing up, but as unknown. Here’s a couple of log messages:

18:13:00.705 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:home:node14' to inbox.
18:13:00.706 [INFO ] [smarthome.event.InboxAddedEvent     ] - Discovery Result with UID 'zwave:device:home:node14' has been added.```

chris · March 20, 2016, 10:38pm

Maybe the device information isn’t being updated in the properties if you accept the device before it’s completed initialisation. I’d suggest to remove it, let it complete initialisation so that it has a name, and then add it.

I’ll take a look at this since this obviously should be handled…

feens · March 20, 2016, 11:22pm

Its showing this even after I remove it and it’s be rediscovered (sitting in the inbox). I’ve tried waking it up, but that doesn’t seem to make a difference. Any other suggestions?

chris · March 21, 2016, 6:43am

Please note that for the latest binding I made some changes to the channel definitions to hopefully fix an issue differentiating between different alarms etc.

This will likely mean that for devices that have channels with alarms, meters, set points etc, they will likely need to be deleted and re-added so they pick up the new definitions.

Chris

chris · March 21, 2016, 6:50am

If there’s nothing in the log showing the device waking, then I’m not sure… The update shouldn’t have affected it’s configuration - it was mainly how the thing type and name are handled which is outside of the protocol layers.

If it’s close enough to the controller that it is in direct communications (eg within let’s say 59 ft) and waking it doesn’t help then it might need to be re included (which would be strange). Otherwise make sure it’s close enough so that the controller can hear it directly…

Heiko_Fanieng · March 21, 2016, 10:51am

Dear @chris,

i have a problem, that i can’t save Configuration parameter 5 of my DSB05 4 in One MultiSensor. I can select “send sensor binary report”, click on save an have 2 times the entry in the log:

11:48:18.413 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:b172f74e:node2’ has been updated.
11:48:18.471 [INFO ] [smarthome.event.ThingUpdatedEvent ] - Thing ‘zwave:device:b172f74e:node2’ has been updated.

But i don’t works, checking the setup after the wake up time the entry ist lost in HABmin:

Could you please check whats going wrong?

Regards
Heiko

chris · March 21, 2016, 11:36am

Any chance of a debug log please ?

chris · March 21, 2016, 11:37am

@shorty707 please let me know if the latest binding correctly differentiates between flood and tilt (note that you’ll need to delete and add the thing in again to pick up the changed config).

feens · March 21, 2016, 12:02pm

Thanks. I managed to get it working again (finally). I ended up restarting OH, and then went right beside my controller and woke it up.

Heiko_Fanieng · March 21, 2016, 12:33pm

No problem Due my Fibaro FIB_FGMS-001 Multisensor lost their luminance with the latest snapshot i’ll setup from the scratch with only Z-Wave devices and log:set debug org.openhab.binding.zwave.

fuzzysb · March 21, 2016, 1:55pm

I have a number of Fibaro FGMS001 motion sensors, that with the latest binding show up as Unknown Devices the database shows these are complete am i missing something fundamental here?

smar · March 21, 2016, 1:59pm

I removed and then re-added the things for these, after which they were recognised properly.

fuzzysb · March 21, 2016, 2:01pm

the only complication here might be that my z-stick is a secondary controller for my zwave network, so i am not including/excluding from openhab

chris · March 21, 2016, 2:07pm

You shouldn’t need to include again, however if you are using a secondary controller, then you will need the device to be close enough to the controller that it can talk directly (ie not routed). You will then need to manually wake the device up as the wakeup class will presumably be configured to communicate with your other controller.