Improvements of the Z-Wave binding for the 1.4.0 version of openhab

[openhab-bot]

From jwsp...@gmail.com on September 02, 2013 14:45:27

With the (upcoming) release of 1.3.0, it's time to think about and work on the next version of the Z-Wave binding. We like this as much to be a collaborative effort as the previous version was.

Ideas and suggestions about what to implement are welcome. In case you actually want to start coding, there is a list of items to work on below:

high priority:

• D make binding between command classes and items more dynamic. So that switches can be bound to dimmers, sensors to contacts or switches, etc.
• M initialize / read binding values in the DYNAMIC node stage during binding initialization.
• M Make polling a binding action, so that it is configurable from the items file. Default should be no polling.
• D Implement associations node stage to read associations. These can be used to query associated nodes for their status, in case the associated nodes do not report themselves directly (don't know if this is neccessary).
• M Implement some form of serialization to save / cache the configuration of the binding to speed up initialization.
• E Implement the SWITCH_TOGGLE_BINARY command class.
• E Implement the SWITCH_TOGGLE_MULTILEVEL command class.
• E Implement THERMOSTAT_MODE command class.
• E Implement THERMOSTAT_SETPOINT command class.
• E Implement BASIC_WINDOW_COVERING command class.
• E Implement DOOR_LOCK command class.
• E Implement ALARM command class.
• E Implement LOCK command class.
• M Implement MULTI_CMD command class. Used to group multiple commands together. Useful for Battery operated devices to empty the wake-up queue into one command at once.
• E Implement SIMPLE_AV_CONTROL command class.
• DD Implement SECURITY Little information. Would require changes to encapsulation, secure key storage in openhab. Not much information. Very useful for locks though. One of the weaker points of Z-Wave that security was an afterthought.

normal priority:

• M Make binding actions for alarm types, so that binding can be done on a specific alarm. Remove alarm values from the binding again then, to make it stateless.
• D Handle adding nodes to the network / removing nodes from the network.
• D Control node configuration parameters using a binding. (Requires changing binding item string format to add parameter number or something).
• DD Implement neighbors node stage. Request node neighbors and update return routes based on the neighbour list and rtt values.
• M Implement the APPLICATION_STATUS command class. Handle incoming rejected and busy signals.
• D Implement the SWITCH_ALL command class. handle incoming switch all commands and implement sending. Some discussion on what to do on those incoming signals and when to send would be neccesary.
• D Implement the SCENE_ACTIVATION command class. Some discussion on how to map scenes onto the openhab bus and vice versa would be neccessary.
• E Implement METER_PULSE command class.
• M Implement CLIMATE_CONTROL_SCHEDULE class. Requires some discussing about how to map / handle scheduling capabilities to open-zwave.
• D Implement SCHEDULE_ENTRY_LOCK command class. Limited info on the command class. Would probably require the a device, commercial software to control it, and serial monitoring software.
• E Implement POWERLEVEL command class. Setting this too low, will make communication unreliable!
• E Implement PROTECTION command class.
• E Implement NODE_NAMING command class. Would require discussion on how to implement: e.q. use item name, or just report or free settable.
• E Implement CLOCK command class.
• E Implement HAIL command class. Some devices use a HAIL to the controller to ask for polling.
• E Implement INDICATOR command class.
• E Implement PROPRIETARY command class. Would require discussion on how to define properietary payloads... in item string? as files?
• E Implement LANGUAGE command class.
• E Implement TIME command class.
• E Implement GEOGRAPHIC_LOCATION command class.
• D Implement COMPOSITE command class. Variation on Multi_Instance. Requires some changes to initialization and encapsulation etc.
• E Implement ENERGY_PRODUCTION command class.
• E Implement MANUFACTURER_PROPRIETARY command class. Would require discussion on how to define properietary payloads... in item string? as files?
• E Implement SCREEN_MD command class.
• E Implement SCREEN_ATTRIBUTES command class.
• E Implement SILENCE_ALARM command class.

low priority:

• E Make a reporting binding action for the node stage, create separate reporting binding actions for sleeping / dead.
• D Handle endpoints in multi-channel nodes that can be added /removed dynamically.
• DD Handle the situation where the stick is not the primary controller. This can be in networks with another (commercial) controller system. In this case enabling the controller to be a SUC is advisable.
• DD implement bridging and virtual nodes. This allows items on the bus to become virtual nodes and use Z-Wave associations or Z-Wave scenes to use items on another bus directly in Z-Wave.
• D Separate the Z-Wave part from the binding part and make it a separate open source library like open-zwave.
• D Implement the CHIMNEY_FAN command class. Have not been able to find a device or documentation / code about it. Should be easy once found.
• D Implement MTP_WINDOW_COVERING command class. Limited info on the command class. Would probably require the a device, commercial software to control it, and serial monitoring software.
• E Implement IP_CONFIGURATION command class. Only for reporting or also to set ip adresses?
• E Implement AV_CONTENT_DIRECTORY_MD command class.
• E Implement AV_RENDERER_STATUS command class.
• E Implement AV_CONTENT_SEARCH_MD command class.
• E Implement AV_TAGGING_MD(0x99,"AV_TAGGING_MD",null),
• D Implement TIME_PARAMETERS command class. Have not found any information.
• D Implement METER_TBL_MONITOR command class to read complex meters.
• D Implement THERMOSTAT_HEATING command class. Have not found any information.
• E Implement THERMOSTAT_OPERATING_STATE command class.
• E Implement THERMOSTAT_FAN_MODE command class.
• E Implement THERMOSTAT_FAN_STATE command class.
• D Implement THERMOSTAT_SETBACK command class. Have not found any information.
• D Implement DOOR_LOCK_LOGGING command class. Have not found any information.

ongoing:

• E Complete the list of device classes. This involves scanning software / documents for the required info or coming along an unknown device class on a device.

Original issue: http://code.google.com/p/openhab/issues/detail?id=431

[openhab-bot]

From DerRo...@gmail.com on September 03, 2013 05:04:24

Hi,

is it possible to implement a Node-Count or am I just missing something?

[openhab-bot]

From der.tim....@gmail.com on September 03, 2013 09:43:26

Hi there,

I was following your development of the ZWave-binding and have to say: Great job, guys! Anyhow I was wondering where the METER_CLASS went. Ben made one, mentioning it in issue #265 , but apparently it never made it to the default branch. So far it would be alright, but I can't even find it in this tasklist you made. Did you skip it for a reason or were it just forgotten?

Thanks for your attention.

[openhab-bot]

From jwsp...@gmail.com on September 03, 2013 12:04:02

METER will be merged from Ben into the 1.4.0 version of the binding. I will probably release a version of the 1.4.0 binding next week. Have been a bit busy with the 1.3 release.

[openhab-bot]

From jwsp...@gmail.com on September 03, 2013 12:07:44

Der Rocka,

You mean like a report item? Yes, that would very well be possibly. Never thought of it ;-) I will add it to the list. Have to find a better way to manage these items as I can't seem to edit comments...

