Don't know how I stumbled across this but

Whatever would have been wrong with

service: homeassistant.turn_off
area_id: area.living_room

?

2 Likes

I wouldn’t say the article is bad but it’s not review in my opinion.
It’s more a comparison to something that few has any clues about.
Kind of like if an astronaut was comparing switches, tools and interfaces from a moon lander with pretty much anything.
It distances you from the review and all you see is a biased opinion where you have no way to check if what is said is remotely true.

But I find it funny that in the end it says:

How do we set a static IP address for an RPi running HA? It doesn’t look to be a simple process

That has nothing to do with the raspberry or HA, someone with all the (on paper) knowledge as him should know that.
Made me giggle a little.

He is using HassOS so yes it is a bit complicated (no UI). Also, the documentation is not that easy to find

If you want to set a static IP then it’s easier to do so in your router. YMMV.

Well it is not static then (manual config) but fixed (DHCP reservation) :wink:

1 Like

The impression I have is they were never intended to be used in any other way. I’m certain Paulus said that but I can’t find a citation so I may be mistaken. Nevertheless, they are undeniably unwieldy to use when composing YAML-based automations.

I’ll admit I used “a trip the .storage directory” for dramatic effect. Both area_id and device_id are visible in the URL when displaying the Area and Device views, respectively. That’s currently the most convenient way that I know how to get those values. However, device_id should probably be revealed in the same way as you described area_id is shown (in a popup).

I don’t see this option when I add an automation, how do I enable this?

That’s pretty cool about area_id in actions though, I didn’t know that. You’re right, that is a big improvement.