HA06 - Example Home Assistant Light Automation for Tasmota and Sonoff S31 switches

What is this?

Home Assistant is dense. It’s got a gui, but the gui needs at least several million dollars of software development to be usable, imho.

It uses yml (Yaml) files for configuration and it’s mostly plain-language and easy to piece together what an automation is doing. It only comes with two example Automations, but many more can be found online.

One of the example automations is motion_light.yml however it does not work with smart switches like the S31. Why? Because the device class is switch, not light. When I first saw this I thought oh no it’s another one of those things that is way too opinionated

Fortunately, it was trivial to modify the automation to work with switches instead of lights (note the source url is the unmodified source):

blueprint:
  name: Motion-activated Light
  description: Turn on a light when motion is detected.
  domain: automation
  source_url: https://github.com/home-assistant/core/blob/dev/homeassistant/components/automation/blueprints/motion_light.yaml
  input:
    motion_entity:
      name: Motion Sensor
      selector:
        entity:
          domain: binary_sensor
          device_class: motion
    switch_target:
      name: Light
      selector:
        target:
          entity:
            domain: switch
    no_motion_wait:
      name: Wait time
      description: Time to leave the light on after last motion is detected.
      default: 120
      selector:
        number:
          min: 0
          max: 3600
          unit_of_measurement: seconds

# If motion is detected within the delay,
# we restart the script.
mode: restart
max_exceeded: silent

trigger:
  platform: state
  entity_id: !input motion_entity
  from: "off"
  to: "on"

action:
  - service: switch.turn_on
    target: !input switch_target
  - wait_for_trigger:
      platform: state
      entity_id: !input motion_entity
      from: "on"
      to: "off"
  - delay: !input no_motion_wait
  - service: switch.turn_off
    target: !input switch_target

With tbe basic GUI automation editor, it’s tricky to setup something like:

When you see motion, turn on the light but after you don’t see motion for X minutes, turn off the light. The UI here actually does do some clever stuff – the YML file lets you specify to show the user a selector with 0 to 3600 seconds so they can drag a slider to whatever makes sense (rather than edit the yaml).

The problem here is it’s setup for smart lights, like Phillips Hue. In our case, this LED strip for under-cabinet lighting is controlled by a smart plug, a switch, not a light. It’s a switch with al light plugged into it. IMHO there isn’t a lot of difference there, but I saw no way via the gui to “cast” the device class from switch to light for that particular switch, so here’s the modified recipe.

With this automation, the gui makes sense, and lets you pick the appropriate devices. For motion, I have integration of Home Assistant into the DSC1864 alarm panel.

Check out the video on using an alarm panel & alarm sensors as part of your home automation solution. It works well.

Hope that helps someone else, and the explanation helps you grok the overall system better.

The ‘cookbook’ is good further reading, but surprising they don’t cover this sort of thing on the light automation page:

3 Likes

It’s funny that I just was watching this video about home automation; and he uses a more component based setup for it, using a containerized “stack”. There was a really nice component in there for filtering and passing messages that maybe would be helpful for yours?

1 Like

It was interesting in the docker thing to run everything, will have to check that out. Home Assistant seems to approach it a little differently than what he did there with NodeRed, but nodeRed integration is available from within HA so… I’m not sure.

1 Like

That’s looking way too complicated / over abstracted for what’s basically:

on-motion -> {
  (re-)start a timer;
  turn switch on;
}

on-timer -> {
  turn switch off;
}

I have a zigbee2mqtt compatible adapter with a timer for disabling joining after n seconds, (these might even be from the docs).

yaml automation excerpts
alias: Enable Zigbee joining
trigger:
  - platform: state
    entity_id: input_boolean.zigbee_permit_join
    to: 'on'
action:
  - service: mqtt.publish
    data:
      topic: zigbee2mqtt/bridge/config/permit_join
      payload: 'true'
  - service: timer.start
    data:
      entity_id: timer.zigbee_permit_join
mode: single
alias: Disable Zigbee joining by timer
trigger:
  - platform: event
    event_type: timer.finished
    event_data:
      entity_id: timer.zigbee_permit_join
action:
  - service: mqtt.publish
    data:
      topic: zigbee2mqtt/bridge/config/permit_join
      payload: 'false'
  - service: input_boolean.turn_off
    data:
      entity_id: input_boolean.zigbee_permit_join
mode: single

I haven’t used tasmota, but you can implement simple automations like that in esphome (as opposed to home assistant): https://esphome.io/guides/automations.html . So you can bypass VMs and containers and all that “cool stuff”, if your “sensor” and “relay?/switch?/light?” are already hooked up to the same physical device.
If they’re not on the same device, you can have multiple esphome devices send each other UDP packets, or mqtt messages (an mqtt broker like mosquitto is less involved than home assistant).

3 Likes

the simplicity is cool, but ultimately I think architecturally I need a centralized message bus. I can do cool things like log stuff and graph it with grafana without significantly impacting latency, and speed.

HA does have a ways go go, and could be simpler. Once you setup the automation you do get a really simple gui for picking devices and params.

the recipies are basically (let user pick devices of this class) does this thing for (user variable 1, timeout)

so a magician can write really cool recipes and you, the user, can just copy-paste what has already been written and get a nice friendly ui for customizing it to your liking.

I get it, but not sure the “right” UX has really been invented yet. Overall I find esphome too rigid, but cool. They are the way they are for robustness but not as flexible. My motion sensor is in the alarm system so the integration isn’t super trivial.

2 Likes

Heard from you last video that you were wiling to build these smart home devices yourself if you had to. Well I have a starting off point .

Check out the following repositories on my GitHub

AJGherardi/HomeHub
AJGherardi/HomeApp
AJGherardi/HomeNodes
AJGherardi/MeshController
AJGherardi/ButtonFirmware
AJGherardi/GoMeshController

I have been working for the past 11 months on a smart home system that uses Bluetooth mesh for device commutations its completely local and integrates with node red for powerful automations. Its beta grade but functional.

Wendell, you are asking about well engineered alarm systems, but have you checked out the trigboards by Kevin Darrah? They are very well made. Actually you can see they are well explained with examples on his youtube channel. I think it’s worth your time to check him out. These are very robust and high quality devices… but also entirely open.

Long time forum lurker and big fan of your YouTube channel, but I think this is my first time posting here. Discovered your channel and forums as I was getting into VFIO passthrough. Great video this week on the Home Automation stuff!

I’m a serial entrepreneur in Tech and have a lot of development/UX experience. I have been quite interested in Home Automation for a few years now. When I built my new place, I had the luxury of wiring everything the way I wanted, completely custom. I have about 4 x Cat6a drops to every room and a centralized server rack with an Unraid server, Ubiquiti gear and some home automation stuff. My philosophy tends to be contrary to your most recent video. I believe that the hardware is commoditized to the point that the important part of this is the software layer. This is similar to the movement towards Software Defined Networking in the consumer/enterprise space.

A bit about my setup:

  • I have an entire Ubiquiti Unifi setup with Unifi Security Gateway, PoE wireless access points, Unifi cameras (mixed reviews on those though tbh). I’m also not happy with the Unifi DVR (now discontinued), but that’s a story for another day. I’ve played around with things like ZoneMinder or Shinobi to try and use TensorFlow w/ NodeRED to inform my ‘security system’ of important events (more on that later).

  • My entire home is outfitted with the First Alert Safe & Sound (Alexa-enabled Smoke/CO Detector). I have one in every major room and a few in my main hallways. I have young children so I use things like white noise skills in each of their rooms while they sleep. I control all of my lights, window coverings, HVAC, etc, via Alexa. While the purists in the Home Automation (especially those focused on local-only, no-cloud services/subscriptions/etc) community may baulk at a dependency on a cloud enabled device, they work really well for a lot of things. In my opinion, Alexa has won the home assistant category by a mile. I’m growing into more of a privacy advocate but I’m reasonably ok with the privacy concerns of Alexa in my home. There also isn’t a great alternative anymore… not much can be done locally since the AI/ML business logic are centralized in the cloud.

  • I fell in love with Noon Home light switches. They are a proprietary, gorgeous smart light switch product with a touchscreen interface. Their focus is on the smart part of lighting being the switch, not the bulb. I think it’s a winning model as it’s more cost effective and offers far more consolidated control over lighting. The company has since sold to Racepoint Energy, who owns Savant (one of the top premium home automation companies out there). The biggest fault of the platform is that it is proprietary, with no freely available API docs, etc. Related, I’ve reverse engineered a lot of their platform using man-in-the-middle approaches to clone their API endpoint calls, but nothing concrete yet. Thankfully, I can interface with them via Alexa Skills.

  • I have a bunch of door, window, motion, multi-sensors, etc that are mostly from Aeotec and z-wave standards based. Nothing really wired directly in my setup, which I suppose is a hacking/jamming concern. I feel that’s very low risk overall. You know the old adage, “If somebody makes all that effort to get in, they probably deserve to”.

After much exploration, I am not a fan of Home Assistant, SmartThings and most of the other solutions out there. Home Assistant does have a place in my setup but it pains me to rely on it. YAML is a terrible method of configuring sensors, endpoints, etc. Thankful for the time and energy folks put into it regardless of my opinions on it! I was not interested in a large Control4, Savant, etc system at the time. The gauging on hardware and the constant requirement of somebody to program it made it a non starter for me.

Given my development/UX background, I started tinkering with the idea of a homegrown solution centered around NodeRED and a lightweight, cross-platform React Native app that will run on iOS/Android/Web. Beyond the basics of media player controls and lighting, NodeRED can instruct my Alexa devices throughout the home to announce all of the necessary notifications (door opened, window opened, security alarm, motion, etc), I can even have it be contextually aware by scheduling and volume levels. One remaining aspect is to make it contextually aware of the room I’m in. If anybody has figured that out, do tell!

I’m essentially creating a REST based API within NodeRED using the HTTP nodes, exposing things like GetDoorSensorStatus, or SetAlarmLevel (Away, Stay, Unlocked), etc. The React Native based app can use sockets to continually poll these endpoints to update the interface(s). NodeRED interfaces with Home Assistant to get a broader support for some devices (i.e. Sonos, Plex, Tizen TVs, etc). I have considered open-sourcing some of this but I’m not quite ready to show it off yet. It’s incredibly early.

NodeRED is perfectly suited to complex pipelines like this. It’s Javascript based which makes it a lot more accessible in my opinion. It’s also easy to create extensions for.

Curious to hear your thoughts on what I think is a movement towards ‘software defined home security/automation’ and becoming less about the security system itself and more about the combination of commodity sensors and devices. I don’t have a lot of faith in the vendor off-the-shelf systems, especially terrible ones like Vivint (I was once a customer). I certainly don’t want to pay near $100/month ever again for what you can get for $15/month in a security monitoring service.

Here, @wendell you can automate your curtains, too! \o/

Probably can make an open-source one with RPi Pico?