Assumption check: Entity_id == friendly_name

Configuration
1

I’m migrating step by step from my VeraPlus to HASS. Now starting with the more complex automization plus I’m excluding the zwave devices from the Vera and adding them to Hass.

I’m using customize.yaml to map all devices to friendly_names in the assumption that I then can build all automization with the friendly names. Then I only need to change the customize.yaml when the device_id names change (eg by removing them from Vera and adding them to Hass).

Is this a correct assumption or did I miss something?

2

That is wrong sadly - Friendly Names are only for display purposes, you need to use the unfriendly names in automations. That is annoying particularly with ZWave as the names are quite unfriendly at times :wink:

3

This was discussed in another post, and I have given the method I use to reference them with my chosen name. Currently this is the only way around using the full ZWave device id:

1 Like
4

Ouch, that’s painfull. I have 90+ zwave sensors/switches etc. I basically can’t build the automation before I have moved the zwave devices over and even then it’s hard work with names like “binary_sensor.everspring_hsm02_doorwindow_sensor_sensor_6”

I see jbardi’s work around but that also is quite some work…

5

True, but you only have to do it once and then you can use easy references in your automations and if you ever replace a sensor/device, you only have to edit one place instead of all your automations one by one.

I think the tipping point is based on whether you have more sensors/devices than scripts or automations and how many attributes you really need to track. In my Aeotec multisensors, for example, there’s three or four attributes I’m never going to track like UV levels and such, so this approach makes sense to me on that level. I don’t have a lot of sensors or attributes to track but I am sure I’ll be doing more scripts, automations and scenes so I’ll probably consider this once I get over one my concerns.

I’ll start by saying I haven’t done enough research to bear this out yet - but my worry is that the more template sensors you create and value templates you use in automations, the slower HASS seems to be in shutdowns and restarts. In overall CPU usage, it hasn’t seemed to have had much of an effect as a few of us were comparing notes in another thread. But I truly feel it has made a difference in my shutdowns/restarts.

6

I have also found this to be the case… It does indeed take about 6-7 minutes for me to restart Home Assistant, but, I only restart it now once in a blue moon, because everything runs smoothly.

What allowed me to reduce the number of times I reboot is the fact that I have changed ALL of my automations over to using AppDaemon, by @aimc

AppDaemon allows me to create automations on the fly, without reloading Home Assistant. In fact, AppDaemon allows you to do more with Home Assistant by allowing automations that would be nearly impossible with Home Assistant’s automation system.

I no longer have a single automation, script or scene in Home Assistant, as all of them have been migrated over to AppDaemon.

In case you are curious, AppDaemon reads the live stream of events from Home Assistant, and thus allows you to interact with all changes to Home Assistant and in-turn, trigger services, events, etc back to Home Assistant. I make changes and click save, and instantly my devices are now using the new automation change I just saved, on the fly without a restart.

Forget a space in your YAML code in Home Assistant? Sorry, you have to reboot Home Assistant… make a typo in a word, like service: switch.trn.on instead of switch.turn_on??? Sorry, you have to reboot Home Assistant, but with AppDaemon? No problem, I fixed the mistake, hit save, and boom, instantly everything works.

For more info, checkout the GitHub for AppDaemon:

And look through the API to get a better understanding:
https://github.com/acockburn/appdaemon/blob/master/API.md

2 Likes