Z-Wave Philio Multi-Sensor PSM02

[franz.di...@gmail.com]

I am having some trouble with my "Philio Multi-Sensor PSM02".

First of all it does not yet seem to be included in the "HABmin" database (Cheers Chris) and it would be helpful if it were.

And I do not know how to receive the motion and door/window status. In fact I don't even know what the generic "zwave:id:1" ("id" being the node ID) binding string for a Contact delivers. When I look at the events when I close the door there is a event that seems to report it being closed followed immediately by to other (both are the same) events that report the opposite status. That could in fact be a bouncing of the open/close sensor, but the magnet is really close so this is not very likely.

I did some experiments with "sensor_binary" combined with "sensor_type" (10 and 12 in this case). But I don't get the results I am looking for.

Any ideas?

[Chris Jackson]

I’ve generated the file for the PSM02 - the help probably needs some formatting at some stage, but at least it will be usable. I’ll create a PR soon.

I have two sensors like this - neither are Philio sensors, but they are different makes, and I simply use zwave="16:1”. I note that in your message you put zwave:id:1 = the first : should be an equal (=) as in my example.

The other thing you might need to do is to set an association - probably setting group 2 to include the controller (node 1) as a member might help.

Chris

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

[franz.di...@gmail.com]

Thanks for providing the XML, Chris.

The first ":" was a typo in my posting only.

[franz.di...@gmail.com]

Part of my question remains.

The instruction sheet for the sensor says that it will send a "Sensor Binary Report" to the nodes in group 1 in case it wants to send a Door/Window report, with "Sensor Type" = 0x0A and sensor values 0x00 and 0xFF respectively. For a motion report it is "Sensor Type" = 0x0C.

Can I receive reports like this with the current implementation/syntax?

I would expect something like "{ zwave="5:1:command=sensor_binary,sensor_type=10" }" to work.

Does that make sense and it is only not implemented (yet) or is there something that makes this nonsense?

Cheers

Dieter

[ritu...@gmail.com]

Hi guys!

Chris, do you know something about Dieter's last question? Is there any way to differentiate between open/close and motion messages?

Many many thanks for the truly awesome work you are doing for this community, you rock man! And thanks also for the rest of the members of the community (Kai, Thomas, Ben...), this program is excellent!

Best regards from Spain,

Aitor

[Chris Jackson]

>
> Chris, do you know something about Dieter's last question? Is there any way to differentiate between open/close and motion messages?

Sorry - no, I don’t know this sensor well. However, if you can put the log into debug mode, and capture incoming messages for the two sensor types, I’ll take a look and see what I can see.

Cheers
Chris

[ritu...@gmail.com]

Hi again Chris!

It seems that it won't be possible to differentiate between the type of messages :( Attached to the message I have uploaded a newly generated debug log file, perhaps it's too long, but I'm going to talk about it now.

At 12:43:35.413 starts a test that I did where I first simulate motion (I move my hand in front of the sensor) and later on I open/close the door sensor. As you can see this is the message generated by the motion detection:

2014-05-04 12:43:35.413 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0C 37 

2014-05-04 12:43:35.415 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 FF 0C 

2014-05-04 12:43:35.416 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-04 12:43:35.416 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-04 12:43:35.416 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:71]- NODE 2: Received Sensor Binary Request

2014-05-04 12:43:35.417 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:81]- NODE 2: Sensor Binary report, value = 0xFF

2014-05-04 12:43:35.417 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners

2014-05-04 12:43:35.417 DEBUG o.o.b.z.i.ZWaveActiveBinding[:361]- ZwaveIncomingEvent

2014-05-04 12:43:35.418 DEBUG o.o.b.z.i.ZWaveActiveBinding[:382]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 255

After every motion or open/close detection the sensor sends information about the temperature and illumination values it measure, that's normal so don't worry about that.

Some lines down, at 12:43:39.699, a door opened message is received:

2014-05-04 12:43:39.699 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0A 31 

2014-05-04 12:43:39.701 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 FF 0A 

2014-05-04 12:43:39.702 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-04 12:43:39.702 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-04 12:43:39.703 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:71]- NODE 2: Received Sensor Binary Request

2014-05-04 12:43:39.703 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:81]- NODE 2: Sensor Binary report, value = 0xFF

2014-05-04 12:43:39.703 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners

2014-05-04 12:43:39.703 DEBUG o.o.b.z.i.ZWaveActiveBinding[:361]- ZwaveIncomingEvent

2014-05-04 12:43:39.704 DEBUG o.o.b.z.i.ZWaveActiveBinding[:382]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 255

Finally, the door closed message is received at 12:43:40:664:

2014-05-04 12:43:40.664 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:971]- Receive Message = 01 0A 00 04 00 02 04 30 03 00 0A CE 

2014-05-04 12:43:40.666 DEBUG o.o.b.z.i.p.ZWaveController[:150]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 00 0A 

2014-05-04 12:43:40.667 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-04 12:43:40.667 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-04 12:43:40.667 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:71]- NODE 2: Received Sensor Binary Request

2014-05-04 12:43:40.668 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:81]- NODE 2: Sensor Binary report, value = 0x00

2014-05-04 12:43:40.668 DEBUG o.o.b.z.i.p.ZWaveController[:376]- Notifying event listeners

2014-05-04 12:43:40.668 DEBUG o.o.b.z.i.ZWaveActiveBinding[:361]- ZwaveIncomingEvent

2014-05-04 12:43:40.669 DEBUG o.o.b.z.i.ZWaveActiveBinding[:382]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 0

Let's summarize the messages received after each event:

Motion:     complete message: 01 0A 00 04 00 02 04 30 03 FF 0C 37;     Payload: 00 02 04 30 03 FF 0C

Opened:   complete message: 01 0A 00 04 00 02 04 30 03 FF 0A 31;     Payload: 00 02 04 30 03 FF 0A

Closed:     complete message: 01 0A 00 04 00 02 04 30 03 00 0A CE;    Payload: 00 02 04 30 03 00 0A

Oh, I was wrong then, my first sentence of the message is not true. Although both type of detections are reported as SENSOR_BINARY (0x30) messages, it seems that there is a common difference in the payload for motion and open/close. This in fact corresponds to what we can read in the manual of the sensor and what Dieter pointed out in his last message. Here it is what the manual tells us:

Motion report:

When the PIR motion detected, the device will unsolicited to send the Sensor Binary Report to the nodes in the group 1.

Sensor Type: Motion (0x0C)
Sensor Value: 0xFF

Door/Window Report:

When the Door/Window state changed, the device will unsolicited to send the Sensor Binary Report to the nodes in the group 1.

Sensor Type: Door/Window (0x0A)

Sensor Value: 0x00 is closed, 0xFF is opened.

Do you know if something can be done to define different items that are attached to each motion or door/window report? If you need more information don't hesitate to ask, I'm very new to openhab and zwave but I will do my best to report as much information as needed.

Sorry for my very long post and for my level of English, if you don't understand anything please ask and I will try to explain myself in a different way.

Thanks again for your awesome work and best regards,

Aitor

PS: I don't understand why in HABmin my device appears as Node 2 but it's Manufacture ID, Device ID and Device Type are 0 and it's Version is 4. Tt's not recognized as as a Philio PSM02 device although the device description is in the Product Explorer tab. Information is reported fine so for now I'm not worried about that, the shame is that I can't change the Configuration Parameters of the device nor the Association Groups. I will probably open a new thread to talk about this, so don't take it into account ;)

El jueves, 20 de marzo de 2014 22:35:27 UTC+1, franz.di...@gmail.com escribió:

[Chris Jackson]

> It seems that it won't be possible to differentiate between the type of messages :( Attached to the message I have uploaded a newly generated debug log file, perhaps it's too long, but I'm going to talk about it now.

The differentiator is the last payload byte - 0C versus 0A. Looking at my docs for the command class, it doesn’t talk about this byte, but from the PSM02 manual, it does talk about sensor types 0A and 0C as being Motion=0C and Door/Window= 0A (and tamper =08).

Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0C 37

Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0A 31

So, my guess is that this is a newer version of the command class than we know about. Can you delete the node2.xml file and restart the binding and send me the log and the new XML file. Hopefully that will tell me what version of the command class it’s supporting and we might be able to make some educated guesses about implementation - I’m guessing they’ve just added an extra byte on the end to denote the sensor type.

