[Feature request] Add event after OTA update

[psolyca]

I have a battery powered device which shutdown automatically after a period of time.
I managed to extend the delay palying with wifi states in my autoexec.bat file.

I try to manage my update automatically with Home Assistant but I have some difficulties.

The process is :

• in HA, check for MQTT Connected event
• in HA, check a firmware is available on my server (I put it manually)
• in HA send to MQTT messages, one to avoid normal start of the device and one to update the device through ota_http

In my module everything is ok, firmware is updated and the device reboot with the new firmware.
BUT on reboot, as the file exists on my server, the process begin again.

I could add a button to enable/disable the update process but I prefer the automatic way.
So I was thinking of an event after the update which could be used to send a MQTT message to HA to delete the firmware file or something in HA to avoid a second update.

Currently, I use button.

[openshwprojects]

I think it's a good idea. So... OTAState event with values like 0 for started, and 1 for done?

[psolyca]

Yes, could be great to have also the start ^

[rpv-tomsk]

BUT on reboot, as the file exists on my server, the process begin again.

Maybe you need to compare fw version and skip new update start?
However, that doesn't cancel the idea of ​​adding an event )

[rpv-tomsk]

Can you please describe the process more detailed, "for newbie" )) ?

in HA send to MQTT messages, one to avoid normal start of the device and one to update the device through ota_http

Why does the device searches for a firmware update on the server after rebooting?
There shouldn't be any new messages, like sent on step 3?

[psolyca]

I'm not sure my process is the rigth one, I tried to simplify it.
It's not the device the problem, it's on HA side.

So on my low powered device (even if USB powered), I have this autoexec.bat.

startDriver tuyaMCU
// TuyaMCU channels
setChannelType 1 Temperature_div10
linkTuyaMCUOutputToChannel 1 val 1
setChannelType 2 Humidity
linkTuyaMCUOutputToChannel 2 val 2
setChannelType 3 BatteryLevelPercent
linkTuyaMCUOutputToChannel 4 val 3
// Temperature sampling
setChannelType 4 ReadOnly
linkTuyaMCUOutputToChannel 6 val 4
setChannelLabel 4 "Temperature sampling"
// Charge state
setChannelType 5 ReadOnly
linkTuyaMCUOutputToChannel 8 bool 5
setChannelLabel 5 "Charge state"
// Temperature unit
setChannelType 6 ReadOnly
linkTuyaMCUOutputToChannel 9 enum 6
setChannelLabel 6 "Temperature unit"
// Maximum temperature set
setChannelType 7 ReadOnly
linkTuyaMCUOutputToChannel 10 val 7
setChannelLabel 7 "Temperature max"
// Minimum temperature set
setChannelType 8 ReadOnly
linkTuyaMCUOutputToChannel 11 val 8
setChannelLabel 8 "Temperature min"
// Maximum humidity set
setChannelType 9 ReadOnly
linkTuyaMCUOutputToChannel 12 val 9
setChannelLabel 9 "Humidity max"
// Minimum humidity set
setChannelType 10 ReadOnly
linkTuyaMCUOutputToChannel 13 val 10
setChannelLabel 10 "Humidity min"
// Temperature alarm
setChannelType 11 ReadOnly
linkTuyaMCUOutputToChannel 14 enum 11
setChannelLabel 11 "Temperature alarm"
// Humidity alarm
setChannelType 12 ReadOnly
linkTuyaMCUOutputToChannel 15 enum 12
setChannelLabel 12 "Humidity alarm"
// Temperature periodic report
setChannelType 13 ReadOnly
linkTuyaMCUOutputToChannel 17 val 13
setChannelLabel 13 "Temperature periodic report"
// Temperature calibration
setChannelType 14 ReadOnly
linkTuyaMCUOutputToChannel 23 val 14
setChannelLabel 14 "Temperature calibration"
// Humidity calibration
setChannelType 15 ReadOnly
linkTuyaMCUOutputToChannel 24 val 15
setChannelLabel 15 "Humidity calibration"

startDriver NTP

// Update "variable"
setChannelPrivate 30 true
// Delay "variable"
setChannelPrivate 40 true

// Timer
// Restart after 165 s (MCU stop wifi module after 175 s and never restart)
setChannelPrivate 50 true
setChannel 50 165
alias do_check if $CH50==0 then restart
alias do_tick backlog addChannel 50 -1; do_check

