I have a trigger channel executing a rule.
When the thing is offline and changes to online the trigger channel fires.
Does anybody has an idea how to exclude this specific situation?
In an item I can use the ‘from’ and ‘to’ statements to prevent this bit not with a trigger channel.
Innogy binding (3.1.0.M3)
Its an in wall dimmer with push button.
The button is a trigger channel
The innogy binding sometimes looses connection and recovers automatically and thats considered as firing the trigger channel.
The button also has a push-count channel.
That could be a workaround (the count value shouldn’t change when the binding looses connection and comes back again) but I’d rather find the root cause then avoiding the iasue.
You’ll probably have to create an issue on the binding and see if this is unexpected or working by design.I don’t know Innogy but I can see reasons why it might trigger that channel when it reconnects being a deliberate design/implementation decision.
I have the same issues with the WeMo binding for v3.2m4. With logging at INFO, I’m seeing numerous units returning state of NULL returned on the thing states polling. When it goes ONLINE, then it triggers the switch channel to ON which it really isn’t but rules fire.
If I recall, the logic polling the units changed from v2.4 to v3.x. v2.4 was completely solid, never had an issue.
Couple things changed a while ago which I could NOT upgrade due to it.
PING vs. HTTP testing - I’m assuming the 3.2m4 version is using HTTP polling now which I show a ton of NULL’s returned on many devices, had to turn off INFO level logging due to it. Now due to this, I’m seeing WeMo THINGS coming on/off line then triggering the switch state to ON when it comes back ONLINE triggering rules.
I’d be glad to show you the raw data what is happening. I have over 30 WeMo’s now and they all work on v2.4 using the PING polling version logic instead.