search

iAnish / openhab

Automatically exported from code.google.com/p/openhab
GNU General Public License v3.0
0 stars 0 forks source link

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

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
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 reported on code.google.com by jwsp...@gmail.com on 2 Sep 2013 at 12:45

GoogleCodeExporter commented 9 years ago 
Hi,

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

Original comment by DerRo...@gmail.com on 3 Sep 2013 at 12:04

GoogleCodeExporter commented 9 years ago 
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.

Original comment by der.tim....@gmail.com on 3 Sep 2013 at 4:43

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 3 Sep 2013 at 7:04

GoogleCodeExporter commented 9 years ago 
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...

Original comment by jwsp...@gmail.com on 3 Sep 2013 at 7:07

GoogleCodeExporter commented 9 years ago 
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é

Original comment by DerRo...@gmail.com on 4 Sep 2013 at 7:40

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 4 Sep 2013 at 10:18

GoogleCodeExporter commented 9 years ago 
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é

Original comment by DerRo...@gmail.com on 4 Sep 2013 at 11:04

GoogleCodeExporter commented 9 years ago 
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é

Original comment by DerRo...@gmail.com on 4 Sep 2013 at 11:16

GoogleCodeExporter commented 9 years ago 
Thanks, I've added it to the wiki page.

Original comment by jwsp...@gmail.com on 4 Sep 2013 at 11:40

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

Original comment by jwsp...@gmail.com on 4 Sep 2013 at 9:22

GoogleCodeExporter commented 9 years ago 
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??

Original comment by serca...@gmail.com on 7 Sep 2013 at 5:59

GoogleCodeExporter commented 9 years ago 
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

Original comment by jwsp...@gmail.com on 7 Sep 2013 at 7:03

GoogleCodeExporter commented 9 years ago 
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!

Original comment by serca...@gmail.com on 7 Sep 2013 at 8:44

GoogleCodeExporter commented 9 years ago 
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!

Original comment by serca...@gmail.com on 7 Sep 2013 at 8:44

GoogleCodeExporter commented 9 years ago 
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

Original comment by ben.jone...@gmail.com on 9 Sep 2013 at 7:16

Attachments:

GoogleCodeExporter commented 9 years ago 
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!

Original comment by ben.jone...@gmail.com on 9 Sep 2013 at 7:22

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 9 Sep 2013 at 7:33

GoogleCodeExporter commented 9 years ago 
Ben, welcome back, let me know what you find.

Original comment by jwsp...@gmail.com on 9 Sep 2013 at 7:38

GoogleCodeExporter commented 9 years ago 
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?

Original comment by ben.jone...@gmail.com on 9 Sep 2013 at 9:10

GoogleCodeExporter commented 9 years ago 
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...

Original comment by ben.jone...@gmail.com on 9 Sep 2013 at 9:20

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

JwS

Original comment by jwsp...@gmail.com on 9 Sep 2013 at 10:24

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 9 Sep 2013 at 11:11

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 10 Sep 2013 at 11:23

GoogleCodeExporter commented 9 years ago 
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)

<node id>[:<endpoint id>][:<argument1>=<value1>[,<argument2>=<value2>]]

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"}

Original comment by jwsp...@gmail.com on 10 Sep 2013 at 6:39

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 10 Sep 2013 at 8:53

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 6:24

Attachments:

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 8:57

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

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 9:21

GoogleCodeExporter commented 9 years ago 
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!

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:31

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:32

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 10:41

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

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 10:43

GoogleCodeExporter commented 9 years ago 
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?

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:50

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 10:51

GoogleCodeExporter commented 9 years ago 
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...

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:53

GoogleCodeExporter commented 9 years ago 
OW yeah, I forgot about the weird BASIC reports from the door sensors...

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 10:57

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 11:11

GoogleCodeExporter commented 9 years ago 
I completely forgot the basic converter. Oops. Creating it now.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 2:29

GoogleCodeExporter commented 9 years ago 
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" }

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 3:21

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 5:26

GoogleCodeExporter commented 9 years ago 
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?

Original comment by roher.ro...@gmail.com on 11 Sep 2013 at 5:31

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 6:20

GoogleCodeExporter commented 9 years ago 
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!

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 8:21

GoogleCodeExporter commented 9 years ago 
forgot to push. Sorry.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 8:42

GoogleCodeExporter commented 9 years ago 
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

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:12

GoogleCodeExporter commented 9 years ago 
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)?

Original comment by ben.jone...@gmail.com on 11 Sep 2013 at 10:31

GoogleCodeExporter commented 9 years ago 
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.

Original comment by jwsp...@gmail.com on 11 Sep 2013 at 11:01

GoogleCodeExporter commented 9 years ago 
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.

Original comment by ben.jone...@gmail.com on 12 Sep 2013 at 12:16

GoogleCodeExporter commented 9 years ago 
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...

Original comment by ben.jone...@gmail.com on 12 Sep 2013 at 4:08

GoogleCodeExporter commented 9 years ago 
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...

Original comment by jwsp...@gmail.com on 12 Sep 2013 at 6:21