Update HA-Core from 2024.3.1 to 2024.4.3 causes issues with REMOTE home assistant instance when calling remote scripts from the master

[ecou2508]

The problem
I have 2 raspberry pi4 setups: a master and a slave, connected together with "remote home-assistant" integration. Both were working fine since years with every updates UNTIL i updated core from 2024.3.1 to 2024.4.3 on both systems:
Strange behaviour appears : remote scripts run TWICE and even 3 times.....

Reinstall of REMOTE HA integration on both systems did NOT help.
Downgrading SLAVE HA Core to previous one (backup) seems ok for a very short time: bug come back in a short time.
Downgrading the MASTER instance HA Core to 2024.3.1 from backup completely solves the problem.
Pay attention to the fact that the problem does not appear immediately, it may takes few min to few hours (i did not measure).
The problem seems to only affect SCRIPTS (Master calls remote HA scripts)
The remote system is on the same LAN
The prefix of the remote instance is 'remote_' (and has always been so...)
The problem only appears with the remote system scripts which are called from the master and therefore are executed on the slave.
thanks :-)
Eddy

[ecou2508]

With no hope of having a remote-homeassistant update, i'm in the process of MIGRATE all the communications (scripts, sensors, switches, lights) handled by remote-homeassistant integration TO MQTT messaging and the mosquitto broker installed on the master raspberry pi.
So: bye-bye Remote-homeassistant !

[larry-glz]

@ecou2508 I’m also not getting the “warm and fuzzies” this integration will continue. Can you provide an example how your handling comms using MQTT?

[ecou2508]

Assuming you have a MQTT broker (mosquito) up and running, and MQTT enabled on both Home assistant instances....
To play audio on a "slave" HA from a master HA:
From the "master":

audio_script_2_ha2:
  sequence:
    #----------------------------------------
    - service: mqtt.publish
      continue_on_error: true
      data:
        topic: "homeassistant/ha2/audio_file_name"
        payload: "{{ audiofile }}"
        retain: true
        qos: 1
    #----------------------------------------
  mode: queued

and example how you call the script (on the master):

  - service: script.turn_on
    target:
      entity_id: script.audio_script_2_ha2
    data:
      variables:
        audiofile: warning.wav

On the "slave" where the audio has to be played:
automation:

- id: mqtt_2_audio_play_file
  alias: mqtt_2_audio_play_file
  trigger:
  - platform: mqtt
    topic: "homeassistant/ha2/audio_file_name"
  action:
  - service: script.turn_on
    target:
      entity_id: script.script_audio
    data:
      variables:
        audiofile: "{{ trigger.payload }}"
  mode: queued

and the script:

script_audio:
  alias: script_audio
  sequence:
  - service: hassio.addon_stdin
    continue_on_error: true
    data_template:
      addon: 3ebf62bd_notifier
      input:
        volume: 100
        # wav and mp3 files ins \config\www\audio
        music: audio/"{{ audiofile }}"
  mode: queued

[ecou2508]

For switches (and lights) and sensors, i can also share the code if you need it ?
For the switches: using the recommandations for MQTT Switch platform (home assistant official docs) does NOT work correctly for sharing between 2 HAs. They suggest to use a command topic and a state topic, i prefer to use a single topic for both and this works perfect, otherwise , with 2 topics mode, i have some specific relais switching accidentaly.........
https://community.home-assistant.io/t/mqtt-statestream-for-connecting-2-ha-instances/721820/9

[larry-glz]

This is good input. Yes, I would like to see the code for switches/lights/sensors

[ecou2508]

The below code is for a "master" HA instance controling a "slave" HA instance (HA2) where Silvercrest Zigbee smart plugs (with power and consumption measuring) are connected with ZHA.

Mosquito Broker is installed on HA1 (unimportant..)
Remarks:

1. As i suggested, the example below is using the same topic for the command (set) and the status of switch !
   because we are here, sharing switches between 2 HA instances and not with standalone switches like tasmota,...
2. Install MQTT Explorer on a PC (windows or linux or mac) and subscribe to all topics on your mosquito broker so it's easy to see what is published and debug things !

##################### HA1 (master side) #########################
Configuration.yaml => mqtt: !include_dir_merge_named mqtt/

Create a mqtt folder, and there create 1 yaml file for sensors and another for switches.

