Zwave2 - Philio PSM02 Slim Multisensor: motion and door sensors seem to be linked

I have a Philio PSM02 Slim Multisensor Firmware Version 1.0 that worked perfectly under the old openHAB 1 Zwave binding.

I am finally moving over to the Zwave2 binding and the only sensor that still makes some problems is this one, as the door/window sensor and the movement sensor seem to be linked in the sense that always both report an alarm even if only one condition should have been triggered.

Yes, the respective items are linked to different channels: :slight_smile:

Contact ZWaveNode008PSM02SlimMultiSensor_DoorWindowSensor               "Lukis Zimmer Tür [MAP(]"             <door>          (gSecurity,gLukisRoom,gDoors)
Switch  ZWaveNode008PSM02SlimMultiSensor_MotionSensor                   "Lukis Zimmer Bewegung"                         <motion>        (gLukisRoom,gSecurity)

The Operation Mode is set to 0, the Multi-Sensor Function Switch is 4.

Does anybody have an idea? Chris?

Without debug logs as listed in the official documentation nobody could have any ideas to help.
What OH2 binding version are you using? Chris recommends 2.5M3 and above.

This is not fully true. I sometimes had the situation that there were people who immediately said something like “This is a problem that I know and it is easy to deal with.” And in my opinion it is better to wait for such an answer than having people dig into megabytes of logs in the first place. But this is debatable :slight_smile:

But there you go:
zwave2.log (545.5 KB)
zwave2events.txt (46.7 KB)

We are speaking about node8. At around the end I enter that room and both channels seem to trigger. This did not happen for zwave1.

I am using the one from the 2.5 test release and not one from Chris’ pool.

This is what I get from your debug log through the log viewer:

It definitely shows the behaviour your are talking about.

We already had a similar report here:

I am using a rebranded version of that device (just motion, not a door sensor) which reports the motion through the sensor_binary channel:

Unfortunately I have no idea how to solve this, we need to ping @chris for help.

1 Like

This looks to be caused by the device sending the BASIC_SET command, which contains no information about what type of sensor it is. This command class is (was!) then linked to the BINARY_SENSOR class, and with no type of sensor, it just triggers all types.

I’ve removed this link, but now it will not trigger at all. Ideally the device should be configured to send the BINARY_SENSOR command, but I don’t see any way to control this, so I don’t see how it is possible for the binding to know what the sensor type is.

1 Like

I don’t know if it makes a difference, but are you sure you have the DIP switches set correctly?

1 Like

Please keep in mind that it worked perfectly under the “old” zwave binding, with exactly the same settings. There must be (i.e. “is”) a way to distinguish between the two sensors.

I understand that you changed something. How do I get this into my system? Remove the thing and add it again? (or can I just edit the json? :slight_smile: )

I am pretty sure that this is correct as it worked under the old binding. I will check later on though.

Wait for the next export to Github (usually weekly) then the snapshot build need to compile the changes into the OH snapshot.
If you are running OH older than 2.5M3 you can use this script to install the new binding. (not sure if 2.5M3 works)

You then need to delete & re-discover the Thing. It should have the same ID so your Items & rules should still work properly.

Will do.

The old binding worked quite differently …

When I am using the test release of openHAB (i.e. “deb unstable main” in sources.list.d), what version in the sense of “2.5Mxxxx” do I run?

Unstable releases are the snapshot releases so you would just need the latest.
The Testing releases are the milestone versions.

No - not with the BASIC command class - ONLY with the BINARY_SENSOR command class.

It may be that this is all just down to the BASIC command class being mapped to the BINARY_SENSOR in the database. This might be the problem and I’ve now fixed that.

Okay. I never said is should be the BASIC command class :slight_smile:

That sounds like a logical explanation for the effect that we see.

Thank you so much in advance Chris. Unfortunately I won’t be able to test that on a short term, but hopefully by next week. I will keep you guys posted.

Okay. I mixed up the testing and the unstable snapshots. But anyway. In that case the update will be easy.

1 Like

I am back again. Meanwhile I had to move to the “testing” repository as the “unstable” repository seems to have some bugs currently.

Installing the “testing” repo reports that a “2.5M3-1” tag is used. So it should be the one that you would like me to have, right?

I removed the sensor that we talked about and rediscovered it using Paper UI.

But it still shows the same effect. When I enter the room, the motion item as well as the open/close item are switched on.

Is there a way that I can make sure or check that your changes have been applied to the “thing”?

@Bruce or @Chris: Is there anything else that I can do right now? I still have the hope that it is some trivial change that resolves my problem :slight_smile:

To get the latest binding fixes you likely need to manually install a snapshot binding.

@5iver wrote a scout that worked prior to M3 but I have not tried it on that version. I may be able to test later this week since I am setting up another M3 installation for testing some new devices.

I installed the "org.openhab.binding.zwave-2.5.0-20191015.051545-123.jar " version yesterday. It works so far but does not recognize the PSM02 sensor as such and the things remains an initializing state even after more than 12 hours.

I deleted the thing in the Paper UI, rediscovered it, added it from the inbox and waited for something to happen.The title of the thing-page says " Z-Wave Node 008 (013C:0002:0002:1.0). It never gets detected as a “PSM02 Slim Multisensor” as in the normal version of the binding.

It works in the sense that messages are received, but there is no change regarding the behaviour that I described as the initial problem.

I guess there is some mess with cached data, maybe the xml files…?

Should I wait for another version to appear?

Would you like to see a debug trace?