Skip to content

Home Assistant integration

rickylee64 edited this page May 18, 2019 · 15 revisions

Declare a switch into your configuration.yaml file following these examples (be careful about spaces that are not rendered correctly into the wiki).

Here is the link to the Home Assistant thread.

For RF

Thanks @ekim from the Home Assistant forum.

switch:
  - platform: mqtt
    name: "outlet5"
    state_topic: "home/OpenMQTTGateway/433toMQTT" # defined by subjectGTWRFtoMQTT in User_config.h
    command_topic: "home/OpenMQTTGateway/commands/MQTTto433/PLSL_180/433_1"
    payload_on: "5321987"
    payload_off: "5321996"
    optimistic: false
    retain: true

For IR

Thanks @craigcarps from the Home Assistant forum.

switch:
  - platform: mqtt
    name: "tvonoff"
    state_topic: "home/OpenMQTTGateway/IRtoMQTT" # defined by subjectGTWIRtoMQTT in User_config.h
    command_topic: "home/OpenMQTTGateway/commands/IR_SAMSUNG"
    payload_on: "3772793023"
    payload_off: "3772793023"
    optimistic: false
    retain: true

If you want to integrate your AC and it is not supported you can use raw signal, this solution is described in this section.

For DHT

Thanks @BertrumUK from the Home Assistant forum.

sensor:
  - platform: mqtt
    name: "MQTT RF Temperature"
    state_topic: "home/OpenMQTTGateway/DHTtoMQTT/dht1/temp"
    unit_of_measurement: "°C"
    value_template: '{{ value | round(2)  }}'

  - platform: mqtt
    name: "MQTT RF Humidity"
    state_topic: "home/OpenMQTTGateway/DHTtoMQTT/dht1/hum"
    unit_of_measurement: "%"
    value_template: '{{ value | round(2)  }}'

Other examples: https://github.com/rickybrent/433toMQTTto433_ESP8266/wiki/HomeAssistant-configuration-example

Real feel sensor (based on above DHT Temperature and Humidity):

sensor:
  - platform: template
    sensors:
      mqtt_real_feel:
        friendly_name: "mqtt real feel"
        value_template: '{{ (((-42.379 + (2.04901523*(((states.mqtt_rf_temperature.state|float)*1.8)+32)) + (10.14333127*(states.mqtt_rf_humidity.state|float)) - (0.22475541*(((states.mqtt_rf_temperature.state|float)*1.8)+32)*(states.mqtt_rf_humidity.state|float)) - (6.83783 * (10**(-3))*((((states.mqtt_rf_temperature.state|float)*1.8)+32)**2)) - (5.481717 * (10**(-2))*((states.mqtt_rf_humidity.state|float)**2)) + (1.22874 * (10**(-3))*((((states.mqtt_rf_temperature.state|float)*1.8)+32)**2*(states.mqtt_rf_humidity.state|float))) + (8.5282 * (10**(-4))*((((states.mqtt_rf_temperature.state|float)*1.8)+32)*(states.mqtt_rf_humidity.state|float)**2)) - (1.99 * (10**(-6))*((((states.mqtt_rf_temperature.state|float)*1.8)+32)**2)*((states.mqtt_rf_humidity.state|float)**2)))-32)/1.8)|round(2) }}'
        unit_of_measurement: "°C"

For Gateway State

Thanks to @Landrash

Reads the state of the LWT topic to detect if the gateway is "Online" or "Offline".

binary_sensor:
  - platform: mqtt
    name: "OpenMQTTGateway"
    state_topic: "home/OpenMQTTGateway/LWT"
    payload_on: "Online"
    payload_off: "Offline"
    device_class: "connectivity"

For gateway status information:

sensor:
  - platform: mqtt
    name: "Wifi OpenGateway ESP32"
    state_topic: "home/OpenMQTTGateway/SYStoMQTT"
    unit_of_measurement: 'dB'
    value_template: "{{ value_json.rssi}}"
    availability_topic: "home/OpenMQTTGateway/LWT"
    payload_available: "Online"
    payload_not_available: "Offline"
    icon: "mdi:wifi"
    json_attributes:
      - version
      - uptime
      - freeMem
      - SSID
      - modules

For BLE

Thanks to @PetricaM

Simple usage (to see it in the frontend) would involve setting only of a MQTT sensor (A). The issue is, however, that the sensor would show unknown value if not updated or the beacon is associated (thus the need for B). C came into being as a need to take into account the movement of the BT beacon from/towards the Gateway (meaning that when strength of the signal increases the sensor set at E will be on). Either D or E binary sensors could be used in automation (however in my example the automation with D binary sensor it would be with "off" rather than "on" for the trigger payload).

There are several limitations to using the BT presence sensor:

  • the BT device needs to be unassociated (so if using a BT token associated to a phone it won't work); the specific case below is for using a Tile associated to my secondary phone on which I keep, most of the time, the BT connection off; when I need to find my keys I open BT connection on the phone
  • due to the fact that Gateway readings are made, in the standard sketch, at 10 seconds (that is the Gateway will scan all BT signals received at each 10s), this is not suitable for using to trigger the lights. Although readings interval can be shorten and it could be used with MQTT Room Presence component (it requires a BT Gateway in each room monitoring is needed) it is not recommendable to use it for turning the lights on an actual production system. This is because, in practice, a light on would require a less than one second interval between trigger and action in order to be usable. I use it to open hallway lights when arriving at home (automation based on the binary sensor E) and it works as it usually takes several seconds from the moment the gateway senses the token until opening the front door. Anyway, redundancy through linking it with other components (such as PIR or open door sensors) would ensure reliability. I have each group of sensor in a separate file in the sensor/binary_sensor/automation folders so use proper indentation if placing all in configuration.yaml. Splitting the configuration in multiple files is highly recommended.

For MiFlora BLE

Thanks to @oakbrad

Create individual MQTT sensors for each value, then combine into one entity using the plant component.

configuration.yaml

sensor: !include sensors.yaml
plant:
  kitchen_pothos:
    sensors:
      moisture: sensor.kitchen_pothos_moisture
      temperature: sensor.kitchen_pothos_temperature
      conductivity: sensor.kitchen_pothos_conductivity
      brightness: sensor.kitchen_pothos_light_intensity
    min_moisture: 10
    max_moisture: 100
    min_conductivity: 200
    min_temperature: 45

sensors.yaml

- platform: mqtt
  name: kitchen_pothos_temperature
  unit_of_measurement: "°F"
  force_update: true
  expire_after: 21600 # 6 hours
  state_topic: "home/OpenMQTTGateway/BTtoMQTT/XXXXXXXXXXXX/tem"
  value_template: "{{ (((value | float) * 9 / 5) + 32) | round(1) }}" # C to F
- platform: mqtt
  name: kitchen_pothos_moisture
  force_update: true
  expire_after: 21600 # 6 hours
  state_topic: "home/OpenMQTTGateway/BTtoMQTT/XXXXXXXXXXXX/moi"
- platform: mqtt
  name: kitchen_pothos_light_intensity
  unit_of_measurement: lux
  force_update: true
  expire_after: 21600 # 6 hours
  state_topic: "home/OpenMQTTGateway/BTtoMQTT/XXXXXXXXXXXX/lux"
- platform: mqtt
  name: kitchen_pothos_conductivity
  force_update: true
  expire_after: 21600 # 6 hours
  state_topic: "home/OpenMQTTGateway/BTtoMQTT/XXXXXXXXXXXX/fer"

I Sensors:

A. Setting up initial sensor
sensor:
  - platform: mqtt
    state_topic: 'home/OpenMQTTGateway/BTtoMQTT/AAAAAAAAAAAA' # if the default MQTT topic was updated then this need to be reflected here; replace AA... with id of your device
    name: 'keys_car_state' 
    expire_after: 300 # modify this to desired value (measurement is in seconds)

B. Setting a sensor through altering the initial sensor readings in order to deal with "unknown" state

sensor:
  - platform: template
    sensors:
      keys_car: #unique names; this is different from the one above
        value_template: >
          {% if is_state('sensor.keys_car_state', 'unknown') %}
            -100 # RSSI values are negative; an even smaller value could be used 
          {% else %}
            {{states.sensor.keys_car_state.state | float}} #if the name of the sensor from step A was changed, include it here
          {% endif %}

C. Setting up a statistics sensor

sensor:
  - platform: statistics
    entity_id: 'sensor.keys_car' # this is the name of the sensor from step B
    name: 'keys_car_stats' #again, different id
    sampling_size: 10 # the default sample size is 20; can be modified to one's desires; 

II. Binary sensors

D. Setting a binary sensor based on the step A; this is mandatory for usage with more complex automation (such as "for" clause for trigger)

sensor:
  - platform: template
    sensors:
      bt_car_keys:
        friendly_name: 'bt_car_keys'
        value_template: >
          {% if is_state('sensor.keys_car_state', 'unknown') %} # modify here the value from step A
            true
          {% else %}
            false
          {% endif %}

E. Setting a binary sensor

sensor:
  - platform: template
    sensors:
        bt_car_keys_threshold:
          friendly_name: 'bt_car_keys_threshold'
          value_template: '{{ states.sensor.keys_car_stats_mean.attributes["average_change"] | float > 0 }}' #"key_car_stats" is the name from C; mean is used but could be also other statistics (median, change, variation, count, etc)

III. Automation

automation:
  - alias: 'bt_hallway_lights'
    initial_state: 'on'
    trigger:
      - platform: state
        entity_id: binary_sensor.bt_car_keys_threshold # the same name as step E
        to: 'on' 
  # with the binary sensor a "for" clause can be used (see below and remove the # if needed); for regular sensors this is not possible; this depends if you live on a upper floor and want to trigger the lights only when in front of the door 
        #for: 
            #seconds: 3
    condition:
      condition: and #a simple condition could be used however I have also a condition that uses different light colors based on a switch; using from the beginning the "condition: and" would be easier to modify subsequently
      conditions:
        - condition: state
          entity_id: sun.sun
          state: 'below_horizon'
    action:
      - service: homeassistant.turn_on
        entity_id: light.hallway #replace with your light

IV. Hide all from view (after ensuring all works as intended) by including this in the configuration.yaml

customize:
    "sensor.keys*":
      hidden: true
    "binary_sensor.bt*":
      hidden: true
    "automation.bt*":
      hidden: true

For Sonoff bridge values works with Openmqttgateway 0.9

thanks @twooting

sensor:
  - platform: mqtt
    name: "SonoffBridge values"
    value_template: "{{ value_json.value }}"
    state_topic: "home/OpenMQTTGateway/SRFBtoMQTT"
    json_attributes: 
      - "raw"
      - "value"
      - "delay"
      - "val_Thigh"
      - "val_Tlow"
    qos: 1
Clone this wiki locally
You can’t perform that action at this time.