[ANSWERED]: Philio PST-02B

Hi,
I've got a 3 in 1 Multisensor from Philio, the PST-02B. It is a new generation small sensor, with luminance, temperature and presence detection. It has an "automatic inclusion mode" when it is powered. No dedicated include/exclude button. I tried and I was unable to include it on my Aeon stick 2 usb controller. Would that be possible or should I wait for the new gen usb stick?

[matt (support)]

Could you not include it with the Z-Stick, or could you not Define/Sync it in Indigo? It should definitely include with the Z-Stick regardless of the generation it is. If it doesn't include, the put the Z-Stick in exclusion mode first and exclude it. It might have been paired in the factory during QA and modules can only be included with 1 controller at a time.

Once you get it included, please copy/paste the Event Log window contents showing the Define/Sync of it with Indigo. I'd like to see what specific capabilities it reports.

Thanks Matt. I tried several times to exclude and finally worked, after opening and pressing several times a switch that is locate just in the reverse of the tamper mechanism. Then I included using the same press method. It is recognized as routing slave and displays only the battery level. Here is the log I got:
Hope this helps to progress in using it later fully. The model number on the sticker,back of the device, reads PST02-1B.

21 Apr 2015 18:42:04
Z-Wave Syncing - started for device "082 - Routing Slave"
Z-Wave Syncing - retrieved module neighbors list: 1, 14, 16, 20, 28, 30, 35, 37, 50, 51, 64, 67, 69, 77
Z-Wave Syncing - requesting neighbor list update of "082 - Routing Slave"
Z-Wave Syncing - neighbor list updated from 1, 14, 16, 20, 28, 30, 35, 37, 50, 51, 64, 67, 69, 77 to 1, 14, 16, 17, 20, 23, 28, 30, 31, 35, 36, 37, 40, 50, 51, 64, 65, 68, 69, 77
Z-Wave Syncing - assigning return route to "082 - Routing Slave"
Z-Wave Syncing - assigned return route
Z-Wave Syncing - retrieved manufacture and model names: Philio - 013C, Routing Slave - 0002000D
Z-Wave Syncing - retrieved protocol version 3.95, app version 1.17
Z-Wave Syncing - retrieved class hierarchy: Routing Slave : -- : -- (04 : 07 : 01, base 00)
Z-Wave Syncing - retrieved command classes: 80v1 70v1 84v2 85v1 86v1 71v1 8Fv1 30v1 31v5 72v1 73v1 98v1 59v1 5Av1 7Av1 5Ev1
Z-Wave Syncing - retrieved wake interval of 1440 minutes
Z-Wave Syncing - device "082 - Routing Slave" wake interval changed to 60 minutes
Z-Wave Syncing - retrieved group 1 associations: []
Z-Wave Syncing - retrieved group 2 associations: []
Z-Wave Syncing - added group 1 association to interface
Z-Wave Syncing - retrieved battery level of 100%
Z-Wave Syncing - created device "082 - Routing Slave"
Z-Wave Syncing - complete
Z-Wave received "082 - Routing Slave" status update battery level 100%

[matt (support)]

Thanks for the additional details. I've added it to our Z-Wave module support request list. We'll look into it.

I have the PST02-C sensor from Philio tech

It is the version with temperature, lightmeter, door/window contact

