Closed GoogleCodeExporter closed 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
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
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
[deleted comment]
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
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
Original issue reported on code.google.com by
bmcro...@gmail.com
on 29 Apr 2013 at 12:25