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

[GoogleCodeExporter]

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]

My damn email replies never seem to work when they come from my phone! I 
replied that I totally agree with the idea of a WIKI page, and would be happy 
to contribute my binding config to help out. This is rapidly becoming quite a 
complicated binding (but extremely powerful!) so beginners will need all the 
help they can get.

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

[GoogleCodeExporter]

It ain't much but I just pushed a support for the HAIL command class to my 
clone 
(https://code.google.com/r/benjones12-zwave2/source/detail?r=62b4b305dc0fe06fa24
1c2fbab124fd77eede70a&name=1.4.0-zwave). It is untested as I don't have any 
devices that 'hail' but it is pretty simple so should be ok I think. 

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

[GoogleCodeExporter]

I don't have any devices either. I'll merge it this weekend.

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

[GoogleCodeExporter]

JwS - I am seeing an odd error sometimes during initialisation. Every so often 
one of my double relay switches fails to properly initialise its end points (in 
ZWaveMultiInstanceCommandClass.initEndpoints()) because it receives a version=0 
(see line 1720 of the attached log).

Because the binding just ignores this error/warning and continues, the second 
end point of that node is never initialised. I was wondering if this sort of 
thing happens, could we force the binding to re-request that phase of the 
initialisation sequence? Since we know at this point it is a multi-instance 
device, we should keep trying until the end points are successfully initialised?

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

[GoogleCodeExporter]

Sorry - forget the log.

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

Attachments:

• zwave.zip

[GoogleCodeExporter]

Hey JwS - found another potential bug I think. In 
ZWaveController.handleIdentifyNodeResponse() you add all mandatory device 
classes - which is a static list. However when you process the end point 
capabilities of a multi-instance device 
(ZWaveMultiInstanceCommandClass.handleMultiChannelCapabilityReportResponse()) 
you don't check this mandatory list and just add command classes based on what 
the device reports.

I can imagine that is probably fine for most devices but my Fibaro Universal 
Sensor is only reporting back SENSOR_BINARY and SENSOR_ALARM classes, i.e. no 
BASIC, but when the sensor is tripped it is sending BASIC reports. Go figure!

This is all working ok but I am seeing warning messages in my log whenever the 
sensor is tripped stating that BASIC is not implemented for endpoint 'n' and 
that it is falling back to the main node. 

I think we should be adding the mandatory command classes during end point 
initialisation of multi instance devices, like we do the for main node. 

Let me know what you think.

Original comment by ben.jone...@gmail.com on 13 Sep 2013 at 2:35

[GoogleCodeExporter]

Just been playing around with the INFO stuff for the controller (node 1). Can I 
make a suggestion to return Integers for all the stat counts? This will make it 
easier to write rules in openHAB to check for high numbers of NAKs/CANs etc. 
Easy enough to convert to strings in the item definitions when displaying in 
the sitemaps.

Original comment by ben.jone...@gmail.com on 13 Sep 2013 at 3:56

[GoogleCodeExporter]

JwS - would you rather I just made these changes and flicked you an email to 
let you know to look in my clone, so you can merge in the changes to your 
clone? Or is it easier to just drop a note here (as I have been doing) and save 
you having to do any merging? I am happy to do either.

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

[GoogleCodeExporter]

Just drop a note in this topic, then the rest of the world knows what's going 
on ;-)

Yeah, I thought about changing the report items and passing them through the 
converter logic, so that you can do all sorts of cool stuff with it, and I left 
it for now, can't do all at the same time ;-)

Original comment by jwsp...@gmail.com on 13 Sep 2013 at 6:24

[GoogleCodeExporter]

I think it's a bit more subtle that just adding the mandatory command classes 
for the endpoints. I can't find anything about that in the spec and my 
multi-channel devices all report the mandatory command classes for their device 
class on their endpoints (as opposed to the mandatory command classes on the 
node, because that is listed in the specs).

Open-Zwave just adds a basic command class, I think to cover for the situation 
you are describing. Fibaro really loves their basic reporting, and I think that 
is a bit "off spec" as well.

The relevant code in open-zwave is below, i think we should just add basic 
there as well, if the node supports it:

 // If we support the BASIC command class and it is mapped to a command class
                                                // assigned to this end point, make sure the BASIC command class is also associated
                                                // with this end point.
                                                if( basic != NULL && basic->GetMapping() == commandClassId )
                                                {
                                                        basic->SetInstance( i );
                                                        if( m_endPointMap != MultiInstanceMapAll || i != 1 )
                                                        {
                                                                basic->SetEndPoint( i, endPoint );
                                                        }
                                                }