[openhab-bot]

From DerRo...@gmail.com on September 04, 2013 00:40:06

Hi,

yes like a report item.

I just noticed it in the OZWCP and thought that it could be quite usefull. Just to see how many nodes my network does have in general. Perhaps also for new added nodes, that I can see, that they were added right. At least that there was added one node before I can try to add it to my items-file. :-)

Regards

André

[openhab-bot]

From jwsp...@gmail.com on September 04, 2013 03:18:07

André,

I think you have an Aeon labs controller that is able to include devices on it's own. I'm not sure which messages are sent (eg. programming return routes in a node, requesting neighbor updates) by the stick in this inclusion process, so it could be that a node is somewhat unusable after inclusion by the stick. Then you'd still need OZWCP to run an initialization before all is well in the network. The binding currently does not assign return routes or requests nodes to update their neighbor list as part of it's initialization phase.

[openhab-bot]

From DerRo...@gmail.com on September 04, 2013 04:04:26

Jan-Willem,

you're right. I don't know exactly whether there is a usefull thing about a Node-Count for everyone, but I came across in OZWCP, that I find this information nice.

It isn't really much about the thing, that I can see whether a node was successfully added or not. Just to see how many a network has in whole. In my little network at the time (with just 1 node) there isn't really a use for it, but perhaps nice to have ;-)

André

[openhab-bot]

From DerRo...@gmail.com on September 04, 2013 04:16:13

Another Website with Z-Wave Productinformation by sigmadesigns. Not like the other, I gave you before, but with official information by vendors etc: http://products.z-wavealliance.org/ There you can download a pdf-file for every official supported product with their supported Device/Command/Controller Classes. Perhaps also worth to be on the wikipage?

