New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Osram/Ledvance OTA updates support #1000
Comments
I have a couple of the SMART+ Motion Sensors so just checked:
|
Thanks for implementing this. I have some E27 bulbs (warm white and rgbw) and smart plugs that I will test this weekend. |
Thanks for sending the data @kiall! The values for |
@kiall seems your device is made by CentraLite while the reference API we currently have is for devices made by Ledvance... we will need to find an API for those in order to support them. I'm updating the title of this thread to be more accurate. The values returned from https://api.update.ledvance.com/v1/zigbee/products seems to indicate that only |
Poking through the available firmwares, it seems your right! I guess this complicates the
|
I've had some success searching for older issues with either 4489 or 4364! Specifically, this issue has a nice database entry:
The two values to retain from this is I cross-checked that
The I then ran the following request:
Amongst the information returned, I found this:
This is basically the current matches the So |
If I have time this weekend, I'm glad to assist with three Smart+ Plugs. |
The API is so simple that... it's done! I locally tested as much as possible and everything seems to be fine, but it would be great to have someone confirm that it actually works on retrieving the files! @Koenkk should I create the PR now or wait for someone to actually confirm it works first? There's also the problem @kiall above exposed: I have no idea how to identify which Osram devices have manufacturer code 4489 or 4364 by looking on the devices.js file... so I don't know which actually support this (though in the end, they will just receive a message saying that no firmware was found) |
It's probably no big deal, especially if there are some comments in the osram.js file to explain the mess OSRAM created 🤣 it'll get cleaned up if/when a firmware source is found. Though, it might make sense to update Z2M to have OTA sources expose the manufacturer IDs they support, and remove the hardcoded OTA choice from devices.js. |
Hi all, I'm trying to help, and I am using @Koenkk's latest-dev docker image. I have created a volume with this repository, but now when I launch the docker container, I get the following error: Using '/app/data' as data directory
How do I add the missing module 'axios' to @Koenkk's docker image? |
@Calimerorulez that is actually expected, you need to do |
Same for me, but I can't run npm ci in the docker container because it restarts all the time |
No, don't do that on the container, do it on the host! So just clone the repo, open a terminal on the root of the repo and run |
If you created the container yourself, add |
no npm on the host and do not feel like to mess with that |
I've tried checking for updates for two different OSRAM devices, but they both said there was no firmware file available.
With traceback: |
Running npm install worked :) Now when I run the check for upgrades, there is no update for my Smart+ Plug apparently, or it is not supported?
It is a |
Ok, I must have done something wrong. I checked out your repository, but I'm missing the osram.js:
I have to switch to your branch. I'll test further :) |
|
@jasperro Thanks for testing! I've checked your device with details You can check by doing the following:
I think I need to improve the error messages... |
@Calimerorulez using the same approach as on my previous post, I can see that the latest available version for the |
@pedrolamas My other device (man: 0x110c | img: 0x0062) has version 1020510, also the latest version, so no update needed |
I've made some adjustments to ensure we always retrieve metadata for existing firmware and then check locally if this is a new version or not. This will improve the debug messages so that "No new image available" will be returned when an image has been found but it is the same version as the current one on the device, and "No image available..." when there is no image at all. |
I've taken the list from https://api.update.ledvance.com/v1/zigbee/products and refactored it to what I believe is a simpler view:
As such, these are the only devices supported by this API. |
Not sure if file versions are correctly interpreted for all devices. I already noticed some days ago that for some Osram/Ledvance devices file version are somewhat strange when comparing real world vs API numbering. See Koenkk/zigbee2mqtt#2921 (comment) My "Plug 01" is on version v1.04.12 and latest version is V0.20 Build 509 So from the CLA60 I would assume that they're equal and the major version number "somehow" needs to be neglected or interpreted in a different way. Not sure why v1.x.y is v0.20 Build xy. Here's my log output when checking for the "Plug 01".
Would be good if in cases like these where the device has a firmware that is newer than the newest firmware provided by the manufacturer there'd be a info/warning in the log. BTW: I can only help you out with the Plug01 as all my other Osram devices are already up2date. |
I did not know that I had to enable debug-logging to see the version numbers, here is my log for my plug:
So no update available :) |
Thanks @andreasbrett for sending that, and you are absolutely right! Your Plug01 device is returning On the Levance website I can see that the available firmware is version 0.20.509, and by downloading the image and analysing it, it reports a fileVersion of 16909577, so the good news is that an update is available for that device (and the same here applies to @Calimerorulez as your logs show the exact same values!) So the question is how we translate fileVersion 16909577 to version 0.20.509. My current approach was to convert 16909577 to hex ("01020509") and substring this as "AAABBCCC", but that approach does NOT work here as this would return version 10.20.509 when we already know it is actually 0.20.509... so the real question is, what is that 1 and how do we get to it? I'm going to download a few more images and compare the fileVersions and indicated versions to see if I can find a pattern... |
Seems that the extra "1" is for the 4364 manufacturer code only... In any case, I found another way around this!
The above is the metadata returned for manufacturerCode 4364, imageType 39, and I can see clearly that the fileVersion is actually part of the fullName field returned, so I'm going to start using that instead of trying to figure out how to go from version->fileVersion I've confirmed this is the case in all other results from the service! |
@pedrolamas maybe this helps? No guarantees anyone is actually following it though. Screenshot from https://zigbeealliance.org/wp-content/uploads/2019/12/07-5123-06-zigbee-cluster-library-specification.pdf |
Thanks @kiall unfortunately I can see it doesn't match as the spec recommends the last 2 bytes to be the stack version and that bit I know it actually matches the build. In any case, I just pushed an update that will parse the fileVersion from the fullName element so I'd expect anyone with Plug01 If you have one of these plugs, please pull the latest and run a "check", if it returns true, then do the "update" next! Be aware that I also renamed any "osram" reference on my code to the more accurate "ledvance". |
I tested the new build, with two Plug 01, both updated without a problem. |
Mine just updated fine too! Thank you all! |
My PR just got merged into the dev branch, so closing this now as resolve! |
I am seeing this error regularly now (within zigbee2mqtt):
Is this something I can help debugging/fixing or is this an already known issue? I have 2 types of |
Seeing same issue regularly in zigbee2mqtt 1.16.1 log.
I have 2 types of My first time to post so please let me know if there is more info I should post or if this is in correct place. Thank you! |
Experiencing the same red message when checking OTA:
|
@ZZJHONS the complete URL seems to work correctly: https://api.update.ledvance.com/v1/zigbee/firmwares/newer?company=4489&product=17&version=0.0.0 Check again, and if this is still happening, we might need to take a closer look! |
I've just tried to update an older OSRAM Smart+ Plug (Model AB3257001NJ). The OTA failed with the error message "No image available for manufacturerCode '4364' imageType '39' " The device is on firmware version 1.04.12. |
@Pferdebockwurst in terms of URL, that also seems to work fine: https://api.update.ledvance.com/v1/zigbee/firmwares/newer?company=4364&product=39&version=0.0.0 Can you try to do a You should get something looking like this: |
I did, and this is the result, on the machine that is running Home Assistant and Zigbee2mqtt: |
Thanks for checking @Pferdebockwurst, given the above I fail to see how this assert is going false... |
I don't know either. @Koenkk is there a recent change that might affect how these devices try to check for an firmware update? I have never had this kind of error when trying to update these devices before. |
I wonder if this problem is now fixed with #5069... 🤔 |
I'd like to know too, but I can't check it because I'm not using the dev branch. |
Well, I now know that #5069 did not fix the problem as that fix is only applied if a proxy is in use, however I managed to confirm that it is in fact the problem! I added a "quick & dirty" test locally to just download from one of the above URL's and can see the data is broken, seems to be this issue with axios, but the proposed solution of sending @Koenkk axios v1.x has shown for a while that it has some serious issues (including this last one), so I would seriously consider downgrading back to v0.x This is the result of running exactly the same test (no code change) with axios v0.27.2: Though the test failed (expected), I can clearly see all the data there. |
@pedrolamas reading axios/axios#5328 it seems this problem has been introduced in 1.2.0, I've locked it to 1.1.3 now. Can you check if this fixed the issue? Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html) |
I ran a quick test with 1.1.3 and indeed it seems to work fine with that version! |
Hi, Maybe the frontend lie? Help would be appreciated. :-)
|
The update could be started by Home Assistant and went smoothly
|
I've been taking a look at the Osram/Ledvance OTA updates and how we can implement this and it does seem quite trivial as they provide a fully open and very well documented API!
I've started a branch in my fork here: https://github.com/PedroLamas/zigbee-herdsman-converters/tree/pedrolamas/osram-ota
Problem is that I currently don't have any Osram device, so I'm asking anyone interested in helping to try my branch (quite trivial if you are using Docker) and report back the debug values from a zigbee2mqtt/bridge/ota_update/check call.
Thanks in advance!
The text was updated successfully, but these errors were encountered: