"Hackish" solution to general loss of bluetooth, dropouts and also OTA failures.

[EasilyBoredEngineer]

Hi All,

As we know bluetooth and wifi is shared on most esps. On my boards, this means that over the air (OTA) updates sometimes hang at about 42%.

Also, as others have noted, just in general the bluetooth randomly tends to drop out and stops the JK's updating home assistant (referenced in #235).

Although this is a bit hacky, here's my two solutions -

Let's first fix the OTA update failures. The solution is to turn off bluetooth automatically before you OTA. here's what you need to change...

First in the switch section of your YAML, you need to add an 'id' to the ble_client section - here I've called it 'bms0_bluetooth.'.

 - platform: ble_client
    ble_client_id: client0
    id: bms0_bluetooth
    name: "${bms0} enable bluetooth connection"

next you need to go to the OTA section and add something like this - this will tell the esp to turn off bluetooth if an OTA update is pending:-

ota:
  password: "your password if you have one"
  on_begin:
    then:
    - switch.turn_off: bms0_bluetooth

Ok - that's the OTA updates sorted.

Now let's move on to the flakey bluetooth connections. My purpose here is to check to see if the bluetooth connection between the JK and the esp is down.

In the binary_sensor of your YAML add or edit the online_status section to add an id... something like this:-

binary_sensor:
  - platform: jk_bms_ble
    jk_bms_ble_id: bms0
    balancing:
      name: "${bms0} balancing"
    charging:
      name: "${bms0} charging"
    discharging:
      name: "${bms0} discharging"
    online_status:
      name: "${bms0} online status"
      id: bms0_status

then you need to add a new 'switch' to reset the esp. Go to the switch: section, and add something like this:-

  - platform: restart
    name: "My Esp Restart"
    id: esp_reset
    restore_mode: ALWAYS_OFF 

then create a new 'trigger' to reset the esp if your bluetooth stops communicating with the BMS. I've chosen to use a cron trigger, checking every 2 minutes, but if anyone can think of a better trigger to use, please comment. Note I've also chosen to kill two birds with one stone by checking we're connected to the home assistant api as well (this fixes wifi issues).

time:
  - platform: homeassistant
    on_time:
      - cron: '* /2 * * * *'
        then:
          if:
            condition:
              and:
                - binary_sensor.is_on: bms0_status
                - api.connected
            then:
              #nothing
            else:
              - switch.toggle: esp_reset

With these mods I've got my setup to be entirely resilient to gremlins.

[syssi]

Do you know the safe mode switch? You could boot your ESP into the safe mode on demand for doing OTA updates: https://esphome.io/components/switch/safe_mode.html

[EasilyBoredEngineer]

G'day my old friend @syssi - thanks again for your awesome contributions, being used almost in their entirety (DL24, JBD, JK) 24/7 out in the Aussie Bush - your hard work appreciated :)

Syssi, yes I have since found out about the safe mode switch, after I concocted this workaround for the OTA updates, but - to be honest - I now just add this workaround to the OTA section of every YAML when I'm using an ESP - it means OTA 'just works' without any other intervention- don't even need to hit a switch - to me it's a perfect addition that should be part of the core.

@syssi - with regards to the second part of my contribution above, do you know of any other triggers I could use to activate a reboot upon loss of bluetooth other than a cron (time:) trigger? There's gotta be a more efficient way to do this than executing potentially blocking code every 2 mins -

Cheers - M

[syssi]

Doing such lightweight stuff every two minutes shouldn't hurt. I would use the interval component instead of using the heavy homeassistant platform: https://esphome.io/guides/automations.html#interval-component

interval:
  - interval: 2min
    then:
      if:
        condition:
          and:
            - binary_sensor.is_on: bms0_status
            - api.connected
        then:
          #nothing
        else:
          - switch.toggle: esp_reset

Please keep in mind the native api has it's own health check. See reboot_timeout and defaults to 15min: https://esphome.io/components/api.html#native-api-component

Same applies to the reboot_timeout parameter of the wifi component: https://esphome.io/components/wifi.html

You could also attach an automation to the online_status sensor directly instead of "polling":

binary_sensor:
  - platform: jk_bms_ble
    jk_bms_ble_id: bms0
    balancing:
      name: "${bms0} balancing"
    charging:
      name: "${bms0} charging"
    discharging:
      name: "${bms0} discharging"
    online_status:
      name: "${bms0} online status"
      id: bms0_status
      on_release:
        if:
          condition:
            for:
              time: 2min
              condition:
                binary_sensor.is_off: bms0_status
          then:
            - switch.toggle: esp_reset

This solution works a bit different:

1. If the online_status turns to offline the on_release trigger should fire
2. The condition of the bms0_status is monitored for 2 minutes. If it doesn't change the ESP will be rebooted

The API connection isn't respected here. The api will reboot the node if there is no api connection for 15 minutes.

[EasilyBoredEngineer]

@syssi - appreciated, mate - I'd tried to get something to work on the binary sensor section but without success - your solution is elegant and I'll try it -

@syssi, can you think of any other way to reestablish ble comms when they fail other than rebooting the board?

[kev300]

Did you try playing with the ble options?

esp32_ble_tracker:
  scan_parameters:
    interval: 500ms

I don't remember exactly why I changed this, but with that mine runs perfectly smooth and never looses connection.