[Feature] Support triggering firmware upgrade through mqtt (in LAN mode) #566
Comments
|
Just to add some info, this does not work with X1 series due to changes done to the firmware updating procedure on-device. Been a major blocker for those looking into this for the past year and some. P1 series I'm surprised that they say they got it working, last I checked with some of the contributors, the P1 series could only do it on much older firmware before a similar change to the X1 series was introduced in the firmware update procedure not allowing it to be successfully triggered via MQTT. Unsure if this has been changed back to being "possible". A1 series had always worked, but there is no guarantee for how long, especially since there are known MQTT security changes coming for all current series of printers. (Though proper A1 I have heard of this sometimes not working, A1 Mini seems OK though, so may be hit or miss still). If this were implemented, users with access to the cloud API can just get the json sig files from an API request for what is available for them to download, in an "officially allowed to upgrade/downgrade to" route. For sig files not in this list, it is possible bambu might take them down if vulnerabilities or errors were in the release, so there is no guarantee it is still hosted, hence why using only what their API list supplies for each printer is a safer route than relying on hardcoded versions/URLs. |
Yeah, but isn't that the case with any third-party software? API's can change, barriers can go up, cloud features could get paywalled. In the end you just never know ;)
Assuming you can trust the repository owner to keep the list up to date, there doesn't seem to be a reason why that same list couldn't be mirrored in a git repo. So it would probably be best if ha-bambulab would maintain it's own list
Ah ok, I wasn't aware about this. That might be a good reason to wait with implementing this indeed |
|
There is some precedent currently that the MQTT data/access for at least reporting will remain even after the changes, and certain requests as well, but I believe some are currently locked down on latest P1 firmware as the first "stage" of this already (very recent, so I wouldn't be surprised if this FW update method stopped working for P1 series from latest firmware and on). And the secondary reason to only use the cloud API list is such that we know it's also only compatible firmwares that can be upgraded/downgraded between for the specific printer and its current FW. What some people didn't realize with the failures they got on the A1 series initially with this method, is that not all firmwares can be upgraded to directly and some need intermediary FWs. For the X1 series for example, you cannot upgrade from the oldest firmware straight to the newest right now, and it requires one of the intermediary FW versions in the 01.06 or 01.07 stream first (I forget which). And likewise for downgrading (hence why many of the older ones are generally unavailable unless you're already on an older FW, that plus security reasons). Not to mention for X1Plus to downgrade to Firmware R, you need to downgrade to the oldest 01.07 build before FWR can be downgraded to. Not saying it's a bad request to implement, just clarifying the original feature request that it won't work for X1 series at all, which was mentioned in the FR, spotty for P1 (we won't know for sure until its next FW version release). And that it's likely best to limit it to expected/available firmware versions due to the compatibility reasons (also saves the trouble from having to maintain or trust a list). I myself looked into this quite a bit over a year ago but concluded that there was not much gain considering all of the edge cases, and this was before the known changes to come lol |
|
Oh, my post is being talked about interestingly. It's 'halwin' and 'lunDreame'. For the @WolfwithSword X1 series, someone else provided the information before, but the update failed. |
The update process requires a sequence of commands that aren't fully triggered via MQTT anymore for firmware updates, been this way for at least a year or more I'd say, hence the lack of progress. I forget the exact stuff since I haven't looked into it since December/January. X1Plus team had tried it out as well before FirmwareR was agreed upon just in case we needed to go to an old exploitable FW version, but we concluded that the process has extra non-MQTT initiated steps which were confirmed after the fact to not be doable on OEM X1 firmware anymore. I am curious however if this might change and be possible with the announcement of offline firmware updates being a thing soon for X1E, X1/X1C, and P1/A1 series in a future firmware update. That might loosen the restrictions a bit (since the FW will need to be on an SD card, bypassing at least one of the sequences). So, potentially next round of FW updates may be very exciting for X1 series! |
|
Stale issue message |
|
Is there anything about this approach that wouldn't work with the ability to send custom mqtt commands via the integration? |
|
What do you mean? |
|
If I created a service to send arbitrary request text to the mqtt would that be enough that you could send the right text to trigger a firmware update? |
|
Sure, it’s possible. We can create a Platform.UPDATE to implement the actual update. I considered submitting it as a PR, but currently, in the bambu_lab component, the binary sensor is triggering the update, so we might need to remove that and refactor it to use platform.update. To obtain the firmware for the Bambu printer, we need the firmware creation timestamp and hash code in the URL. This makes it difficult to get the complete firmware address for each print. Therefore, in my GitHub firmware repository, we register the Bambu account linked to the printer to extract the firmware address. Since I use the P1P/S model, other users with different printers may need to assist in this process. |
|
I'm looking for a lighter weight solution that doesn't risk annoying the Bambu folks. Baked in firmware update support possibly starts to cross a line that stops them tolerating this integration. So I was thinking if the update can be triggered by crafting a payload that the end user provides but is pushed to the printer via a generic 'push' mechanism then that feels less likely to be contentious given we already provide contol of the printer as long as it's in pure cloud connection mode or in pure lan mode. That would make firmware update accessible to the small percentage of users that would like to be able to do it but not confuse/complicate the experience for the majority that will just continue to update their printer firmwares when prompted by the printer. |
|
You can extract the firmware address by slightly modifying the URL while supporting offline SD update for all BambooLab models. This allows you to implement platform update locally on the component. https://github.com/lunDreame/user-bambulab-firmware/blob/main/scripts/fetch.py For MQTT transport commands, refer to assets/*.json files. |
|
Since December 10th firmware can now also be downloaded directly here:
for offline upgrading the firmware using the SD card |
Describe the feature
It turns out it is possible to trigger a firmware upgrade through mqtt, credits for this go to the user halwin on cafe.naver.com. It works by posting a json with the latest firmware description over mqtt (see prev link for details). The printer can then download the firmware directly from the CDN, without having to be signed in to the cloud.
The json with the latest firmware update can only be downloaded when you are signed in, this repo keeps track of the latest available firmwares. Note that that repo is relying on users with a cloud account to update those ota upgrade json's.
What device is this for?
X1/P1/A1
Other Information
See :
The text was updated successfully, but these errors were encountered: