Implement ZWave Binding

[GoogleCodeExporter]

General ZWave Support

Implement binding for ZWave Controller/Device/Network support. 

Original issue reported on code.google.com by bmcro...@gmail.com on 29 Apr 2013 at 12:25

[GoogleCodeExporter]

any device. It's really a case of flooding the stick.

Up until now i was quite aggressive... while not receiving anything of the 
stick, just send as much data to it as possible. This leads to a lot of CAN's 
(not really a problem, can resend) 

Problem with that is that a complete sequence with sendData and callback to a 
node takes:

1 PC SendData Request
2 stick ack
3 stick SendData Response with status
4 PC ack
5 stick SendData Request with callback ID and status
6 PC ack.
7 stick (Possibly node application data request)
8 PC ack.

Now with all the delays in between, especially during polling (but also during 
init), I sent more messages... this easily floods the stick, which gets you a 
SendData response with status 0x0X at step 3.

You can also try and wait out the sequence, before sending a new message, but 
the entire cycle takes a few 100ms... to0 much...

Original comment by jwsp...@gmail.com on 7 Aug 2013 at 8:12

[GoogleCodeExporter]

I've studied the sources of open-zwave and a python and c# implementation. It 
seems that they all serialize access to the stick with the concept of a 
"transaction", which is a sequence of messages. The transaction has an expected 
reply. Only when the expected reply is received, the current message is removed 
from the queue and the next message is sent. If during any of these stages an 
error occurs, the transaction is canceled and the message is put at the tail of 
the send queue (or a wake-up queue).

Now a couple of implementations also implement prioritizing the send queue to 
give initialization messages priority over commands and commands priority over 
statusses.

Sending and receiving is truly separated by two threads and signalling for the 
transaction is done using a mutex or something comparable.

It's not very difficult to implement this as well in this binding, so i'm 
planning on doing that next week.

Original comment by jwsp...@gmail.com on 8 Aug 2013 at 6:16

[GoogleCodeExporter]

I finally received my new devices. I have 'included' the door/window sensor 
(FGK-101) after attaching a DS18B20 temperature sensor and it is showing up in 
the ZWave binding logs as node 4. However opening/closing the sensor is not 
registering anything in the logs. I presume this type of device is not 
supported by the version of the binding I have, but I was expecting to see some 
messages appearing - even if they weren't recognised. I won't spend any more 
time on this until I get your latest code however, as obviously things have 
changed significantly now! Do you envisage this sensor working with the latest 
code, with a second endpoint for the temp sensor? Cheers, Ben.

Original comment by ben.jone...@gmail.com on 8 Aug 2013 at 10:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

JW:

Have you committed your code to your clone? I don't see any zwave bindings in 
it when i am attempting to merge.

Original comment by bmcro...@gmail.com on 11 Aug 2013 at 2:28

[GoogleCodeExporter]

It's there in the 1.3.0-zwave binding. Branch. My plane just landed. I will 
pick up tomorrow where I left off last week.

Original comment by jwsp...@gmail.com on 12 Aug 2013 at 10:11

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Ben, I cannot tell whether your sensor will work. I think not, because probably 
it is a multi-level sensor and I only implemented binary sensor. Good news is 
that the new binding should report the (unsupported) command classes in the 
debug log, so if you would be so kind as to upload it here, i'll have a look at 
it.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 2:53

[GoogleCodeExporter]

It seems that I've squashed the send / receive bugs. To tackle this I have 
serialized access to the controller and added the concept of a transaction.
Sadly I had to remove the separation between the serial interface and the 
Z-Wave controller class. Errors at the serial interface level also influence 
the transaction at the controller level. It felt more natural to combine them, 
than create some complex signalling mechanism between the serial interface and 
the controller class.

I also added message prioritization and notification of completed messages.

As promised the binary bindings for 1.2 and 1.3.0 snapshot. Please test. When 
encountering bugs, please include a full debug log and report your issue here. 

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 3:39

Attachments:

• org.openhab.binding.zwave-1.2.0-SNAPSHOT.jar
• org.openhab.binding.zwave-1.3.0-SNAPSHOT.jar

