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.
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
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)
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.
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).