Original comment by jwsp...@gmail.com on 13 Sep 2013 at 6:28

[GoogleCodeExporter]

I've fixed the basic "bug". It's in my clone.

Original comment by jwsp...@gmail.com on 13 Sep 2013 at 6:38

[GoogleCodeExporter]

Nice - looks good JwS. Just noticed a potential bug in 
ZWaveNode.resolveCommandClass().  After line 415 you should be testing for a 
null return value I think. Otherwise you will get a null reference exception in 
line 418 if null is returned.

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

[GoogleCodeExporter]

I have just pushed a change to ZWaveBinarySwitchCommandClass so it handles 
SWITCH_BINARY_SET in much the same way you handle BASIC_SET - i.e. treat it as 
a SWITCH_BINARY_REPORT. My Aeon Labs Micro Smart Energy Switch returns a 
SWITCH_BINARY_SET and a BASIC_REPORT when the switch is activated by the 
binding and I was getting warnings in my logs. Seems to be working fine in my 
network now.

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

[GoogleCodeExporter]

There seems to be a lot of creativity involved in interpreting the specs ;-)
I'll have a look at it and merge it. Thanks!

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

[GoogleCodeExporter]

found another issue... The binding didn't refresh the values when the items 
file got reloaded. Fixed that one as well.

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

[GoogleCodeExporter]

Did you see my comment #54? I haven't noticed that issue much recently but do 
you think it is worth adding some handling to allow the binding to recover from 
receiving version=0 for a multi instance node? Would you rather I added new 
'issues' for these things or just do it via this one?

AFAIK the only outstanding things are this, the default handling of BASIC 
reports and using state converters for the info reports. 

Think it is really starting to look very stable now. Great job!

Original comment by ben.jone...@gmail.com on 14 Sep 2013 at 6:57

[GoogleCodeExporter]

Just pushed some changes to my clone so the ZWave info stuff is now using the 
state converters. I now have rules setup to alert me if a node dies. Merge with 
your main branch if you are happy with it :).

Original comment by ben.jone...@gmail.com on 15 Sep 2013 at 3:06

[GoogleCodeExporter]

Oops I completely forgot to tell you that #54 is fixed.

https://code.google.com/r/jwspuij-zwave/source/detail?r=8b751a4496f940aee70acb4c
df9da036948acb10&name=1.4.0-zwave#

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

[GoogleCodeExporter]

Ah sweet. Thanks!

Original comment by ben.jone...@gmail.com on 15 Sep 2013 at 8:38

[GoogleCodeExporter]

For those of you interested in running a beta version, I've included the binary 
below.

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, respond_to_basic=true"} 
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"}

Some general binding options are:

command=xxxx this binds this item to a specific command class
refresh_interval=xxx this is a polling interval in seconds. Default the binding 
does not poll.
respond_to_basic=true this indicates that the item should respond to basic 
reports, sent out by some fibaro sensors.

Original comment by jwsp...@gmail.com on 16 Sep 2013 at 6:31

[GoogleCodeExporter]

JwS - I am still seeing the issue in #54 sporadically. When the version number 
0 is received for the MULTI_INSTANCE class, only the first end point is 
initialised. I only get this error every now and again, but could we add some 
handling to the binding so it retries if it receives version = 0 for a multi 
instance device (or any device?)?

2013-09-17 08:11:22 DEBUG o.o.b.z.i.p.ZWaveController[:192]- Application 
Command Request from Node 5
2013-09-17 08:11:22 DEBUG o.o.b.z.i.p.ZWaveController[:210]- Incoming command 
class MANUFACTURER_SPECIFIC (0x72)
2013-09-17 08:11:22 DEBUG 
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:82]- Received Manufacture 
Specific Information for Node ID = 5
2013-09-17 08:11:22 DEBUG 
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:99]- Node 5 Manufacturer 
ID = 0x010f
2013-09-17 08:11:22 DEBUG 
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:100]- Node 5 Device Type = 
0x0200
2013-09-17 08:11:22 DEBUG 
o.o.b.z.i.p.c.ZWaveManufacturerSpecificCommandClass[:101]- Node 5 Device ID = 
0x300a
2013-09-17 08:11:22 WARN  o.o.b.z.i.p.c.ZWaveMultiInstanceCommandClass[:534]- 
Unknown version 0 for command class MULTI_INSTANCE (0x60)

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

