Home Assistant: Difference between revisions

From Leo's Notes
This page was last edited on 29 November 2022, at 06:25.
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
Home assistant is an open source home automation platform that can run on a local server.  It makes it extremely easy to integrate data from online and sensors around your home and performing some action based on the input.
Home assistant is an open source home automation platform that can run on a local server.  It makes it extremely easy to integrate data from online and sensors around your home and performing some action based on the input.
== Tasmota Integration ==
Read over the documentation at https://tasmota.github.io/docs/Home-Assistant/. However, a few things that I've constantly needed to look up are listed below.
* Relays as switches can be changed to a light entity by setting <code>SetOption30 1</code>
* <code>SetOption114</code> when set to 1 detaches the switch from its relay and sends MQTT messages instead
* <code>SetOption19</code> when set to <code>0</code> enables Home Assistant auto discovery; set to <code>1</code> only if you want to use the device as a MQTT device. It's one or the other; the device will show up under Tasmota xor MQTT.
* <code>SwitchMode#</code> should be set to <code>15</code> for switches that are reading values
Tasmota switches will by default show up as <code>binary_sensor.switch#</code>; this is expected. Manually change the entity ID.


==Tasks==
==Tasks==
Line 11: Line 21:


===Changing a Tasmota switch as a motion device===
===Changing a Tasmota switch as a motion device===
Tasmota switches with <code>SetOption114</code> are detected as binary_sensors by default. For blueprints that filter based on specific device classes (Eg. motion, light bulb), you will want change the device class. The simplest solution is to make your Tasmota device announce its configuration so that Home Assistant can auto-discover the configuration without requiring changes made to <code>configuration.yml</code>.
Tasmota switches with <code>SetOption114</code> are detected as binary_sensors by default. For blueprints that filter based on specific device classes (Eg. motion, light bulb), you will want change the device class.  


In the example below, I will be changing two PIR motion detectors connected to switch5 and switch6 into a motion device class.  
The simplest way to change an existing entity's device class is to specify a customization in <code>configuration.yml</code> using its entity ID:


