Do not know how I missed that. Did find it now. Great! 
Sorry I can’t contribute on the API approach…
Yeah but we still need at least the latest version from Github which is not beta to compare it with the current version.
The latest_release_tag attribute from GitHub is not sufficient for this. Any ideas? We need a list of all versions and grab the newest one which is not “-beta”.
After that we can make a simple current vs. latest (non-beta) version comparison and proceed for creating the sensor, building proper notifications etc.
Something like:
sensor:
# Deconz Firmware version installed
- platform: command_line
name: deCONZ Firmware installed
command: 'cat /config/.storage/core.device_registry | grep -A 3 "Dresden Elektronik" | grep "sw_version" | cut -c32-36'
scan_interval: 43200
command_timeout: 60
value_template: "{{ value }}"
binary_sensor:
- platform: template
sensors:
updater_deconz:
friendly_name: 'deConz ConbeeI firmware Updater'
icon_template: mdi:update
value_template: >-
{% set new = state_attr('sensor.deconz_github', 'latest_release_tag').replace('v', '') %}
{% if ("beta" not in new) and (new != states('binary_sensor.deconz_firmware_installed')).format() %}
true
{% else %}
false
{% endif %}
Ops…
Right. BUT how to cut the string. Currently the latest_release_tag gives “v2.9.0-beta” which is a string that can not be compared to an int/float.
Tried to use
{% set version = "v2.9.0-beta" | regex_findall_index('=([0-9]*\.[0-9]*.[0-9])', 0) %}
{{ version }}
in the dev tools (template section) but I get a IndexError: list index out of range so the regex is not working…
Looks like the command line sensor (installed version) picks up a list and not only the version number:
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', '') %}
1 Like
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.
Ah great, that worked!
lovelace (conditional) would look like
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.
Looks like I have problems picking the value from the file.
My attempts has been with these results, any ideas?:
| cut -c32-36' --> ull, ull, 2.7.1
| cut -c33-36 --> ll, ll, .7.1
| cut -d: -f2 --> null, null, "2.7.1",
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'
1 Like
Too much DE 
As mentioned, that file parsing approach has more disadvantages than the API way… you discovered one of those 
Well, we got it working at last somehow
Let’s monitor the file when a firmware update has arrived. It may get an entry into the file.
1 Like
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.
1 Like
IMPORTANT / Update 2022-02-13:
See post deConz Addon - deConz Firmware integration sensor - #36 by e-raser for necessary changes since HA 2022.2 (where GitHub integration has been removed for YAML use, instead only using the UI is allowed now).
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)
My deCONZ latest firmware sensor still shows:
…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:
Everything fine:
So I´d like to set this whole deCONZ firmware update thing as “working as expected / stable / productive” 
Update: as mentioned in deConz Addon - deConz Firmware integration sensor - #22 by e-raser …
…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:
- platform: command_line
name: deCONZ Firmware installed
command: 'cat /config/.storage/core.device_registry | grep -A 3 "Dresden Elektronik" | grep "sw_version" | cut -c32- | rev | cut -c3- | rev'
scan_interval: 43200
command_timeout: 60
value_template: "{{ value }}"
If someone not having updated to latest v2.10.4 release yet could test and verify this is working that would be nice.
@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?
- platform: github
access_token: !secret GitHub_token_deCONZ
repositories:
- path: 'dresden-elektronik/deconz-rest-plugin'
name: "deCONZ Firmware"
scan_interval: 86400
From the release notes they recommend using
“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.”
But I have not managed to get it working(?)
Indeed, this new sensor shows the current stable release and not the latest beta release.
That’s why I’m asking. 
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.
Yes, I do see them after enabling the entities (disabled by default).
You got things working again? Could you share what steps were necessary for this?
I did not have time to upgrade to HA 2022.2 yet.
Updated to 2022.2(.6) now. Steps to make things working again:
-
Added GitHub integration using the UI, selected “dresden-elektronik/deconz-rest-plugin” project (which has been starred already before)
-
Removed this section and restarted HA (to have the entity “sensor.deconz_firmware_latest” ready to be used again (why: see comment below step 3)
- platform: github
access_token: !secret GitHub_token_deCONZ
repositories:
- path: "dresden-elektronik/deconz-rest-plugin"
name: "deCONZ Firmware latest"
scan_interval: 43200
- Updated the actual update sensor
- 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_releasetosensor.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…
- platform: command_line
name: deCONZ Firmware installed
command: 'grep -A 3 "Dresden Elektronik" /config/.storage/core.device_registry | grep "sw_version" | cut -c32- | rev | cut -c3- | rev'
scan_interval: 43200
command_timeout: 60
value_template: "{{ value }}"
…to this template sensor (still in old format, but anyway):
- platform: template
sensors:
deconz_firmware_installed:
friendly_name: "deCONZ Firmware installed"
value_template: >-
{% set entity_id_in_device = 'f0e0XXXXXXXXXXXXXXXXXXXXXXXXXXXX' %}
{{ device_attr(entity_id_in_device, 'sw_version') }}
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.