Philio devices unsupported?

Since my upgrade to zwave JS I’m having major problems with my Philio door/window devices (PST02A and PST02C). None of them report movement or open/close. In the (now expanded) log I’m seeing this:

2021-05-01T14:14:48.854Z DRIVER « [Node 038] [REQ] [ApplicationCommand] └─[MultiCommandCCCommandEncapsulation] 2021-05-01T14:14:48.859Z DRIVER Received a command that contains multiple CommandClasses. This is not supporte d yet! Discarding the message... 2021-05-01T14:14:48.861Z CNTRLR « [Node 038] TODO: no handler for application command 2021-05-01T14:14:53.995Z SERIAL « 0x010f00040012097105000000ff0708006b (17 bytes)

Are these Philio devices not supported yet?

I have the feeling I’m not asking this place in the right place … Not trying to be impatient (I’m amazed at the progress that is being made), but in the mean time I’m kind of lost here and actually considering reverting back to the old z-wave :- :roll_eyes:

I was having the same issue with PST02A.

If you go to the configuration parameters for this device, you find “Parameter 7: Customer Function”.
Bit 5 is “Disable Multi CC in auto report”, which was set to 1 (disable) on my device.
After setting it to 0 (enable), my device reported movement and open/close correctly. You can do that by subtracting 16 from the current value of Parameter 7.

Don’t forget to wake up your device so it get’s the configuration update.

philio parameter 7

I’ve tried several configuration options, but perhaps not this one yet. I’ll give it a try, thanks!

Ok, my findings are a bit different, but the result is now usable, although not perfect. This is a workaround, not a solution.

Below is about the PST02A, but the same goes for the PST02C, just minus the motion.

Going over many possible configurations again, I found that bit 5 doesn’t have any effect, other than not getting an error in the log. Bit 4 however does have effect on some attribute values, although not the ones I expected.

Unfortunately the _access_control_window_door_is_open and _home_security_motion_detection never change value in whatever configuration. Since these are enabled by default, have values “open” and “close” and have by default the right icons, these would be where you’d first look. Also the _access_control_door_state never changes state and stays “Window/door is closed”. And finally, the device triggers “When window/door is opened” are linked to these and therefore won’t work, neither will any logic related to tampering.

Curiously there are also the _door_window and _open attributes, which are by default disabled by HA. After enabling these, it turns out that they change value when bit 4 = 1 (eg parameter value 22). Unfortunately these have value “On” and “Off” and no icon, which can of course be overcome.

Finally, setting Bit 5 to “1” does take care of the error message in the log (see first post). But other tan that it doesn’t seem to effect anything. So my advise is: enable the mentioned attributes, set param 7 to 54. (as opposed to @zsot suggestion, I think you have to add/subtract 32 for bit 5, but I could be wrong of course) and change the device class to door / motion.

This workaround stopped working in one of the recent upgrades. Now none of attributes are giving me anything useable anymore. I’ll have to go over de different configurations again to see if I can get anything out of them somehow. Getting a bit tired of this though :frowning:

On my DCH-Z110 (which is I think the exact clone of the Philio sensor) I’ve used the following parameters on Parameter 7:

Disable send of BASIC OFF after door closed is set to DISABLED
Notification Type is set to Notification Report
Disable Multi CC in auto report is set to DISABLED
Disable to report battery state is set DISABLED

With the above it reports on and off correctly and with the correct icon (door).

First tests show that this works, thanks a lot @Lukacs_Attila!
It also seems that the battery reports doesn’t really matter.
I’ll continue with some more tests before believing it, but for now I’m really happy :slight_smile:

You don’t have to test. It’s working :slight_smile:

Motion as well? Can’t get that to work yet …

It does log a notification, but nothing changes value:

2021-08-07T08:25:25.375Z CNTRLR [Node 038] [~] [Notification] notificationMode: “push” [Endpoint 0] [internal]
=> “push”
2021-08-07T08:25:25.379Z SERIAL » [ACK] (0x06)
2021-08-07T08:25:25.382Z DRIVER « [Node 038] [REQ] [ApplicationCommand]
└─[NotificationCCReport]
notification type: 7
notification status: 255
notification event: 0xfe
2021-08-07T08:25:25.390Z CNTRLR [Node 038] [~] [Notification] Home Security[unknown]: 254 => 254 [Endpoint 0]

Sorry, mine is a door/window/illumination/temperature sensor, without PIR (the motherboard has the soldering points for the PIR sensor though :slight_smile: ).

Well apparently mine is as well at the moment, lol :wink:

I’ll dig some deeper in the reporting back of of OFF report, because it doesn’t seem to send that in the current configuration (param 7 = 102). Therefore the movement event looks like this (it’s already 8 = ON):
2021-08-07T08:40:32.077Z DRIVER « [Node 038] [REQ] [ApplicationCommand]
└─[NotificationCCReport]
notification type: Home Security
notification status: 255
notification state: Motion detection
2021-08-07T08:40:32.084Z CNTRLR [Node 038] [~] [Notification] Home Security[Motion sensor status] [Endpoint 0]
: 8 => 8

I confirmed this by manually setting the state of the *_home_security_motion_detection attribute to ‘off’. After that it indeed detects motion (once). This could also be a workaround.

I suspect the notification type OFF-event “0xfe” is not recognized as such by the Zwave JS software…

This thing is driving me nuts. Did a reinterview of the device and now both door and motion seem to work with Bit 4: Notification Type = 1: Sensor Binary Report.

Hi Vinx,
I am having the same problem you had, but I cannot seem to resolve it.

  1. What final values did you set for the parameters?
  2. How did you force it to wake to accept the parameters? Mine seems to be not waking, even with the button inside.

Thanks!

Okay, the wakeup is fine. But the parameters…not seeming to work with 22 or 20 for parameter 7.

For me there were two ways to “solve” it, depending on which type of notification you choose.

  1. Notification type = Sensor Binary Report. This only worked after reinterview. I had to do this for all my devices, so I think something changed in one of the HA-updates. I’ve tested 22 and 118 and they both work now, so apparently bit 5 and 6 are no game changers here, even though bit 5 = 0 enable will result in error messages in the log.
  2. Notification type = Notification Report. This works only with 102 and only for open/close. I did not get motion to work.

Did you do the reinterview before you tested 22?
Also notice that depending on method 1 or 2 there are other entities that are being triggered. Check if they are enabled.

With 22, I get:

2021-09-01T11:35:50.661Z DRIVER Received a command that contains multiple CommandClasses. This is not supporte
d yet! Discarding the message…
2021-09-01T11:35:50.663Z CNTRLR « [Node 006] TODO: no handler for application command
2021-09-01T11:35:51.934Z DRIVER Received a command that contains multiple CommandClasses. This is not supporte
d yet! Discarding the message…
2021-09-01T11:35:51.935Z CNTRLR « [Node 006] TODO: no handler for application command
2021-09-01T11:36:02.232Z DRIVER Received a command that contains multiple CommandClasses. This is not supporte
d yet! Discarding the message…
2021-09-01T11:36:02.235Z CNTRLR « [Node 006] TODO: no handler for application command

That was after a reinterview as well. Let me try 102.

102 does not register anything in the log. Hmmm…perhaps back to 22.