This is what appears inside my log when I open or close the door :
20 Jun 2015 14:47:26
Z-Wave Debug RCVD multiCmdPacket: 01 24 00 04 00 05 1E 8F 01 04 03 80 03 64 09 71 05 00 00 00 FF 06 16 00 05 31 05 03 01 0D 06 31 05 01 0A 00 42 7D
Z-Wave Debug . . multiCmdPacket: node 005, numCmds 4
Z-Wave Debug RCVD requestBatteryLevel: 01 09 00 04 00 05 03 80 03 64 FF
Z-Wave Debug . . requestBatteryLevel: node 005, level 100
Z-Wave received "005 - Deur Sensor Eetplaats" status update battery level 100%
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 0F 00 04 00 05 09 71 05 00 00 00 FF 06 16 00 FF
Z-Wave Debug . . requestAlarmSensorStatus: node 005, endpoint None, cmdClass 71, type 0, value 0
Z-Wave Debug RCVD requestVarSensorStatus: 01 0B 00 04 00 05 05 31 05 03 01 0D FF
Z-Wave Debug . . requestVarSensorStatus: node 005, endpoint None, type 3, raw value 010D...
Z-Wave Debug . . requestVarSensorStatus: 13% (float: 13.000000)
Z-Wave Debug RCVD requestVarSensorStatus: 01 0C 00 04 00 05 06 31 05 01 0A 00 42 FF
Z-Wave Debug . . requestVarSensorStatus: node 005, endpoint None, type 1, raw value 0A00...
Z-Wave Debug . . requestVarSensorStatus: 66 °F (float: 66.000000)
Z-Wave Debug RCVD multiCmdPacket: 01 24 00 04 00 05 1E 8F 01 04 03 80 03 64 09 71 05 00 00 00 FF 06 17 00 05 31 05 03 01 08 06 31 05 01 0A 00 42 79
Z-Wave Debug . . multiCmdPacket: node 005, numCmds 4
Z-Wave Debug RCVD requestBatteryLevel: 01 09 00 04 00 05 03 80 03 64 FF
Z-Wave Debug . . requestBatteryLevel: node 005, level 100
Z-Wave received "005 - Deur Sensor Eetplaats" status update battery level 100%
Z-Wave Debug RCVD requestAlarmSensorStatus: 01 0F 00 04 00 05 09 71 05 00 00 00 FF 06 17 00 FF
Z-Wave Debug . . requestAlarmSensorStatus: node 005, endpoint None, cmdClass 71, type 0, value 0
Z-Wave Debug RCVD requestVarSensorStatus: 01 0B 00 04 00 05 05 31 05 03 01 08 FF
Z-Wave Debug . . requestVarSensorStatus: node 005, endpoint None, type 3, raw value 0108...
Z-Wave Debug . . requestVarSensorStatus: 8% (float: 8.000000)
Z-Wave Debug RCVD requestVarSensorStatus: 01 0C 00 04 00 05 06 31 05 01 0A 00 42 FF
Z-Wave Debug . . requestVarSensorStatus: node 005, endpoint None, type 1, raw value 0A00...
Z-Wave Debug . . requestVarSensorStatus: 66 °F (float: 66.000000)


Sorry for the newbie question, as I am very new to Indigo : is there a way to manually configure unsopported devices or is an update from your end always needed before new types of devices can work ?
I'm currently on my trial period with Indigo. Last week I purchased a Vera Edge and it has been an extremely frustrating experience. I am still within my return period for the Vera, but it depends if I can get the philio sensors working in Indigo or not.

Sorry for the newbie question, as I am very new to Indigo : is there a way to manually configure unsopported devices or is an update from your end always needed before new types of devices can work ?

I can't comment on the rest, but support for new devices currently has to come from the developers.

New versions of known models don't usually take long, it's the new devices or those with new features that take a while.

Thanks for the clarification.

Actually I think it's a good thing that the developers need to provide support for devices.
I had a nightmare experience with a Vera Edge controller trying to add these sensors.
They worked in the end but there was much voodoo and jumping through lots of hoops involved to get them to function properly.

[jay (support)]

Because of how Z-Wave classes are implemented, some devices will just work because they implement the standard classes in the standard way. This is almost universally true for devices implementing On/Off and dimming functionality. Beyond that, it starts getting a little less clear. There are standard classes for sensors, like the one you have.

When you did the define and sync, what happened? It looks as if Indigo knows something about the device.

[EDIT] sorry, didn't go far enough up the thread to see Matt's post. It looks like we'll have to add a specific device definition for this device.

Hi guys,

I bought a couple of these Philio PST02-1B Philio Tech 3-in-1-sensors.
I have 4 of the old version (PST01) and they are working perfect.

At this moment the PST02 series are recognized by Indigo as a Slave module.
And that's not right

Below the results/different of the 2 versions (old and new).
Please could you add this module to the Indigo support list.
The old ones are not deliverable anymore, so now we have 2 modules we can't use

Thanks for all your work and kind regards,

John


The (old) PSP01;