In special for example the Fibaro Double Relay Switch (It's an 1 page pdf): http://products.z-wavealliance.org/products/46 André

[openhab-bot]

From jwsp...@gmail.com on September 04, 2013 04:40:12

Thanks, I've added it to the wiki page.

[openhab-bot]

From jwsp...@gmail.com on September 04, 2013 14:22:17

Little heads up. I've laid the ground work for the converter stuff. Hopefully I can finish it by the end of the week.

[openhab-bot]

From serca...@gmail.com on September 07, 2013 10:59:36

Hi everybody,

First of all, thanks for this great contribution.

I've been following the zWave thread, and I have just downloaded the 1.3 snapshot binding. However it does not work as I expected.

I have an Aeon Labs USB Z-Stick Zwave controller, and a Fibaro Controlled Switch (Fibaro calls it FGWPE/F-101). It also can be used to measure power consumption.

Both devices work fine when used outside openHAB. I tested with Zwave.me and I have been able to control the switch and to query its state.

Fibaro switch has Id=2 and the network is functioning, as the Zwave.me tests reveal.

However, when I use them with openHAB, the Fibaro switch behaves kind of weird... OpenHAB acknowledges when I turn the switch on/off (using the manual button on the Fibaro switch) because the web interface shows the appropiate state, but I cannot make openHAB turn the switch on/off FROM the web interface.

It seems that I can read the satus of the device but I cannot send commands to it.

Besides, openHAB always says that device is dead when I query the Sleeping_Dead state (both when the device is connected and disconnected from the wall)

What am I doing wrong???

What I need is:

-to be able to control the switch with OpenHAB web interface -to know if the switch has been swichted off/on -to know if the switch has lost mains power supply (it is dead)

My items file contains these lines:

String ZwaveNode02Id "Node ID [%s]" {zwave="2:1:NODEID"} Switch ZwaveNode02Switch "Fibaro Switch" {zwave="2"} String ZwaveNode02Dead "Node Is Dead [%s]" {zwave="2:1:SLEEPING_DEAD"}

And my sitemap contains these lines:

Frame label="Zwave" { Text item=ZwaveNode02Id Switch item=ZwaveNode02Switch icon="light" Text item=ZwaveNode02Dead icon="light" }

The Fibaro switch is in front of the Zwave controller so I am sure it is not a range problem.

Any ideas??

[openhab-bot]

From jwsp...@gmail.com on September 07, 2013 12:03:59

This is a bit of a problem device. I have one myself. It has a firmware bug that prevents it from initializing properly and it has an energy meter combined as well in a way that the binding currently does not support. The next beta release, which is imminent, will support it however.

JwS

Verstuurd vanaf mijn iPhone

[openhab-bot]

From serca...@gmail.com on September 07, 2013 13:44:04

Thanks Jan-Willem. I was starting to think that I was a fool :-)

Does Fibaro know the bug? Is there a firmware upgrade to solve it?

In case they don't know, I think we should tell them, don't you think?

Thanks JW!

[openhab-bot]

From serca...@gmail.com on September 07, 2013 13:44:08

Thanks Jan-Willem. I was starting to think that I was a fool :-)

Does Fibaro know the bug? Is there a firmware upgrade to solve it?

In case they don't know, I think we should tell them, don't you think?

Thanks JW!

[openhab-bot]

From ben.jone...@gmail.com on September 09, 2013 00:16:32

Hey JW - back from holidays and feeling refreshed! Looks like you have been pretty busy. I downloaded the 1.3.0 release and ran up the ZWave binding but had to make a couple of modifications to get my METER node working and had to change the BINARY_SENSOR and BASIC command classes to return OPEN/CLOSED rather than ON/OFF as that is how my config is setup.

Anyways, I have been noticing a lot of errors. These were happening before 1.3.0 final, and are still happening. All the nodes seem to respond ok although it does sometimes take a couple of openHAB restarts to get them all to come up. Some responses seem to get missed and the node gets stuck in VERSION or MANUFACTURER, it can vary.

I am guessing it is the same issue I am seeing once the binding is running, but when it is running it just ignores those failures since it is all initialised already.

Attached are my logs. The send/receive threads are dying a lot which is a bit of a worry. I have removed the USB hub and now have the stick connected via a 500mm USB extension cord, as I know you mentioned that could be a cause of serial problems.