[GoogleCodeExporter]

I've written the start of a wiki page (in word, no permission to create wiki 
pages). Please expand / correct. Also check for spelling errors since English 
is not my native language.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 4:17

Attachments:

• [text zwave binding.docx](https://storage.googleapis.com/google-code-attachments/openhab/issue-265/comment-110/text zwave binding.docx)

[GoogleCodeExporter]

You now have wiki edit rights as well - feel free to put it directly there!

Original comment by kai.openhab on 14 Aug 2013 at 4:22

[GoogleCodeExporter]

Thanks. I will this evening.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 4:46

[GoogleCodeExporter]

https://code.google.com/p/openhab/wiki/ZWaveBinding

Wikipage is there. Please edit there directly or post changes here.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 7:30

[GoogleCodeExporter]

Hey Jan - attached is my debug log. I have the following setup;

Node 1 - Aeontec USB stick v2
Node 2 - Single switch (in-wall) Hallway Treads
Node 3 - Double switch (in-wall) Garden Lights
Node 4 - Door/window sensor
Node 5 - Double switch (in-wall) Garage Lights

With the latest version of your binding Nodes 1, 2, and 3 are working 
perfectly. Node 4 is being recognised (from what I can tell in the logs) but is 
never waking up or reporting any messages. And Node 5 is no longer working 
(this was working with the previous version of the binding).

I was wondering if I hadn't paired the door/window sensor properly, but the 
fact the controller is reporting it tells me it was linked ok? But nothing is 
coming back from it. I might have a go at re-pairing and seeing if that helps.

Not sure why Node 5 has died though. 

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 8:43

Attachments:

• zwave.zip

[GoogleCodeExporter]

I'll have a look at your logs. Pairing will probably not help. The fact that it 
shows is a good indication that it is still paired. Please note that for 
instance for my sensor, the wake-up interval is 3600 seconds! So it can take up 
to an hour for my sensor to initialize.

Node 5 seems to be the victim of node 4 not initializing. I will try and create 
the same situation here. My battery operated device is the last node. I will 
add another device with a higher node ID to my network to create the same 
situation.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 8:54

[GoogleCodeExporter]

Yeah I was wondering if that had something to do with (Node 4 not initialising 
inhibiting Node 5). Let me know if there is anything else you would like me to 
try/test.

BTW - thanks again for the fantastic work you are doing on this!

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 8:59

[GoogleCodeExporter]

Hmmm... maybe I spoke too soon. The maximum interval for your device seems to 
be 255 seconds. You could try and get it working first in the open-zwave 
control panel. If you're sure that it works and that you get wake-up events, 
then retry the binding.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 9:03

[GoogleCodeExporter]

Is there a version of the open-zwave control panel for Windows? My openHAB 
server is headless Ubuntu. I have had a quick look and can only see compiled 
versions for RPi and OS X. Sorry - haven't used that tool before, but it looks 
to be very useful!

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 9:06

[GoogleCodeExporter]

Too bad. Adding an extra device to my network keeps working:

23:26:01.259 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 1 has been in Stage 
Node Complete since Wed Aug 14 23:25:21 CEST 2013
23:26:01.259 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 3 has been in Stage 
Node Complete since Wed Aug 14 23:25:25 CEST 2013
23:26:01.260 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 6 has been in Stage 
Node Complete since Wed Aug 14 23:25:27 CEST 2013
23:26:01.260 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 10 has been in 
Stage Node Complete since Wed Aug 14 23:25:29 CEST 2013
23:26:01.260 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 11 has been in 
Stage Node Complete since Wed Aug 14 23:25:32 CEST 2013
23:26:01.260 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 12 has been in 
Stage Ping Node since Wed Aug 14 23:25:22 CEST 2013
23:26:01.261 DEBUG o.o.b.z.i.p.ZWaveController[:845] - Checking if 1 min has 
passed in current stage.
23:26:01.261 DEBUG o.o.b.z.i.p.ZWaveController[:838] - Node 13 has been in 
Stage Node Complete since Wed Aug 14 23:25:47 CEST 2013

 I'll have to dig deeper into your logs. Hold on.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 9:27

[GoogleCodeExporter]

I don't think so. There are instructions for ubunto though. 
http://www.strengholt-online.nl/howto-compile-open-zwave-and-openzwave-control-p
anel-on-ubuntu/

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 9:28

[GoogleCodeExporter]

Ben.. I've got 3 times a failed ping from Node 5 in your network... The stick 
actively reports it back as failed...

2013-08-15 08:22:56 DEBUG o.o.b.z.i.c.ZWaveNoOperationCommandClass[:86]- 
Creating new message for application command No Operation for node 5
2013-08-15 08:22:56 DEBUG o.o.b.z.i.p.SerialMessage[:108]- Creating empty 
message of class = SendData (0x13), type = Request (0x00)
2013-08-15 08:22:56 DEBUG o.o.b.z.i.p.ZWaveController[:1020]- Callback ID = 5

2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:227]- Message: class = 
SendData (0x13), type = Request (0x00), buffer = 01 07 00 13 05 01 00 00 EF 
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:248]- Message type = 
REQUEST
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:359]- Handle Message 
Send Data Request
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:365]- CallBack ID = 5
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:366]- Status = 0x01
2013-08-15 08:23:00 ERROR o.o.b.z.i.p.ZWaveController[:407]- Got an error while 
sending data to node. Resending message.
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:1020]- Callback ID = 13

