User Tools

Site Tools


hass:high_availability

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
hass:high_availability [2020/06/03 09:59] ahass:high_availability [2021/08/13 23:36] (current) a
Line 32: Line 32:
  
 ===== Active/Standby State ===== ===== Active/Standby State =====
-Only one instance must be active at time. This requires a method for transferring control between instances. The simplest method for achieving this is a MQTT topic indicating which instance is active.+Only once instance should be active at any given time. This requires a way of suppressing the automations from running, as well as detected when the active instance has failed. 
 + 
 +This starts off with a heartbeat automation that publishes the instances IP address every 60 seconds; 
 + 
 +<code> 
 +- id: '1583253390883' 
 +  alias: HASS:Heartbeat 
 +  description: '' 
 +  trigger: 
 +  - platform: time_pattern 
 +    seconds: '0' 
 +  condition: 
 +  - condition: state 
 +    entity_id: binary_sensor.active 
 +    state: 'on' 
 +  action: 
 +  - data: 
 +      payload: "{{ states('sensor.local_ip') }}" 
 +      topic: home/hass/active 
 +    service: mqtt.publish 
 +</code> 
 + 
 +This works in concert with a binary_sensor that compares the published IP to the instance IP: 
 + 
 +<code> 
 +binary_sensor: 
 +  - platform: template 
 +    sensors: 
 +      active: 
 +        friendly_name: "Active IP" 
 +        value_template: "{{ states('sensor.partner') == states('sensor.local_ip') or is_state('sensor.partner', 'OFFLINE') or is_state('sensor.partner', 'unavailable') }}" 
 +</code> 
 + 
 +Each automation then includes a condition to check the state of this sensor: 
 + 
 +<code> 
 +  condition: 
 +  - condition: state 
 +    entity_id: binary_sensor.active 
 +    state: 'on' 
 +</code> 
 + 
 +Control can be manually transferred between instances by calling the heartbeat automation on the standby instance. This immediately publishes the IP address, toggling the state of the binary sensor in each instance. 
 + 
 +===== Active/Standby State (Old method) ===== 
 +This is the previous method I used for transferring control between the two instances. It had the advantage of not needing condition in each automation, but could get itself unstuck if all of the automations failed to enable or disable correctly. 
 + 
 +The currently active instance was recorded in the following MQTT topic:
  
 <code> <code>
Line 62: Line 109:
     payload: !secret partner     payload: !secret partner
     retain: 'false'     retain: 'false'
-<code>+</code>
  
 Additionally, to cover the scenario for a sudden loss of service, such as a crash or an ungraceful shutdown a heartbeat automation is used. Additionally, to cover the scenario for a sudden loss of service, such as a crash or an ungraceful shutdown a heartbeat automation is used.
Line 105: Line 152:
 This arrangement also allows for automations which should run regardless of whether the instance is active or not, or automations which run specifically when the instance is inactive. It does however require each automation to be modified with this condition, which may be onerous for an established setup. This arrangement also allows for automations which should run regardless of whether the instance is active or not, or automations which run specifically when the instance is inactive. It does however require each automation to be modified with this condition, which may be onerous for an established setup.
          
 +==== Disabling/Enabling Automations ====
 +This method is a little more involved to implement, but does allow existing automations to be used unmodified. The first part of the puzzle is a script to create a group which contains all the current automations:
 +
 +<code>
 +create_every_automation_group:
 +  sequence:
 +  - service: group.set
 +    data_template:
 +      object_id: every_automation
 +      entities: '{{ states.automation | map(attribute=''entity_id'') | join('','')}}'
 +</code>
 +
 +With this group created we can now control the status of each automation with the ''automation.turn_on'' service. Two automations are used to switch Home Assistant into and out of the active state:
 +
 +<code>
 +- id: '1582909860207'
 +  alias: HASS:Standby
 +  description: ''
 +  trigger:
 +  - entity_id: sensor.active
 +    platform: state
 +    to: !secret partner
 +  condition: []
 +  action:
 +  - data: {}
 +    service: script.create_every_automation_group
 +  - data: {}
 +    entity_id: group.every_automation
 +    service: automation.turn_off
 +  - data: {}
 +    entity_id: automation.hass_active
 +    service: automation.turn_on
 +- id: '1582910169504'
 +  alias: HASS:Active
 +  description: ''
 +  trigger:
 +  - entity_id: sensor.active
 +    from: !secret partner
 +    platform: state
 +  condition: []
 +  action:
 +  - data: {}
 +    service: script.create_every_automation_group
 +  - data: {}
 +    entity_id: group.every_automation
 +    service: automation.turn_on
 +</code>
  
 +Note that after the instance is moved into standby, the last action of the HASS:Standby automation is to re-enable the HASS:Active automation. This allows the standby instance to become active if its partner goes offline.
hass/high_availability.1591149557.txt.gz · Last modified: 2020/06/03 09:59 by a