[GoogleCodeExporter]

There was no 0 version received. 0 is the default value if no version info is 
received. I'll have to have another look into the log to see why the binding 
continues without all the version info. I'll look at it tomorrow.

Original comment by jwsp...@gmail.com on 16 Sep 2013 at 8:59

[GoogleCodeExporter]

Ok - I think I have tracked this down. If you look in the log I posted in 
comment #55 you will see that for node 6 the binding received TWO node info 
messages (lines 1607 and 1663). The first message causes the node stage to 
advance and the version request is sent, however the second message arrives 
immediately afterwards and advances the node stage again. This happens before 
the version response comes back and thus we get the bug where the multi 
instance command class is told to initialise its end points, before the version 
response has been processed.

I am not sure of the best way to fix this. Whether you change the node advance 
stuff to be more explicit, so when advancing you pass what the next stage 
should be. Or if you add some validation to ignore certain initialisation 
messages (i.e. node info responses) if they have already been processed.

I will leave it with you to decide!

PS - did you see my changes for the info command state conversion stuff? I am 
using this on a local version of my binding but don't want to lose it if/when I 
upgrade to your latest code. 

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 1:09

[GoogleCodeExporter]

It's a very crappy problem. I've tried ignoring the double messages, but they 
do not have a callback ID (sadly). Simple detection gave problems with wake-up 
devices, because they restart their init sequence on wake-up and then double 
messages will happen.

I was thinking about adding the stage to advance to too. 

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 6:54

[GoogleCodeExporter]

Sounds like you are on top of what is happening. Not sure there is much I can 
add to help? I have noticed another strange initialisation error this evening 
(see log below for node 7). It receives a VERSION (0x86) message with command 
class MULTI_CMD (0x8f) and version = 0. The checksum seems to be ok so I don't 
think it is a scrambled packet, but I have never seen one of these before (that 
I can recall). Any ideas?

The other thing is the node is marked DEAD by the binding (in the logs) but I 
don't think the 'dead' property on the ZWaveNode object is being updated. I 
only noticed this as I am now displaying the node info properties in my sitemap 
(with rules to alert me if a node dies) and this didn't update. 

2013-09-17 19:26:08 DEBUG 
o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1133]- Message = 01 0A 00 04 00 
07 04 86 14 8F 00 EF 
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:146]- Creating new 
SerialMessage from buffer = 01 0A 00 04 00 07 04 86 14 8F 00 EF 
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:150]- Message checksum 
calculated = 0xEF, received = 0xEF
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:163]- Message Node ID = 255
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:164]- Message payload = 00 
07 04 86 14 8F 00 
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:145]- Incoming message 
to process
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.SerialMessage[:238]- Assembled message 
buffer = 01 0A 00 04 00 07 04 86 14 8F 00 EF 
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:146]- Message: class = 
ApplicationCommandHandler (0x04), type = Request (0x00), buffer = 01 0A 00 04 
00 07 04 86 14 8F 00 EF 
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:166]- Message type = 
REQUEST
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:192]- Application 
Command Request from Node 7
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.ZWaveController[:210]- Incoming command 
class VERSION (0x86)
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:86]- Received 
Version Request for Node ID = 7
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:110]- Process 
Version Command Class Report
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:120]- Node 7 
Requested Command Class = MULTI_CMD (0x8f)
2013-09-17 19:26:08 DEBUG o.o.b.z.i.p.c.ZWaveVersionCommandClass[:121]- Node 7 
Version = 0
2013-09-17 19:26:08 ERROR o.o.b.z.i.p.c.ZWaveVersionCommandClass[:128]- 
Unsupported command class MULTI_CMD (0x8f)

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 8:14

[GoogleCodeExporter]

Firmware bug? Sometimes one of my nodes sends illegal command class values in 
the node info frame... Packet, including checksum is OK, but the CC values 
don't match at all...

Multi_CMD is not supported by the binding, so it would never ask for it's 
version...

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 8:33

[GoogleCodeExporter]

I don't know what has changed (haven't changed my binding in the last few days) 
but I can't get the binding to start without these duplicate node info 
messages. 2-3 nodes every time fail to start properly. And it was all going so 
well!

Just saw your last comment. I think something has gone a bit haywire in my 
controller. Trying a soft reset via OZWCP...

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 8:34

[GoogleCodeExporter]

Or a network collision. An avarage of 1 in 256 collided packets will end up 
with a garbled packed with the right checksum on a collision.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 8:35

[GoogleCodeExporter]

Nah something has gone wrong with the controller. I am seeing loads of Out Of 
Frame Flow warnings (sending NAKs) even after a soft reset. A hard reset will 
wipe all associations correct? Don't really want to do that! Might try 
disconnecting the stick for a minute and retrying...

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 8:37

[GoogleCodeExporter]

I was thinking of implementing deleting and assigning return routes and doing a 
round at a scheduled time (at night or something, every night) to make sure 
that all return routes will stay in a healthy condition.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 8:38

[GoogleCodeExporter]

Dont hard reset ;-)

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 8:38

[GoogleCodeExporter]

Yep - made that mistake before! Not sure what happened but after unplugging and 
reconnecting the Out Of Frame Flow errors have stopped. Now just having to 
rebuild the mesh network. God knows why this all went tits up!

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 8:57

[GoogleCodeExporter]

I merged your changes and also realized that there were no state Converters for 
decimal to on/off open/closed items. Added those as well.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 9:20

[GoogleCodeExporter]

Knock wood, but since I've added a greenwave power bar at a difficult spot in 
my living room, the binding has been rock solid for over a week now. No init 
errors or problems whatsoever, although I keep switching the stick (virtually 
through ser2net) from my dev environment to my server daily.

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

[GoogleCodeExporter]

Yeah mine has been rock solid up until today as well. Was initialising every 
time, with just the occaisional error (duplicate node info). God knows what 
went wrong this evening but I am still unable to get it going...

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

[GoogleCodeExporter]

I think I have fixed it - and I think I know what it was...I have never done a 
Node Neighbour Update on Node 1 (i.e. the controller) via OZWCP. As a result I 
think the controller has always thought it could 'see' all my nodes (probably 
from when each node was included). 

However after trying just about everything else this evening I managed to send 
a Neighbour Update request to Node 1 and all of a sudden it is only reporting 
as being able to 'see' a few nodes. What this means I think, is that the 
controller is now not blindly trying to send messages to nodes it thinks it can 
see, but which are out of range. It is now using the mesh network properly and 
routing messages to these nodes through other nodes that are visible to the 
controller.

I think I might have solved all my timeout issues with this breakthru - fingers 
crossed!!! The binding has started up smoothly with no warnings or errors or 
timeouts, which is the first time I have seen this ever!

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

[GoogleCodeExporter]

BTW - I think implementing a schedule to delete and assign return routes could 
be useful - as long as it was optional - i.e. could be disabled. I get the 
feeling once a network is setup correctly you probably don't want to be messing 
with it much - and nodes should hardly ever move. 

Did you find that bug with a node not updating the isDead() property? 

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

[GoogleCodeExporter]

Great I fixed the advance node stage, in case that happens again. I'll commit 
shortly.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 10:27

[GoogleCodeExporter]

Have not been able to look at it yet. Have to "kill" a node, and since 
everything is pretty much connected or built in right now, I was thinking about 
installing a new one and test with that one. I'll do that tomorrow. Don't have 
time today.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 10:29

[GoogleCodeExporter]

Cheers mate - a very frustrating evening has brightened up considerably! Time 
for bed now. 

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

[GoogleCodeExporter]

Fixed the advancing node stage bug. It's in my clone.

BTW, what's the firmware of your stick? Aeon labs provides updates and it might 
pay off to update the FW.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 10:44

[GoogleCodeExporter]

I'm happy to announce that i've updated the METER command class to support 
version up until version 3. Now I can read all power and energy values from my 
greenwave (shuko) power bar. For €50 you get a 6 socket energy/power 
measuring switchable power bar. Not a bad deal!

config:

Switch Switch_Powerbar_Subwoofer "Subwoofer" (GF_Living) 
{zwave="26:1:command=switch_binary"} 
Switch Switch_Powerbar_Reiceiver "Versterker" (GF_Living) 
{zwave="26:2:command=switch_binary"} 
Switch Switch_Powerbar_DVD "DVD" (GF_Living) 
{zwave="26:3:command=switch_binary"} 
Switch Switch_Powerbar_TV "Televisie" (GF_Living) 
{zwave="26:4:command=switch_binary"} 
Switch Switch_Powerbar_Xbox "XBOX-360" (GF_Living) 
{zwave="26:5:command=switch_binary"} 
Switch Switch_Powerbar_PC "Mediacenter" (GF_Living) 
{zwave="26:6:command=switch_binary"} 

