Formating to string (".format()") and we have to remove the “v” from the github version: {% set new = state_attr('sensor.zigbee_conbee1', 'latest_release_tag').format().replace('v', '') %}
Works for me. Check your root file and track down every step (pipe command). It is highly fragile cause only one change in formatting (e. g. blank space) and the version is not captured correctly. The commands definitely capture only the version line and take apart all unnecessary chars left and right of the version.
Let´s see when the next stable is released if that (+ automation) works.
So next step is to get the latest non-beta release, even it should work already. Big improvement would be to go for the REST API and geht installed version from this source.
UPDATE1:
No wonder, I have “Dresden Elektronik” three times in the file. I had to use an additional key: command: 'cat /config/.storage/core.device_registry | grep -A 3 "Dresden Elektronik" | grep -A 3 "Phoscon-GW" | grep "sw_version" | cut -c32-36'
It will be interesting if GitHub will get the “Current Stable” value at all, or if this is only for Beta-versions. If so, we are back to the API solution. Or raise a Dresden Elektronik, GitHub feature request for a attribute for the last stable version.
Today´s situation:
My supervisor addon updates notification told me there´s a new deCONZ addon version which brings new v2.10.4 (current/latest stable: v2.9.3)
…but it might be outdated (only updated once every 24 hours, changed this to every 12 hours now).
So my whole deCONZ firmware update setup seems to work, but the supervisor addon update notification (which sometimes also includes deCONZ firmware updates) usually is quicker.
Just to make sure e. g. @Tomahawk: what does your deCONZ latest firmware sensor look like? Is v2.10.4 served as stable?
Update:
Should work as v2.10.4 is listed as stable release on https://github.com/dresden-elektronik/deconz-rest-plugin/releases - it´s just my sensor update interval which is a bit big (once every 24 h) so it missed the new version. Restarted HA and here we go:
…this is what happened after upgrading to the latest v2.10.4 release (which takes one more character → 9 went 10):
I think a proper sed command (RegEx) should fix this “once and for all”, as quick & dirty “solution” I just enhanced the current command. So new sensor definition for the currently installed deCONZ version is:
@e-raser@Tomahawk
Since we can’t use the code below anymore since 2022.02.xx, is there still a possibility to get the latest (BETA) deCONZ Firmware release tag?
“When you have authorized the integration, you select repositories you want to monitor, the list contains repositories you have starred on GitHub with your account.”
Do you see the integration in HA after setting it up? I don’t. After getting the " Congratulations, you’re all set! Your device is now connected." I see no integrations or devices.
UPDATE: Deleted the Github entry and re-did the process with success.
- platform: template
sensors:
deconz_firmware_update_available:
friendly_name: "deCONZ Firmware Update"
value_template: >-
{% set latest = state_attr('sensor.deconz_firmware_latest', 'tag').format().replace('v', '') %}
{% if ("beta" not in latest) and (latest != states('sensor.deconz_firmware_installed')) %}
true
{% else %}
false
{% endif %}
Note:
Because of statistics mapping (long-term record in InfluxDB) and to avoid few UI adjustments → instead of using the default sensor name “sensor.dresden_elektronik_deconz_rest_plugin_latest_release” I decided to reuse the old custom sensor name “deconz_firmware_latest” and therefore renamed the new entity of the GitHub integration. Therefore only thing changed is the attribute name.
Renamed sensor.dresden_elektronik_deconz_rest_plugin_latest_release to sensor.deconz_firmware_latest
That’s it. Result is looking good. Need to check if that beta behaves the same like before, I think so.
Additional note (nothing to do with the HA 2022.2 release / GitHub integration change):
For the sensor.deconz_firmware_installed sensor I meanwhile switched from this old command_line sensor…
To get the device_id once, have a look at /config/.storage/core.device_registry (take care to not change anything!) and search for "manufacturer": "Dresden Elektronik",. The 6th line below that one which starts with "id": has the device_id.