Testing Z-Wave binding on openHAB-2

@chris I updated the Leviton DZR15 entry in the db (which I’m assuming you saw). Any chance of squeaking that into tonight’s build? …added a receptacle to my family room and would like to tie it in with my switch :slight_smile: …wasn’t thinking of the database when I got a different one than the rest of my receptacles (it was in stock at HD and saved me ordering online).

I’ve just reprocessed the complete database to fix an error exporting devices with SENSOR_ALARM class. This may be at least part of the problem people are seeing with some sensors (but probably not if there’s nothing logged in the log at all :sunglasses:).

The other thing I’ve done (hopefully correctly!) is to consolidate the Philio devices since as far as I understand, for most of the Philio devices, the -1A / -1B / etc bit on the end just relates to the region, and type of ply etc. So, from a database perspective, it doesn’t make sense to have this in there multiple times…

The change in the Philio devices might upset some configurations, so I’ll apologise now (sorry :wink:).

@feens - I just saw your message in time :slightly_smiling:

Chris

@chris trying to figure out how to get my Aeotec hidden door sensor to work. It worked fine in version 1.9 of the binding. It seems to use the BASIC command set to send the open/closed commands, but I’m not sure how to get items to do that in the new binding. I tried playing with the config options for sending or not sending the basic and binary commands, but it still doesn’t trigger the item. Thoughts?

@feens , This is a device I worked on. I have mine working quite well now, so give these settings a try (picture)

Also, make sure the association back to the controller exists. I should also mention though that this is the gen5 version. Is yours? I do not recall, and do not see which yours is with a quick look back.

where do you get that listing from?

same settings for mine … moving my hand: (incoming alarm? transaction not completed? :frowning: )

07:57:23.619 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 09 0A 71 05 00 00 00 FF 07 08 00 00 6C 
07:57:23.623 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
07:57:23.625 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 09 0A 71 05 00 00 00 FF 07 08 00 00 6C 
07:57:23.627 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 09 0A 71 05 00 00 00 FF 07 08 00 00 6C 
07:57:23.629 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 09 0A 71 05 00 00 00 FF 07 08 00 00 
07:57:23.630 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 9: Application Command Request (ALIVE:DONE)
07:57:23.632 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 9: Incoming command class ALARM
07:57:23.634 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 9: Received Alarm Request
07:57:23.635 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 9: Process Alarm Report, V3, length 13
07:57:23.636 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 9: Alarm report - 0 = 0, source=0, event=8, status=255
07:57:23.638 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 9: Alarm Type = General (0)
07:57:23.639 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
07:57:23.640 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Got an event from Z-Wave network: ZWaveAlarmValueEvent
07:57:23.642 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
07:57:23.643 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:alarm_general
07:57:23.645 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Processing event as channel zwave:aeon_zw100_00_000:15348538564:node9:alarm_general OnOffType
07:57:23.646 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:aeon_zw100_00_000:15348538564:node9:alarm_general to OFF
07:57:23.656 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:alarm_general
07:57:23.659 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Processing event as channel zwave:aeon_zw100_00_000:15348538564:node9:alarm_general OnOffType
07:57:23.668 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - Updating zwave:aeon_zw100_00_000:15348538564:node9:alarm_general to OFF
07:57:23.675 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_relhumidity
07:57:23.676 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_relhumidity
07:57:23.677 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_ultraviolet
07:57:23.677 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_ultraviolet
07:57:23.678 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_temperature
07:57:23.679 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_temperature
07:57:23.680 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_luminance
07:57:23.681 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_luminance
07:57:23.681 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_binary
07:57:23.683 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:sensor_binary
07:57:23.684 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:battery-level
07:57:23.685 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 9: Checking channel zwave:aeon_zw100_00_000:15348538564:node9:battery-level
07:57:23.686 [DEBUG] [ssage.ApplicationCommandMessageClass] - Transaction not completed: node address inconsistent.

My node 2 and 3 has like a vendor code in front (SW-ZCS-1 and AN157) but node 6 doesn’t.

I also found a typo in node 2, where Pdgin instead of Plug-in (like in Node6).

Any update on this? Version 2.0 won’t pass the WAF and as you can imagine, this is a MUST.