> PS: I don't understand why in HABmin my device appears as Node 2 but it's Manufacture ID, Device ID and Device Type are 0 and it's Version is 4. Tt's not recognized as as a Philio PSM02 device although the device description is in the Product Explorer tab. Information is reported fine so for now I'm not worried about that, the shame is that I can't change the Configuration Parameters of the device nor the Association Groups. I will probably open a new thread to talk about this, so don't take it into account ;)

Normally when I’ve seen the IDs etc = 0, it’s because the XML file is broken. In a recent addition, I added a check so that if the type/id are 0, it reinitialises the information (i.e. as though the XML file wasn’t there). I note in your log there’s the following error -:

2014-05-04 12:09:50.018 ERROR o.o.b.z.i.p.i.ZWaveNodeSerializer[:101]- NODE 2: There was an error writing the node config to a file: etc/zwave/1.5/node2.xml (Permission denied)

This might be related.

Cheers
Chris

[Chris Jackson]

I just had a look at the OZW implementation, and it confirms my previous email. So, it will require a small bit of work, but it’s possible :) I’ll try and take a look at it later tonight.

Chris

[ritu...@gmail.com]

I've deleted the node2.xml file from the etc/zwave/1.5 folder, set full 777 permissions to the folder and restarted the whole computer just in case. Attached to the message you can find the newly created node2.xml and zwave.log files.

Your support is amazing Chris, but you don't need to have a look at this tonight, take your time ;)

Best regards,

Aitor

PS: I don't understand why I'm still getting the following message: "NODE 9: There was an error writing the node config to a file: etc/zwave/1.5/node9.xml (Permission denied)". Node 9 (Fibaro universal dimmer) is working great and it appears correctly in HABmin, so it shouldn't write anything new to the node file.

[Chris Jackson]

> I've deleted the node2.xml file from the etc/zwave/1.5 folder, set full 777 permissions to the folder and restarted the whole computer just in case. Attached to the message you can find the newly created node2.xml and zwave.log files.

Thanks - I’ll take a look.

> PS: I don't understand why I'm still getting the following message: "NODE 9: There was an error writing the node config to a file: etc/zwave/1.5/node9.xml (Permission denied)". Node 9 (Fibaro universal dimmer) is working great and it appears correctly in HABmin, so it shouldn't write anything new to the node file.

The XML file gets rewritten a few times - when the node completes initialisation, when you request a configuration or association change, or when there’s a heal. It’s just so that the XML file has the most up to date information on the state/configuration of the node so we know this when the binding restarts.

Cheers
Chris

[Chris Jackson]

Thanks. Unfortunately this didn’t give me the info I was hoping to see. Can you try the attached version and send me the XML/logs again. It should now request the version of the binary sensor class - I’m hoping it’s something higher than 1, but we’ll see…

Cheers
Chris

[ritu...@gmail.com]

Here you have Chris, I think that this is what you were looking for:

<entry>

      <commandClass>SENSOR_BINARY</commandClass>

      <binarySensorCommandClass>

        <version>2</version>

        <instances>0</instances>

      </binarySensorCommandClass>

    </entry>

See you! ;)

El jueves, 20 de marzo de 2014 22:35:27 UTC+1, franz.di...@gmail.com escribió:

[Chris Jackson]

Brilliant - that’s exactly what I was looking/hoping for :)

Cheers

Chris

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

<node2.xml><zwave.log>

[Chris Jackson]

Have a try with this. I’ve tried a number of my sensors, but none of them support this so I can’t really test it… In the first instance, I’d be interested to see what turns up in the logs to see if it detects the different sensor types. If that works, then you could try adding ,sensor_type=10 (or 12) to the binding to see if it can differentiate between the two…

Let me know how it goes.

Chris

[ritu...@gmail.com]

Hi Chris.

I have briefly tried the new .jar file and I'm getting strange problems with my ZWave controller (Aeon Z-Stick S2), tomorrow I will make more tests so don't worry. This is what can be seen in the logs:

Message received when motion event is detected:

2014-05-05 01:10:06.646 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0C 37 

2014-05-05 01:10:06.648 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 FF 0C 

2014-05-05 01:10:06.649 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-05 01:10:06.649 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-05 01:10:06.650 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 2: Received Sensor Binary Request

2014-05-05 01:10:16.333 WARN  o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1093]- Threads not alive, respawning

2014-05-05 01:10:16.334 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:908]- Stopped Z-Wave send thread

2014-05-05 01:10:16.343 INFO  o.o.b.z.i.p.ZWaveController[:355]- Disconnected from serial port

2014-05-05 01:10:16.344 INFO  o.o.b.z.i.p.ZWaveController[:274]- Connecting to serial port /dev/zwave

2014-05-05 01:10:16.353 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:964]- Starting Z-Wave receive thread

2014-05-05 01:10:16.353 INFO  o.o.b.z.i.p.ZWaveController[:287]- Serial port is initialized

2014-05-05 01:10:16.354 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:821]- Starting Z-Wave send thread

Message received when open/close event is detected:

2014-05-05 01:06:52.941 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 0A 00 04 00 02 04 30 03 00 0A CE 

2014-05-05 01:06:52.944 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 00 0A 

2014-05-05 01:06:52.945 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-05 01:06:52.945 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-05 01:06:52.945 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 2: Received Sensor Binary Request

2014-05-05 01:06:52.946 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:91]- NODE 2: Sensor Binary report, type=Unknown, value=0x00

2014-05-05 01:06:52.946 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners

2014-05-05 01:06:52.947 DEBUG o.o.b.z.i.ZWaveActiveBinding[:362]- ZwaveIncomingEvent

2014-05-05 01:06:52.947 DEBUG o.o.b.z.i.ZWaveActiveBinding[:383]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 0

Here you can see that the type is unknown, so I guess that something is missing.

I can't understand why everytime that a motion event is received that strange threads and serial problems appear, and as you can see from the log file it just happens with that kind of message :(

More test will be done tomorrow, now it's time to go to bed ;)

Good night guys!

El jueves, 20 de marzo de 2014 22:35:27 UTC+1, franz.di...@gmail.com escribió:

[Chris Jackson]

Thanks.
It looks like it’s getting the version information, so it should interpret the extra byte. I’ll add some more information for debug to try and work out what’s going on.

Regarding the thread not alive message - I’ve also seen this but as it doesn’t happen too often I’ve not looked too closely at it. I need to understand what the binding is looking at to determine this since in my setup it appears as though the thread is ok. Is this what you are referring to when you say "I'm getting strange problems with my ZWave controller”?

I’ll send out an update a little later…

Cheers
Chris

[Chris Jackson]

Ah - my mistake! There’s a cut and paste error - I copied a line of code but forgot to update the pointer so it’s looking for the sensor type in the same byte as the value…. I’ll fix this and will still add another line or two of debug, but hopefully this will move us on…

[franz.di...@gmail.com]

Guys,

thanks for bringing this up again. I am still having problems with that sensor, although these are not the original ones any more. I think partly because I changed some of the settings in the sensor and, last but not least, because Chris is making real progress in enhancing the binding.

@Aitor: What settings did you do for that "Multi Function ... " status byte (I don't remember the exact name and can't look it up right now)? I think some of the problems we are facing are related to this. I just can't understand some of the statements made in the manual. Especially those where they speak about stuff like "disable x integrate y" with x,y being sensors. What do they mean by "integrate"? Include? Combine? ...

@Chris: The movement sensor seems to react to movement only for a while (after re-initializing it with ozwcp) and then after a short while within openHAB never again. Just to be sure: I would expect the binding to declare complete nodes as "dead" and not only sensors within nodes. Is that true?

 Cheers

Dieter

[Chris Jackson]

Updated binding. I think this will also fix the receive thread error you saw when the binary sensor message was received. I suspect there was an exception thrown, but (annoyingly) exceptions end up in the openhab.log file…

Let me know if this gets any further - there’s a bit more debug as well…

Chris

[Chris Jackson]

> @Chris: The movement sensor seems to react to movement only for a while (after re-initializing it with ozwcp) and then after a short while within openHAB never again. Just to be sure: I would expect the binding to declare complete nodes as "dead" and not only sensors within nodes. Is that true?

That’s correct. Also, when a node is marked DEAD, if the sensor sends a message (and it’s received by the controller!) then the binding marks it ALIVE again. So, you should still see the incoming messages in the log at least?

Chris

[franz.di...@gmail.com]

> Also, when a node is marked DEAD, if the sensor sends a message (and it’s received by the controller!) then the binding marks it ALIVE again.

Great. That is a design decision that I wanted to propose anyway. I had the impression that this was not the case for a while.

> So, you should still see the incoming messages in the log at least?

I will check for this as soon as I find the time.

Dieter

[Chris Jackson]

On 5 May 2014, at 16:23, franz.di...@gmail.com wrote:

> > Also, when a node is marked DEAD, if the sensor sends a message (and it’s received by the controller!) then the binding marks it ALIVE again.
>
> Great. That is a design decision that I wanted to propose anyway. I had the impression that this was not the case for a while.

I changed this a few weeks back, so you’re right, it wasn’t always the case. However, I’ve also just today found another instance where the device can respond to a message and stay DEAD, so this will be in the binding soon.

Chris

[ritu...@gmail.com]

Hi Chris!

Great news, things seem to be working fine! With the message I attach the usual zwave.log file and the node2.xml.

This is what it is received now when motion is detected:

2014-05-06 00:45:15.745 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0C 37 

2014-05-06 00:45:15.748 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 FF 0C 

2014-05-06 00:45:15.748 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Node Complete)

2014-05-06 00:45:15.749 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-06 00:45:15.749 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 2: Received Sensor Binary Request (v2)

2014-05-06 00:45:15.750 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:87]- Processing Sensor Type 12

2014-05-06 00:45:15.750 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:90]- Sensor Type is MOTION

2014-05-06 00:45:15.750 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:95]- NODE 2: Sensor Binary report, type=Motion, value=0xFF

2014-05-06 00:45:15.750 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners

2014-05-06 00:45:15.751 DEBUG o.o.b.z.i.ZWaveActiveBinding[:374]- ZwaveIncomingEvent

2014-05-06 00:45:15.751 DEBUG o.o.b.z.i.ZWaveActiveBinding[:395]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 255

And this when the door/window sensor is moved:

2014-05-06 00:38:54.627 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1026]- Receive Message = 01 0A 00 04 00 02 04 30 03 FF 0A 31 

2014-05-06 00:38:54.627 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message buffer = 01 09 00 13 02 02 84 09 25 0C 41 

2014-05-06 00:38:54.628 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:855]- Sending Message = 01 09 00 13 02 02 84 09 25 0C 41 

2014-05-06 00:38:54.629 DEBUG o.o.b.z.i.p.ZWaveController[:153]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 02 04 30 03 FF 0A 

2014-05-06 00:38:54.629 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 2: Application Command Request (Stage Static Information)

2014-05-06 00:38:54.630 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 2: Incoming command class SENSOR_BINARY (0x30)

2014-05-06 00:38:54.630 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 2: Received Sensor Binary Request (v2)

2014-05-06 00:38:54.630 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:87]- Processing Sensor Type 10

2014-05-06 00:38:54.630 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:90]- Sensor Type is DOORWINDOW

2014-05-06 00:38:54.631 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:95]- NODE 2: Sensor Binary report, type=Door/Window, value=0xFF

2014-05-06 00:38:54.631 DEBUG o.o.b.z.i.p.ZWaveController[:379]- Notifying event listeners

2014-05-06 00:38:54.631 DEBUG o.o.b.z.i.ZWaveActiveBinding[:374]- ZwaveIncomingEvent

2014-05-06 00:38:54.631 DEBUG o.o.b.z.i.ZWaveActiveBinding[:395]- Got a value event from Z-Wave network for nodeId = 2, endpoint = 1, command class = SENSOR_BINARY, value = 255

Awesome, exactly as it should!

So, should this code: "{ zwave="2:1:command=sensor_binary,sensor_type=10" }"  and "{ zwave="2:1:command=sensor_binary,sensor_type=12" }" work now? ;)

Thank you sooo much for your work Chris, it's awesome to realize how far have we got in just a couple of days. You can have a look at MCV forums and see how their customers are willing for the correct integration of this sensor with the firmware ;)

Best regards,

Aitor

[Chris Jackson]

Great news, things seem to be working fine! With the message I attach the usual zwave.log file and the node2.xml.

Brilliant - I'm pleased it's running. I'll take a look at the log when I get home tonight just to be sure...

 

Thank you sooo much for your work Chris, it's awesome to realize how far have we got in just a couple of days. You can have a look at MCV forums and see how their customers are willing for the correct integration of this sensor with the firmware ;)

Yes, I had a Vera for a couple of years and wrote a number of plugins for the unit, but they were sooo unresponsive to fixing even simple problems (like adding decimal points to temperature sensor readings). That's why I moved to OH - the ZWave source code is a bit of a learning curve, and the binding has it's own issues of course, but at least we can all have some input into our system...

Cheers

Chris

[Chris Jackson]

> So, should this code: "{ zwave="2:1:command=sensor_binary,sensor_type=10" }" and "{ zwave="2:1:command=sensor_binary,sensor_type=12" }" work now? ;)

All looks ok in the logs, so yes, give the above binding strings a try and see what happens - hopefully it should work :)

Chris

[franz.di...@gmail.com]

Hi Chris

This morning a saw that you committed your latest changes and gave it a try. It still does not work for me.

In the following, the items involved are defined like follows (translated some of the stuff into english...)

Contact Door_3d "Door Kinderzimmer [MAP(de2.map):%s]" (Security,Kinderzimmer)  { zwave="5:1:command=sensor_binary,sensor_type=10" }

Contact Door_3m "Movement Kinderz. [MAP(mv.map):%s]" <present> (Security,Kinderzimmer) { zwave="5:1:command=sensor_binary,sensor_type=12" }

The events log (I simplified it for you by grepping only for the relevant things and giving additional comments about what happened):

(opening the door)
2014-05-09 07:14:20 - Door_3d state updated to OPEN
2014-05-09 07:14:20 - Door_3m state updated to OPEN
2014-05-09 07:14:20 - Door_3d state updated to OPEN
2014-05-09 07:14:20 - Door_3m state updated to OPEN
2014-05-09 07:14:31 - Door_3d state updated to OPEN
2014-05-09 07:14:31 - Door_3m state updated to OPEN
2014-05-09 07:14:42 - Door_3d state updated to OPEN
2014-05-09 07:14:42 - Door_3m state updated to OPEN
(closing the door)
2014-05-09 07:17:28 - Door_3d state updated to OPEN
2014-05-09 07:17:28 - Door_3m state updated to OPEN
2014-05-09 07:17:32 - Door_3d state updated to CLOSED
2014-05-09 07:17:32 - Door_3m state updated to CLOSED
2014-05-09 07:17:47 - Door_3d state updated to OPEN
2014-05-09 07:17:47 - Door_3m state updated to OPEN

We see that there are way too many messages being exchanged and OPEN messages that cancel the effect of the "real" CLOSE messages. Maybe it helps to know that this sensor is relatively far away from the controller.

What is going on there?

Dieter

[Chris Jackson]

Hi

Actually, I think I was wrong. The latest version on the habmin site doesnt have tgis - I uploaded this test version in a message to the list a few days ago. Maybe you can find this, or I will compile a version tonight with this included and upload to rhe havmin site.

Sorry for this.

Chris 

Sent from Samsung Mobile

[franz.di...@gmail.com]

No problem.I will wait for the stuff to appear via git ...

Dieter

[franz.di...@gmail.com]

OK. I was too curious to wait :-)

I installed the latest jar file that you posted in this thread and ... openHAB does not receive  events for the motion and open/close sensor any more. The event.log is completely free of such messages. The light and temperature reporting events get through just like always.

I don't have much time this evening. Let me wait for the "real" jar to be available tomorrow, do more testing  and analyze the logs.

Cheers

Dieter

[Chris Jackson]

Thanks - if you can post a log that would be useful. From Aitor’s info, the command class is receiving the messages and distinguishing the different messages, but there’s one more step that hasn’t been tested and I need logs to see if it’s working (and from your report, it’s probably not).

If you can post the debug log, or better still, a trace log, that would be really useful otherwise I probably can’t progress this (tomorrow is fine :) ).

Cheers
Chris

[ritu...@gmail.com]

Hi guys!

Sorry for being out this 2-3 days, I was really busy during the week ;)

Things are working fine here, I'm going to reboot now and set the debug level to trace and post some logs in some minutes. We will see what they show.

[ritu...@gmail.com]

Here are my logs. Sensor_movimiento means movement_sensor and sensor_puerta means door_sensor, so as you can see in the event.log file everything works perfectly. This is how I have defined my items:

Contact movement_sensor       "movement_sensor [%s]"        <frontdoor>     { zwave="2:1:command=sensor_binary,sensor_type=12" }

Number  temperature_hallway    "Temperatura Pasillo [%.1f ºC]" <temperature>   { zwave="2:1:command=sensor_multilevel,sensor_type=1" }

Number  movement_sensor_batery       "Batería del sensor de movimiento [%d %%]"      { zwave="2:1:command=battery" }

Number  light_hallway     "Luz Pasillo [%d]"      <light> { zwave="2:1:command=sensor_multilevel,sensor_type=3" }

Contact door_sensor"Sensor de puerta [%s]" <frontdoor>     { zwave="2:1:command=sensor_binary,sensor_type=10" }

Contact movement_sensor_sala  "Sensor Movimiento Sala [%s]"   <siren> { zwave="3:1:command=sensor_binary" }

The third node is a EZMotion 3in1 sensor that I'm configuring now, so just focus on the messages received by Node 2 when viewing the logs.

The .jar file that I'm using is the latest version that Chris posted in this thread, so it should also work for you Dieter ;)

If you need more information, configuration files or tests don't hesitate to ask!

[Chris Jackson]

Thanks - it seems the events correlate properly with the sensor type in the log, so it looks like it’s working well to me.

Dieter - please let us know if it’s working for you. You should also be able to use the version on the HABmin git site if you want (I posted that last night)...

Cheers
Chris

[franz.di...@gmail.com]

Hi guys,

no, I now used Chris' latest commit and the result is still the same: when I open or close the door, I receive temperature and illumination reports :-), but there is no single bit for open/close and movement to be seen. 

I also removed the "node*.xml" files to have a clean state and tried again.

Something in the latest changes must have broken things for me.

Dieter

[Chris Jackson]

Can you provide logs with at least debug enabled?

Thanks
Chris

[franz.di...@gmail.com]

Done. Sent to you via normal mail. 

Greetings Dieter

[Chris Jackson]

Hmm - it’s a bit strange.

The problem (I think) is that for some reason in your system (at least in the log you sent) this node is progressing to DONE before it’s receiving the node info frame which tells it what command classes are supported. So, when it steps through the node advancer, it doesn’t think the version class is supported, so doesn't request the version. It then only uses version 1 instead of V2 which doesn’t support the sensor type.

Looking at this a bit more, it all starts here I think -:

2014-05-11 19:34:26 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message buffer = 01 04 00 60 05 9E
2014-05-11 19:34:26 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:890]- Sending Message = 01 04 00 60 05 9E
2014-05-11 19:34:26 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1061]- Receive Message = 01 04 01 60 01 9B
2014-05-11 19:34:26 DEBUG o.o.b.z.i.p.ZWaveController[:159]- Message: class = RequestNodeInfo (0x60), type = Response (0x01), payload = 01
2014-05-11 19:34:26 DEBUG o.o.b.z.i.p.s.RequestNodeInfoMessageClass[:38]- Request node info successfully placed on stack.
2014-05-11 19:34:27 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1061]- Receive Message = 01 06 00 49 81 00 00 31
2014-05-11 19:34:27 DEBUG o.o.b.z.i.p.ZWaveController[:159]- Message: class = ApplicationUpdate (0x49), type = Request (0x00), payload = 81 00 00
2014-05-11 19:34:27 DEBUG o.o.b.z.i.p.s.ApplicationUpdateMessageClass[:89]- NODE 0: Application update request, Node Info Request Failed, re-request node info.
2014-05-11 19:34:27 ERROR o.o.b.z.i.p.s.ApplicationUpdateMessageClass[:99]- NODE 0: Got Node Info Request Failed while sending this serial message. Requeueing

Assembled message buffer = 01 04 00 60 05 9E
This is the request and it’s fine - it’s requesting the node info frame for node 5.

Receive Message = 01 04 01 60 01 9B
The controller responds saying it got the request

Receive Message = 01 06 00 49 81 00 00 31
The is the response from the controller, and it’s now broken. The first 00 is the node number, so we’re getting a response from node 0! Clearly, this isn’t node 5, and it’s also invalid.

This doesn’t seem to be anything the binding is doing wrong, so I’m not too sure what’s up. I would suggest trying to exclude node 5, and re-include it and see if that helps…

Chris

[franz.di...@gmail.com]

> so we’re getting a response from node 0! Clearly, this isn’t node 5, and it’s also invalid.

I remember seeing references to nodes 0 and also 255 every once in a while for some weeks now.

> this node is progressing to DONE before it’s receiving the node info frame which tells it what command classes are supported.

From your understanding: Is this node stage advancing a strictly formal model (such as a state machine) or could it be that a node can be allowed to react on such messages even if it already in status DONE? Who is in charge of that? Is a node saying which stage it is in or does the software, i.e. in our case the "binding", impose such a view on it?

Dieter

[Chris Jackson]

> so we’re getting a response from node 0! Clearly, this isn’t node 5, and it’s also invalid.

I remember seeing references to nodes 0 and also 255 every once in a while for some weeks now.

Node 255 is normal - that's the controller (which is also node 1, but 255 is used for control of the controller).

 

From your understanding: Is this node stage advancing a strictly formal model (such as a state machine) or could it be that a node can be allowed to react on such messages even if it already in status DONE? Who is in charge of that? Is a node saying which stage it is in or does the software, i.e. in our case the "binding", impose such a view on it?

I believe that it shouldn't advance until it receives the messages it wants - it's effectively a state machine.

The problem though is that for some reason the list of command classes returned is not complete, so the binding jumps some stages (which it can do - correctly), so the problem seems to be early on with what is returned to some initial requests. I think it's worth excluding the device and re-include it to see if this helps...

The node advancer code is very difficult to follow. The problem is that it is scattered all through the binding - all the relevant command classes make a decision to advance or not, and they then call the node advancer to move on (where some other decisions are made). I want to consolidate this so that everything is in the node advancer class so that it's much easier to follow. I don't think there is any major problem with the way it works now, but it's just messy, and there are other things that need to be added to the initialisation but I don't want to do this until the code is a bit cleaner as teh chance of breaking it is high...

Cheers

Chris

[franz.di...@gmail.com]

> Node 255 is normal - that's the controller (which is also node 1, but 255 is used for control of the controller).

Thanks. I learned something new again :-)

>I think it's worth excluding the device and re-include it to see if this helps... 

Sure. Did so. Node 5 has now become node 11, but nothing changes: it sends temperature and light reports, but is silent about door and movement.

> but it's just messy, and there are other things that need to be added to the initialisation but I don't want to do this until the code is a bit cleaner as teh chance of breaking it is high...

Understood.

Cheers

Dieter

[Chris Jackson]

After the reset of the node, do you still see ‘NODE 0:’ messages?

Cheers
Chris

[franz.di...@gmail.com]

I see 3  "... NODE 0: Got Node Info Request Failed while sending this serial message. Requeueing.." messages and then
"...NODE 0: Node Info Request Failed 3x. Discarding message"

This sequence is then repeated once (until now).

Cheers

Dieter

BTW: The last 1.5.0 update broke all of my GUI again. I can only look at the logs right now. This already happened some weeks ago, took me hours of debugging in vain, and then went away after the next update. I am not complaining to you but just describing that debugging is difficult under these circumstances.

[Chris Jackson]

I see 3  "... NODE 0: Got Node Info Request Failed while sending this serial message. Requeueing.." messages and then
"...NODE 0: Node Info Request Failed 3x. Discarding message"