There are also a lot CAN messages from the controller. I am starting to wonder if there is not something wrong with my USB stick?!

Anyways - let me know if you see anything obvious. Not sure what else I can try.

Cheers, Ben

Attachment: zwave.zip

[openhab-bot]

From ben.jone...@gmail.com on September 09, 2013 00:22:50

Hmmm - after looking at that log some more it looks like the send/receive threads always seem to die just after a METER_EVENT is received. That is a bit of a red flag! I will look into that tomorrow as this is my code!

[openhab-bot]

From jwsp...@gmail.com on September 09, 2013 00:33:43

Sercasyr,

Fibaro has been notified and they promised a fix. We will create a workaround though, this is way easier. Normally Fibaro puts the firmware on new devices and they make them available through their own gateway product, Homecenter 2. I've never seen separate firmware updates for devices.

[openhab-bot]

From jwsp...@gmail.com on September 09, 2013 00:38:08

Ben, welcome back, let me know what you find.

[openhab-bot]

From ben.jone...@gmail.com on September 09, 2013 14:10:44

Ok - well I couldn't see anything obviously wrong, however after disabling support for the METER command class (0x32) (by setting it null in the ZWaveCommandClass.CommandClass enum) and removing the item from my config, the binding is humming along perfectly. No errors, timeouts, or thread restarts. The only error I see is the 'Unsupported command class METER' whenever my switch/meter node sends a METER report.

I have no idea what that command class is doing to cause such mayhem but it is a little concerning! Has anyone else managed to get METER reports working on any other devices?

[openhab-bot]

From ben.jone...@gmail.com on September 09, 2013 14:20:24

It looks like the switch only sends meter reports every 10 mins, but my binding was failing every minute (at least). So I am thinking this problem is to do with the binding polling the node and requesting a meter report, via the METER_VALUE binding action, which happens every 60 seconds. But I am still unsure exactly what that problem is...

[openhab-bot]

From jwsp...@gmail.com on September 09, 2013 15:24:03

I'll have a look at it tomorrow. I'm pretty much ready with 1.4.0 alpha to incorporate meter.

JwS

[openhab-bot]

From ben.jone...@gmail.com on September 09, 2013 16:11:15

Nice one - I have been keeping an eye on your 1.4.0 branch - looks great. Let me know when it is ready for testing and I will start using it here.

[openhab-bot]

From jwsp...@gmail.com on September 10, 2013 04:23:08

OK, I've completed the items below in my 1.4 branch.

• D make binding between command classes and items more dynamic. So that switches can be bound to dimmers, sensors to contacts or switches, etc.
• M initialize / read binding values in the DYNAMIC node stage during binding initialization.
• M Make polling a binding action, so that it is configurable from the items file. Default should be no polling.
• M Make binding actions for alarm types, so that binding can be done on a specific alarm. Remove alarm values from the binding again then, to make it stateless.

[openhab-bot]

From jwsp...@gmail.com on September 10, 2013 11:39:22

And I merged the METER class. Thanks Ben. I'm happy to announce that the binding now fully supports the Fibaro FGWPE/F-101 switch witch included power and energy meters. I have one myself (connected to my espresso machine) and it works beautifully.

I'll test it for a few days with my setup because I've changed about every bit of code in the binding, but will provide binaries before the end of the week.

For those of you interested, the configuration part for the Fibaro FGWPE/F-101 is below:

Switch Coffee_Kitchen_Switch "Koffiemachine" (GF_Cellar) {zwave="18:command=switch_binary"} Number Coffee_Kitchen_Power "Koffiemachine actueel verbruik [%.1f W]" (GF_Cellar) { zwave="18:command=sensor_multilevel" } Number Coffee_Kitchen_Energy "Koffiemachine totaal verbruik [%.2f KWh]" (GF_Cellar) { zwave="18:command=meter" }

What is immediately obvious is that a command class is specified (besides the node ID) because this device has only one endpoint, but multiple different command classes.

There have been more changes to the binding format, but in general the binding format is: (brackets indicate optional values)

