jgreene
(Joe Greene)
May 26, 2018, 3:27am
1
Z-Wave Binding binding-zwave - 2.3.0.SNAPSHOT
OpenHab2 system:version 4.1.3
Nexia DB100z180-02278-07 REV G (rev 09)
Raspbian 8 (Jessie)
zwave_class_basic
ROUTING_SLAVE
zwave_class_generic
SENSOR_NOTIFICATION
zwave_frequent
false
zwave_neighbours
1,2,5,7,8
zwave_version
1.44
zwave_listening
false
zwave_plus_devicetype
POWER_MANAGEMENT_SENSOR
zwave_deviceid
12592
zwave_nodeid
10
zwave_routing
true
zwave_beaming
true
zwave_class_specific
NOTIFICATION_SENSOR
zwave_manufacturer
376
zwave_devicetype
17474
@chris Seems initialized, but only has a battery-level channel. Is this channel actually the sensor channel or is it just for the batteries powering the device?
I also keep seeing this periodically.
2018-05-25 22:33:10.592 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 10: Transaction not completed: node address inconsistent. lastSent=10, incoming=255
2018-05-25 22:33:20.095 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 06 06 31 05 01 22 00 CF 2F
2018-05-25 22:33:20.144 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
2018-05-25 22:33:20.175 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 0C 00 04 00 06 06 31 05 01 22 00 CF 2F
2018-05-25 22:33:20.206 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 0C 00 04 00 06 06 31 05 01 22 00 CF 2F
2018-05-25 22:33:20.237 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class=ApplicationCommandHandler[0x04], type=Request[0x00], priority=High, dest=255, callback=0, payload=00 06 06 31 05 01 22 00 CF
chris
(Chris Jackson)
May 26, 2018, 9:25am
2
Looking at the database, there should be a channel called Power Management Notification - this is an alarm channel, so I guess it is the doorbell?
The database could obviously do with improving for this device (for starters renaming the alarm if this is really the doorbell alarm). The manual attached to the database is also rather unhelpful.
jgreene
(Joe Greene)
May 26, 2018, 3:01pm
3
Ok weird I had to click see more in PaperUI to see the PowerManagementNotiffication channel
chris
(Chris Jackson)
May 26, 2018, 3:11pm
4
Maybe that’s a bug in PaperUI? There’s nothing in the way this channel is defined that should prevent it from being listed as a channel.
jgreene
(Joe Greene)
May 26, 2018, 3:17pm
5
I would be inclined to agree with that…
jmckenna
(James McKenna)
May 28, 2018, 11:40pm
6
Any luck with this device? I just set it up today and I am getting no updates on the alarm channel. In the log I see “channel notification_power_management is not implemented”:
2018-05-28 19:04:46.277 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 55 0A 71 05 00 00 00 FF 08 00 00 00 37
2018-05-28 19:04:46.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=85, callback=0, payload=00 55 0A 71 05 00 00 00 FF 08 00 00 00
2018-05-28 19:04:46.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage past lock Message: class=ApplicationCommandHandler[4], type=Request[0], dest=85, callback=0, payload=00 55 0A 71 05 00 00 00 FF 08 00 00 00
2018-05-28 19:04:46.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=85, callback=0, payload=00 55 0A 71 05 00 00 00 FF 08 00 00 00
2018-05-28 19:04:46.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-05-28 19:04:46.278 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 85: Application Command Request (ALIVE:DONE)
2018-05-28 19:04:46.278 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: resetResendCount initComplete=true isDead=false
2018-05-28 19:04:46.278 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: Incoming command class COMMAND_CLASS_ALARM, endpoint 0
2018-05-28 19:04:46.278 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 85: SECURITY not supported
2018-05-28 19:04:46.279 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 85: Received COMMAND_CLASS_ALARM V4 NOTIFICATION_REPORT
2018-05-28 19:04:46.279 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 85: NOTIFICATION report - 0 = 0, event=0, status=255, plen=0
2018-05-28 19:04:46.279 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 85: Alarm Type = POWER_MANAGEMENT (0)
2018-05-28 19:04:46.279 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
2018-05-28 19:04:46.279 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 85: Got an event from Z-Wave network: ZWaveAlarmValueEvent
2018-05-28 19:04:46.279 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 85: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_ALARM, value = 255
2018-05-28 19:04:46.279 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter processing NOTIFICATION
2018-05-28 19:04:46.279 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 0, type OnOffType
2018-05-28 19:04:46.279 [DEBUG] [ternal.converter.ZWaveAlarmConverter] - Alarm converter NOTIFICATION event is 0, channel notification_power_management is not implemented.
2018-05-28 19:04:46.279 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 85: Commands processed 1.
2018-05-28 19:04:46.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 85: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@768b28a3.
2018-05-28 19:04:46.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-05-28 19:04:46.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-05-28 19:04:46.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-05-28 19:04:46.280 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start
jmckenna
(James McKenna)
May 29, 2018, 1:24am
7
I updated the database so that channel type is now alarm_raw instead of notification_power_management. I made the change locally in my jsondb and then created a rule like @feens (Doorbell serial port trigger ). Things seem to be working now.
The one thing I don’t like about this sensor is that if you press the doorbell quickly, it doesn’t always pickup the event. That’s the fault of the device though.
feens
(Trevor)
August 9, 2019, 10:04pm
8
@jmckenna @chris how do you use the alarm_raw
item with my rule? The change to that broke things for me since updating OH and thus the Zwave binding.
sihui
(SiHui)
August 10, 2019, 6:00am
9
A quick forum search found:
Here is my current rule for parsing alarm_raw. My locks (Schlage BE469) do not update the lock_door channel, so I use alarm_raw to update the items linked to lock_door, and base rules off of that item’s state. Maybe all locks behave this way? You’ll find several examples of using the JSONPATH transform to parse the data in the lambda. This can be tricky though, because JSONPATH will throw an exception if the element name you are searching for does not exist in the JSON. I haven’t had any issues…
1 Like
chris
(Chris Jackson)
August 10, 2019, 8:51am
10
What change are you referring to? I’m not aware of any recent changes to the alarm_raw
channel.
feens
(Trevor)
August 10, 2019, 9:04am
11
@chris
@sihui that’s actually the place I started but couldn’t get it to work. There doesn’t seem to be much documentation on the Alarm types.
chris
(Chris Jackson)
August 10, 2019, 9:13am
12
Ok, that was 18 months ago
Most alarms are simple Contact or OnOff types so don’t really require much documentation to use. The alarm_raw
is a bit different in that it will dump information that comes from the device. This can change depending on the device, but it is provided as a simple JSON string that you would need to decode in the rule.
feens
(Trevor)
August 10, 2019, 9:27am
13
chris:
Ok, that was 18 months ago
Ya, I’m updating all of my OH setup now. Obviously that change is supposed to make the setup more obvious than using the power management type. Is it possible that I can still use the same rule and just switch the item name, or is there an easy way to see what the raw response I get back is?
chris
(Chris Jackson)
August 10, 2019, 9:35am
14
I’m not sure what the rule is, but I guess it’s using a channel that doesn’t exist, so probably not.
What channel are you using and how is it configured?
feens
(Trevor)
August 10, 2019, 9:43am
15
Sorry, the rule was linked to above by @jmckenna . I originally wrote it. Basically it just checked the power management status changing to ON. So now I somehow need to check if an event occurred but I’m not sure what to look for.
chris
(Chris Jackson)
August 10, 2019, 12:25pm
16
What is the channel type for your old channel?
feens
(Trevor)
August 10, 2019, 12:51pm
17
… something else I’m missing?
chris
(Chris Jackson)
August 10, 2019, 1:02pm
18
Sorry - I missed that as I’ve not read back through all this post looking for this bit of hidden information.
jmckenna
(James McKenna)
August 10, 2019, 1:18pm
19
I don’t think I actually made any changes to the database. Just locally. I see the database was updated today though. The Power Management Notification item links as a number. Here is an example rule:
rule "Doorbell received alarm"
when
Item Doorbell_Notify changed to 1
then
logInfo("outside", "Rule: Doorbell received alarm - {}", Doorbell_Notify)
createTimer(now.plusSeconds(15))[|
Doorbell_Notify.postUpdate(0)
]
end
sihui
(SiHui)
August 10, 2019, 1:23pm
20
I did just the Overview, Inclusion and Exclusion information.