Hi, I experience that only than “HACS” sensor provides me with an update. Since a while (don’t know when but longer time ago) I do not seem to get a notification for any of the other sensors…
Is this by design versus the recent update of home assistant? And others experiencing this?
Hello,
Could someone please help me out with this one?
I’m trying to get snapshots list from supervisor and would like to get latest slug so I could restore it automatically with an automation if necessary. I’m unable to even get the parsed listing in to HA.
This is my latest take on this:
- platform: command_line
name: Snapshots
command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq --slurpfile slugs found_snapshots.txt ''{"snapshots":[.data.snapshots[] | select(.slug as $slug | $slugs | index($slug) | not)]}'''
value_template: '{{ value_json.snapshots | length }}'
json_attributes:
- snapshots
- date
- name
- slug
And this results to error:
Logger: homeassistant.components.command_line
Source: components/command_line/__init__.py:41
Integration: command_line (documentation, issues)
First occurred: 19.32.06 (1 occurrences)
Last logged: 19.32.06
Command failed: curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq --slurpfile slugs found_snapshots.txt '{"snapshots":[.data.snapshots[] | select(.slug as $slug | $slugs | index($slug) | not)]}'
I’m not really sure what to make of your “found_snapshots” file, not really understanding how that’s connected to your use case. It sounds like you want to find the latest snapshot and store its slug in a sensor. Based on that the command I would use is this:
curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq '[.data.snapshots[]] | sort_by(.date) | last'
This gets the list of snapshots, sorts the list by date ascending, then just keeps the last one (which is the newest by date). You can then leverage that in a sensor like this:
- platform: command_line
name: Latest snapshot
command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''[.data.snapshots[]] | sort_by(.date) | last'''
value_template: '{{ value_json.slug }}'
json_attributes:
- name
- date
- type
- protected
Seems like that gets you everything you need to do what I believe you’re trying to do.
Is there some reason your capturing a list of snapshot slugs in a text file and using it to filter the list? If so you’ll have to explain why so I can try and figure out what’s going wrong. Doesn’t seem necessary to get the slug of the latest snapshot though since the data of each snapshot includes a date.
Thank you for your effort and this did indeed work.
Little bit more background for this: I’m trying to build redundant/highly available HA backup server which would launch automatically if the main server drops offline. Otherwise the backup servers overlapping automations and processes are turned off with automation. Updating configs to two server is quite hindrance so I was looking to this matter by trying to restore latest snapshot automatically in backup server.
I simplified the sensor even more for my purpose:
- platform: command_line
name: Latest snapshot
command: 'curl http://supervisor/snapshots -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''[.data.snapshots[]] | sort_by(.date) | last | .slug'''
This could have been enough for me but then I ran to another problem with shell_command: I tried to launch the restore in several ways:
shell_command:
restore: 'ha snapshots restore "{{latest_snapshot}}"'
This didn’t work as the shell commands are run in homeassistant docker, not hassio-cli
Then I tried to proceed with
shell_command:
restore: 'curl -X POST http://supervisor/snapshots/restore "{{latest_snapshot}}" -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"'
But ran to 405 method not allowed error.
After total of 24 hours trying to solve this I’ve given up for now. Some sources indicate that calling ssh command could bypass limitations, but I see here so much breaking possibilites that I have decided for now to do the “cloning” of main server to backup server by hand.
My daily samba backup -goes straight to backup server so this is quite good emergency solution for now. Well maybe this way I have more control over the backup server and I can test&try with it and I don’t have to think about the automatic backup system running over my unfinished tinkering.
On my phone at the moment so I can’t test this myself but I notice the URL you are using to restore seems to be incorrect. Here is the API for interacting with snapshots via supervisor. There are two APIs you can use to restore a snapshot via the API -
/snapshots/<snapshot>/restore/full/snapshots/<snapshot>/restore/partialThe slug goes in the URL as a resource path parameter, not the body. The body is just the password for a full restore or the details of what to restore for a partial restore (and the password).
If you’re trying to restore on another system you might have to use the upload snapshot API to get the snapshot into the correct place first unless the two share a folder for backups.
Also just an FYI, to get the value of the latest_snapshot sensor your template should be {{ states('sensor.latest_snapshot') }} not {{ latest_snapshot }}.
Cool idea though! If you get it all working you should make a thread or guide about your setup. Would be great to have things auto fail over to a backup replica.
Just FYI, the following sensor:
- platform: command_line
name: HassOS Installed Version
command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"hassos":.data.operating_system}'''
value_template: "{{ value_json.hassos[7:] }}"
Needs to be updated to this in 2020.12:
- platform: command_line
name: HassOS Installed Version
command: 'curl http://supervisor/host/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)"|jq ''{"hassos":.data.operating_system}'''
value_template: "{{ value_json.hassos[18:] }}"
I know … but would be possible to put all this in a blueprint?
Thanks
No. It’s a sensor not an automation.
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.
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):
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.
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.