Philio PST02-1C Slim Multi Sensor still not working within Issue-352-Security branch

[ugoviti]

I'm testing Philio PST02-1C with Issue-352-Security branch, but it still not working (not status change when opening or closing the sensor).

Attached the logs of inclusion, opening and closing the sensor.

Let's me know if you need other info.

King Regards!

pst02-1c-inclusion-OZW_Log.txt | uploaded via ZenHub

pst02-1c-closing-sensor-OZW_Log.txt | uploaded via ZenHub

pst02-1c-opening-sensor-OZW_Log.txt | uploaded via ZenHub

[Fishwaldo]

Looking at the Logs: 1) your using the ControllerCommand method todo inclusion. That will result in no attempt to enable security. You should use the new AddNode method instead. (Or OZWCP)

(Regardless, this device would be best used in non-secure mode. You can try including secure, but with a sleeping node, I doubt it would work too well. (We can try and if it fails as I suspect it will we can report it as bug to Philio

2) as far as status updates, I see Alarm CommandClasses triggered, so it should work. Why do you think it's not working.

[ugoviti]

Hi justin, thank you for replying.

I'm using Domoticz as OZW controller, I will report your suggestions to main developer.

anyway, inside domoticz, when opening or closing the sensor, I don't get any device update inside the web interface.

Can be related to this?

Opening sensor: 2015-05-10 17:58:00.474 Info, Node005, Received Alarm report: type=0, level=0 2015-05-10 17:58:00.476 Detail, Node005, Refreshed Value: old value=0, new value=0, type=uint8

Closing sensor: 2015-05-10 17:58:26.579 Info, Node005, Received Alarm report: type=0, level=0 2015-05-10 17:58:26.580 Detail, Node005, Refreshed Value: old value=0, new value=0, type=uint8

the value remain 0 when opening and when closing, I think domoticz can't identify the status of device.

King regards

[Fishwaldo]

I see this on your "open" log: 2015-05-10 15:48:32.736 Detail, Node005, Changes to this value are not verified 2015-05-10 15:48:32.738 Detail, Node005, Refreshed Value: old value=23, new value=22, type=uint8

So there is a change (the Alarm Class has many ValueID's tied to it). You would have to ask Domoticz why its not updating though. On the Close Log, its just after startup, so its populating the ValueID's - Hence we don't see "what changed" in that one... but I assume you would see something like new value=23, old value=22 if you do it after OZW has been running for a while.

I will be putting in some compile "warnings" soon so developers are encouraged to upgrade to the new API ASAP.

[nechry]

hello ugoviti, for info: the current config files is not fully right for this device. I add some PR to fix the 3 devices see: https://github.com/OpenZWave/open-zwave/pull/549 https://github.com/OpenZWave/open-zwave/pull/548 https://github.com/OpenZWave/open-zwave/pull/547 https://github.com/OpenZWave/open-zwave/pull/546

each version have some parameters or flag specific

[ugoviti]

Hi nerchi,

I seen your patches but still not tried... removing PIR configurations parameters for PST02-1C version (that doesn't have a PIR inside) I doubt that fix that specific problem (or I'm wrong?).

I agree with Justin, that must be fixed within the controller software (Domoticz in my case).

greetings.

[Fishwaldo]

Ok. So I will close this issue then?

[nechry]

Ugoviti, yes is why I just wrote for information. But we know a good configuration file is always fine.

[gizmocuz]

Finally had a option to test with this device. It will work in the end, but:

when receiving an update for COMMAND_CLASS_ALARM

we receive a BYTE value:

0x16 = door open 0x17 = door closed

0x08 = PIR (Burglar) 0x03 = Temper switch (Burglar)

is this standard ? (Or only for philio), is there some documentation about these values

Is there any application at the moment that handles this ?

Sure now i check for these values it will work, but would it not be easier is er translate this value to

0x03 => 0XFF 0x08 => 0xFF 0x16 => 0xFF 0x17 => 0x00

I also noticed this node is always failing when trying to request AlarmCmd_Get, maybe its an option to add this in the configuration file:

<!-- COMMAND_CLASS_ALARM AlarmCmd_Get not supported -->
<CommandClass id="113" action="remove" />

[Fishwaldo]

As you figured out, the Byte value indicates what type of Alarm was triggered.Your refering to the Alarm Level ValueID right?

I dont' think this is standardized, but vendor dependant. I'm hestitant to change the value reported as then you might have challenge determining what happened on certian devices that use the Alarm class for more than one "type" of alarm, or different alarm stages (eg, Normal, warning, critical etc I've seen on a Flood Sensor)

as for the config change, doing remove would cause us to drop the entire ALARM class from the device. Its better to do a getsupported="false"

but can you test before I make the change...

[Fishwaldo]

Ok. I stand semi corrected. Version 1 of the Alarm CC is vendor dependant, Version 2 has some definiations. We only half handle version 2 in the code, as in saying what "type" of alarm it is, but don't handle the alarm events that well.

Could you post a Alarm Report Recieved Line to issue #558 and where you found what the bytes represent?

[gizmocuz]

This indeed seems to solve the timeout messages:

^^^ something is wrong with this post display, i miss the line CommandClass id "113" getsupported="false"

if you can edit my post, you will see more lines above

@Fishwaldo I just read the philio PST02 manual, and it specifies the values 0x16/0x17

then because i was debugging i set a breakpoint and notices the 0x03 (temper) and 0x08 (pir)

[Fishwaldo]

Ok. Closing this issue and we will track the updates in #558

[openzwave-dev-watcher]

Hello ervery body,

Can you tell me how to to disable secure mode for PST02-1C. I try to include this device to Openhab and Habmin, but openhab shows always that "unsurported command class security", and in Habmin it show somtimes the name of this device but in sleep node or somtimes it is not recognized.

Thank you very much

Am Sonntag, 7. Juni 2015 17:25:33 UTC+2 schrieb Justin Hammond:

Ok. Closing this issue and we will track the updates in #558 https://github.com/OpenZWave/open-zwave/issues/558

— Reply to this email directly or view it on GitHub https://github.com/OpenZWave/open-zwave/issues/552#issuecomment-109764576 .

[Fishwaldo]

OpenHAB doesn't use OZW. You need to take it up with the OpenHAB developers.