[:][:=[,=]] Some more examples are: String ZwaveStatsSOF "Number Start of Frames[%s]" (gZwaveStats) {zwave="1:command=info,item=sof"} String ZwaveStatsACK "Number of Acknowledgments [%s]" (gZwaveStats) {zwave="1:command=info,item=ack"} String ZwaveStatsCAN "Number of CAN [%s]" (gZwaveStats) {zwave="1:command=info,item=can"} Contact Door_Living_Switch "Schuifdeur sensor [MAP(nl.map):%s]" (GF_Living) {zwave="25:command=sensor_binary"} Number Door_Living_Sensor_Battery "Schuifdeur sensor batterijniveau [%d %%]" (GF_Living) { zwave="25:command=battery" } Dimmer Light_Toilet_Dimmer "Toilet Dimmer [%d %%]" (GF_Toilet) {zwave="10:1:restore_last_value=true"} Switch Mech_Vent "Mechanische ventilatie middel." (GF_Kitchen) {zwave="11:1"} Switch Mech_Vent_High "Mechanische ventilatie hoog." (GF_Kitchen) {zwave="11:2"}

[openhab-bot]

From ben.jone...@gmail.com on September 10, 2013 13:53:50

Looks awesome JwS! Can't wait to get my hands on this. My binding seems to be working a lot more reliably now I am not polling for METER values. Did you make any changes to my METER command class - find any bugs? I presume it is working ok for you?

I am not too fussed as I only have one node which reports METER values, and that is on a single LED outdoor light so uses next to no power at all.

[openhab-bot]

From ben.jone...@gmail.com on September 10, 2013 23:24:52

Built your latest version (1.4.0) of the binding and have been testing it out today. I definitely have something funny going on with my Aeon Labs Micro Smart Energy Switch. I have disabled meter reports (I think!) but when the binding starts up it is requesting a value during initialisation.

It seems like anytime this switch sends a meter report the message is received ok but then something (I presume the ACK?) times out and the send/receive threads die. Logs attached. So I really don't want these meter reports being sent! In 1.3.0 I just removed the item binding for the METER command and everything was sweet (the node is right next to the controller so definitely not a network issue).

So can you confirm the meter report request is sent if a node reports support for the METER command class? And if so, do you think we can disable this if there is no item binding for this action, since there is nothing to initialise?

Got a few other things but I will try and keep each message related to a single issue.

Attachment: zwave.zip

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 01:57:57

I'm pretty sure that the METER report is delivered to an incompatible item.. a switch or dimmer or something and that an exception is thrown.

Could you send me the binding configuration for this item? try explicitly specifying the command class (the other one, not METER) in the binding config.

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 02:21:46

I think I fixed it. I'm now also considering the type of the z-wave value when picking a converter.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 03:31:13

The thing is I didn't have any item configured for the meter value, all I have is a simple Switch item for the node {zwave="3"} - i.e. it is just a light switch. Or are you suggesting I try something like {zwave="3:command=SWITCH_BINARY"} to ensure the meter report is ignored?

I will try your new code tomorrow first thing - it is getting a little late here to be firing up the dev PC and compiling binaries!

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 03:32:44

BTW - what is the syntax for enabling polling for an item? All my Fibaro switches are pretty good at reporting state changes, but the Aeon Labs Micro Switch doesn't seem to do it so I will need to poll that one node.

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 03:41:56

refresh_interval=xx where xx is the amount of seconds.

and yes, I mean {zwave="3:command=SWITCH_BINARY"}, this will ignore the meter reports.

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 03:43:14

And try associating the Aeon Labs switch with the controller in open-Zwave. It will probably start reporting it's values.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 03:50:31

I did have it associated and at one point it was reporting its values, but since the meter issue I was trying to stop any meter reports so removed all associations. Once I get the node working ok (i.e. not crashing whenever a meter report arrives!) I will try and get the associations working again.

I did notice with my other sensors that they send BASIC reports when they are tripped (i.e. Door Sensor and the Universal Sensor). I had Contact items configured with binding configs like {zwave="10:command=SENSOR_BINARY"} but my items were not being updated when the sensor was tripped.

