No idea. The esp32 and the curtain is literally right next to each other.
if the rssi in HA shows up fine I am not concerned, maybe just be a logging issue. I haven’t seen a value greater (less than technically) then rssi -85 in my testing
HA is showing -77 the highest.
I am starting to play with the bot and noticing the on/off switch icon always revert back to the off state.
I have tried adding ‘assumed_state’ to customize.yaml file, but doesn’t work. Anyone knows who to fix?
switch.floor_heat_switch:
icon: mdi:power
assumed_state: false
The success value shows a 5. I thought it suppose to be a 1?
status = {"status":"success","value":5}
Answer:
I am just assuming the curtain response values are the same as bots where 1 or 5 = success, 3 = busy, everything else means failed
setting the hold seconds on bots is useful for people that need to use the same bot for different hold times.
Example: turning something on requires holding for 10 seconds, turning that same thing off requires holding for 0 seconds.
I have a device that does just that. I need to hold press for 3 seconds to turn off. A short press to turn on. I tried to follow your example in the V3 release note, but I am not understanding.
you have 2 options to set hold time
a )
publish a value from 0-100 for bot to (just lile position for curtain
<ESPMQTTTopic>/bot/<name>/set
b) publish a message like {"id":"switchbotone", "hold":5} to
<ESPMQTTTopic>/setHold
when hold time is set, the hold time will be retrieved right after
now that hold time is set, you can call a press command and it will hold for the new time you set
you have to set the hold time before the press.
You can set hold time right before the press action, or at anytime before. the bot remembers its hold time and so does the esp32
I should have a fix for this in v3.1. That works nice when the bot is in press mode, but ya in switch mode the state flips back temporarily until it receives a state update from the esp32
it will currently switch to the proper state once the commandSent is received and for good measure also when the individual device scan is performed after a set/control
v3.1 released
If previously using curtain you will need to delete the device and rediscover in HA after an ESP32 reboot in order to use new curtain position topic
bots had the mode attributes added
Ok. So this is what I have tried and it isn’t working. In the mobile app, I have set the press-hold time back to zero.
Need to have V4.0 +. I created a template script.
holdpress_bot:
sequence:
- service: mqtt.publish
data:
topic: 'switchbotmqtt/esp32/holdPress'
payload : "{\"id\":\"{{ bot }}\", \"hold\":\"{{ press }}\"}"
I am calling this script via automation. Not sure if the delay is needed, but I have tried with and without delay.
- alias: '24hr fan toggle on-off'
trigger:
- platform: time
at: '05:25:00'
- platform: time
at: '23:00:00'
condition:
- condition: template # Someone is Home
value_template: "{{ is_state('input_select.home_mode', 'Home') }}"
action:
- service: >-
{% if is_state( 'sensor.time', '05:25' ) %}
switch.turn_on
{% else %}
switch.turn_off
{% endif %}
data:
entity_id: switch.24hr_fan
- alias: '24hr fan toggle speed'
trigger:
- platform: state
entity_id: sensor.period_of_the_day
to: 'nightlight'
- platform: time
at: '05:30:00'
condition:
- condition: template # Someone is home
value_template: "{{ is_state('input_select.home_mode', 'Home') }}"
action:
- service: script.holdpress_bot
data:
bot: '24hr_fan'
press: 0
- service: switch.turn_on
data:
entity_id: switch.24hr_fan_switch
Both automation are zero second presses. I am assuming it is from the app I have set to zero.
In MQTT, I can see the setHold and it seems to be taken the hold numbers correctly.
To create a customer switch with hold press. Change to suite to your settings.
switch.yaml
- platform: template
switches:
floor_heater:
friendly_name: 'Floor Heater'
value_template: "{{ states('input_boolean.floor_heat') }}"
turn_on:
- service: script.holdpress_bot
data:
bot: 'floor_heat' # taken from your esp32 bot name
press: 0 # how long you want the press to hold
- service: input_boolean.turn_on
entity_id: input_boolean.floor_heat
turn_off:
- service: script.holdpress_bot
data:
bot: 'floor_heat' # taken from your esp32 bot name
press: 3 # how long you want the press to hold
- service: input_boolean.turn_off
entity_id: input_boolean.floor_heat
icon_template: >-
{% if is_state('input_boolean.floor_heat', 'on') %}
mdi:check-circle
{% else %}
mdi:check-circle-outline
{% endif %}
input_boolean.yaml
floor_heat:
name: Floor Heat
icon: mdi:radiator
you can try with <ESPMQTTTopic>/bot/<name>/set
payload "3" or 3 for a hold
you should not need a delay since the esp32 will handle it
I just noticed <ESPMQTTTopic>/setHold does not do a requestSettings after. It just sets the value on the bot. I’ll update it so it does
I have changed the script to this and mqtt does not read the changes under setHold
holdpress_bot:
sequence:
- service: mqtt.publish
data:
topic: 'switchbotmqtt/bot/24hr_fan/set'
payload: 3
I do not need to enable this setHold in the esp config file correct?
Oh wait, I see, it is not under a folder in the bot’s name. but the bot does not hold the press though.
nothing to do on esp32. but give me a couple min I am working on some minor changes again
I’ll try your scripts after
1 Like
Also in V3, I noticed I can only use switch.turn_on to press the bot. Using `switch.turn_off have no affect in moving the bot.
action:
- service: switch.turn_on
data:
entity_id: switch.24hr_fan_switch
v3.2 release. I haven’t tried your scripts yet, but I am able to call setHold and immediately after a press command. They will process in order by the esp32
Yes when the switch is in press mode, OFF is disabled/ignored. This is normal. A switch in press mode will always default to state = “OFF”. To do the press action, simply always call the ON command
If you want to manage an ON/OFF switch that controls a press action, you would need to create a separate device. The switchbot has no idea of the ON/OFF state when in press mode
the hold secs value is returned by an automatic requestSettings call that is made right after the hold secs command. You will find the hold secs confirmed value here on the settings topic. HA receiving a message on the settings topic will update the hold secs in HA
- <ESPMQTTTopic>/bot/<name>/settings
Example payloads:
- {"firmware":4.9,"timers":0,"inverted":false,"hold":5}
If you want to manage an ON/OFF switch that controls a press action, you would need to create a separate device. The switchbot has no idea of the ON/OFF state when in press mode
oh. I read some comments about this, but didn’t quite understand.
This will still work under V3.2?
Yes I fixed the setHold topic in v3.2, it wasn’t calling the requestSettings after to collect the proper hold secs from the bot.
setting the hold time through the /set topic was properly calling requestSettings, I just missed it in the other topic. Fixed in v3.2
Where you able to get it to work with the setHold? Still not able from my end.
I have tried both of these scripts.
holdpress_bot:
sequence:
- service: mqtt.publish
data:
topic: 'switchbotmqtt/setHold'
payload_template: "{\"id\":\"{{ bot }}\", \"hold\":\"{{ press }}\"}"
holdpress_bot:
sequence:
- service: mqtt.publish
data:
topic: 'switchbotmqtt/bot/{{ bot }}/set'
payload: "{{ press }}"
I am seeing the changes in mqtt.
yes, it seems to be working fine for me in nodered. I’ll try ur script in a bit. working on a couple things atm
…and you aren’t seeing hold returned here…?
see "hold": 5 in my example
<ESPMQTTTopic>/bot/<name>/settings
Example payloads:
- {"firmware":4.9,"timers":0,"inverted":false,"hold":5}
this is where the hold is returned after u set it.
the esp32 cant call the press action before it gets this
This is the serial log output.
Control MQTT Received...
Received something on switchbotmqtt/esp32/control
24hr_fan
Processing Control MQTT...
Device: 24hr_fan
Device value: ON
Try to connect. Try a reconnect first...
lld_pdu_get_tx_flush_nb HCI packet count mismatch (1, 2)
Reconnect failed
Connected
Connected to: fa:b6:25:7b:05:e4
RSSI: -79
Sending command...
subscribed to notify
CUSTOM write service not found.
Sending command...
Attempt to send command. Not connecting. Try connecting...
Try to connect. Try a reconnect first...
Connected
Reconnected client
Connected to: fa:b6:25:7b:05:e4
RSSI: -83
subscribed to notify
Wrote new value to: cba20002-224d-11e6-9fb8-0002a5d5c51b
notifyCB
deviceName: WoHand
Success! Command sent/received to/from SwitchBot
The response value from bot action: 5
Done sendCommand...
In the app, do I set it to zero or 3 for my case?