Run the COSMOS update through Moonraker's update_manager

[kyleinoregon]

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, and it is part of the COSMOS build only (COSMOS=true).

What

A small UpdateManagerClient. The Update button sends machine.update.client for the cosmos entry over the existing websocket instead of running a shell command, and the notify_update_response stream 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 "Update COSMOS Failed" dialog with Moonraker's message and an OK button; a refused request (for example while printing) does the same immediately. An update started from Mainsail or Fluidd shows on the screen the same way.

Nothing is configurable: the app name is cosmos and the strings are the COSMOS build's. grumpyscreen ships as part of COSMOS, so the Moonraker side (OpenCentauri/cosmos#313) is always there and there is no fallback to the old shell command.

Notes:

• No changes to websocket_client: it already dispatches notifications by method name and supports request callbacks.
• The dialog is the multiline_message variant of create_configurable_dialog(), since the default no-button dialog on a 272 px high screen is too short for a two-line message.
• Only notifications for cosmos are shown, so an unrelated update started from a browser does not pop a dialog on the printer.

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 without COSMOS=true, no warnings.

[pellcorp]

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.

[kyleinoregon]

Done: everything in update_manager_client.{h,cpp} and its use in setting_panel is now inside #ifdef UPDATE_BUTTON_CMD, which the Makefile only defines when UPDATE_CMD is set. Built both ways: without UPDATE_CMD the binary has no reference to the update_manager API (checked with strings), with the cosmos settings it behaves as before, no warnings either way. The default grumpyscreen.cfg is untouched; the [update_manager] section only exists in cosmos's own config in OpenCentauri/cosmos#313.

[pellcorp]

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

[pellcorp]

I am thinking to make some changes to the way we package the update capability, now that Cosmos is the only downstream project that uses Update I am considering changing the #ifdef logic to be a bit simpler, so likely going to be #ifdef COSMOS probably directly integrating the various messages into the main project so that the cosmos project does not need to override them, will make things a bit simpler, but at that point you will need to rebase again for this PR, assuming cosmos decides to go ahead.

[pellcorp]

I have made some changes to grumpyscreen to make COSMOS a first class citizen, so you pass COSMOS=true to the makefile to activate the Update button now, no need to pass all the extra stuff, the Update, Switch to Stock and Factory reset messages currently defined by cosmos are now part of a COSMOS build to make things a bit easier.

[pellcorp]

Also just want to say, there is ZERO reason to provide config for different clients, this code is only ever going to be used by COSMOS, so you can just hardcode stuff in the update manager client code, cos we will never use it outside cosmos build.

[jamesturton]

this code is only ever going to be used by COSMOS, so you can just hardcode stuff in the update manager client code, cos we will never use it outside cosmos build.

I get your point, but from the other side, if it is implemented in moonraker using the existing API then other GUIs (such as klipperscreen running on an external display) will also "just work" without the need to make patches there. So I think this will be a much more robust solution in the long run.

[kyleinoregon]

Rebased onto main with the COSMOS=true build (#290) and simplified as suggested: the client is now inside #ifdef COSMOS, the app name is fixed to cosmos, and the [update_manager] config key is gone, so grumpyscreen.cfg needs nothing for it. It is one commit now, on top of #286.

The one thing I kept is a fallback: if Moonraker answers machine.update.client with 404 (no cosmos updater, so a COSMOS without OpenCentauri/cosmos#313), the button runs cosmos_update_cmd as it does today. Happy to drop that too if you would rather not carry it.

James is right that the update itself lives in Moonraker, so Mainsail, Fluidd or a KlipperScreen see the same thing; this PR is only the screen showing that stream. Built with and without COSMOS=true, no warnings, and re-tested on the Centauri Carbon.

[pellcorp]

I don't mind so much, cos all the update code lives inside #ifdef COSMOS :-)

[pellcorp]

this code is only ever going to be used by COSMOS, so you can just hardcode stuff in the update manager client code, cos we will never use it outside cosmos build.

I get your point, but from the other side, if it is implemented in moonraker using the existing API then other GUIs (such as klipperscreen running on an external display) will also "just work" without the need to make patches there. So I think this will be a much more robust solution in the long run.

I don't mind long as the default grumpyscreen.cfg does not have this section as its not relevant to Simple AF and you guys write your own anyway.

[pellcorp]

this code is only ever going to be used by COSMOS, so you can just hardcode stuff in the update manager client code, cos we will never use it outside cosmos build.

I get your point, but from the other side, if it is implemented in moonraker using the existing API then other GUIs (such as klipperscreen running on an external display) will also "just work" without the need to make patches there. So I think this will be a much more robust solution in the long run.

Oh maybe you misunderstood me, I just meant I dont want the update_manager config in the default grumpyscreen.cfg, nor do I necessarily think you even need to list the update manager ID either, cos GrumpyScreen is only ever going to be used for Updates by you guys, but honestly I also dont care that much, long as its contained in #ifdef COSMOS you can do whatever you want within reason :-)

[kyleinoregon]

Rebased on current main after the theme refactor (the dialog now sizes itself, so the multiline option is gone). Builds clean with and without COSMOS=true.

[pellcorp]

apologies but more conflicts, maybe don't even bother fixing until its clear cosmos is going to merge.