I was just thinking at the notification part (all the rest is more or less the same for everyone, so the code doesn’t change, the only thing that could be difference is how the notification is done …).
I am wrong?
Well not wrong, just incredibly vague. You replied to a post about a sensor and were talking about blueprints (which I couldn’t care less about, so you’re on your own there).
I’ll think about it. I would probably need to break this up into about 10 different blueprints and packages though. Each alert would become a blueprint and then I’d have to include a package you would need to install as well to have the sensors it depends on. Also the alert would probably not be repeatable like an alert is since to do that I would have to copy the logic this blueprint put together into each one.
I also am not sure how I feel about posting complex reusable assets like that which I am not using myself since then I’m essentially making other users my beta testers. Alerts are so much cleaner and simpler so there’s no way I would switch my system to use automations for notifications when alerts are available. Plus you can’t make a selector for a notification service or a device with a notification service currently, the best you can do is make a selector for devices of type mobile_app which is a lot more limiting. I don’t use the mobile app’s service for notifications myself so that would be another blocker for me to be able to adopt my own work.
I think I will wait for now to see what comes out next release before making any significant changes. Blueprints are clearly front and center on the HA team’s mind so I imagine they will be aggressively updated in the near future. I also notice there’s quite a lot of blueprints about notifications right now so I’m hoping there are some changes designed to make that easier. I think instead I may spend some of my time over break to take a look under the hood instead and see what it would take to add support for blueprints of type alert as then it would be easy to turn this into blueprints.
2 Likes
Many thanks … I got your point.
Great! I was looking for a central notification setup for all the important updates (not sure why it’s not part of the default setup yet):
- HA Core
- HA Supervisor
- HASS OS
- HACS
- deCONZ Firmware
And this thread is like a jackpot. Even one of my first thoughts was „Well, a blueprint would be great, right?“ I‘m going to implement it as it is. Will also dig through all the posts to make sure not to miss important updates to the code in case the initial post has not been updated meanwhile.
Thanks again for sharing!
1st issue:
Using the device_class: problem does not work for me, therefore in lovelace UI the state_color: true does not work unfortunately.
I get errors in config check:
Invalid config for [sensor.template]: value is not allowed for dictionary value @ data['sensors']['updater_addons']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_hacs']['device_class']. Got 'problem'
value is not allowed for dictionary value @ data['sensors']['updater_supervisor']['device_class']. Got 'problem'. (See ?, line ?).
What I use instead: icon_template: 'mdi:update'
The config check errors still appear even if those icon_template lines are removed.
Probably a syntactical problem. Anyway, also automations are shown with state_color: true in lovelace UI. Tried to change the device class using the customize options, but that only gives me
So how to fix it in the .yaml, ideas?
2nd issue:
The 'entity_id' option is deprecated, please remove it from your configuration
How to fix that?
That device class is for a binary sensor, not a sensor.
Sensor device classes: https://www.home-assistant.io/integrations/sensor/#device-class
Binary sensor device classes: https://www.home-assistant.io/integrations/binary_sensor/#device-class
Likewise, state colour only works for devices with binary states. e.g. switches, input booleans, binary sensors. Not the sensor domain.
For your 2nd issue remove the key entity_id: form all your template sensors. Just like it says in the warning.
Thank you, that makes sense.
For #2:
So what will stay in that part?
- platform: template
sensors:
# True if there's an update available for supervisor
updater_supervisor:
friendly_name: 'Updater - Supervisor'
device_class: problem
entity_id:
- sensor.supervisor_updates
value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"
# True if there's updates available for any HACS components
updater_hacs:
friendly_name: 'Updater - HACS'
device_class: problem
entity_id:
- sensor.hacs
value_template: "{{ states('sensor.hacs') | int > 0 }}"
# True if there's updates available for any addons
updater_addons:
friendly_name: 'Updater - Addons'
device_class: problem
entity_id:
- sensor.supervisor_updates
value_template: "{{ states('sensor.supervisor_updates') | int > 0 }}"
Bad indentation lines 26 and 29!
@CentralCommand can you please update your yaml config in the OP to fix the
The 'entity_id' option is deprecated, please remove it from your configuration
warnings? I´m not familiar enough with YAML yet. Just remove the entitiy_id lines as suggested by @tom_l won’t work, keeping the lines below (e. g. sensor.*updates) as is or with name: sensor.*updates) also doesn’t.
It’s not rocket science, e.g. this:
- platform: template
sensors:
updater_supervisor:
friendly_name: 'Updater - Supervisor'
device_class: problem
entity_id: ### <--------------- Remove this ###
- sensor.supervisor_updates ### and this ###
value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"
Becomes this:
- platform: template
sensors:
updater_supervisor:
friendly_name: 'Updater - Supervisor'
device_class: problem
value_template: "{{ state_attr('sensor.supervisor_updates', 'update_available') }}"
availability_template: "{{ (states('sensor.supervisor_updates') | int(-1)) > -1 }}"
Do the same for every template sensor.
1 Like
Why aren’t you just using the package file, that is noted in the first post? It is up to date and runs just fine (removing the two indentation errors). The only thing you may need to change is the notifier.
Did not see it until now. But even that code still contains deprecated entity_id options.
That worked. Thought the entitiy_id is a reference for further attributes - but it´s just unnecessary part of yaml code. My deprecated warnings are gone now, thanks folks.
Huh, when did that slip in, I’m sorry about that, both indentation errors are fixed now. Thanks for pointing that out.
1 Like
I updated the package to fix the indentation errors pointed out but there were no template sensors in the package which had entity_id, that had been fixed already. The package is mostly using threshold sensors now since I realized that was an easier way to get a binary sensor which is true when a number is greater then 0 (and those require the entity_id field). I updated the details post to do the same thing as the package for sensor.updater_hacs and sensor.updator_addons and fixed sensor.updater_supervisor to no longer have entity_id
1 Like
It does? 
I can’t see any. 
You do realise, entity_id is only deprecated for a template sensor, not for all occurrences… 
I’d start “fresh” in your case. Remove your entries and copy the “new” package/version from the first post. Change the notofier, if necessary, and you are good to go. Another advantage is, whenever there is an update, you just need to copy it from here and are good to go.
Everything is fine and working for me even with the “old” template sensor based approach I will keep now, thanks. As you can see
CentralCommand even updated the OP meanwhile.
Any idea on how to work around such - okay, quite rare and not normal - situations?
I´m talking bout this section:
- platform: command_line
name: HASS OS Update
command: >
curl http://supervisor/os/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"
| jq '{"newest_version":.data.version_latest,"current_version":.data.version}'
value_template: >
{% if value_json.newest_version != value_json.current_version %}on
{% else %}off
{% endif %}
json_attributes:
- newest_version
- current_version
...
...
So the interesting part with actual numbers:
{% if 5.9 > 5.10 %} on
{% else %} off
{% endif %}
gives on cause 5.10 is taken as 5.1 so 5.9 is greater than 5.10. I thought “greater than” is better than “not equal” (!=) but… not at the finish line yet.
Scenario: update to an officially released version higher than currently provided for the majority.
- Latest HASS OS available in UI: 5.9
- Latest available HASS OS I upgraded to: 5.10
Maybe it´s better to just go for the ‘update_available’ return?
I changed it, looking good now even for this rarely available scenario.
- platform: command_line
name: HASS OS Update
command: >
curl http://supervisor/os/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"
| jq '{"newest_version":.data.version_latest,"current_version":.data.version,"update_available":.data.update_available}'
value_template: >
{% if value_json.update_available == true %}on
{% else %}off
{% endif %}
json_attributes:
- newest_version
- current_version
- update_available
1 Like
States are strings so you have to convert those values to actual numbers to do a mathematical comparison like that. You can do that like this:
{% if value_json.newest_version | float > value_json.current_version | float %}
Though actually I’m not sure if this is a good idea. I am blanking on the details but I feel like a month or two ago there was an issue where people were seeing an update message in their supervisor panel that was actually telling them to downgrade to the prior version of either HA OS or supervisor due to an issue. I’m failing to find a link but I’m pretty sure this happened and obviously this would be an issue with this comparator.
If there’s an update_available field now it is probably better to just rely on that. Not sure if that is new or just missed the first time. Can change the sensor to this in that case:
EDIT: removed. @e-raser has it right below. I forgot this was actually a sensor not a binary_sensor despite only have a value of on or off