Is this the correct format? I tried command=BASIC as well, but this gave a warning about a missing converter type or something (sorry don't have the log in front of me). Can you see anything wrong with my initial attempt using SENSOR_BINARY, knowing that only BASIC reports are coming back?

Is this something wrong with the sensor config, or should your new converter stuff handle this case and convert the BASIC report to an Open/Closed contact value?

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 03:51:37

And I did not really change the METER command class. I've expanded it a bit so that it supports up to version 3 of the command class and I've added RESET functionality, that you can bind to an OnOff item (and create a push button in the sitemap) to reset the energy meter. That looked like a nice gimmick.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 03:53:21

Yeah I saw that reset stuff. Quite useful I guess - I would love to get my hands on one of your wall plugs but they are not available for AUSNZ yet...

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 03:57:24

OW yeah, I forgot about the weird BASIC reports from the door sensors...

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 04:11:36

I can't remember what you did exactly in 1.3.0 to fix these. Something along the lines of handling BASIC reports as a 'fallback'? The problem I had was that initially you were sending ON/OFFs for the BASIC reports - but I wanted to use Contact items - so I had a custom version of your binding which handled them as OPEN/CLOSED.

I was hoping all your new converter stuff would eliminate the need for my customisation.

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 07:29:36

I completely forgot the basic converter. Oops. Creating it now.

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 08:21:15

I've fixed it, it's in my clone. I completely looked over it, had a few non functioning sensors myself. Anyway, my binding strings to the door sensor:

Contact Door_Living_Switch "Schuifdeur sensor [MAP(nl.map):%s]" (GF_Living) {zwave="25:command=sensor_binary,respond_to_basic=true"} Number Door_Living_Sensor_Battery "Schuifdeur sensor batterijniveau [%d %%]" (GF_Living) { zwave="25:command=battery" }

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 10:26:56

Hmm Ben,

Meter seems more complicated than we thought. I have a Greenwave powerbar (actually Schuko) that has meter support. It seems that it can measure both power in W and energy in KWh. But instead of a separate command class SENSOR_MULTILEVEL (like the fibaro), it uses the scales feature to report them as different scales.

I'll adjust it accordingly.

[openhab-bot]

From roher.ro...@gmail.com on September 11, 2013 10:31:39

Hi JWSP! I am a little bit confused - is this new binding config format (command=...) supported only in future 1.4.0 version, or in current 1.3.0 too?

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 11:20:38

Only in 1.4.0 i'm afraid. This thread is about the next version of the binding. I'll provide some alpha binaries, but as you see, stuff breaks here.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 13:21:37

JW - I can't see anything in your clone since the fix from comment #28.

BTW - I did notice there was no basic converter but figured you had some other cunning way of handling those messages - my bad - I should have alerted you!

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 13:42:57

forgot to push. Sorry.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 15:12:58

Great - thanks! So I have compiled your changes and things are looking better. The METER reports are not arriving anymore, so node 3 is correctly initialising. And the BASIC reports from my sensors are being handled - many thanks!

Next problem however. Node 4 is failing to initialise. This is a standard Fibaro 2x1.5kW switch. Below are the log entries relating to it during initialisation. It looks like the binding receives an application command request and then dies. After this the binding is unable to recover and the node is marked dead.

This looks like another one of my timeout issues, and node 4 is quite far from the controller, but I wouldn't expect a timeout to kill the send/receive threads. If there are exceptions being thrown, is there any way we can dump the details to the logs?

2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1133]- Message = 01 05 00 04 08 04 F2 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.SerialMessage[:146]- Creating new SerialMessage from buffer = 01 05 00 04 08 04 F2 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.SerialMessage[:150]- Message checksum calculated = 0xF2, received = 0xF2 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.SerialMessage[:163]- Message Node ID = 255 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.SerialMessage[:164]- Message payload = 08 04 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.ZWaveController[:145]- Incoming message to process 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message buffer = 01 05 00 04 08 04 F2 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.ZWaveController[:146]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), buffer = 01 05 00 04 08 04 F2 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.ZWaveController[:166]- Message type = REQUEST 2013-09-12 09:09:43 DEBUG o.o.b.z.i.p.ZWaveController[:192]- Application Command Request from Node 4 2013-09-12 09:09:48 ERROR o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1019]- Timeout while sending message to node 4. Requeueing 2013-09-12 09:09:48 ERROR o.o.b.z.i.p.ZWaveController[:308]- Got an error while sending data to node 4. Resending message. 2013-09-12 09:09:48 DEBUG o.o.b.z.i.p.ZWaveController[:847]- Callback ID = 15 2013-09-12 09:09:48 DEBUG o.o.b.z.i.p.ZWaveController[:717]- Enqueueing message. Queue length = 7 2013-09-12 09:09:48 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:996]- Took message from queue for sending. Queue length = 6 2013-09-12 09:09:48 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message buffer = 01 08 00 13 04 01 00 25 0F CB 2013-09-12 09:09:48 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1007]- Sending Message = 01 08 00 13 04 01 00 25 0F CB 2013-09-12 09:09:52 DEBUG o.o.b.z.i.ZWaveActiveBinding[:98]- Zwave Network isn't ready yet! 2013-09-12 09:09:52 WARN o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1199]- Threads not alive, respawning 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1036]- Stopped Z-Wave send thread 2013-09-12 09:09:52 INFO o.o.b.z.i.p.ZWaveController[:708]- Disconnected from serial port 2013-09-12 09:09:52 INFO o.o.b.z.i.p.ZWaveController[:627]- Connecting to serial port /dev/zwave 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1090]- Starting Z-Wave receive thread 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:991]- Starting Z-Wave send thread 2013-09-12 09:09:52 INFO o.o.b.z.i.p.ZWaveController[:640]- Serial port is initialized 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:996]- Took message from queue for sending. Queue length = 5 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message buffer = 01 08 00 13 05 01 00 25 04 C1 2013-09-12 09:09:52 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1007]- Sending Message = 01 08 00 13 05 01 00 25 04 C1 2013-09-12 09:09:52 ERROR o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1148]- Message cancelled by controller (CAN), resending 2013-09-12 09:09:53 DEBUG o.o.b.z.i.p.ZWaveController[:717]- Enqueueing message. Queue length = 6 2013-09-12 09:09:53 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:996]- Took message from queue for sending. Queue length = 5 2013-09-12 09:09:53 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message buffer = 01 08 00 13 05 01 00 25 04 C1 2013-09-12 09:09:53 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:1007]- Sending Message = 01 08 00 13 05 01 00 25 04 C1 2013-09-12 09:09:53 ERROR o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1148]- Message cancelled by controller (CAN), resending 2013-09-12 09:09:53 DEBUG o.o.b.z.i.p.ZWaveController[:717]- Enqueueing message. Queue length = 6

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 15:31:38

In another attempt to initialise I got a version = 0 when initialising a multi instance node. This caused the binding to report a warning but then it couldn't proceed and the node was marked dead. Looking at your code would it be possible to trap this error and attempt to retry this phase of initialisation (i.e. resend the request)?

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 16:01:45

No idea about logging, usually I run the binding in the debugger during development. The binding should not throw exceptions on timeouts. When you have logged one, I'll look into it.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 17:16:06

I can't run mine in the debugger unfortunately, my dev pc is too far away from the controller, and I am loathed to move it for fear of messing up my mesh network.

Now, after a few restarts, I have all nodes up and running. I will keep an eye on things and continue to dig around your code to see if I can see what is going wrong (when it does).

Cheers.

[openhab-bot]

From ben.jone...@gmail.com on September 11, 2013 21:08:22

JwS - hats off to you my friend. This latest version of the binding is fantastic. I have managed to get all my config tweaked and now all my nodes happily report state change events when manually switched. There is next to no traffic on my ZWave network, except for the occasional temperature report and of course when something is switched/activate.

The new converter stuff seems to be working great. I have switches and contacts receiving BASIC reports and they all update seamlessly.

One thing I did think, would it be worth making the RESPOND_TO_BASIC command ON by default? I have a couple of nodes/sensors that send BASIC reports and I would be surpised if there weren't more out there. Rather than force a user to explicitly set this option, it might save a few headaches if it was enabled by default. I can't think of any reasons you wouldn't want to handle a BASIC report, but you can always disable the option explicitly if required.

Just a thought - otherwise everything seems to be humming along swimmingly! About time to get some more devices I think...

[openhab-bot]

From jwsp...@gmail.com on September 11, 2013 23:21:39

I'm glad it works for you :-) Yeah, I think I can make the binding part a bit more clever. Basic can be enabled by default, but then I have to make a best guess which item is the "basic" item. i.e. with the door sensor, there is also an item bound to the battery command class, and we don't want that one to respond to the basic reports.

Maybe it's also time to start a wiki page / DB with binding config lines per device. I think maybe Thomas was right the other day, it will help novice users to quickly set-up a their network.

Holy grail of course is dynamic creation of items based on the discovered nodes. This way, there is no configuration anymore...