Omg, thank you so much.
1 Like
Can a sensor be made for os agent?
- platform: github
access_token: xxxxxx295af35336abeab34ebf81ac31c4
repositories:
- path: 'home-assistant/os-agent'
Thanks I did a search in my HA after you posted the the code and I found that I had already setup this sensor. I set this up the same time and the same way that I set up the core sensor. Now I need to remember why I didnāt add it to my system status card? I had an issue getting the current version. On the core I setup a āupdate sensorā
- platform: command_line
name: Updater Core
command: 'curl http://supervisor/core/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 %}on{% else %}off{% endif %}"
json_attributes:
- update_available
- newest_version
- current_version
Tried the same for os-agent and it doesnāt work.
- platform: command_line
name: Updater Core
command: 'curl http://supervisor/os_agent/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 %}on{% else %}off{% endif %}"
json_attributes:
- update_available
- newest_version
- current_version
I assume that I am looking at the wrong place?
I donāt think supervisor has an endpoint for os-agent.
Is there anyway to get this info? The sensor from agent just shows latest. It does not show current.
Using a bash script in cron
#!/bin/bash
# Only edit the following setup lines with correct login information
# Mosquitto Broker Details
mqttuser=***user
mqttpassword=***pass
mqttbroker=**ipaddress
mqttport=**port
# DO NOT ALTER ANYTHING BELOW THIS LINE
versionstring=$(dpkg -l | grep os-agent | tr -s ' ' | cut -d ' ' -f3)
versionstring='{"state":"'"v$versionstring"'"}'
echo $versionstring
# Publish to MQTT Broker
mosquitto_pub -h $mqttbroker -p $mqttport -u "$mqttuser" -P "$mqttpassword" -t haosagentinstalled -m "$versionstring" -r
You need to have mosquitto tools installed.
Is this mqtt installed in HA or under debian?
I use an mosquitto on another pi, but any mqtt server will do, as long as HA knows about it.
On debian, mosquitto-clients needs to be installed.
Hi @CentralCommand since upgraded to HA 2021.11 series I get template warnings e. g. for:
# True if there's updates available for any HACS components
updater_hacs:
friendly_name: "Updater - HACS"
icon_template: "mdi:update"
value_template: "{{ states('sensor.hacs') | int > 0 }}"
Log tells:
Template warning: 'int' got invalid input 'unknown' when rendering template '{{ states('sensor.hacs') | int > 0 }}' but no default was specified. Currently 'int' will return '0', however this template will fail to render in Home Assistant core 2022.1
I think that might be during startup of HA when HACS (and therefore sensor.hacs) is not available yet. So there needs to be a default for those cases, right?
How to solve that the easiest way?
value_template: "{{ states('sensor.hacs') | int(0) > 0 }}"
1 Like
I guess installing this will make my installation unsupported?
This script looks kinda familiar hahaha
1 Like
No. It is only supported if you add extra docker containers.
the new release of the supervisor (2021.12.0) now includes a dedicated endpoint for the updates.
You can check out Add /supervisor/available_updates endpoint by ludeeus Ā· Pull Request #3300 Ā· home-assistant/supervisor Ā· GitHub and Add documentation for /supervisor/available_updates by ludeeus Ā· Pull Request #1135 Ā· home-assistant/developers.home-assistant Ā· GitHub.
I have created the following sensor to use it:
- platform: command_line
name: Updater
command: 'curl http://supervisor/supervisor/available_updates -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"updates": [.data.available_updates[] | .update_type]}'''
scan_interval: 600
value_template: "{{ value_json.updates | length }}"
json_attributes:
- updates
4 Likes
I was working on adding manual sensors, but it turns out that the Supervisor Integration actually has binary sensors for updates being available now for each addon installed as well as the operating system, but they are disabled by default. Enabling these was a fair bit easier than trying to setup the command_line sensors.
1 Like
where can you enable them?
edit: nm, found it
Yea I had tried those a bit ago but the problem before was that I wanted one sensor that told me āis there an add-on with an update?ā and getting that was painful. Thereās an update_available sensor per add-on but there was no real way to collect all those sensors to answer my question. And no easy way to get the current version, latest version and other information about the add-on from that sensor to craft notifications with all the information I wanted.
However I realized since I initially looked at that integration this problem has been solved thanks to the great device template functions that raman325 added. Now I can answer my question in a sensor with this one template:
{{ expand(
integration_entities("hassio")
| select('search', '_update_available(_\d+)?$')
| reject('search', '_operating_system_')
) | selectattr('state', 'eq', 'on')
| list | count }}
And starting from that update_available entity I can figure out the slug of an addon and then any other information I want using this template:
{% set entity_id = "<id of entity created by hassio integration>" %>
{{ (device_attr("entity_id", "identifiers") | first)[1] }}
Which means I can reduce this packageās reliance on the command line integration a bit. Well at least for tracking add-on and os updates, commandline sensors are still needed for all the others to my knowledge. Iāve been updating my config and will publish an updates once I get things to a good state.
Although Iāll probably publish it as a separate package. The benefit of the package as it is now is people can just drop it in and it basically starts working. If it depends on the hassio integration then its not that simple anymore. I have to instruct people to enable that integration (which can only be done in the UI not in the packageās YAML), enable all the sensors it creates and ensure they maintain the proper naming convention for their entities (i.e. entity IDs of the update available sensors contain the string _update_available). It would be nice if there was a better way to publish dependencies and find those particular entities within the integration.
3 Likes
Hello,
great news, i search for a while for addon only,
could you share your complet sensor code please?
Thanks!
Like you just want me to turn my template into a template sensor for you? I havenāt made the new package yet. If you just want the one sensor then here I suppose it would be like this:
template:
- sensor:
- unique_id: 8b6338db01224a878c9eb22db4ef1d9c_addons_have_updates
state: >-
{{ expand(
integration_entities("hassio")
| select('search', '_update_available(_\d+)?$')
| reject('search', '_operating_system_')
) | selectattr('state', 'eq', 'on')
| list | count }}
2 Likes