I am making some additional changes to the design. I am added a configuration setting to define what mode the device is in. Now the device_override will have a mode option. For example:
The options for mode will be toggle and on_only Toggle will work for 8 button and 4 button toggle but with the assumption that the user will use subcat: 0x1a for 4 button and subcat: 0x1b for 8 button. I considered adding a 4_scene mode but I think this is better for a few reasons.
BTW, the motion sensor has this same option but with only toggle or on_only so that is one of the reasons I decided to keep it simple with toggle and on_only modes. These will work for motion sensors too.
Added the override for the subcat and now it’s working fine. Since it’s the remote at fault regarding the groups and not the code then I’m just switching round my labels and it’s correcly operating 8 devices now.
One other thing I’ve noticed is that it has a tendency to generate multiple events for a button push, which can mean that switches ‘bounce’. On my MQTT switches it is less of a problem, but on my LEDs sometimes you have to press the button on the remote half a dozen times before the state change occurs. If you look at the HA control panel at the same time you’ll see the state change and then immediately change back.
Is there a means of adding a de-bounce within the HA logic, or does this need a change to the Insteon PLM code to ignore duplicate messages within a very short timeframe?
@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.