Number Power_Powerbar_Subwoofer "Subwoofer actueel verbruik  [%.1f W]" 
(GF_Living) {zwave="26:1:command=meter,meter_scale=E_W"} 
Number Power_Powerbar_Reiceiver "Versterker actueel verbruik  [%.1f W]" 
(GF_Living) {zwave="26:2:command=meter,meter_scale=E_W"} 
Number Power_Powerbar_DVD "DVD actueel verbruik  [%.1f W]" (GF_Living) 
{zwave="26:3:command=meter,meter_scale=E_W"} 
Number Power_Powerbar_TV "Televisie actueel verbruik  [%.1f W]" (GF_Living) 
{zwave="26:4:command=meter,meter_scale=E_W"} 
Number Power_Powerbar_Xbox "XBOX-360 actueel verbruik  [%.1f W]" (GF_Living) 
{zwave="26:5:command=meter,meter_scale=E_W"} 
Number Power_Powerbar_PC "Mediacenter actueel verbruik  [%.1f W]" (GF_Living) 
{zwave="26:6:command=meter,meter_scale=E_W"} 

Number Energy_Powerbar_Subwoofer "Subwoofer totaal verbruik  [%.2f KWh]" 
(GF_Living) {zwave="26:1:command=meter,meter_scale=E_KWh"} 
Number Energy_Powerbar_Reiceiver "Versterker totaal verbruik  [%.2f KWh]" 
(GF_Living) {zwave="26:2:command=meter,meter_scale=E_KWh"} 
Number Energy_Powerbar_DVD "DVD totaal verbruik  [%.2f KWh]" (GF_Living) 
{zwave="26:3:command=meter,meter_scale=E_KWh"} 
Number Energy_Powerbar_TV "Televisie totaal verbruik  [%.2f KWh]" (GF_Living) 
{zwave="26:4:command=meter,meter_scale=E_KWh"} 
Number Energy_Powerbar_Xbox "XBOX-360 totaal verbruik  [%.2f KWh]" (GF_Living) 
{zwave="26:5:command=meter,meter_scale=E_KWh"} 
Number Energy_Powerbar_PC "Mediacenter totaal verbruik  [%.2f KWh]" (GF_Living) 
{zwave="26:6:command=meter,meter_scale=E_KWh"} 

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 3:49

[GoogleCodeExporter]

Hmm Ben, i would not update to the latest version. There is something seriously 
wrong with the node stage advancing now...

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 5:13

[GoogleCodeExporter]

Hi JWSP!
I happily report that your binding (version 1.3.0) works very stable with my 
network for a couple of days.
The only problem left is that periodically my serial adapter changes its port 
and becomes /dev/ttyUSB1 instead of /dev/ttyUSB0, and the whole OpenHAB 
crashes. :( But it occurs not so often.

And if you have implemented the scales for METER command class - could you 
please implement the same thing for SENSOR_MULTILEVEL?

Original comment by roher.ro...@gmail.com on 17 Sep 2013 at 5:16

[GoogleCodeExporter]

No there is not. I had the same issues as you. Re-requesting neighbor info 
helped.

Original comment by jwsp...@gmail.com on 17 Sep 2013 at 5:40

[GoogleCodeExporter]

Sweet - so ok to update to your latest codeset? The meter changes look good, I 
have been noticing my one meter returning differing values depending on whether 
the switch is on or not - this should resolve that nicely!

Original comment by ben.jone...@gmail.com on 17 Sep 2013 at 8:18

[GoogleCodeExporter]

FYI - just updated the firmware in my USB stick to v3.07. I couldn't figure out 
how to determine what version it had originally but the upgrade went through 
ok. Things seem to be fine afterwards - thankfully it didn't lose any 
associations!

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

[GoogleCodeExporter]

Tried your latest code - the meter stuff is working great - good job. Will keep 
an eye out for any issues with the node advance stuff as well.

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

[GoogleCodeExporter]

You had version 2.78

Original comment by jwsp...@gmail.com on 18 Sep 2013 at 5:46

[GoogleCodeExporter]

How can you tell? I checked the OZWCP logs before and after the upgrade and I 
thought they were both reporting a Zwave serial version of 2.78.

Original comment by ben.jone...@gmail.com on 18 Sep 2013 at 6:37