`

Yes, it does. In the case of the BeNext devices, the vendor code, as best as I can find in any of their documentation was plugindimmer. If you know where to find ‘proper’ codes, I’d prefer to change it, but I was unable to find any.

I think this must have been fixed already as it looks correct in the database. If you want to fix it in your system, you need to update the thing configuration.

Here’s maybe a basic question. But:- since yesterday, I have “lost” a couple of nodes. I think it happened when I run around the house adding a “new batch”. The one that I’m concentrating on now is node 24, a Fibaro Wall socket.
If I look in the log it says it is not initialized e.g.:

09:41:44.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Polling...
09:41:44.007 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 24: Polling deferred until initialisation complete

And when I push the button on the unit;

10:44:54.272 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 18 03 25 03 FF 30 
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
10:44:54.273 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 18 03 25 03 FF 30 
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 18 03 25 03 FF 30 
10:44:54.273 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 03 25 03 FF 
10:44:54.273 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message.
10:44:54.982 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2 
10:44:54.982 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
10:44:54.983 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2 
10:44:54.983 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 29 D2 
10:44:54.983 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 29 
10:44:54.983 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message.

There’s nothing else in the log, that relates to node 24.
I have at least two other nodes with similar behavior, where at least two of them used to work fine.
Restarting oh does not make any difference, and I update binding once a day. Openhab is about one or two days old by now.

This looks fine - it’s sending you and alarm and it looks like it’s updated the channel? Is that not correct?

No - sorry, I’ve not had a chance to look at this. I’ll take a look over the next few days.

Ummm - yes there is. I can see a message from Node 24, and a statement that it’s being ignored because the device isn’t yet initialised??

You don’t say what this node is, but it looks like it’s not completed initialisation. It therefore needs to be woken up. Maybe the wakeup class isn’t configured, in which case it will need to be manually woken up.

ok one question ahead:

bhuism above posted his log: he gets an update for: Incoming command class SENSOR_BINARY
I do get an update on the same sensor and motion: Incoming command class ALARM

also both parameters (binary, alarm) do not get an update either on basicui nor within habmin (ever):

Is this for exactly the same device? Maybe there’s a setting to change the command class being used (often there is) or maybe they have different firmware and the manufacturer has changed the way it works. Either way, the binding can’t change this - it needs to deal with whatever the device sends…

Maybe there’s a bug in the converter - I’ll take a look. From the log you posted above it looks like it should say ON…

?? There’s nothing else in the log except the part that I just presented.

You don’t say what this node is, but it looks like it’s not completed initialisation. It therefore needs to be woken up. Maybe the wakeup class isn’t configured, in which case it will need to be manually woken up.

I thought I wrote it, but more explicitly it is a FGWPE/F-101.
Apart from pressing the button, I have now also tried to unplug it. This gives similar messages;

11:23:11.840 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:11.841 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 00 FB 11:23:11.841 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 00 11:23:11.841 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:12.871 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.871 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:12.872 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.872 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 18 0A 32 02 21 44 00 00 10 DC 00 00 60 11:23:12.872 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 0A 32 02 21 44 00 00 10 DC 00 00 11:23:12.872 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:14.343 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:14.343 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 09 00 04 00 18 03 25 03 FF 30 11:23:14.343 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 03 25 03 FF 11:23:14.344 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:15.052 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:15.053 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 18 06 31 05 04 22 00 25 DE 11:23:15.053 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 18 06 31 05 04 22 00 25 11:23:15.053 [WARN ] [ssage.ApplicationCommandMessageClass] - NODE 24: Not initialized yet, ignoring message. 11:23:16.155 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD 11:23:16.155 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0 11:23:16.155 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD 11:23:16.155 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0E 00 04 00 24 08 32 02 21 12 00 07 00 00 DD

I guess maybe you are suggesting to simply reset the nodes that where caught in this limbo?

Sorry - I misread your message, you’re right…[quote=“vespaman, post:471, topic:7522”]
I guess maybe you are suggesting to simply reset the nodes that where caught in this limbo?
[/quote]

No - I’m just stating that it hasn’t finished initialisation and that’s why it’s not working. It should finish initialisation quite quickly if it’s a mains powered device, although I have seen here some devices sit in the WAIT state for a long time and I’ve not looked at this yet (maybe I should :wink:). It’s hard to say what’s happening with the device without seeing a longer log during the initialisation phase, but it might be the same issue.

Resetting the node is unlikely to help…

Hi again,

Now the meter is found correctly, but i only see channel for 2 phases. My meter has 3 clamps, can i add 1 to configuration, or does it need to be added in the template?

/Henrik

Just to confirm, this is for the DSB28 - correct?

You need to add it to the database so that the channels get updated correctly in the binding. Currently there are 3 endpoints in the database - the root, and 2 others. Do you know if the root (ie endpoint 0) is like a ‘total’ of the other 2? If so, then the route forward is to add another endpoint (3), and copy exactly the same as endpoint 1 and 2. The other thing we should do is to change the names. If we know that endpoint 0 is a ‘whole house’ or ‘total’, then we should make the names ‘Whole House Electric meter (watts)’, and for endpoint 1, ‘Clamp 1 Electric meter (watts)’ sort of thing. The names in there at the moment are auto generated from reading the XML…

If the above is correct, can you make the database update?

at the karaf shell prompt, type > items
You can get to the shell by running: runtime/karaf/bin/client