@paulster It did not make it in. In fact, I closed the pull request because I have decided not to have mini-remotes show up as entities in HA. They will only generate events (on and off). Having them as binary_sensors does not make sense, the more I thougth about it. I should be pushing another PR tomorrow.
Regarding the delay and the duplicates you are referring to, I am a bit confused. First, I am not getting a delay with the triggers and if any entity is operating without a delay then every entity should operate without a delay so I am not clear on the situation. So I don’t see why MQTT entities would appear different than LED entities.
If you see the HA binary sensor change state then the trigger also fired. I am confident of that. Is it possible there is a delay in the LED sensors hearing the “action”? If you are pressing the remote multiple times, is it possible that is causing the issue?
I think what is happening is the remote is either not debounced very well, or is deliberately sending a continuous stream of ‘press’ events while the button is pressed, meaning that you’ll get multiple events received in HA. If you end up with an odd number of events then you’ll get the state change you expect, but with an even number of events they’ll net out to no change of state.
I imagine the MQTT broker ignores what it considers duplicate events within a defined time period, so works around this by default.
If there is a means of capturing the events sent from the remote then this ought to be fairly easy to track down, but then the question is how to solve it.
So I see what it is. This is a problem in the underlying insteonplm library that I have known about for a while but did not prioritize because it did not cause issues. When an INSTEON device sends a direct message like the ones we are talking about, it also sends clean up messages that follow up. These clean up messages are causing the library to hear and trigger the ‘on’ message multiple times. I assume MQTT devices don’t change state very quickly (i.e sub 0.5 sec) where the LED devices do. I am not seeing the issue because the Insteon devices don’t change state in less than 0.5s either (at least not in the HA system even if the actual device is faster than that). I will look at what it will take to dedup these messages. It has to be done some time so might as well be now.
In the meantime, add a delay to the action function before issueing the change state command. For example:
This will ensure that the signals are all heard before the state changes. Hopefully a 1 second delay does not ruin your use case until the real fix can get posted.
That’s great that you know what it is. I found that a 300ms delay seemed to deal with the multiple messages without making it unreasonably sluggish, so I’ve got a good workaround for the time being.
I submitted a pull request tonight for the mini-remotes. Threechanges from the version you have been using:
Mini-Remotes no longer show up as binary sensors. They only respond to events.(on and off)
The event names are now insteon_plm.button_on and insteon_plm.button_off. This will make them more applicable to other devices like toggle linc swiches.
Duplicate messages are now eliminated. (Woohoo)
If you want to use this now you can use the link above and download it from my repo. Keep in mind you need to upgrade to the latest insteonplm version 0.11.7.
- id: mini_remote_3f4733_button_a
alias: Mini Remote 1 Button A
trigger:
platform: event
event_type: insteon_plm.button_on
event_data:
address: 3f4733
button: a
action:
service: homeassistant.toggle
entity_id: switch.lounge_leds
If I trigger the event through the HA web interface it works, and I also see the circular buttons at the top of the web page for each of the 8 buttons per remote, which fire when you physically press a button, so something is going awry between the detection of the buttons being pressed and my trigger definitions.
The fact that you are seeing binary sensors at the top of the page indicates you are not running the current code. Did you down load it from my repository recently?
I’ve been testing this new version for the past 24 hours and it seems to be working really reliably.
It’s cleaned up the HA web interface nicely without all the binary sensors, and it’s activating precisely once per button press, which is a big improvement.
The only downside is the lag between the button press and the action that this version has introduced, presumably while it is dealing with the trailing messages.
Is there any way to get it to trigger the action immediately, but to then continue to suppress the trailing messages so that additional actions aren’t generated? There’s about a half-second delay between button press and action which, to the uninitiated, can make it seem like the button press didn’t do anything at first.
I am not seeing that lag. Have you run your instance in debug mode to see how fast the messages come in? It would be helpful to know if the message are the bottleneck or if Home Assistant is the bottle neck.
From what I can see, the delay seems to be with the messages. Running a tail -f on the log file I only see messages as the state change occurs. If I look at my Insteon repeater the state change occurs as the message light stops flashing and reverts to static, which is why I made the assumption that the logic was waiting for all of the messages to come in as opposed to executing on the first and then ignoring the subsequent ones.
Is there any specific testing or logging you’d recommend?
Can you send the debug log with both /homeassistant/components/insteon_plm and insteonplm both in debug mode? Here is the configuration.yaml settings you need: