Tag Archives: home automation

Making a “dumb” lamp smart with Home Assistant

I have a parrot – her name’s Terry Datyl. I also have a bunch of house plants. These two statements are connected, though perhaps not in an obvious manner.

Part of my morning routine is to go downstairs and uncover Terry’s cage, turn on the light next to the cage, and then turn on the radio so she has a “flock” of sorts to hang out with. Next, I turn on the various grow lights for the house plants.

That was the routine for several years. I’d connect lamp timers when I was gone for the weekend and it all worked fairly well.

A while back, I thought it might be interesting to have Home Assistant take over turning on the plant lights. Ideally, a trigger would fire when Terry’s lamp was turned on and I could just put some smart plugs on the plant lights.

Have you ever tried shopping for a smart lamp? They do exist, but it mostly seems like accent lighting. I haven’t found anything which was meant to illuminate a room and nothing that really fit into our décor anyhow.

So, what I hit on was the idea of connecting the existing lamp (the “control lamp” if you will) to a TP-Link HS110 smart plug. In addition to the vanilla on/off capability, this particular plug also reports power usage. (Note: This may no longer be possible with TP-Link smart plug. A 2020 firmware update removed an API Home Assistant relies on. The general concepts however should still apply to other smart plugs with power monitoring capabilities.)

So, step one was to connect the plant lights to smart plugs. I used TP-Link plugs because I already had them, but you can use others. (As noted above, that may indeed be necessary.)

Next, I created two “scenes” in Home Assistant. One in which all the plant lights were on, and another where they were all off. (Creatively named, “Plants Off” and “Plants On.”)

Next up was setting up the HS110 plug that would be running the show. In addition to an on/off state, the HS110 exposes several state “attributes”: voltage, current, and the current (meaning “right now”) power in watts. This last one is what we’re interested in.

State attributes vary from one device to the next, so Home Assistant doesn’t really have a good way to expose them directly. Instead, you can expose the values you want via sensor templates.

Go into the Home Assistant config directory and edit the sensor.yaml file (creating it if necessary). Here’s the entry I created to read how many watts Terry’s lamp is using

- platform: template
  sensors:
    terry_s_lamp_watts:
      friendly_name_template: "{{ states.switch.terry_s_lamp.name}} Current Consumption"
      value_template: '{{ states.switch.terry_s_lamp.attributes["current_power_w"] | float }}'
      unit_of_measurement: 'W'

Note: the friendly_name_template and value_template entries are one line apiece (one day I’ll tweak this theme to better accommodate code snippets). This is just a plain YAML file so all the usual editing concerns apply.

This shows up in Home Assistant as a numeric sensor with the name sensor.terry_s_lamp_watts (you may need to restart for it to show up). It’s a floating-point number, so we’ll have to accommodate for that in the automation.

You’ll need to know how much power the lamp draws in its on and off states so in the Home Assistant UI, go to Developer Tools > States and select the entity sensor.terry_s_lamp_watts (substituting your sensor’s name, of course) and if all is right, the current power draw will show up in the “State” field. Turn the lamp on and off (using the the lamp’s switch, not the smart switch) and note the values (click the “refresh” icon to get the new value).

The final step then is to create two automations. Mine are named “Terry’s lamp turns on” and “Terry’s lamp turns off.”

For the “on” automation, I used a numeric state trigger on the entity sensor.terry_s_lamp_watts. The power usage tends to vary over time as the bulb warms and cools, so I chose 9 watts as a value that comfortably below the lamp’s “on” state while still higher than the lamp’s “off” state. (Similarly, the “off” automation uses a value of 5 watts, which allowed me to turn on the radio that was plugged into the same smart plug without triggering the automations.)

For both automations, the only action is to activate the appropriate scene. Either scene.plants_on or scene.plants_off.

At this point, you now have a single lamp which uses its existing switch to control other lights. (This means, no worries about guests messing things up by not using the smart switch – this adds smarts to the “dumb” lamp.)

Latency

With the HS110 smart plug on the control lamp, there’s a delay of up to 30 seconds between the time the control lamp changes state and when the automation will run. That’s because TP-Link smart plugs don’t actively report their state and Home Assistant has to use “local polling” to check whether the switch’s state has changed since the last time it was set. In order avoid flooding the local network with traffic, Home Assistant only checks the device’s status once every 30 seconds. Devices from other manufacturers may behave differently.

To solve this using the HS110 device, I added an additional automation, using a trigger type of “Time Pattern” with Hour and Minutes left blank and Seconds set to /3, the automation runs every 3 seconds. I then set the action manually, in the UI’s YAML editor

