-
Notifications
You must be signed in to change notification settings - Fork 85
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
Add software update capability #709
Conversation
Will there be some new API-commands available to control this? |
It would be nice if these steps where totally independent:
I would like them to be:
The reason I want this is to be able to test firmware updates for devices in development, which is not yet published to the DCL. Then step 1 and 2 would be bypassed. It would be nice with a separate API-function for each of the steps. |
TODO:
|
745ff7d
to
b43b024
Compare
Yes,
Yes, I intend to split this two operations. It is a bit a question of what the reference will be to apply the update. I intend to use the software version number (in integer format) as reference, as this should be unique. So the commands will be: {
"command": "check_node_update",
"args": {
"node_id": 50
}
} This will return information about the software, the exact format is tbd (currently a raw dump of the JSON data returned by the DCL). Then with this command the update will get applied: {
"command": "update_node",
"args": {
"node_id": 50,
"software_version": 123,
}
} Will then start the node update.
Agreed, we'll need to have a way to support non-DCL updates. In fact, for testing I already need this (I've now added hardcoded updates for the OTA Requestor example). There are various use cases, from just not in DCL but online, to just an update file from somewhere. Each of these cases need some metadata to match the update file with the right devices. The metadata should probably closely follow the DCL format. For online ones, we could probably just pass it through the WebSocket API as well, essentially how you suggest. But I don't think this will cover all use cases. 🤔 |
c6e19e2
to
bb700de
Compare
b649d5a
to
21ea899
Compare
0bf4bc5
to
7f5460b
Compare
8c22aa5
to
0764463
Compare
Check if there is a software update available using DCL software update information.
The OTA provider downloads the updates and prepares them so Matter devices can consume them.
Use the OTA Provider example app to implement a OTA provider. The example app supports a JSON update descriptor file to manage update metadata. Tested with the OTA Requestor app.
0764463
to
9ed6840
Compare
Start and commission OTA Provider App when necessary. Use random discriminator and passcode. Store the Node ID of the OTA Provider App once setup for fast re-use.
Verify that the DCL software update is indeed applicable to the currently software running on the device. Add test coverage as well.
Add global check for update where we can insert hardcoded updates or updates from other sources in the future.
Co-authored-by: Marcel van der Veldt <[email protected]>
Can you mark it as ready once its entirely complete ? Then we'll do one final review (and hopefully the merge) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
Sorry for chiming in, not sure if this is the best place or if this would be feasible, but: would the updates feature also support firmware downgrading, or that depends on the software on the matter devices? |
No, downgrading is not supported by Matter OTA. From the standard:
|
I've built docker image from git main branch and started it - how do I get update notification? It seems there is update available for my device (Aqara Window and Door Sensor P2), about an hour after docker container restart passed, but I don't see any notification in HA. |
@nerijus You won't see a notification in HA, as the HA core PR is not merged yet: |
Thanks; is there a possibility to upgrade manually from command line from within python-matter-server docker shell? |
I updated files from home-assistant/core#120304 manually (and a few other files like select.py, strings.json), but now after restarting HA I get:
|
Just have a little bit of patience folks until this is available. It will also be added as a button the the matter server's own debug UI. The changes for HA core need some more adjustments before we merge them but plan is still to get it done on time for the next beta. |
I would like to test the new software update capability. What is the high level flow (which commands to use) if I provide my own firmware file? |
I'm using HomeAssistant and Matter-Server with thread devices, everything works fine. I would like to be able to perform OTA updates to the devices but I don't have an account in DCL, is there a possibility to update the firmware of the devices added in HomeAssistant through Matter-Server locally? for example by indicating to Matter-Server a path where the update files are. Is there such a possibility? I have seen that in the Matter-Server configuration there is an option to add "--ota-provider-dir", but I don't know how it works. Is this option the correct one to indicate a path where the update files are saved? How do you indicate that path? thanks |
@JoseAntonioMG Look here: |
This adds software update capability to the Python Matter Server.
As it stands, the implementation does the following things:
3a. On first use, the OTA Provider App is first commissioned to the fabric
The node then communicates directly with the OTA Provider. Progress of the update can be observed in the OTA Software Update Requestor Cluster of the device being updated.
There are a few things which still need to be sorted out: