OH3 zWave Motion Alarm not recognised firing (But Analyse shows it transition OK)

  • Platform information:

    • Hardware: R-Pi4 4GB with Razberry daughter board
    • OS:OpenHabian OH3.0.2
    • Java Runtime Environment: 11
    • openHAB version: 3.0.2
  • Issue of the topic:
    Previously (OH2) everything was mostly working. Now although OH3 is pretty much a bit improvement I can’t seem to get motion detection from a Fibaro multi sensor 6 firing correctly.

In the Item I can see via Analyse that the device is transitioning and the ON/OF is apparently being seen by OH3. e.g.

But the transitions don’t appear in event.log

openhabian@openhab:~ $ grep ZWHall /var/log/openhab/events.log
openhabian@openhab:~ $


And of course because events.log doesn’t see it my rules that use the event transition no longer work either


rule "Hallway Motion Detector triggered"
    Item ZWHallwaySensor_MotionAlarm received update ON
  logInfo("Main Hall Lights", "Motion On - MainHallManual_Mode = "+MainHallManual_Mode+" MainHallEvening_Mode = "+MainHallEvening_Mode)

The item in the channel is set to the ‘Default’ profile. And it’s of type switch/point

Should it be a different item type for a Motion Alarm sensor? And if Analyse shows it transition between ON/OFF why doesn’t events.log?

Is there anything at all in your events.log?

Try a less-picky rule trigger for testing

    Item ZWHallwaySensor_MotionAlarm received update

Try profile (none) - there is something screwy about having both Default and none choices.

Well, nothing for that device… Plenty for other things updating. e.g.

penhabian@openhab:~ $ tail -f /var/log/openhab/events.log|egrep -i hall
2021-05-14 14:33:22.506 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HallEntrance_Temp' changed from 14.47 °C to 14.46 °C
2021-05-14 14:33:22.507 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HallEntrance_Humid' changed from 63.36 to 63.45
2021-05-14 14:34:52.794 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HallEntrance_Temp' changed from 14.46 °C to 14.48 °C
2021-05-14 14:34:52.795 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'HallEntrance_Humid' changed from 63.45 to 63.38

And I see the config being updated for the target

2021-05-14 14:32:45.299 [INFO ] [openhab.event.ItemUpdatedEvent ] - Item 'MainHallM6Sensor_MotionAlarm' has been updated.

try none? Hmm… OK, I stopped using None (The ‘default’) because that stopped the update of read values from sensors (I use ‘Default’ now. Which is not the default… I’ll never get this terminology right at this rate)


So … what is this Item? It looks suspiciously like the one you want.

I don’t which is the correct ‘none’ profile, having two is screwy.
Hold on …

Looks like you are currently correct, and Default is the way to go.

It does. Unfortunately that log is from me editing the target… Not from the motion alarm actually triggering

I did a quick test with No profile. And I think that’s it… (I got one transition logged run events.log - I’m just tidying it up and I’ll see if that’s consistent)

I don’t really understand profiles properly, so I’m not sure why it would stop it from being updated when sensors reporting temperature etc HAVE to have a profile named ‘Default’ and not a (default) profile of None.

events.log by default does not show Item state updates. It does show Item changes.

Some motion sensors never send an “off”, just an “on” trigger. An Item linked to such a channel will get updates but never change state (after the first time).
It’s possible to work around that with use of expire, if you’d like to see changes.

So far as I can make out, profiles (none) and Default should be the same. Showing both is just a UI menu bug.

The purpose of a profile is to transform the raw data from the channel in some way, before it arrives at the Item state. You won’t be wanting any of that when linking a switch channel to a switch Item.

The MultiSensor6 does send trigger and clear events. It was working fine under OH2 where there isn’t as much opportunity for getting the config wrong. I’m pretty sure events.log always used to log both, so I’m assuming it should do for OH3 as well (Maybe faulty thinking there). We’ll see how we get on I guess.

events.log stopped logging updates only at around OH2.3

But if you got both, then there would be changes logged.
The single-event theory was speculation to fit your observations.

I’m still confused about MainHallM6Sensor_MotionAlarm and ZWHallwaySensor_MotionAlarm

Just here to mention, the documented ( in the binding docs) way to troubleshoot Z-Wave issues is to
collect DEBUG logs so the system can tell you what it sees to reduce guesswork,

There is also a log viewer here to assist.


Yeah, the observed was that zWave was getting the updates. Because Analyse showed them both transitioning from ON to OFF and OFF to ON.

It was the rules that weren’t firing like they did on OH2. And of course missing from events.log

I’m not sure (More testing needed), but I think it might get the difference between ‘switch’ and ‘contact’ perhaps?

Just looking, if it is the latest firmware, only OH 3.1.0M4 and later have the latest database entry. OH 3.0.2 only has database entries up to sometime in December 2020,


Analyze works off persisted Item data, doesn’t care where it came from zwave or what.

Your zwave channel has a type, switch or contact, beyond your control, not shown in screenshots to date.
Currently you’ve married it to a Switch type Item,obviously types should match.

There is a potential rules bug - editing an Item after the rule is loaded seems to destroy the trigger linkage. Previously only confirmed for files-based rules and Items.
The workaround is to make a small rule edit, will recreate linkage on saving.

That does not affect events.log, which should be logging changes (and not updates-to-same).

1 Like