Z-Wave Indigo Device "Carport Motion " Z-Wave Properties:
Indigo Z-Wave Version: 1.0.355
Node ID: 71
Model: Multi Sensor (PSM/PSP)
Model ID: 00020002
Manufacturer: Philio
Manufacturer ID: 013C
Protocol Version: 3.41
Application Version: 1.00
Model Definition Version: 2
Library Type: 6
Class Name: Binary Sensor (routing)
Class Hierarchy: 04 : 20 : 01
Command Class Base: 30
Command Versions: 20v1 80v1 84v2 85v1 86v1 70v1 30v1 31v5 72v1
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, waking
Neighbors: 1, 11, 12, 15, 16, 17, 22, 25, 27, 33, 38, 39, 40, 45, 48, 54, 56, 57, 60, 61, 62, 66
Associations: 1:[1] 2:[]
Config Values: 3:70 4:99 5:8 6:5 7:6 8:3 9:4 10:12 11:12 12:1 13:1


The NEW PST02

Z-Wave Indigo Device "085 - Routing Slave" Z-Wave Properties:
Indigo Z-Wave Version: 1.0.355
Node ID: 85
Model: Routing Slave
Model ID: 0002000D
Manufacturer: Philio
Manufacturer ID: 013C
Protocol Version: 3.95
Application Version: 1.16
Model Definition Version: 0
Library Type: 3
Class Name: Routing Slave
Class Hierarchy: 04 : 07 : 01
Command Class Base: 00
Command Versions: 80v1 70v1 84v2 85v1 86v1 71v1 8Fv1 30v1 31v5 72v1 73v1 98v1 59v1 5Av1 7Av1 5Ev1
Multi-Endpoint Types: - none -
Multi-Endpoint Classes: - none -
Multi-Instance Counts: - none -
Features: routing, battery, beaming, waking
Neighbors: 1, 11, 12, 15, 16, 17, 22, 25, 27, 33, 34, 38, 39, 40, 41, 45, 48, 54, 56, 57, 60, 62, 64, 65, 77
Associations: 1:[1] 2:[]
Config Values: - none -

Hi,

I have the Philio PST-02A device and really would like to know id there's any progress in this?
Please give us an update

[matt (support)]

We aren't giving individual updates on specific module support anymore, but are actively working on adding new Z-Wave hardware support to the next major release of Indigo.

Hello guys,

Could you tell us why there is a difference between your support of the Fibaro FGMS-001 with new firmware and
the Philio PST series with new firmware?

Why is there a discriminating difference?

We are now waiting for almost 10 months for support of the latest Philio products.
I understand that sometimes total new Z-Wave devices are being supported in a total new Indigo versions but we don't understand why all normal existing devices aren't maintained.

Good software is always alive and kicking

Kind regards and all the best,

John

I'd also like to repeat my previous request to "Please" support the PST02-C.
It's been only 8 months since my last request.
I hope I don't come over as being pushy

[matt (support)]

The difference is we have confirmation one works with an existing device definition, the other I believe is going to require a new device definition. We cannot control what changes manufacturers make between firmware or model updates, and often times that make non-trivial changes in how the module communicates (and what configuration parameters are exposed). Some vendors are better about maintaining backwards compatibility (as in this case Fibaro did).

The other issue is that, of course, we don't have time to add all the requested modules (literally dozens of requests) to Indigo 6.1. Some of them will have to wait for Indigo 7, including the Philio.

Thanks for the explanation.

It's strange that in the beginning of Indigo 6 with the new Z-wave opportunities all kind of devices were supported.
When a new Z-wave brand or device was introduced, new little updates of Indigo came within a couple of weeks.

Many users switched to Indigo 6 and are now dependent of this version.
It's not so nice that this basic modules (which are regular changed by the manufacturer, new firmware, old for new one) are not being supported anymore by Indigo.
In fact Indigo at this moment support less Z-wave modules than a year ago…

We understand that there is a limit of your support of the flood of all new devices. That's normal and we agree with your business model of Indigo 7, you have to earn of course money!
But we disagree with the Indigo policy at this moment to let the users wait sometimes more than 10 months without any new little version for the normally supported brands and devices.

Kind regards,

John