This shows you the differences between two versions of the page.
Both sides previous revision Previous revision | |||
hass:high_availability [2020/06/03 10:33] a [Active/Standby State] |
hass:high_availability [2021/08/13 23:36] (current) a |
||
---|---|---|---|
Line 32: | Line 32: | ||
===== Active/ | ===== Active/ | ||
- | Only one instance | + | Only once instance |
+ | |||
+ | This starts off with a heartbeat automation that publishes the instances IP address every 60 seconds; | ||
+ | |||
+ | < | ||
+ | - id: ' | ||
+ | alias: HASS: | ||
+ | description: | ||
+ | trigger: | ||
+ | - platform: time_pattern | ||
+ | seconds: ' | ||
+ | condition: | ||
+ | - condition: state | ||
+ | entity_id: binary_sensor.active | ||
+ | state: ' | ||
+ | action: | ||
+ | - data: | ||
+ | payload: "{{ states(' | ||
+ | topic: home/ | ||
+ | service: mqtt.publish | ||
+ | </ | ||
+ | |||
+ | This works in concert with a binary_sensor that compares the published IP to the instance IP: | ||
+ | |||
+ | < | ||
+ | binary_sensor: | ||
+ | - platform: template | ||
+ | sensors: | ||
+ | active: | ||
+ | friendly_name: | ||
+ | value_template: | ||
+ | </ | ||
+ | |||
+ | Each automation then includes a condition to check the state of this sensor: | ||
+ | |||
+ | < | ||
+ | condition: | ||
+ | - condition: state | ||
+ | entity_id: binary_sensor.active | ||
+ | state: ' | ||
+ | </ | ||
+ | |||
+ | 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/ | ||
+ | This is the previous method I used for transferring control between | ||
+ | |||
+ | The currently active instance was recorded in the following | ||
< | < |