waitFor WifiState 4
// Send MCU fake wifi status (not connected) to delay power off
tuyaMcu_sendMCUConf 3

waitFor MQTTState 1
delay_ms 500
// Check if update available
if $CH30==1 then goto end

// Check for delay
if $CH40==1 then goto delay

// finally if nothing else start normally to handle status data
startDriver tmSensor
// and send MCU real wifi status (connected)
tuyaMcu_sendMCUConf 4
goto end

delay:
do_tick
delay_s 1
goto delay

end:

For information, without tmSensor the device stay up for 175 s, then stop and does not restart automatically. With tmSensor it's 5 s after "wifi connected" and restart automatically. So I play with the wifi state to be able to delay shutdown.

So, on HA side I have currently 2 input_boolean

obkupdate:
  name: Update OBK
  icon: mdi:update
obkdelay:
  name: Add delay
  icon: mdi:clock

Which are handle on my dashboard with two buttons in the badge section

- type: custom:mushroom-template-badge
        content: >-
          {{ 'Update' if states(entity) == 'on' else 'No update' }}
        icon: mdi:clock
        color: '{{ ''green'' if states(entity) == ''on'' else ''red'' }}'
        entity: input_boolean.obkupdate
        tap_action:
          action: toggle
      - type: custom:mushroom-template-badge
        content: >-
          {{ 'Delay' if states(entity) == 'on' else 'No delay' }}
        icon: mdi:clock
        color: '{{ ''green'' if states(entity) == ''on'' else ''red'' }}'
        entity: input_boolean.obkdelay
        tap_action:
          action: toggle

Finally, I have this automation which handle communication

alias: OBKClock inform update and/or delay
description: ""
triggers:
  - trigger: mqtt
    topic: OBKClock/connected
    payload: online
conditions: []
actions:
  - action: shell_command.fw_exists
    data: {}
    response_variable: fw_exists_ret
    enabled: false
  - if:
      - condition: template
        value_template: "{{ fw_exists_ret['stdout'] == '1' }}"
        enabled: false
      - condition: state
        entity_id: input_boolean.obkupdate
        state: "on"
    then:
      - action: mqtt.publish
        metadata: {}
        data:
          qos: "2"
          topic: OBKClock/30/set
          payload: "1"
      - action: mqtt.publish
        metadata: {}
        data:
          qos: "2"
          topic: cmnd/OBKClock/ota_http
          payload: http://192.168.1.20:8123/local/fw.rbl
        enabled: true
      - action: input_boolean.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: input_boolean.obkupdate
    else:
      - action: mqtt.publish
        metadata: {}
        data:
          qos: "2"
          topic: OBKClock/30/set
          payload: "0"
  - if:
      - condition: state
        state: "on"
        entity_id: input_boolean.obkdelay
    then:
      - action: mqtt.publish
        metadata: {}
        data:
          qos: "2"
          topic: OBKClock/40/set
          payload: "1"
      - action: input_boolean.turn_off
        metadata: {}
        data: {}
        target:
          entity_id: input_boolean.obkdelay
        enabled: false
    else:
      - action: mqtt.publish
        metadata: {}
        data:
          qos: "2"
          topic: OBKClock/40/set
          payload: "0"
mode: single

You can see that I tried to automate firmware detection in HA (it's currently disable) with the shell_command.fw_exists. It's a script which check file fw.rbl on my server (I put it manually).
And that's where I have troubles.
When the firmware is uploaded to the device, I do not have time to delete the file on the server cause I do not know when the upload is finished and when the device is started again. I know it with the MQTT connected status but it's too late, the process begin again.

[rpv-tomsk]

Don't read your reply carefully yet (will do this later), but... maybe you have to remove cmnd/OBKClock/ota_http value after a while?
So, device has to start OTA right after received MQTT message (message processing takes X seconds), that process takes YY seconds,
so remove message from "MQTT topic" after "X+1" < T < YY should be clear solution, which does not requires to delete file from server?

[psolyca]

I can not alter the command.
And I do not like the principle of X or YY times, cause it depends on the network and you could be faster or slower.
Event is a good way to get it on time.

[rpv-tomsk]

Yes, maybe be OTA _started_event could used to remove "command" from "queue"?