Issue of the topic:
I have a rule firing a pushbullet notification when an item controlled by pigpio changes to the ON state. The rule is working but, instead of sending a single notification, it sends upwards of 18 of them nearly simultaneously.
The log doesn’t show any kind of bounce on the pigpio input (I’ve changed the debounce delay to 500ms just in case) and it doesn’t appear that the rule is firing multiple times (I need to check this and I’m not sure how right now).
Rule:
rule "Back Door Alert"
when
Item PigpioRemote_SecurityBackDoor received update
then
if (PigpioRemote_SecurityBackDoor.state == ON)
{
val actions = getActions("pushbullet", "pushbullet:bot:[redacted]")
if (actions !== null)
{
val result = actions.sendPushbulletNote("[redacted]", "DOOR ALERT", "Back door has been opened")
}
}
end
Items and things were all created in the OH3 GUI and I used the Pushbullet documentation as the basis for my rule.
to the beginning of your rule. That will definitely only trigger once per rule and you can see when the rule starts. For even more information add a second “Rule stopped” log to the end of your rule. When trying to chase down issues in rules you can’t use too much logging.
Further things to consider:
This might be part of your problem. I don’t know how your remote works but received update is a trigger that runs pretty much whenever any value is sent from a channel even if it’s the same value that item already has. So, even if you’re not getting any bounce or flipping you may be getting a series of ‘ON’ values in a row that are triggering this rule. Consider using changed as the trigger instead and that will only run the rule if the command that the item receives actually causes the state to change (which sounds more logical for a physical object such as a door anyway).
Another test you can run is to temporarily trigger this rule with a different item that you control, such as a dummy switch item that you create and setup with a simple widget. Then you can see if the notification is sent only once or many times with what you can guarantee is a single, controlled trigger event.
I actually added the logging step shortly after asking the question and it did reveal that there’s something going on with the pigpio items: there were 10 instances of the message in the log. I changed the trigger condition from received update to changed and that cleared up the repeated log entries.
I guess the “debounce” item in pigpio isn’t working as advertised… Maybe enabling the pull up or pull down resistor would take care of that? I need to take a second look at the level converter circuit I cooked up for this thing and see if it would be necessary…
At any rate, thank you so much for getting this sorted!