2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:359]- Handle Message 
Send Data Request
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:365]- CallBack ID = 13
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:366]- Status = 0x01
2013-08-15 08:23:00 ERROR o.o.b.z.i.p.ZWaveController[:407]- Got an error while 
sending data to node. Resending message.
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:1020]- Callback ID = 14

2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:248]- Message type = 
REQUEST
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:359]- Handle Message 
Send Data Request
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:365]- CallBack ID = 14
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:366]- Status = 0x01
2013-08-15 08:23:00 ERROR o.o.b.z.i.p.ZWaveController[:407]- Got an error while 
sending data to node. Resending message.
2013-08-15 08:23:00 DEBUG o.o.b.z.i.p.ZWaveController[:1003]- Node 5 is dead, 
not sending message.

It seems that you have to re-add / reconfigure your network using open-zwave 
control panel or some other Z-Wave software until you have all five devices 
reporting ready. Then please retry the binding.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 9:36

[GoogleCodeExporter]

The indicated Status code 0x01 indicates that the message timed out while 
waiting for the acknowledgement. The time stamps are strange though. The first 
time it's 4 seconds. That's rather long. The second and third time are instant 
though, that's weird...

Although this could have to do with the logger time resolution.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 9:55

[GoogleCodeExporter]

Ok - thanks Jan. I just reinstalled the earlier version of your binding and
can confirm that Node 5 is receiving commands from openHAB and turning the
lights on/off.

But looking at the logs the node is still being reported as 2013-08-15
09:54:31 DEBUG o.o.b.z.i.p.ZWaveController[:165]- Node 5 is in Stage Node
Dead or Sleeping.

I had a quick look in your code and noticed you had changed some logic which
means messages are not sent if the node is reported as dead or sleeping.
Does that sound about right?

So my guess is that this node is perhaps unable to send messages back to the
controller, but is still able to receive messages. Does that sound like a
possible scenario?

I did notice that if I manually switched the garage lights on, the state
isn't being updated in openHAB like it does for the other nodes. So this
adds further weight to my theory.

Assuming this is the case I think your binding is fine. I need to see if I
can rearrange the aerial in the micro switch to get better range (not sure
how much luck I will have with that).

I am trying to compile the openzwave control panel but am getting errors in
the last stage. I will continue to trouble shoot and try and get it up and
running as it is obviously a very useful tool.

That will hopefully guide me in the right direction with the door/window
sensor. 

Many thanks for your help!!

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 10:08

[GoogleCodeExporter]

Sounds plausible.I have also had a wrong association with the controller. The 
node must be associated in one of it's groups (last one I think) with the 
controller to be able to report back to it.

You can also have the nodes see each other by learning their neighbour nodes 
and / or specify return routes. All can be initiated / configured by the 
control panel.

Original comment by jwsp...@gmail.com on 14 Aug 2013 at 10:35

[GoogleCodeExporter]

I have managed to get the openzwave control panel running and can see my
network.

It is reporting Node 5 as dead. Do you think my theory about the device
being able to receive but not transmit back has merit?

I have excluded and re-included the door sensor so it is now Node 6 and it
just says the status 'Probe (sleeping)'. I clicked on 'Information' details
and it says the Wakeup Interval is 3600. I am not sure what this means
however? For a battery powered sensor what causes the device to 'wakeup'? I
am opening/closing the sensor, right next to the controller stick, but
nothing is happening in the control panel. If I click on 'Current Values'
for the sensor it shows nothing. For the two active switch nodes when
clicking on 'Current Values' I get a UI showing the values and the ability
to send commands. Does this lack of UI tell me anything? Is this device just
not being identified properly?

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 10:49

[GoogleCodeExporter]

Ok - so I removed and re-add the troublesome dual switch node and it was being 
recognised, going through the initialisation stages, reporting its version etc. 
I was even able to send commands (and them be acknowledged) from the control 
panel. However it never reached 'Ready' and then after a while was reported as 
'Dead'. Now it won't report/do anything. Once marked as Dead it seems the 
controller just assumes it is literally that - dead. I did notice the 
Application Version was different to the working dual switch I have installed 
so I have emailed the supplier to find out what the story is there. And still 
nothing being reported by the door sensor...I better do some work but will 
continue with this tonight. Thanks again for your help.

Original comment by ben.jone...@gmail.com on 14 Aug 2013 at 11:33

[GoogleCodeExporter]

Ok - I moved the controller USB stick to another PC and ran up openHAB (Windows 
PC). This machine is a lot closer to the node causing issues, and sure enough 
it works fine here. The other nodes, which are not all that far away, are now 
out of range and get marked as dead. Seems this Aeotec USB stick has pretty 
poor range, or perhaps it is the Fibaro devices?

So I think that explains the dead node. But I can't get anywhere with the door 
sensor. It just doesn't want to report anything.

I did notice the following in the logs (on the test machine) before I enabled 
full DEBUG logging;

15:11:56.121 INFO  o.o.b.z.i.c.ZWaveWakeUpCommandClass[:173]- Got Wake Up 
Notification from node 7, continuing initialization.
15:11:56.156 WARN  o.o.b.z.i.c.ZWaveCommandClass[:158]- Unsupported command 
class ASSOCIATION (0x85)
15:11:56.157 WARN  o.o.b.z.i.c.ZWaveCommandClass[:158]- Unsupported command 
class CONFIGURATION (0x70)
15:11:56.158 WARN  o.o.b.z.i.c.ZWaveCommandClass[:158]- Unsupported command 
class BATTERY (0x80)
15:11:56.160 WARN  o.o.b.z.i.c.ZWaveCommandClass[:158]- Unsupported command 
class FIRMWARE_UPDATE_MD (0x7a)

I am wondering if this device needs something to be sent to it before it will 
associate with the controller properly? Since it is a security device perhaps 
it needs some sort of authentication or setup message to be sent?

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 3:25

[GoogleCodeExporter]

Ok - think the sensor is working (at least on the Windows test machine) - see 
the attached log. It still doesn't look like it is reporting open/close events, 
but it is getting 'woken up'. Sorry but I don't know what the lifecycle should 
look like so I am a bit lost. Is this just a case of the command classes not 
being implemented yet in the binding? I would have expected to see messages 
coming back when the sensor is opened/closed - or am I missing something?

Sorry for the continued updates!!

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 3:46

Attachments:

• openhab.zip

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

First the good news. Your sensor is working. It has woken up and shows a 
wake-up interval of 120 seconds. It has the command classes SENSOR_ALARM and 
BINARY_SENSOR which are both supported. (Ignore the target node, it’s a typo, 
the repeated wake-up interval. I’ve fixed that already).

15:38:42.827 DEBUG o.o.b.z.i.c.ZWaveWakeUpCommandClass[:136]- Wake up interval 
report for nodeId = 7, value = 120 seconds, targetNodeId = 120

Now the sensor reports it’s alarm types, and here is where it goes wrong… 
The binding cannot decode the supported alarm types. This way incoming alarm 
events are not recognized.

The sensor reports it’s alarm types in very strange way… Your sequence is: 
00 03 02 01 05 04. This translates with some bit shifting and so on to alarm 
types 8, 9, 17, 24, 32, 34, 42… As a comparison, my flood sensor gives 
sequence: 20, which translates to alarm type 5. Now the list of supported types 
is below. 5 makes sense, but your values are completely out of range.

GENERAL(0, "General"), 
SMOKE(1, "Smoke"),
CARBON_MONOXIDE(2, "Carbon Monoxide"), 
CARBON_DIOXIDE(3, "Carbon Dioxide"), 
HEAT(4, "Heat"),
FLOOD(5, "Flood");

It’s actually a problem as well in open-zwave… And this is the only source 
I have on how to implement sensor_alarm, so this is where I got the decoding 
routine of the bitmask. 

https://code.google.com/p/open-zwave/issues/detail?id=143

I think, but this is a maybe… That fibaro fucked up the encoding of the alarm 
sensor types and just presents a byte list of supported types. 0,3,2,1,5,4 
actually means all types are supported. 
What I will do is create an alternate way of decoding the sensor type values, 
based on your reported device and manufacturer ID.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 8:37

[GoogleCodeExporter]

You’ve obviously got some issues with the topology of your network. Z-Wave is 
a mesh network, this means that all (repeating) nodes are able to route 
messages to another node in the network. This way the network becomes way more 
robust and reliable. For instance, if you look at my network topology (send me 
yours, it’s an option in open-zwave panel), that is attached as a txt file to 
my post:
You will see that node 11 is furthest away from the controller and it can only 
communicate with my controller through node 3 or 12. Node 13 is purposely 
disconnected, so it does not report it’s neighbors, but some other nodes have 
seen it before, so that shows as well.
The controller has to “learn” which routes are available so that it can 
send the message to the right nodes immediately. It has to form an “image” 
of the network. The same is through for the nodes themselves, they have to know 
how to reach the rest as well.
Best way to do this is to install the controller in it’s final position, and 
use the control panel to update the nodes and the controller. Now, I 
experienced similar problems in the beginning and the way I did this (and I’m 
not sure this is the best way, because I’ve spent some hours on this as 
well), is as follows:
1.  Request a node neighbor update list for every node that is reachable from 
the controller.
2.  Check the topology to see whether some unreachable node is reachable by 
another node.
3.  Send test & heal messages to the non responding node (a couple, 5 to 10 or 
so).
4.  Close the connection to the stick from the control panel
5.  Initialize the connection to the stick from the control panel.
6.  The non reachable node should be initializing now. This maybe gives new 
routes, so start at step 1 again.

After a couple of tries this way I completely got my network working. It’s 
best to have the battery operated device fully awake during this process. My 
flood sensor has a button that keeps it awake for 15 minutes constantly to 
facilitate this process. Some battery operated devices need removal / 
re-inclusion for this or removal of the battery and putting it back in. Check 
the manual of the device for that.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 9:16

Attachments:

• topology.txt

[GoogleCodeExporter]

I'm pretty sure that it is a bug in the firmware. the device incorrectly lists 
the alarm types byte by byte, instead of as a bitmap as normal devices do.

Anyway I've created a new version of the binding. It should display "Detected 
Fibaro FGK - 101 Door / Window sensor, activating workaround for incorrect 
encoding of supported alarm bitmap." in the log somewhere in the initialization 
process and then list the supported alarm types.

You can bind the node to a contact item. It should display OPEN / closed.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:53

Attachments:

• org.openhab.binding.zwave-1.2.0-SNAPSHOT.jar
• org.openhab.binding.zwave-1.3.0-SNAPSHOT.jar

[GoogleCodeExporter]

Ok I am definitely making progress. Following your steps above I have been able 
to get the 'distant' node recognised by one of my other nodes (see the attached 
topology). It is now being initialised in the network and hopefully will begin 
playing ball! God knows how you figured out those steps but I am very 
appreciative to you for sharing them! 

As for the sensor, I spent a bit of time this afternoon looking through your 
alarm command class implementation and comparing it to the OpenZWave stuff. I 
follow exactly what you are saying, and yes I think your assumption is probably 
quite accurate. I would still have expected to see the ALARM messages coming 
back, even if the REPORT message wasn't understood by the controller tho? That 
was the bit that confused me. 

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 11:03

Attachments:

• topology.txt

[GoogleCodeExporter]

Ok - definite progress with the alarm sensor. The messages are being reported, 
but not handled...

2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:134]- Creating new 
SerialMessage from buffer = 01 09 00 04 00 07 03 20 01 FF 28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:179]- Calculated checksum 
= 0x28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:138]- Message checksum 
calculated = 0x28, received = 0x28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:140]- Checksum matched
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:152]- Message Node ID = 255
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:153]- Message payload = 00 
07 03 20 01 FF
2013-08-15 23:14:25 DEBUG 
o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1260]- Message is valid, 
sending ACK
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:226]- Incoming message 
to process
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:179]- Calculated checksum 
= 0x28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message 
buffer = 01 09 00 04 00 07 03 20 01 FF 28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:227]- Message: class = 
ApplicationCommandHandler (0x04), type = Request (0x00), buffer = 01 09 00 04 
00 07 03 20 01 FF 28
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:248]- Message type = 
REQUEST
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:316]- Handle Message 
Application Command Request
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:318]- Application 
Command Request from Node 7
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:334]- Incoming command 
class %s (0x%02x)
2013-08-15 23:14:25 DEBUG o.o.b.z.i.p.ZWaveController[:343]- Found Command 
Class BASIC, passing to handleApplicationCommandRequest
2013-08-15 23:14:25 DEBUG o.o.b.z.i.c.ZWaveBasicCommandClass[:83]- Handle 
Message Basic Request
2013-08-15 23:14:25 DEBUG o.o.b.z.i.c.ZWaveBasicCommandClass[:84]- Received 
Basic Request for Node ID = 7
2013-08-15 23:14:25 WARN  o.o.b.z.i.c.ZWaveBasicCommandClass[:89]- Command 0x01 
not implemented.

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

[GoogleCodeExporter]

Unfortunately even though the openzwave control panel is reporting Node 8 is 
accessible via Node 2, the openHAB binding is unable to 'see' Node 8 during 
initialisation and seems to mark it as Dead. Then subsequently any attempts to 
send a command to that node are aborted.

Or am I being too impatient...? Will Node 8 be brought back to life if the 
network can find a route to it? Or is it finished once it is marked Dead?

2013-08-15 23:16:05 DEBUG o.o.b.z.i.ZWaveActiveBinding[:239]- 
internalReceiveCommand(itemname = Lights_Garage, Command = ON)
2013-08-15 23:16:05 DEBUG o.o.b.z.i.ZWaveActiveBinding[:256]- BindingProvider = 
org.openhab.binding.zwave.internal.ZWaveGenericBindingProvider@2c4eeb91
2013-08-15 23:16:05 DEBUG o.o.b.z.i.ZWaveActiveBinding[:257]- Got nodeId = 8, 
endpoint = 1, action = NONE
2013-08-15 23:16:05 DEBUG o.o.b.z.i.ZWaveActiveBinding[:272]- ZWaveController 
is connected
2013-08-15 23:16:05 DEBUG o.o.b.z.i.ZWaveActiveBinding[:274]- Sending ON
2013-08-15 23:16:05 DEBUG o.o.b.z.i.c.ZWaveBinarySwitchCommandClass[:133]- 
Creating new message for application command SWITCH_BINARY_SET for node 8
2013-08-15 23:16:05 DEBUG o.o.b.z.i.p.SerialMessage[:108]- Creating empty 
message of class = SendData (0x13), type = Request (0x00)
2013-08-15 23:16:05 DEBUG o.o.b.z.i.p.ZWaveController[:902]- Encapsulating 
message for node 8, instance / endpoint 1
2013-08-15 23:16:05 DEBUG o.o.b.z.i.p.ZWaveController[:1003]- Node 8 is dead, 
not sending message.

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 11:20

[GoogleCodeExporter]

Still not quite right. After restarting openHAB I got all nodes reaching 
'Complete' for the first time ever! But sending commands to Node 8 is still 
failing. Attached are my debug logs for the binding from startup this latest 
time.

Unfortunately it is getting late here and I need to get some sleep. I will be 
online again in about 8-9 hours and will happily pick this up again, I feel 
like I am making some real progress here.

I am very appreciative of your efforts to assist me here Jan-Willem!!

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 11:32

Attachments:

• zwave.zip

[GoogleCodeExporter]

Just noticed that even though the binding started ok and got Node 8 to 
completed, it is now being reported as Dead. And hence no commands are getting 
through. Seems that if I run openzwave control panel and let it get everything 
sorted, then run the binding it initialises ok, but eventually loses 'sight' of 
Node 8 once I shutdown the control panel. Not sure if that is remotely feasible 
but I am tired and am probably not making much sense!

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 11:34

[GoogleCodeExporter]

It's clearly a range issue. Even during the initialization phase multiple 
messages time out. After 3 re-submissions I set the node to dead. You got to 
two re-submissions during init, but then the node responded, so it finished 
initialization. Afterwards a poll message timed out after 3 times.

Now I've changed the binding, so that on an incoming message I reset the node 
status to alive as well. This way when the node reports again (by pressing the 
switch for example) and the message makes it to the controller, the node will 
be alive again.

It does not solve your problem though. Node 8 is too far from node 2 to 
reliably transmit a message every time. The best way to proceed would be to 
place a routing (grid-powered) device somewhere in the middle and let the 
network relearn. 

Just curious... What kind of walls do you have (concrete, brick, drywall) and 
what is the distance between these nodes?

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 12:35

Attachments:

• org.openhab.binding.zwave-1.3.0-SNAPSHOT.jar
• org.openhab.binding.zwave-1.2.0-SNAPSHOT.jar

[GoogleCodeExporter]

Your sensor is almost correct. It works, but a parameter is wrongly defined. 
You need to set parameter 5 of the device to 0 (zero) instead of 255. Now it 
sends a basic SET command to the controller as if it is another node that can 
be controlled this way (eg a switch or a dimmer). It needs to report and alarm, 
so you need to set it to 0 (generic alarm).

http://www.fibaro.com/files/instrukcje/eng/DoorWindowSensor%20FGK-101-107%20ENG_
v21-v23.pdf

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 12:51

[GoogleCodeExporter]

And to set a parameter you use open-zwave control panel.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 1:26

[GoogleCodeExporter]

OK, I've actually implemented BASIC SET for the controller as a level report. 
This means you can leave the parameter (though it's better to set it, this is 
not standard).

The only catch is that you have to bind it to a switch with BASIC SET or bind 
it to a contact for ALARM. 

I've also included the command class and action for battery levels, so that you 
can report battery levels. Seemed fun.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 4:09

Attachments:

• org.openhab.binding.zwave-1.2.0-SNAPSHOT.jar
• org.openhab.binding.zwave-1.3.0-SNAPSHOT.jar

[GoogleCodeExporter]

Hi guys!

It's a completely amazing job you all did developing Z-Wave binding. Starting 
it's prototype several months ago I had no idea it would ever go that far! :-)
I have a small suggestion though. I think everybody wants to get Z-Wave very 
much in 1.3.0 release which as you know will happen on September 8th. So my 
proposal is to target Z-Wave binding for this release, even if it doesn't 
support all possible Z-Wave devices and publish it with 'known limitations', 
i.e. list of devices/device types and features which are supported, concentrate 
on binding stability and get to review by Thomas and Kai before the end of 
August. And then, after 1.3.0 release concentrate on introducing new devices, 
workarounds for buggy vendors and so on :-)

p.s. No kidding! This is absolutely amazing. Probably it is the biggest thing 
developed for openHAB by community so far!

Best regards,
Victor Belov

Original comment by belovic...@gmail.com on 15 Aug 2013 at 6:28

[GoogleCodeExporter]

Thanks. I absolutely agree about getting the binding ready. I do need some 
feedback for that. The binding works for me, but that's not the best indication 
I guess. I'm purposely holding off from implementing things like thermostats, 
querying values on startup, adding nodes dynamically to the network etc. for 
now.

So guys please test and report. I'll try and resist the urge to put in new 
stuff. To me the binding is ready for review, so Thomas, Kai be my guest.

One question... Do I have to merge the latest changes from the openHAB default 
branch into my branch? There is something changed in the isProperlyConfigured 
handling and the version numbers need to be updated. I can do that, or leave it 
up to the person merging into default.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 8:29

[GoogleCodeExporter]

Jan - answers to your questions;

1. What sort of walls do I have - standard 90mm timber framing with 13mm 
plaster board lining. There are insulation batts in all the walls (including 
interior). The problematic node is in the garage however, which is behind a 
50mm aerated concrete panel so that is probably not helping things. The 
distance from the controller is only about 10m though so I am a little 
disappointed by the range.

2. Agree that range is the issue here. I am going to try adding another node a 
bit closer to increase the 'mesh'. Unfortunately there isn't much between the 
controller and the garage I want to control!

3. I can't figure out how to set PARAMETER 5 on the alarm sensor using the 
OpenZWave control panel. Nothing shows up for any node type if I click on the 
'Configuration' radio button (below the device list). And there is nothing list 
anywhere else that I can see for setting device parameters.

4. What is the syntax for binding to the battery level for the sensor?

I agree with you Victor that we need to get this as stable as possible. I am 
trying to do as much testing as I can, but am obviously having issues. From 
what I can tell the binding is very stable at this point, considering how much 
work Jan-Willem has done. I will be continuing to test it as much as I can.

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 9:15

[GoogleCodeExporter]

Jan,

Thanks for agreeing on this! :-)
I'm unpacking my Z-Wave stuff and will start helping you with testing on 
monday, promise! :-)

Ben,

Thank you for putting so much effort in testing it!

Best regards,
Victor Belov

Original comment by belovic...@gmail.com on 15 Aug 2013 at 9:22

[GoogleCodeExporter]

Ben, the XML config file which lists the manufacturer info does not list 
deviceId 3000, only 1000 in open zwave. Copy the line in manufacturer XML and 
change 1000 to 3000. It will work then.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 9:41

[GoogleCodeExporter]

I have 7 meters of range and 200mm concrete between a node and my controller 
and it does not work either. Luckily there is another device in between. So 10m 
and 50mm concrete sounds plausible.

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 9:45

[GoogleCodeExporter]

I have updated the manufacture XML file and copied the line as you said. 
However still nothing. I think I am somehow missing that configuration when 
running the control panel. As you can see all my devices are listed with 
'unknown ids' where 010f is cleared configred as Fibaro in that XML file.

Confused!

1 *LB   Static Controller   Unknown: id=0086 Unknown: type=0002, 
id=0001             10:08:34    Ready
2 LBR   Routing Slave       Unknown: id=0086 Unknown: type=0003, 
id=0012         off 10:08:27    Probe1
3 LBR   Routing Slave       Unknown: id=010f Unknown: type=0200, 
id=0109         off 10:08:27    Probe1
7 BR    Routing Slave       Unknown: id=010f Unknown: type=0700, 
id=3000         off 10:08:29    Probe1 (sleeping)
8 LBR   Routing Slave       Unknown: id=010f Unknown: type=0200, 
id=300a         off 10:08:27    Probe1

Original comment by ben.jone...@gmail.com on 15 Aug 2013 at 10:13

[GoogleCodeExporter]

!BTW, to anyone merging this: I've tagged a commit for myself before I complete 
turned the binding around. You probably do not want to merge the tag in the 
.hgtags file...

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:13

[GoogleCodeExporter]

Yeah, you are missing the config files.. You should copy them from open-zwave 
and place them in a config folder in the open-zwave control panel root...

Original comment by jwsp...@gmail.com on 15 Aug 2013 at 10:15