Closed GoogleCodeExporter closed 8 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
[deleted comment]
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
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:
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:
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
Thanks. I will this evening.
Original comment by jwsp...@gmail.com
on 14 Aug 2013 at 4:46
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
[deleted comment]
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
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:
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:
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:
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
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
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:
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
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:
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
And to set a parameter you use open-zwave control panel.
Original comment by jwsp...@gmail.com
on 15 Aug 2013 at 1:26
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:
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
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
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
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
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
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
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
!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
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
Original issue reported on code.google.com by
bmcro...@gmail.com
on 29 Apr 2013 at 12:25