Run the update through Moonraker's update_manager when configured - #289
Open
kyleinoregon wants to merge 4 commits into
Open
Run the update through Moonraker's update_manager when configured#289kyleinoregon wants to merge 4 commits into
kyleinoregon wants to merge 4 commits into
Conversation
…ommands The update, switch-to-stock and shutdown-host handlers ran their command synchronously on the LVGL thread from inside the click dispatch and only created the "Initiated" dialog after the command returned. Commands that end in a reboot never return, so the screen showed nothing at all until the printer restarted, not even the button's pressed state. Factory reset already avoids this by creating the dialog first and deferring the command to a one-shot lv_timer. Generalise that into run_command_deferred() and use it for all four commands. Factory reset keeps its 5 s delay; the others wait 500 ms, enough for LVGL to render the dialog before the command blocks the thread. Failure handling is unchanged: a non-zero exit replaces the dialog with the "Failed" one. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
With [update_manager] application: cosmos in the config, the update button asks Moonraker to update that update_manager entry (machine.update.client) instead of running a shell command, and the progress Moonraker streams through notify_update_response is shown in a dialog, the same way Mainsail and Fluidd show it. A failed update ends in the "Failed" dialog with the message from Moonraker; a refused request (for example while printing) does the same straight away. Without the config key nothing changes: the button keeps running its configured command. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This was referenced Sep 5, 2026
Owner
|
All the update manager code must be put within #ifdef UPDATE_CMD or the like, Cosmos is the only downstream that uses the update button, I do not want any of this code being present in what we build for Simple AF. The default grumpyscreen.cfg will not have the update manager config either. |
Everything in update_manager_client.{h,cpp} and its use in the settings
panel is now inside #ifdef UPDATE_BUTTON_CMD, which the Makefile defines
only when UPDATE_CMD is set. A build without the update button, such as
Simple AF, compiles none of it and the binary has no reference to the
update_manager API.
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Author
|
Done: everything in update_manager_client.{h,cpp} and its use in setting_panel is now inside |
Owner
|
This pr won't be merged until the cosmos change is merged I was planning to test and merge the dialog change after the mmu change |
kyleinoregon
pushed a commit
to kyleinoregon/cosmos
that referenced
this pull request
Sep 5, 2026
Review follow-up. The cosmos_update.py component is now placed into the Moonraker source tree with the subdir fetcher option instead of being copied in do_install. The cosmos-update-start helper, the UPDATE_COSMOS and CHECK_FOR_UPDATES shell commands, the _UPDATE_COSMOS macro, the startup update check, the check-update script and the check_for_updates option are removed: update_manager refreshes on its own schedule and the web UIs show what it finds, and grumpyscreen starts the update over its own Moonraker connection (pellcorp/grumpyscreen#289) using the [update_manager] application key in grumpyscreen.cfg. The screen's cosmos_update_cmd and the recipe wording are back to what main ships. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
When the update was started from Mainsail or Fluidd there is no button title to reuse, and the failure dialog read "Updating cosmos Failed". Use "Update <app>" in that case, and keep the button title otherwise. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows the discussion in OpenCentauri/cosmos#308: COSMOS is moving its updater into Moonraker's
update_manager(OpenCentauri/cosmos#313), so every UI shows the same thing. This is the screen's side of that. Stacked on #286: the first commit here is that PR, only the second one is new.What
A small
UpdateManagerClient, switched on by naming the update_manager entry in the config:With that key, the update button sends
machine.update.clientfor that entry over the existing websocket instead of running a shell command, and thenotify_update_responsestream Moonraker sends during the update is shown in a dialog: "Downloading COSMOS update... 40%", "Installing the update, do not power off the printer!", and so on. The printer reboots by itself once the update is installed, so the last dialog ("COSMOS update installed, the printer is rebooting") has no button and closes on its own after eight seconds. A failed update ends in the "Failed" dialog with Moonraker's message and an OK button; a refused request (for example while printing) does the same immediately.Without the key nothing changes: the button keeps running its configured command through the deferred path from #286, so nobody else's build or config is affected.
Notes:
websocket_client: it already dispatches notifications by method name and supports request callbacks.multiline_messagevariant ofcreate_configurable_dialog(), since the default no-button dialog on a 272 px high screen is too short for a two-line message.Tested
Centauri Carbon (480x272,
GUPPY_SMALL_SCREEN) on COSMOS 26.08.0 with the cosmos updater component from OpenCentauri/cosmos#313: dry run first (download only, flash stubbed), then a real 26.08.0 re-flash started from the screen's Update button. In both, the dialog appeared the moment the prompt was confirmed and stepped through Moonraker's messages: reinstall notice, download percentages, "Installing the update, do not power off the printer!", "Update installed, rebooting..." and the final "COSMOS update installed, the printer is rebooting". In the dry run that last dialog closed by itself after eight seconds; in the real run the printer rebooted underneath it. The same runs appeared in Mainsail's update dialog. Built with and withoutUPDATE_CMD, no warnings.One thing worth knowing for anyone configuring this: grumpyscreen's override config only merges keys that already exist in the base config, so the
[update_manager]section has to be in the basegrumpyscreen.cfg(the cosmos PR ships it there), not only in the user override.