I’m not sure I understand. The only bit that you can’t change is the channel definition. Items you can do what you want with - they are linked to a channel, but you give them your own name, category, groups etc… This is irrespective of how the item was generated - by this I mean if it was generated automatically by ESH, or manually through the UI - if you are using the static item files, then you need to edit it there of course.
A, I see now, for some reason the pull down with groups in the “Edit Item” popup) did not show groups which where defined (by me) in an .items file, but a hard F5 cleared that right up 
Happy to see one can easilly edit the generated items, almost no need anymore for manual item definitions
works like a charm 
I wonder why I did not experience this issue until I updated the C/F stuff. It must have been then that it was because those were the only items that were saved. That would imply that something changed recently with how the polling interval was set. @Chris, did you not save the value if it was empty previously perhaps?
This is what I am experiencing as well. Once it started throwing the exception, there was no recovery short of removing the thing.
I also wondered this, but unfortunately, all the history of the binding was ‘lost’ when I squashed everything and merged it into the master branch so I can’t now go back and look what it was like two days ago…
I think that I wasn’t reading the poll period in this part of the code until the past day or so - this is why when we first added the polling period option, all the polling occurred at 15 seconds. However, I don’t think there’s any way to confirm.
What I do know is the error on line 107 is where it reads the poll period and converts it to a BigInteger. The C/F stuff is all handled further down, and is handled as a String anyway since it needs to be processed in a different part of the binding (ie the command class converters) where different data types might be required.
@chris do you know how to manually add the config options when binding an item to a channel in a item file? I’m letting the zwave binding add all my zwave things automatically, but then manualing linking the thing to an a channel so to keep my existing item file (and rules, groups, ect) in place. So for example:
Dimmer Light_Great_Lights "Ceiling [%d%%]" <dd_light> (Group_Great) {channel="zwave:leviton_vri06_00_000:a15f6ccf:node15:switch_dimmer"}//{zwave="15"}
You can see in OH1 this was set to zwave=15, but now points to the auto generated thing. Also, where is the parameter config_scale parsed in code? I don’t see it directly, is something looking for “config_*” and setting it that way? Thanks!
Oops I meant “but then manualing linking the item to an a channel”
No - I’m not familiar with the OH2 text definition files - sorry.
It’s in the converter file (MultilevelSensorConverter). Note that it’s expecting an integer, so I’ve just changed the channel definition.
When the binding starts, it puts all the configs for each channel into a map, and it gets processed from there…
Sorry, I do not know the exact features of the ZWave binding here, so it might be a dumb question: What config options do you refer to? Are these configurations of the link or of the channel? If it is the channel, you do not need to specify anything in the link, do you?
I think he’s referring to channel configuration parameters…
I have both channel properties (fixed definitions of how the channel works) and channel parameters (user configurable channel parameters such as temperature scale returned from the device).
It took me a minute to realize this is a parameter on the channel itself, and would not make sense to define in the item-> channel mapping.
@chris sorry to pester you, are your temperature sensor changes checked in? It looks like the code on github does not have the scale channel configuration yet. It’s still commented out in the XML file and I don’t see it referred to in code.
No - it’s not checked in, sorry.
I was going to do it last night and started to convert the thing labels to use the new interface and found a bunch of bugs in the new stuff which left me in a half way state with HABmin 
. I’ll need to revert a bunch of stuff to get this working again until the fixes in the core filter through to OH2.
@chris I’m trying to figure out how to get a new doorbell sensor to work (and get the info into the database). From the logs I gather that it is using the command class ALARM. I can see in my logs that whenever the doorbell is pressed it sends ‘0’ as a value, but can’t figure out how to access it via a rule (I tried doing a “changed to 0”, but it only changes the first time (from UNDEF to 0). I also tried “received command” and “received update”.
I’m also trying to figure out the best way to get the info into the database. There’s no xml for it, so I’m assuming manually. I found a bit of info here: http://products.z-wavealliance.org/products/1349
Here’s my log messages as well:
09:21:06.181 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
09:21:06.182 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Command class ALARM not found, trying to add it.
09:21:06.183 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Creating new instance of command class ALARM
09:21:06.185 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Adding command class ALARM
09:21:06.185 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Adding command class ALARM to the list of supported command classes.
09:21:06.187 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received Alarm Request
09:21:06.187 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm report - Value = 0
09:21:06.190 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = General (0)
09:21:06.191 [DEBUG] [ve.internal.protocol.ZWaveController] - Notifying event listeners: ZWaveAlarmValueEvent
09:21:06.192 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - ZwaveIncomingEvent
09:21:06.192 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
09:21:06.195 [DEBUG] [ssage.ApplicationCommandMessageClass] - Transaction not completed: node address inconsistent.
09:21:06.204 [INFO ] [marthome.event.ItemStateChangedEvent] - Sensor_Doorbell changed from NULL to 0
09:21:08.861 [DEBUG] [l.ZWaveController$ZWaveReceiveThread] - Receive Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
09:21:08.864 [DEBUG] [l.ZWaveController$ZWaveReceiveThread] - Receive queue ADD: Length=1
09:21:08.864 [DEBUG] [ve.internal.protocol.ZWaveController] - Receive queue TAKE: Length=0
09:21:08.866 [DEBUG] [wave.internal.protocol.SerialMessage] - Assembled message buffer = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
09:21:08.868 [DEBUG] [ve.internal.protocol.ZWaveController] - Process Message = 01 10 00 04 00 0E 0A 71 05 00 00 00 FF 08 00 00 00 6C
09:21:08.869 [DEBUG] [ve.internal.protocol.ZWaveController] - Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0E 0A 71 05 00 00 00 FF 08 00 00 00
09:21:08.870 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:PING)
09:21:08.871 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
09:21:08.871 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received Alarm Request
09:21:08.872 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm report - Value = 0
09:21:08.873 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = General (0)
I’m a bit confused - if there’s no database entry, then I’m surprised it works at all to be honest. I’d suspect that the update you’re seeing is coming from somewhere else - not the zwave binding as if the device has no database, then it has no channels (and hence, not much else).
We should try and work out why the device is failing to produce an XML since this is normally indicative of other problems that will need to be fixed before it will work properly. If we fix the XML production, then we also answer the question of how to get the data into the database… 
If you can provide a log during startup with this device, I’ll take a look to see if there’s something wrong…
No worries, but I see it’s checked in now so thanks! I’ll try out the temp changes today and let you know how they go. I’m having an issue with the latest code where my thermostats never go online, buts its not clear from the logs why, I’ll use this as an opportunity to get familiar with the binding.
Hi @chris,
i’m coming back to my problem with Reitz 054375 Schuko Plug Switch, which is a rebrand of Popp Wall Plug Switch Schuko (IP20).
When i connect it to my Homee it was delivered with it works fine, but not if coupled over the AEON Labs Z-Wave Stick with latest nightly build of openHAB.
Maybe the linked manual can help, there are more configuration parameters then in HABmin for Reitz 054375 Schuko Plug Switch?
Regards,
Heiko
I really need to see a debug log to see what’s going on. The device looks like a pretty simple device - no parameters etc, so it should work like any other switch.
1 Like
Here’s the filtered log of node 14 (my doorbell) from OH2 startup until I go down and press the doorbell. I should note that I’m currently using v1.9 of the binding, as my switches/outlets are still waiting approval in the db, so I can’t use 2.0.
2016-02-26 07:22:28.314 [INFO ] [age.SerialApiGetInitDataMessageClass] - NODE 14: Node found
2016-02-26 07:22:28.387 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Init node thread start
2016-02-26 07:22:31.023 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 14: Serializing from file /opt/openhab-new/userdata/zwave/node14.xml
2016-02-26 07:22:31.025 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 14: Error serializing from file: file does not exist.
2016-02-26 07:22:31.165 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - EMPTYNODE: queue length(0), free to send(true)
2016-02-26 07:22:31.169 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - EMPTYNODE try 1: stageAdvanced(false)
2016-02-26 07:22:31.173 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: Initialisation starting
2016-02-26 07:22:31.213 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - advancing to PROTOINFO
2016-02-26 07:22:31.218 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - PROTOINFO try 0: stageAdvanced(true)
2016-02-26 07:22:31.223 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: PROTOINFO - send IdentifyNode
2016-02-26 07:22:31.264 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - queued packet. Queue length is 1
2016-02-26 07:22:31.265 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 14: Init node thread finished
2016-02-26 07:22:31.316 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: ProtocolInfo
2016-02-26 07:22:31.318 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Listening = false
2016-02-26 07:22:31.371 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Routing = true
2016-02-26 07:22:31.392 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Beaming = true
2016-02-26 07:22:31.398 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Version = 4
2016-02-26 07:22:31.411 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: FLIRS = false
2016-02-26 07:22:31.416 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Security = false
2016-02-26 07:22:31.427 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Max Baud = 40000
2016-02-26 07:22:31.445 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Basic = Routing Slave
2016-02-26 07:22:31.447 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Generic = Garage Door
2016-02-26 07:22:31.474 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 14: Specific = Simple Garage Door
2016-02-26 07:22:31.486 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Creating new instance of command class NO_OPERATION
2016-02-26 07:22:31.504 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Adding command class NO_OPERATION to the list of supported command classes.
2016-02-26 07:22:31.507 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Creating new instance of command class BASIC
2016-02-26 07:22:31.523 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Adding command class BASIC to the list of supported command classes.
2016-02-26 07:22:31.601 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - PROTOINFO: Transaction complete (IdentifyNode:Request) success(true)
2016-02-26 07:22:31.659 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - checking initialisation queue. Queue size 1.
2016-02-26 07:22:31.661 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - message removed from queue. Queue size 0.
2016-02-26 07:22:31.726 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - PROTOINFO: queue length(0), free to send(true)
2016-02-26 07:22:31.753 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - PROTOINFO try 1: stageAdvanced(false)
2016-02-26 07:22:31.789 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - advancing to NEIGHBORS
2016-02-26 07:22:31.792 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - NEIGHBORS try 0: stageAdvanced(true)
2016-02-26 07:22:31.817 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: NEIGHBORS - send RoutingInfo
2016-02-26 07:22:31.823 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 14: Request routing info
2016-02-26 07:22:31.871 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - queued packet. Queue length is 1
2016-02-26 07:22:32.033 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.138 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.149 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.473 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.489 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.510 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.535 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.559 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.590 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.643 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.691 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.750 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.780 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.859 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.916 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:32.961 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:33.006 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:33.069 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:33.495 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 14: Got NodeRoutingInfo request.
2016-02-26 07:22:33.498 [DEBUG] [almessage.GetRoutingInfoMessageClass] - NODE 14: Neighbor nodes: 1 11
2016-02-26 07:22:33.518 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - NEIGHBORS: Transaction complete (GetRoutingInfo:Request) success(true)
2016-02-26 07:22:33.520 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - checking initialisation queue. Queue size 1.
2016-02-26 07:22:33.521 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - message removed from queue. Queue size 0.
2016-02-26 07:22:33.522 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - NEIGHBORS: queue length(0), free to send(true)
2016-02-26 07:22:33.524 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - NEIGHBORS try 1: stageAdvanced(false)
2016-02-26 07:22:33.525 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - advancing to FAILED_CHECK
2016-02-26 07:22:33.526 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - FAILED_CHECK try 0: stageAdvanced(true)
2016-02-26 07:22:33.530 [DEBUG] [rialmessage.IsFailedNodeMessageClass] - NODE 14: Requesting IsFailedNode status from controller.
2016-02-26 07:22:33.534 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - queued packet. Queue length is 1
2016-02-26 07:22:33.765 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:34.814 [DEBUG] [rialmessage.IsFailedNodeMessageClass] - NODE 14: Is currently marked as healthy by the controller
2016-02-26 07:22:34.826 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - FAILED_CHECK: Transaction complete (IsFailedNodeID:Request) success(true)
2016-02-26 07:22:34.828 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - checking initialisation queue. Queue size 1.
2016-02-26 07:22:34.829 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - message removed from queue. Queue size 0.
2016-02-26 07:22:34.831 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - FAILED_CHECK: queue length(0), free to send(true)
2016-02-26 07:22:34.833 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - FAILED_CHECK try 1: stageAdvanced(false)
2016-02-26 07:22:34.834 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - advancing to WAIT
2016-02-26 07:22:34.836 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: loop - WAIT try 0: stageAdvanced(true)
2016-02-26 07:22:34.838 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: WAIT - Listening=false, FrequentlyListening=false
2016-02-26 07:22:34.840 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer: WAIT - Still waiting!
2016-02-26 07:22:38.353 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:39.988 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:41.647 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:43.088 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:47.402 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:49.070 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:50.291 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:51.560 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:52.819 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:55.933 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:57.152 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Polling list: item Sensor_Doorbell is not completed initialisation
2016-02-26 07:22:57.664 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - WAIT: The WAIT is over!
2016-02-26 07:22:57.665 [DEBUG] [nitialization.ZWaveNodeStageAdvancer] - NODE 14: Node advancer - checking initialisation queue. Queue size 0.
2016-02-26 07:24:45.395 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:PING)
2016-02-26 07:24:45.396 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
2016-02-26 07:24:45.398 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Command class ALARM not found, trying to add it.
2016-02-26 07:24:45.399 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 14: Creating new instance of command class ALARM
2016-02-26 07:24:45.402 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Adding command class ALARM
2016-02-26 07:24:45.403 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 14: Adding command class ALARM to the list of supported command classes.
2016-02-26 07:24:45.405 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received Alarm Request
2016-02-26 07:24:45.406 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm report - Value = 0
2016-02-26 07:24:45.408 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = General (0)
2016-02-26 07:24:45.411 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0
2016-02-26 07:24:46.611 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Application Command Request (ALIVE:PING)
2016-02-26 07:24:46.611 [DEBUG] [ssage.ApplicationCommandMessageClass] - NODE 14: Incoming command class ALARM
2016-02-26 07:24:46.612 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Received Alarm Request
2016-02-26 07:24:46.613 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm report - Value = 0
2016-02-26 07:24:46.613 [DEBUG] [.commandclass.ZWaveAlarmCommandClass] - NODE 14: Alarm Type = General (0)
2016-02-26 07:24:46.615 [DEBUG] [ng.zwave.internal.ZWaveActiveBinding] - NODE 14: Got a value event from Z-Wave network, endpoint = 0, command class = ALARM, value = 0Is it just the ZW4005 you’re waiting for? Sorry - I missed that but I’ll merge that today so it’s in tomorrows update.
That and the ZW3003. I don’t mean that to rush you though…I’m content enough sticking with 1.9 as the 2.0 branch settles a bit. As I have time I’ll keep coming back to it and testing.
No problem - I’ve done that too… The database needs a slightly better interface for showing those devices needing approval. Currently I get a list of changes which shows me which ones are done and which aren’t, but if a lot happens in a short time the list gets long and it’s easy to miss stuff…
Feel free to prod if devices are not done after a day or two (just clicking on the ‘request approval’ button again should be enough ) …