For the first PIR connected to switch5, we will write the following Yaml:
#Make sure that you see the tasmota device and its entities. Change the entity ID as required (since they'll most likely be called <code>binary_sensor.sensor#</code>).
#Edit <code>configuration.yml</code> and add the following lines. The key must match the entity ID set in the previous step. Specify the <code>device_class</code> to something that makes sense (motion, door, light, illuminance, etc. See: https://www.home-assistant.io/docs/configuration/customizing-devices/#device-class)
{{Highlight
{{Highlight
| code = name: Main Floor PIR
| code = homeassistant:
state_topic: tasmota/%topic%/stat/STATE5
  customize:
payload_on: "ON"
    binary_sensor.leosroom_pir:
payload_off: "OFF"
      friendly_name: Leo Room Movement
availability_topic: tasmota/%topic%/tele/LWT
      device_class: motion
payload_available: Online
    binary_sensor.mainfloor_pir:
payload_not_available: Offline
      friendly_name: Main Floor Movement
device_class: motion
      device_class: motion
force_update: true
| lang = yaml
unique_id: '%deviceid%_mainfloor_motion'
device:
  identifiers:
    - '%deviceid%'
| lang = terminal
}}
}}
The <code>state_topic</code> is dependent on the <code>FullTopic</code> value that's configured in Tasmota. My configuration has it set to <code>tasmota/%topic%/%prefix%/</code> which means <code>Switch5</code> will announce its state at <code>tasmota/%topic%/stat/STATE5</code>. You will need to adjust the <code>state_topic</code> and <code>availability_topic</code> depending on your configuration. The on/off payload is also the default values of "ON" and "OFF".  Set the <code>unique_id</code> to something unique for this PIR sensor -- this value will be used in Home Assistant.
Convert this Yaml into compressed JSON (use https://onlineyamltools.com/convert-yaml-to-json). You should have something that looks like this:


{{Highlight
#Restart Home Assistant or reload the customizations (something that you need to enabled in your profile)
| code = <nowiki>{"name":"Main Floor PIR","state_topic":"tasmota/%topic%/stat/STATE5","payload_on":"ON","payload_off":"OFF","availability_topic":"tasmota/%topic%/tele/LWT","payload_available":"Online","payload_not_available":"Offline","device_class":"motion","force_update":true,"unique_id":"%deviceid%_mainfloor_motion","device":{"identifiers":["%deviceid%"]}}</nowiki>
#The devices should appear with the new device class -- the icons should reflect this. If not, restart the device as well to trigger an auto discovery.
| lang = json
}}


Generate the Yaml and JSON configuration for any additional PIR sensors that are connected to this Tasmota device.
Alternatively, you can try the instructions outlined at https://blakadder.com/pir-in-tasmota/. However, this method will create another device and entity under the MQTT integration and requires injecting a couple rules into the Tasmota device. I tried to follow the instructions and was only partially successful. In the end, I resorted to the customizations in <code>configuration.yml</code> instead.
 
Create a new rule that announces the configuration when the Tasmota device boots by running the following command in the Tasmota console (or via MQTT). Additional PIRs can be appended to the backlog command.
{{Highlight
| code = rule1 on system#boot do backlog publish2 <JSON1>; [publish2 <JSON2>;] endon
| lang = text
}}
In my case where I had 2 PIRs, the rule1 command I used looked like this:
{{Highlight
| code = <nowiki>rule1 on system#boot do backlog publish2 homeassistant/binary_sensor/%deviceid%_mainfloor_motion/config {"name":"Main Floor PIR","state_topic":"tasmota/%topic%/stat/STATE5","payload_on":"ON","payload_off":"OFF","availability_topic":"tasmota/%topic%/tele/LWT","payload_available":"Online","payload_not_available":"Offline","device_class":"motion","force_update":true,"unique_id":"%deviceid%_mainfloor_motion","device":{"identifiers":["%deviceid%"]}}; publish2 homeassistant/binary_sensor/%deviceid%_basement_motion/config {"name":"Basement PIR","state_topic":"tasmota/%topic%/stat/STATE6","payload_on":"ON","payload_off":"OFF","availability_topic":"tasmota/%topic%/tele/LWT","payload_available":"Online","payload_not_available":"Offline","device_class":"motion","force_update":true,"unique_id":"%deviceid%_basement_motion","device":{"identifiers":["%deviceid%"]}} endon</nowiki>
| lang = text
}}
Activate the rule, then reboot.
{{Highlight
| code = rule 1
restart 1
| lang = text
}}
If everything worked, you should see the PIR sensors as motion devices in Home Assistant.


===Setting up a reverse proxy to home assistant===
===Setting up a reverse proxy to home assistant===
Line 90: Line 73:


Now that you've added a RTSP camera to Home Assistant, you can also configure it to record
Now that you've added a RTSP camera to Home Assistant, you can also configure it to record
== Tasks ==
=== Run a shell script with a button ===
You can configure Home Assistant to run any command (including a shell script) quite simply.
First, edit <code>configuration.yaml</code> and define a new <code>shell_command</code> containing your commands. You can pass in parameters as command line arguments with template variables inside double quotes. For my use case, I wish to call a <code>tapo.sh</code> script that sends the X and Y offsets the camera should move. The <code>shell_command</code> definition should look like this:{{Highlight
| code = shell_command:
  tapo_move: /config/scripts/tapo.sh "<nowiki>{{ x }}" "{{ y }}</nowiki>"
| lang = terminal
}}Restart Home Assistant for the changes to apply.
Next, create a button in your dashboard and have the "Tap Action" be "Call Service" and specify the service to be the <code>shell_command.tapo_move</code> entity defined in the previous step. If you have any variables you would like to pass to the script, switch to the YAML editor and add them under a <code>data</code> key within the <code>tap_action</code>. The button definition under the YAML view should look similar to this:{{Highlight
| code = - show_name: true
  show_icon: true
  type: button
  tap_action:
    action: call-service
    service: shell_command.tapo_move
    data:
      x: 10
      y: 0
| lang = yaml
}}
Save the dashboard. Now, when pressing the button, it should invoke the <code>shell_command.tapo_move</code> command. The X and Y values should also be passed to the shell script.
I've used this to sucessfully control the motor of a Tapo C200 camera using a basic shell script rather than using pytapo (I just wanted to keep things simple without adding more dependencies for my use case).
== Troubleshooting ==
=== Error: Only automations in automations.yaml can be deleted. ===
This is such an opaque error message which I somehow managed to encounter after renaming one of my automations. There was no way to delete this phantom automation from the web interface since any attempt to interact with the automation will result in this helpful error: <code>Only automations in automations.yaml can be deleted.</code>
To fix this, you will have to edit the automations.yml file to contain an automation with this ID and alias name. Go to your automations page and click on the problematic automation. The URL should contain the ID number. The alias is the name of the automation. Add the following block to the automations.yml file:
{{Highlight
| code = - id: '1668998180437'
  alias: my broken automation's name
  description: foobar
  trigger: []
  condition: []
  action: []
  mode: single
| lang = terminal
}}
Restart Home Assistant. Go back to your automations list and you should now hopefully be able to delete the automation because it's now in the file.{{Navbox Linux}}
[[Category:Linux]]
[[Category:LinuxUtilities]]

Latest revision as of 06:25, 29 November 2022

Home assistant is an open source home automation platform that can run on a local server. It makes it extremely easy to integrate data from online and sensors around your home and performing some action based on the input.

Tasmota Integration

Read over the documentation at https://tasmota.github.io/docs/Home-Assistant/. However, a few things that I've constantly needed to look up are listed below.

  • Relays as switches can be changed to a light entity by setting SetOption30 1
  • SetOption114 when set to 1 detaches the switch from its relay and sends MQTT messages instead
  • SetOption19 when set to 0 enables Home Assistant auto discovery; set to 1 only if you want to use the device as a MQTT device. It's one or the other; the device will show up under Tasmota xor MQTT.
  • SwitchMode# should be set to 15 for switches that are reading values

Tasmota switches will by default show up as binary_sensor.switch#; this is expected. Manually change the entity ID.

Tasks

Adding Tasmota devices to Home Assistant

For the most part, Tasmota devices should automatically be found once you add the MQTT integration followed by the Tasmota integration. There is nothing to configure with the Tasmota configuration, however your devices running Tasmota need to be configured with an appropriate Topic and FullTopic MQTT setting (the defaults should work!).

If your devices aren't being detected by Home Assistant, ensure that your Tasmota devices have FullTopic set to something that includes the %prefix% and %topic% variables. Eg. /tasmota/%topic%/%prefix%/. Restart the device. When the devices connects to the MQTT server, the Tasmota integration should be able to detect it.

As a side note: For read-only switch sensors (eg. PIR/alarm zones), Tasmota should be configured with SetOption114 1 and SwitchOption# 15. With this configuration, the switches should appear as a binary sensor.

Changing a Tasmota switch as a motion device

Tasmota switches with SetOption114 are detected as binary_sensors by default. For blueprints that filter based on specific device classes (Eg. motion, light bulb), you will want change the device class.

The simplest way to change an existing entity's device class is to specify a customization in configuration.yml using its entity ID:

  1. Make sure that you see the tasmota device and its entities. Change the entity ID as required (since they'll most likely be called binary_sensor.sensor#).
  2. Edit configuration.yml and add the following lines. The key must match the entity ID set in the previous step. Specify the device_class to something that makes sense (motion, door, light, illuminance, etc. See: https://www.home-assistant.io/docs/configuration/customizing-devices/#device-class)
homeassistant:
  customize:
    binary_sensor.leosroom_pir:
      friendly_name: Leo Room Movement
      device_class: motion
    binary_sensor.mainfloor_pir:
      friendly_name: Main Floor Movement
      device_class: motion
  1. Restart Home Assistant or reload the customizations (something that you need to enabled in your profile)
  2. The devices should appear with the new device class -- the icons should reflect this. If not, restart the device as well to trigger an auto discovery.

Alternatively, you can try the instructions outlined at https://blakadder.com/pir-in-tasmota/. However, this method will create another device and entity under the MQTT integration and requires injecting a couple rules into the Tasmota device. I tried to follow the instructions and was only partially successful. In the end, I resorted to the customizations in configuration.yml instead.

Setting up a reverse proxy to home assistant

In order for Home Assistant to work behind a reverse proxy, you will need to add the following to your configuration.yml file:

http:
  base_url: http://assistant.example.com
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - 172.18.0.0/16

Adjust the reverse proxy subnet as required. In my case, because I was running Home Assistant behind a Traefik reverse proxy on the docker subnet, I allowed the entire 172.18.0.0/16 subnet, but you can be more precise.

Adding RTSP camera feeds to home assistant

The camera integration (https://www.home-assistant.io/integrations/camera/) can be activated by adding the following to your configuration.yml file.

camera:
  - platform: ffmpeg
    name: frontdoor
    input: -rtsp_transport tcp -i rtsp://rtsp-server/frontdoor

  - platform: ffmpeg
    name: street
    input: -rtsp_transport tcp -i rtsp://rtsp-server/street

After adding this, you should see the RTSP streams in your Lovelace dashboard.

Now that you've added a RTSP camera to Home Assistant, you can also configure it to record

Tasks

Run a shell script with a button

You can configure Home Assistant to run any command (including a shell script) quite simply.

First, edit configuration.yaml and define a new shell_command containing your commands. You can pass in parameters as command line arguments with template variables inside double quotes. For my use case, I wish to call a tapo.sh script that sends the X and Y offsets the camera should move. The shell_command definition should look like this:

shell_command:
  tapo_move: /config/scripts/tapo.sh "{{ x }}" "{{ y }}"

Restart Home Assistant for the changes to apply. Next, create a button in your dashboard and have the "Tap Action" be "Call Service" and specify the service to be the shell_command.tapo_move entity defined in the previous step. If you have any variables you would like to pass to the script, switch to the YAML editor and add them under a data key within the tap_action. The button definition under the YAML view should look similar to this:

- show_name: true
  show_icon: true
  type: button
  tap_action:
    action: call-service
    service: shell_command.tapo_move
    data:
      x: 10
      y: 0

Save the dashboard. Now, when pressing the button, it should invoke the shell_command.tapo_move command. The X and Y values should also be passed to the shell script.

I've used this to sucessfully control the motor of a Tapo C200 camera using a basic shell script rather than using pytapo (I just wanted to keep things simple without adding more dependencies for my use case).

Troubleshooting

Error: Only automations in automations.yaml can be deleted.

This is such an opaque error message which I somehow managed to encounter after renaming one of my automations. There was no way to delete this phantom automation from the web interface since any attempt to interact with the automation will result in this helpful error: Only automations in automations.yaml can be deleted.

To fix this, you will have to edit the automations.yml file to contain an automation with this ID and alias name. Go to your automations page and click on the problematic automation. The URL should contain the ID number. The alias is the name of the automation. Add the following block to the automations.yml file:

- id: '1668998180437'
  alias: my broken automation's name
  description: foobar
  trigger: []
  condition: []
  action: []
  mode: single

Restart Home Assistant. Go back to your automations list and you should now hopefully be able to delete the automation because it's now in the file.