Ole8700 / openhab

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

Implement ZWave Binding #265

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
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 commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
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 commented 9 years ago
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