Strange - from what I can tell, the request from the binding looked ok and was requesting for node 5, but the stick responded with the node 0. Can you copy the log from just before and after these messages and attach it here (or email to me)?

 

BTW: The last 1.5.0 update broke all of my GUI again. I can only look at the logs right now. This already happened some weeks ago, took me hours of debugging in vain, and then went away after the next update. I am not complaining to you but just describing that debugging is difficult under these circumstances.

What GUI do you mean ? The standard (classic) GUI or do you mean the HABmin GUI? I don't think this has anything to do with zwave (??) - I hope - but I keep it in mind.

Cheers

Chris

[franz.di...@gmail.com]

At least the HABDroid GUI. Did not check the others ...

But obviously I did not make it clear enough that I think it is *not* your problem :-) That last build had so many changes ..

Dieter

[franz.di...@gmail.com]

> Strange - from what I can tell, the request from the binding looked ok and was requesting for node 5, but the stick responded with the node 0. Can you copy the log from just before and after these messages and attach it here (or email to me)?

Can't do it right now. I ran my update routine and this clears the logs. I restarted openHAB from remote and no messages to Node 0 appear. It never works when someone is watching.

I will try again when I find the time.

BUT: Did you really mean node *5* in your post? This has been reborn as node 11 in the meantime!

Dieter

[franz.di...@gmail.com]

> Can't do it right now. I ran my update routine and this clears the logs. I restarted openHAB from remote and no messages to Node 0 appear. It never works when someone is watching.

That said it appeared. You got it via mail.

[Chris Jackson]

Can't do it right now. I ran my update routine and this clears the logs. I restarted openHAB from remote and no messages to Node 0 appear. It never works when someone is watching.

No problem :)

 

BUT: Did you really mean node *5* in your post? This has been reborn as node 11 in the meantime!

Yes - I was referring to your old logs though - I don't think I've seen any logs since it changed to node 11. I'm assuming that the node 0 errors are now caused by node 11, but I'll see when you send the log (no hurry - just when you get the chance).

Cheers

Chris 

[Chris Jackson]

That said it appeared. You got it via mail.

Got it - thanks. I'll take a look tonight.

Cheers

Chris 

[franz.di...@gmail.com]

>  I'll take a look tonight.

Any news on this? Just curious... My feeling is that we're close to a solution :-)

[Chris Jackson]

I wasn’t able to see anything in the log. I wouldn’t mind taking a look at a longer log so I can be sure what was happening for a longer period before the event.

[franz.di...@gmail.com]

You have mail :-)

This is a longer zwave.log with various things going on (pressing the tamper button, opening the door, getting close, closing the case, ....)

Thanks for your efforts again.

Dieter

[Chris Jackson]

Thanks - I’ll take a look at some stage over the next few days - I’m out in Germany for work until Friday, so I might not get a chance until then…

Cheers
Chris

[franz.di...@gmail.com]

In which area of Germany?

[Chris Jackson]

Im in Friedrechshafen this week...

Sent from Samsung Mobile

--
You received this message because you are subscribed to the Google Groups "openhab" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openhab+u...@googlegroups.com.
To post to this group, send email to ope...@googlegroups.com.
Visit this group at http://groups.google.com/group/openhab.
For more options, visit https://groups.google.com/d/optout.

[Dieter Bolz]

Not a place to worry about Z-Wave sensors  :-)

You received this message because you are subscribed to a topic in the Google Groups "openhab" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openhab/KaonJsO17Bg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openhab+u...@googlegroups.com.

[Chris Jackson]

Hi Dieter,
As a matter of interest, what hardware are you using? (i.e. the host - not the zwave stick).

Chris

[franz.di...@gmail.com]

Hi Chris

I am using a Raspberry Pi. For testing purposes, I may switch over to a 64 bit Ubuntu.

Dieter

[franz.di...@gmail.com]

Hi Chris

Hurray! Something in the last couple of days must have made this problem go away. I just updated to build #642 and the event log (and the items themselves) show sensible behaviour. It must not have been that very build, though. I just did not look closely the last couple of days. I have yet to see that the motion sensor switches to OFF again, but that may be its internal behaviour. I just have to wait longer. Did you do something about it or does that stem from changes made somewhere else ...?

Cheers

Dieter

[franz.di...@gmail.com]

OK. I've been waiting for two hours now. Checking the events.log, there is actually not a single CLOSE event, but lots of OPEN events only. Can it be that the CLOSE message is interpreted the wrong way? 

Cheers

Dieter 

[Chris Jackson]

> OK. I've been waiting for two hours now. Checking the events.log, there is actually not a single CLOSE event, but lots of OPEN events only. Can it be that the CLOSE message is interpreted the wrong way?
>

Hi Dieter,
Firstly, no I haven’t changed anything that should have affected this…

OPEN events should work, but if you can send a log I’ll take a look.

Cheers
Chris

[franz.di...@gmail.com]

Firstly, no I haven’t changed anything that should have affected this…

Strange. All those "bouncing" events have disappeared.
 

OPEN events should work, but if you can send a log I’ll take a look.

 OPEN events for the motion sensor do work, but there is no single CLOSE event for it. There are CLOSE events for the door sensor. It was my gut feeling that it would be easy to spot the problem. But I will provide you with a recent log later.

[Chris Jackson]

> OPEN events for the motion sensor do work, but there is no single CLOSE event for it. There are CLOSE events for the door sensor. It was my gut feeling that it would be easy to spot the problem. But I will provide you with a recent log later.

Sorry- got this around the wrong way :)

Unfortunately there’s no such thing as ‘easy’ when it comes to the zwave binding. There are different messages that the device can send to report the same thing so I really need to see what’s coming in from the device :(

Thanks.

Cheers
Chris

[franz.di...@gmail.com]

Log sent via mail. It is a startup including a final open/close for the door sensor. I hope I waited long enough for a CLOSE event to be sent from the motion sensor. If you don't see anything like this I could send you another log with some hours in between. But this may become indigestible ...

Cheers 

DIeter

PS: We are only a few millimeters away from a status where all of my sensors work!

[franz.di...@gmail.com]

Hi Chris

FYI: I gave I another try after deleting the sensor XMLs and (possibly, I don't remember) another software update. Now there are no more Open/Close messages at all, for motion and door sensor. Temperature and light still work.

The final millimeters are getting longer :-)

Dieter

[franz.di...@gmail.com]

@Chris: FYI: Your latest commit causes the motion and the door sensor (as seen by the user) to always report the same values (again).

[Chris Jackson]

Strange - I haven’t made any changes for a few weeks (24th May it seems). What version have you changed to/from?

Chris

[franz.di...@gmail.com]

Hi Chris

GIT said: "merge branch 'rules'"

Cheers

Dieter

[Chris Jackson]

Ah - sorry, you were talking about the HABmin branch - I was looking at the zwave binding…

I guess merging the branches has pulled in an old version of the zwave binding - I’ll replace it with the old one again.

Thanks for confirming.

Cheers
Chris

[Marcel Verpaalen]

hi Chris,
It there still differences between the version included in habmin and the latest from cloudbees?

[Chris Jackson]

Yes - the current best one to use is the Cloudbees version. I compiled up a new version with some new stuff last night but we had a big storm here and we’ve just got power back on :(

I’ll load a new version to the HABmin site shortly.

Chris

On 14 Jun 2014, at 11:26, Marcel Verpaalen <marcel.v...@gmail.com> wrote:

>
> hi Chris,
> It there still differences between the version included in habmin and the latest from cloudbees?
>

[ritu...@gmail.com]

Hi Chris!

Sorry for needing to bother you again, but I'm having some problems with my Philio device and I don't know what's going on. I had a problem with my ubuntu server and I needed to reinstall my openhab configuration, so now I have a openhab 1.5 installation and I'm using the zwave.1.6.snapshot file available in your habmin repository at GitHub.

I have a couple of problem that I will appreciate if you can have a look at:

- My Philio device is not creating a valid xml file, as you can see in the attached node2.xml file.

- The oddest problem is that in the log file I'm seeing the movement and door/window messages as sensor_binary, type="Unknown", just the same as when we (well, you :D) were developing this new type of sensors. Have you changed anything in the binding recently regarding this? Did you forget to include the changes that you previously made to your master developer branch? The Unknown type message can be seeing at 14:16:12.350.

I don't understand what's going on :( :(

If you can have a look at the log files when you have some spare time it would be great ;-)

Many thanks for your help and best regards,

Aitor

[ritu...@gmail.com]

Hi again Chris!

What do you think that it could happen if I manually replace the "corrupted" node2.xml file with one of the ones that I sent you in this post? For example the node2.xml file that I posted the 6th of May. Is that a good or a terrible idea?

Thank you very much for your work and best regards,

Aitor

[Chris Jackson]

> What do you think that it could happen if I manually replace the "corrupted" node2.xml file with one of the ones that I sent you in this post? For example the node2.xml file that I posted the 6th of May. Is that a good or a terrible idea?

It can't hurt, but it also may not make much difference. Alternatively, you could delete the XML file completely. If the XML is not being re-created, then it potentially means that the binding is having trouble talking to the device.

It’s also worth upgrading to the very latest version (i.e. from today) from Cloudbees as this may also solve any problems like this.

Cheers
Chris

[ritu...@gmail.com]

Hello Chris!

I'm not sure if you have read my previous message, the one that I wrote 4 days ago (15th of July). From your last answer I can guess that you have missed it, am I correct? ;) ;)

I have tried the latest zwave binding file from Cloudbess, but with that file I'm having problems with Habmin, the zwave binding configuration tab is empty. I'm going back to the zwave binding file in your Habmin repository, the one from July the 12th.

Even if I delete the node2.xml file and restart OpenHab again to let the binding create a new one, the new node2.xml file is still "corrupted" :( Do you think that deleting the node from the stick and including it again could solve the problem?

Do you know something about my second problem? The type="Unknown" problem? :(

Thanks for your help and sorry for bothering you ;)

Aitor

[Chris Jackson]

Sorry - I did see this message but forgot to reply…

Last things first… The problem with the unknown. This is possibly related to the other problem (FFFFs - or corrupted XML as you put it). The “corruption” isn’t really corruption - it’s indicates that the binding probably isn’t communicating with the device - when the node is initialised in the binding, it sets the value to FFFF. Previously, this was set to 0, but I recently found out that 0 is actually a valid number, so if we want to mark this as invalid, then we need to use something different. So, I changed it to -1 (of FFFFFFFF) - unfortunately this caused another issue within the XML read/write routine, so I’ve just changed it to MAX_INTEGER (or 7FFFFFFF)….

Anyway, back to the Unknown… During binding startup, the binding reads some config data from a node - one thing it reads is the version of the command classes that the device supports. If it doesn’t read this, then it will use version 1 - and this is an issue here. Version 1 doesn’t know about the extra byte that indicates the type, so it shows “unknown”. Looking in your log, it seems that the device status, with the unknown is coming in before the device has finished initialisation, so it will treat it as a version 1 command class.

Unfortunately there’s a problem with the latest product file - I suspect I messed it up by leaving out a tag in the XML, but someone has just created a PR to fix it (thanks :) ). I will make this change now and load a new version to the HABmin site. I’ll upload it in a few minutes - give this a try and see if it helps, but also make sure the device completes initialisation. If the problem still exists, please send the logs again…

Cheers
Chris

[Ard van der Leeuw]

Hi, 

sorry to interfere with this thread, but I am also seeing regular issues with ReceiveThread failing. 

2014-08-03 12:25:00.314 WARN  o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1112]- Threads not alive, respawning

2014-08-03 12:25:00.568 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:942]- Stopped Z-Wave send thread

I've been able to capture the exception from my screen, as it doesn't seem to make it into any of the logs:

12:10:18.580 INFO  runtime.busevents[:26] - Accu_Woonkamer state updated to 100

Exception in thread "Thread-37" java.lang.ArrayIndexOutOfBoundsException: 6

        at org.openhab.binding.zwave.internal.protocol.SerialMessage.getMessagePayloadByte(SerialMessage.java:301)

        at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveBinarySensorCommandClass.handleApplicationCommandRequest(ZWaveBinarySensorCommandClass.java:87)

        at org.openhab.binding.zwave.internal.protocol.serialmessage.ApplicationCommandMessageClass.handleRequest(ApplicationCommandMessageClass.java:79)

        at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingRequestMessage(ZWaveController.java:182)

        at org.openhab.binding.zwave.internal.protocol.ZWaveController.handleIncomingMessage(ZWaveController.java:162)

        at org.openhab.binding.zwave.internal.protocol.ZWaveController.access$12(ZWaveController.java:156)

        at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveReceiveThread.processIncomingMessage(ZWaveController.java:990)

        at org.openhab.binding.zwave.internal.protocol.ZWaveController$ZWaveReceiveThread.run(ZWaveController.java:1046)

12:10:20.748 INFO  runtime.busevents[:26] - Licht_Woonkamer state updated to 8

And this is the information in the zwave.log;

2014-08-03 12:10:18.635 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:58]- Status = Transmission complete and ACK received. (0x00)

2014-08-03 12:10:18.639 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 09 00 04 00 0B 03 30 03 FF 36

2014-08-03 12:10:18.644 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 03 30 03 FF

2014-08-03 12:10:18.646 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.648 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class SENSOR_BINARY (0x30)

2014-08-03 12:10:18.650 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 11: Received Sensor Binary Request (v2)

2014-08-03 12:10:19.870 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:261]- Queue length is 2 - deferring HEAL.

2014-08-03 12:10:20.297 WARN  o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1112]- Threads not alive, respawning

2014-08-03 12:10:20.299 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:942]- Stopped Z-Wave send thread

2014-08-03 12:10:20.303 INFO  o.o.b.z.i.p.ZWaveController[:380]- Disconnected from serial port

2014-08-03 12:10:20.304 INFO  o.o.b.z.i.p.ZWaveController[:299]- Connecting to serial port /dev/ttyAMA0

2014-08-03 12:10:20.323 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:998]- Starting Z-Wave receive thread

It seems as if the zwave code is choking on something that is being sent in the 'Sensor Binary Request (v2)'. 

This happens for both Philio PSP01-01 devices I have (which are identified as Philio PSM-02 devices though). The PSP01 and PSM02 are very similar, but differ in the fact that the PSP has PIR detection/switch, while PSM has a magnetic door/window switch. 

When I look at Aitor's logfile, I do see the same issue. 

This was done using the 1.6-snapshot version of the ZWAVE-addon (downloaded on August 1, 2014). 

I will try replacing it with the 1.5.1 version in the cloudbees repository and see what happens then. 

[Chris Jackson]

Hi,

Can you post the information from the zwave log just before the event displayed on the screen? The logged information seems to be just after, but I think it would be useful to see what happened leading up to the event.

Cheers

Chris

[Ard van der Leeuw]

As far as I could tell, the information in the zwave.log before this event seemed to be fully handled messages, but here it is:

2014-08-03 12:10:18.423 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 08 00 04 00 0B 02 84 07 79

2014-08-03 12:10:18.428 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 02 84 07

2014-08-03 12:10:18.430 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.433 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class WAKE_UP (0x84)

2014-08-03 12:10:18.435 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:128]- NODE 11: Received Wake Up Request

2014-08-03 12:10:18.437 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:181]- NODE 11: is awake

2014-08-03 12:10:18.439 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

2014-08-03 12:10:18.442 DEBUG o.o.b.z.i.ZWaveActiveBinding[:384]- ZwaveIncomingEvent

2014-08-03 12:10:18.444 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:403]- NODE 11: Is awake with 4 messages in the wake-up queue.

2014-08-03 12:10:18.447 DEBUG o.o.b.z.i.p.ZWaveController[:643]- Callback ID = 72

2014-08-03 12:10:18.449 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:860]- Took message from queue for sending. Queue length = 0

2014-08-03 12:10:18.453 DEBUG o.o.b.z.i.p.ZWaveController[:389]- Enqueueing message. Queue length = 0

2014-08-03 12:10:18.454 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message buffer = 01 09 00 13 0B 02 80 02 25 48 03

2014-08-03 12:10:18.459 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:889]- Sending Message = 01 09 00 13 0B 02 80 02 25 48 03

2014-08-03 12:10:18.467 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 04 01 13 01 E8

2014-08-03 12:10:18.481 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Response (0x01), payload = 01

2014-08-03 12:10:18.483 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:36]- Sent Data successfully placed on stack.

2014-08-03 12:10:18.492 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 08 00 04 00 0B 02 84 07 79

2014-08-03 12:10:18.497 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 02 84 07

2014-08-03 12:10:18.498 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.501 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class WAKE_UP (0x84)

2014-08-03 12:10:18.502 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:128]- NODE 11: Received Wake Up Request

2014-08-03 12:10:18.504 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:181]- NODE 11: is awake

2014-08-03 12:10:18.506 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

2014-08-03 12:10:18.507 DEBUG o.o.b.z.i.ZWaveActiveBinding[:384]- ZwaveIncomingEvent

2014-08-03 12:10:18.510 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:403]- NODE 11: Is awake with 3 messages in the wake-up queue.

2014-08-03 12:10:18.511 DEBUG o.o.b.z.i.p.ZWaveController[:643]- Callback ID = 73

2014-08-03 12:10:18.513 DEBUG o.o.b.z.i.p.ZWaveController[:389]- Enqueueing message. Queue length = 1

2014-08-03 12:10:18.517 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 08 00 04 00 0B 02 84 07 79

2014-08-03 12:10:18.522 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 02 84 07

2014-08-03 12:10:18.524 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.526 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class WAKE_UP (0x84)

2014-08-03 12:10:18.527 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:128]- NODE 11: Received Wake Up Request

2014-08-03 12:10:18.529 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:181]- NODE 11: is awake

2014-08-03 12:10:18.531 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

2014-08-03 12:10:18.533 DEBUG o.o.b.z.i.ZWaveActiveBinding[:384]- ZwaveIncomingEvent

2014-08-03 12:10:18.536 DEBUG o.o.b.z.i.p.c.ZWaveWakeUpCommandClass[:403]- NODE 11: Is awake with 2 messages in the wake-up queue.

2014-08-03 12:10:18.538 DEBUG o.o.b.z.i.p.ZWaveController[:643]- Callback ID = 74

2014-08-03 12:10:18.540 DEBUG o.o.b.z.i.p.ZWaveController[:389]- Enqueueing message. Queue length = 2

2014-08-03 12:10:18.547 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 05 00 13 48 00 A1

2014-08-03 12:10:18.551 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Request (0x00), payload = 48 00

2014-08-03 12:10:18.553 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:57]- CallBack ID = 72

2014-08-03 12:10:18.555 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:58]- Status = Transmission complete and ACK received. (0x00)

2014-08-03 12:10:18.560 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 09 00 04 00 0B 03 80 03 64 1D

2014-08-03 12:10:18.565 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 03 80 03 64

2014-08-03 12:10:18.566 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.569 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class BATTERY (0x80)

2014-08-03 12:10:18.570 DEBUG o.o.b.z.i.p.c.ZWaveBatteryCommandClass[:74]- Node 11: Received Battery Request

2014-08-03 12:10:18.572 DEBUG o.o.b.z.i.p.c.ZWaveBatteryCommandClass[:84]- Node 11: Battery report value = 0x64

2014-08-03 12:10:18.574 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

2014-08-03 12:10:18.575 DEBUG o.o.b.z.i.ZWaveActiveBinding[:384]- ZwaveIncomingEvent

2014-08-03 12:10:18.577 DEBUG o.o.b.z.i.ZWaveActiveBinding[:405]- Got a value event from Z-Wave network for nodeId = 11, endpoint = 1, command class = BATTERY, value = 100

2014-08-03 12:10:18.586 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

2014-08-03 12:10:18.588 DEBUG o.o.b.z.i.ZWaveActiveBinding[:384]- ZwaveIncomingEvent

2014-08-03 12:10:18.591 DEBUG o.o.b.z.i.p.ZWaveController[:643]- Callback ID = 75

2014-08-03 12:10:18.593 DEBUG o.o.b.z.i.p.ZWaveController[:389]- Enqueueing message. Queue length = 3

2014-08-03 12:10:18.595 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:935]- Response processed after 134ms/3569ms.

2014-08-03 12:10:18.597 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:860]- Took message from queue for sending. Queue length = 2

2014-08-03 12:10:18.600 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message buffer = 01 09 00 13 0B 02 30 02 25 49 B2

2014-08-03 12:10:18.603 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:889]- Sending Message = 01 09 00 13 0B 02 30 02 25 49 B2

2014-08-03 12:10:18.611 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 04 01 13 01 E8

2014-08-03 12:10:18.622 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Response (0x01), payload = 01

2014-08-03 12:10:18.623 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:36]- Sent Data successfully placed on stack.

2014-08-03 12:10:18.627 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 05 00 13 49 00 A0

2014-08-03 12:10:18.631 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Request (0x00), payload = 49 00

2014-08-03 12:10:18.633 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:57]- CallBack ID = 73

2014-08-03 12:10:18.635 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:58]- Status = Transmission complete and ACK received. (0x00)

2014-08-03 12:10:18.639 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 09 00 04 00 0B 03 30 03 FF 36

2014-08-03 12:10:18.644 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 03 30 03 FF

2014-08-03 12:10:18.646 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:18.648 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class SENSOR_BINARY (0x30)

2014-08-03 12:10:18.650 DEBUG o.o.b.z.i.p.c.ZWaveBinarySensorCommandClass[:75]- NODE 11: Received Sensor Binary Request (v2)

2014-08-03 12:10:19.870 DEBUG o.o.b.z.i.ZWaveNetworkMonitor[:261]- Queue length is 2 - deferring HEAL.

2014-08-03 12:10:20.297 WARN  o.o.b.z.i.p.ZWaveController$WatchDogTimerTask[:1112]- Threads not alive, respawning

2014-08-03 12:10:20.299 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:942]- Stopped Z-Wave send thread

2014-08-03 12:10:20.303 INFO  o.o.b.z.i.p.ZWaveController[:380]- Disconnected from serial port

2014-08-03 12:10:20.304 INFO  o.o.b.z.i.p.ZWaveController[:299]- Connecting to serial port /dev/ttyAMA0

2014-08-03 12:10:20.323 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:998]- Starting Z-Wave receive thread

2014-08-03 12:10:20.328 INFO  o.o.b.z.i.p.ZWaveController[:312]- Serial port is initialized

2014-08-03 12:10:20.330 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:855]- Starting Z-Wave send thread

2014-08-03 12:10:20.335 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:860]- Took message from queue for sending. Queue length = 1

2014-08-03 12:10:20.342 DEBUG o.o.b.z.i.p.SerialMessage[:226]- Assembled message buffer = 01 0A 00 13 0B 03 31 04 01 25 4A B5

2014-08-03 12:10:20.349 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveSendThread[:889]- Sending Message = 01 0A 00 13 0B 03 31 04 01 25 4A B5

2014-08-03 12:10:20.362 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 04 01 13 01 E8

2014-08-03 12:10:20.371 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Response (0x01), payload = 01

2014-08-03 12:10:20.373 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:36]- Sent Data successfully placed on stack.

2014-08-03 12:10:20.651 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 05 00 13 4A 00 A3

2014-08-03 12:10:20.655 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = SendData (0x13), type = Request (0x00), payload = 4A 00

2014-08-03 12:10:20.657 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:57]- CallBack ID = 74

2014-08-03 12:10:20.658 DEBUG o.o.b.z.i.p.s.SendDataMessageClass[:58]- Status = Transmission complete and ACK received. (0x00)

2014-08-03 12:10:20.717 DEBUG o.o.b.z.i.p.ZWaveController$ZWaveReceiveThread[:1045]- Receive Message = 01 0B 00 04 00 0B 05 31 05 03 01 08 C0

2014-08-03 12:10:20.723 DEBUG o.o.b.z.i.p.ZWaveController[:158]- Message: class = ApplicationCommandHandler (0x04), type = Request (0x00), payload = 00 0B 05 31 05 03 01 08

2014-08-03 12:10:20.725 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:37]- NODE 11: Application Command Request (Stage Node Complete)

2014-08-03 12:10:20.728 DEBUG o.o.b.z.i.p.s.ApplicationCommandMessageClass[:55]- NODE 11: Incoming command class SENSOR_MULTILEVEL (0x31)

