My SwitchBot is already set up in momentary mode from the SwitchBot app, yet the controls presented by HA for the device are toggle style and maintain their state when pressed. How can I configure HA’s SwitchBot integration to match the momentary mode?
Also, the integration’s documentation shows a “SwitchBot” entity with a “Switch mode” that should show the mode of the SwitchBot. However, there seems to no such entity when I look for it in HA settings.
I just installed a Switchbot and I’m wondering the same thing. Both lightning symbols trigger the Switchbot just the same which then pushes the physical button momentarily. The logbook doesn’t show a trigger if the same lightning symbol is pushed again which means that only way to get automation triggers in HA is to alternate between pushing the symbols which makes no sense. There should be one momentary symbol, not two latching ones.
This bugged me as well when I tried this earlier this year, before I switch to SwitchBot bot/curtain/meter/contact/motion MQTT ESP32 bridge - Local control where I just have a toggle button.
I am considering switching back now, with esphome bringing bluetooth proxy functionality, but if that messes with automations it wouldnt be a big help.
For the current implementation of the momentary mode (I call it push mode):
That’s exactly what’s confusing me too. Even the bot is set to “push mode”, the integration offers a switch entity with states on and off and actions turn on and turn off.
Both actions do the same: the bot’s arm pushes once. That leads to an inconsistent state based on the real-life usage of the bot:
E. g. I have to turn the switch entity on once to silence a sounder of a device which does not constantly make that sound. So the SwitchBot device state does not correspond with the device it controls.
Therefore I’d propose for all devices set to push mode to not offer a switch but a button entity. That’s the perfect (and existing) solution for exactly that operation mode of those WoHand devices.
I worked around this by using an automation which automatically turns the switch off after it has been turned on. In this case the arm is pushing a 2nd time of course which is acceptable in my first use-case. Anyway, pretty ugly workaround.
Update: found this issue. Not much progress until now, not sure if the SwitchBot integration actually is maintained.
Of course, I just don’t have access to it right now. But it is quite simple… once the entity gets turned on, wait 3 seconds and turn it off again, that’s it. If I remember it correctly without the 3 seconds delay it didn’t work cause the Bluetooth delay is quite massive.
Annoying anyway, the integration should just fix this…
I found something that works for me. I had an automation earlier that would just trigger the action twice with a delay to get back to the off state but I did not like that.
So instead after searching I went with an service that sets it off without doing the actual action.
(For my use-cases this workaround has the positive side effect of still having a state (on|off) - which is not the case for button entities - so I can do things with the switch entity in the UI. The workaround just makes the look and feel in the UI more intuitive and consistent to the expected behaviour.)
Crazy: once I run service: homeassistant.turn_off for the entity_id: switch.bot it stays off when it’s off.
But as I created a light.bot entity (using switch as x) based on the switch.bot, now when I run service: light.turn_off for the light.bot entity, guess what happens? Yeah, even it is OFF, the bot turns the light on.
This is pretty annoying especially as I’m using
service: light.turn_off
data: {}
target:
entity_id: all
to turn off all lights once there’s no one at home anymore (and this way the bot controlled light will always be turned on! ). Magic all of course also includes light.bot.
How to work around or even fix that? Any idea?
(not using entity_id: all or “switch as x” is not an option.)