You can ONLY have one file for MQTT definitions with the keyword "sensor:" at top of the file and ONLY one file with the keyword "switch:". That means you have to put all the sensors in 1 file and the switches in another unique file (the same goes for binary_sensor: MQTT statement in a third file...)
MQTT definitions DOES NOT use the same rules as Home Assistant Templates definitions where you may have tons of files with the keyword "sensor:", "binary_sensor:" without any problem but with MQTT, this doesn't work ! ! !

These 2 files are for sensors, binary_sensors and switches definitions (like in configuration.yaml)

Example of sensors code for a plug named TS011F02 where you want "active power" and "energy delivered" :

sensor:
############  TS011F_02  ##############
  - name: "ts011f_02_active_power"
    unique_id: "ts011f_02_active_power"
    state_class: "measurement"
    device_class: "power"
    unit_of_measurement: "W"
    icon: mdi:flash
    state_topic: "homeassistant/sensor/ts011f_02_active_power/state"
    qos: 0

  - name: "ts011f_02_summation_delivered"
    unique_id: "ts011f_02_summation_delivered"
    state_class: "total_increasing"
    device_class: "power"
    unit_of_measurement: "kWh"
    icon: mdi:lightning-bolt
    state_topic: "homeassistant/sensor/ts011f_02_summation_delivered/state"
    qos: 0

and in the yaml file for the "switch side" of the same plug:

switch:
  - unique_id: ts011f_02_switch
    name: "ts011f_02_switch"
    icon: "mdi:electric-switch"
    state_topic: "homeassistant/switch/ts011f_02_switch"
    command_topic: "homeassistant/switch/ts011f_02_switch"
    availability_topic: "homeassistant/sensor/ts011f_02_status"
    payload_available: "available"
    payload_not_available: "unavailable"
    payload_on: "on"
    payload_off: "off"
    optimistic: false
    qos: 1
    retain: true

##################### HA2 (slave side) #########################
in configuration.yaml:

mqtt: !include_dir_merge_named mqtt/

mqtt_statestream:
  base_topic: homeassistant
  publish_attributes: true
  publish_timestamps: false
  include:
    entities:
      - sensor.ts011f_02_active_power
      - sensor.ts011f_02_summation_delivered
# This will automatically creates/publish all the necessary topics  for the above sensors ! ! !

Somewhere, place these 2 automations:
first one turn the switch on or off based on what is received on MQTT topic
(on HA2, nothing to put in /mqtt/sensors.yaml or /mqtt/switches.yaml definition files..)

# ts011f_02_switch  (MQTT)
- id: mqtt_2_ha2_ts011f_02_switch
  alias: mqtt_2_ha2_ts011f_02_switch
  trigger:
  - platform: mqtt
    topic: "homeassistant/switch/ts011f_02_switch"
  condition: []
  action:
  - if: "{{ trigger.payload == 'on' }}"
    then:
      - service: switch.turn_on
        continue_on_error: true
        target:
          entity_id: switch.ts011f_02_switch
  - if: "{{ trigger.payload == 'off' }}"
    then:
      - service: switch.turn_off
        continue_on_error: true
        target:
          entity_id: switch.ts011f_02_switch
  mode: queued

second one is publishing state changes if the switch is manipulated localy, so the master HA can be aware of..

- id: ha2_ts011f_02_switch_2_mqtt
  alias: ha2_ts011f_02_switch_2_mqtt
  trigger:
  - platform: state
    entity_id: switch.ts011f_02_switch
  condition: []
  action:
  #----------------------------------------
  - service: mqtt.publish
    data:
      topic: "homeassistant/switch/ts011f_02_switch"
      payload_template: "{{ states['switch.ts011f_02_switch'].state }}"
      retain: true
      qos: 1
  #----------------------------------------
  - if: "{{ states['switch.ts011f_02_switch'].state == 'unavailable' }}"
    then:
    #-------------------
    - service: mqtt.publish
      data:
        topic: "homeassistant/sensor/ts011f_02_status"
        payload_template: "unavailable"
        retain: true
        qos: 1
    #-------------------
    else:
    #-------------------
    - service: mqtt.publish
      data:
        topic: "homeassistant/sensor/ts011f_02_status"
        payload_template: "available"
        retain: true
        qos: 1
    #-------------------
  #----------------------------------------
  mode: queued

Be patient for debugging and observe what is published with MQTT Explorer.

[larry-glz]

Thanks. I’ll give it a try

[ecou2508]

in the above latest automation, i think it would be preferable to use states('entity_id') instead of states['entity_id'].state and check also for unknown state (unknown or unavailable).
I'm doing some tests for a few days because i have zigbee signal quality problems with ZHA and the home assistant skyconnect
usb stick....