2014-08-03 12:10:20.730 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:92]- NODE 11: Received Sensor Multi Level Request

2014-08-03 12:10:20.732 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:125]- NODE 11: Sensor Multi Level report received

2014-08-03 12:10:20.734 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:129]- NODE 11: Sensor Type = (0x03), Scale = 0

2014-08-03 12:10:20.738 DEBUG o.o.b.z.i.p.c.ZWaveMultiLevelSensorCommandClass[:144]- NODE 11: Sensor Value = (8.000000)

2014-08-03 12:10:20.740 DEBUG o.o.b.z.i.p.ZWaveController[:404]- Notifying event listeners

The error also happened with the 1.5.1 zwave binding, but as far as I could tell, that contained the changes for v2 binary sensors already. 

I would suggest checking the length of the received data packet before deciding to move behind the end of it. Somehow it seems this event does not contain the extra byte that you expect with a V2 binary sensor message, but it does seem to work with the 'old' code. 

Thanks, 

Ard

[Chris Jackson]

Thanks - it looks like the message isn’t being handled correctly - I agree with your comment on fixing it, but can you confirm that that this sensor is reporting command class V2, even though it seems to be sending the V1 class? Seems a bug in the sensor to me (but I agree that it should also be fixed in the binding so I’ll do this).

Cheers
Chris

[Chris Jackson]

Sorry - I should have checked the logs as it shows it’s V2 there… Definitely seems a bug in the sensor but I’ll fix this shortly…

Chris

[Ard van der Leeuw]

Well, 

the little paper manual mentions COMMAND_CLASS_SENSOR_BINARY_V2

This is also what I see in the node11.xml:

<node>

  <deviceClass>

    <basicDeviceClass>ROUTING_SLAVE</basicDeviceClass>

    <genericDeviceClass>BINARY_SENSOR</genericDeviceClass>

    <specificDeviceClass>ROUTING_SENSOR_BINARY</specificDeviceClass>

  </deviceClass>

  <version>4</version>

  <manufacturer>0x13c</manufacturer>

  <deviceId>0x2</deviceId>

  <deviceType>0x2</deviceType>

  <listening>false</listening>

  <frequentlyListening>false</frequentlyListening>

  <routing>true</routing>

  <supportedCommandClasses>

    <entry>

      <commandClass>SENSOR_BINARY</commandClass>

      <binarySensorCommandClass>

        <version>2</version>

        <instances>0</instances>

      </binarySensorCommandClass>

    </entry>

    <entry>

      <commandClass>NO_OPERATION</commandClass>

      <noOperationCommandClass>

        <version>0</version>

        <instances>0</instances>

      </noOperationCommandClass>

    </entry>

    <entry>

      <commandClass>ASSOCIATION</commandClass>

      <associationCommandClass>

        <version>1</version>

        <instances>0</instances>

        <configAssociations>

          <entry>

            <int>1</int>

            <associationGroup>

              <Index>1</Index>

              <Nodes>

                <int>1</int>

              </Nodes>

            </associationGroup>

          </entry>

          <entry>

            <int>2</int>

            <associationGroup>

              <Index>2</Index>

              <Nodes>

                <int>1</int>

              </Nodes>

            </associationGroup>

          </entry>

        </configAssociations>

      </associationCommandClass>

    </entry>

    <entry>

      <commandClass>WAKE_UP</commandClass>

      <WakeUpCommandClass>

        <version>2</version>

        <instances>0</instances>

        <targetNodeId>1</targetNodeId>

        <interval>1800</interval>

        <minInterval>1800</minInterval>

        <maxInterval>432000</maxInterval>

        <defaultInterval>86400</defaultInterval>

        <intervalStep>1800</intervalStep>

      </WakeUpCommandClass>

    </entry>

    <entry>

      <commandClass>CONFIGURATION</commandClass>

      <configurationCommandClass>

        <version>1</version>

        <instances>0</instances>

        <configParameters/>

      </configurationCommandClass>

    </entry>

    <entry>

      <commandClass>SENSOR_MULTILEVEL</commandClass>

      <multiLevelSensorCommandClass>

        <version>5</version>

        <instances>0</instances>

        <sensors>

          <sensorType>LUMINANCE</sensorType>

          <sensorType>TEMPERATURE</sensorType>

        </sensors>

      </multiLevelSensorCommandClass>

    </entry>

    <entry>

      <commandClass>MANUFACTURER_SPECIFIC</commandClass>

      <manufacturerSpecificCommandClass>

        <version>1</version>

        <instances>0</instances>

      </manufacturerSpecificCommandClass>

    </entry>

    <entry>

      <commandClass>VERSION</commandClass>

      <versionCommandClass>

        <version>1</version>

        <instances>0</instances>

        <libraryType>LIB_CONTROLLER_BRIDGE</libraryType>

        <protocolVersion>7.1</protocolVersion>

        <applicationVersion>1.0</applicationVersion>

      </versionCommandClass>

    </entry>

    <entry>

      <commandClass>BASIC</commandClass>

      <basicCommandClass>

        <version>0</version>

        <instances>0</instances>

      </basicCommandClass>

    </entry>

    <entry>

      <commandClass>SWITCH_BINARY</commandClass>

      <binarySwitchCommandClass>

        <version>0</version>

        <instances>0</instances>

      </binarySwitchCommandClass>

    </entry>

    <entry>

      <commandClass>BATTERY</commandClass>

      <batteryCommandClass>

        <version>1</version>

        <instances>0</instances>

        <batteryLevel>100</batteryLevel>

      </batteryCommandClass>

    </entry>

  </supportedCommandClasses>

  <nodeNeighbors>

    <int>1</int>

    <int>2</int>

    <int>3</int>

    <int>4</int>

    <int>5</int>

    <int>6</int>

    <int>8</int>

    <int>9</int>

  </nodeNeighbors>

  <lastUpdated>2014-08-06 09:15:54.326 UTC</lastUpdated>

  <queryStageTimeStamp>2014-08-06 09:15:54.326 UTC</queryStageTimeStamp>

  <nodeStage>DONE</nodeStage>

However, this xml contains other parameters that are a bit confusing to a newbie like me... ie. why would a battery operating device report 'routing=true'... and I'm not sure why it has a 'BINARY_SWITCH' command class, unless that's used to send OUT messages to other devices when the PIR is triggered. Also, I'm not sure if the XML is based on parameters that are reported by the device, or based on the XML-file that comes with the ZWAVE binding. 

Ard.

[Chris Jackson]

Thanks - I think the sensor isn’t correct as it’s reporting V2, but only providing V1 data. However, since I don’t know the exact V2 specification maybe this is ok (??)…

Anyway, it’s an easy fix so I’ll push this shortly. Thanks for the help.

Cheers

Chris

[Ard van der Leeuw]

Thanks Chris, 

I can verify that the error has disappeared for at least a day. 

Ard

[Alex Einz]

Hi Chris, I have a similar device TSM02 , seems like the original manufacturer started release their own products with almost similar specs.

Would it be possible to include this and another couple of  devices in the binding ?

Attached are the XML files, would you need any additional information ?

[Chris Jackson]

Hi,

I can add this reasonably easily I think. Are you able to confirm which version of the Philio this is - or alternatively if you can provider the user manual that shows the configuration and association parameters?

Cheers

Chris

[Alex Einz]

Hi Chris

node3.xml -TSM02 manufacturer is TBK but except that it seems identical to the Philio PSM02 - manual with configuration options attached

node4.xml is Aeon Labs DSB09104-ZWUS - Z-Wave Smart Energy Meter developer pdf with all the options is attached too 

node5.xml - attached here is Aeotec Z-Wave Smart Energy Plug-In Dimmer, G2 or DSC25 , I cant find any options for it except the following link though 

http://www.discounthomeautomation.com/Aeon-Labs-Aeotec-Z-Wave-Smart-Illuminator-AEDSC25ZWUS

Thank you for looking into this!

[Alex Einz]

Chris, could you let me know when those could make it into the DB , so I could test those ?

[Chris Jackson]

I’ve added the TSM02 using the PSM02 configuration. Please let me know if it’s ok.

Chris