service: homeassistant.update_entity
data: {}
entity_id:
  - switch.terry_s_lamp
  - switch.office_light

This action causes Home Assistant to update the state for both the switch.terry_s_lamp (the control lamp) and switch.office_light (the smart switch in my home office, also a TP-Link device).

Creating A Hue Account

Another entry in the “So I can look this up later” series.

I’ve been trying to hook up some Phillips Hue bulbs to the Google Assistant. To do that, you need to link your Hue and Google accounts. That’s not a problem, except I didn’t have a Hue account….

The online help and several searches said to create it through the Hue app. I think there was an option to do that when I first installed the app, but I didn’t want to create yet another online account just then and skipped it. And now that I wanted to create one, I couldn’t find an option to do so. (This is where someone will inevitably chime in with, “Just click on this item, and then click such-and-such….” and I don’t know what to say to that except that I spent a good long time digging though the app, clicking every option I could find.)

Long story short, I finally discovered you can go to https://account.meethue.com and create an account there. Once you’ve done that, and assuming you’re on the same network as the Hue bridge, you click a button on the web site, push the button on the bridge, and through some magic I don’t quite understand, the browser will detect your bridge and link it to your account.

Home Assistant: Text to Speech and URLs

This is one of those “In case I run into this again” type of posts, with the hope that it might help someone else too.

I’ve been trying to get Home Assistant’s text to speech integration working, but when I try to play anything via the developer tools or even a smart speaker’s entity card, all I get is a beep but no speech. I haven’t much use for it until recently, but I know it was working at one time, so something must have changed.

What I finally figured out is that my Home Assistant instance was misconfigured. Under Configuration > General, there are two URL settings. One is “External URL”, which is the URL to use for accessing your Home Assistant instance from outside your house. The other is “Internal URL” which is the URL to use from devices which are on your home network.

A few months ago, I set up Let’s Encrypt with DuckDNS so I could securely use the Home Assistant companion app from outside the house. This had the side effect of making it so the assistant could only be contacted via https. It’s still on port 8123 though, so there’s really no place to redirect from.

What does all of this have to do with Home Assistant? The TLS certificate associated with my setup only works for the name I setup with DuckDNS, so I’ve been using that name and hadn’t noticed that Home Assistant’s “Internal URL” was set to the RaspberryPi’s IP address instead of the DuckDNS name. So when my smart speaker attempted to retrieve the audio file from that URL, the HTTP connection it was using failed.

I updated the internal URL to match the DuckDNS name, and voila! I can now play speech through my smart speakers.

Home Assistant and TP-Link

Last week, I spotted this tweet from the official Home-Assistant account.

In short, what’s happened is that TP-Link issued a firmware update that turns off the ability to control their smart plugs (and, one assumes, smart switches) from a device on the local network (e.g. Home Assistant), leaving the cloud-based API, and their official KASA app, as the only way to control the devices.

I use TP-Link smart plugs myself. Currently to automate some lamps in the living room, but I’ll also be using them soon to automate the Christmas lights. (Sure, I could use a lamp timer, but I want the lights to go on right at sunset, not “sometime near sunset.” 😁) For me, key parts of the value proposition were (a) It worked with Home Assistant (b) It didn’t require using someone else’s cloud (i.e. my usage patterns remain private).

Digging into it a bit… Turns out that there really is a legit security flaw with these devices. I haven’t seen any official details from TP-Link, but I found other reports of problems (Which?, October 2020; Fernando Gont, March 2017) involving weak encryption and the ability for other people to control the device.

So, it’s a legitimate concern. Ideally, the fix would be a locally accessible API with authentication. Turning off local access altogether is rather “ham fisted.”

Home Assistant has issued an alert that the TP-Link integration is “broken” with a link to a user-community discussion, though the alert isn’t really as obvious as one might hope….

Now that I know about the problem, I’ll have to weigh the risks of leaving the firmware out of date against losing my automations. I like the TP-Link plugs, they’ve been pretty reliable over the past several years, and the Home Assistant integration is about as simple as they come (you add a plug to your network, Home Assistant adds it to the list of devices…. easy peasy).

Ultimately, this comes down to the risks of using a “black box” product, where there is no official support for Home Assistant. Fortunately, there is a bit of good news in this. TP-Link seems to value the Home Assistant community and in response to the uproar is working on a fix to restore the local-control functionality.

The question is, do I trust them not to break it again?