I just realized that sending g-code from the command line results in an error - will investigate further.

Found the issue! Apparently the padding field was not being set in make_mqtt_pkt(). Changed it to an empty binary string to let .pack() fill it up depending on the m5 byte. Note that the m5 byte will still be 2 for sent messages, not 1 as found in received messages for the M5C. But that does not seem to hurt, as I was able to home my printer's head by sending "G28;" from the command line.

BTW, I also adjusted README.md a bit to mention the M5C.

fixes #137 #147

One more observation - the PPPP badge in the web interface will currently not turn green for the M5C because, after reading the code, this is actually the status of the video connection. So the PPPP connection may be established correctly after all and sending gcode files will work just fine.

Maybe we should add a check for the badge that does a health check on PPPP for M5C to turn the status green in absence of the video feed

Maybe we should add a check for the badge that does a health check on PPPP for M5C to turn the status green in absence of the video feed

I may take a look into that as time permits. However, as it supposedly does not affect the overall functionality I assume this can be done via a separate PR.

Any review comments for this PR? Are there things to change before it can be merged?

As there was no feedback yet to the previous commits anyway, I ended up adding the feature suggested by @billyjbryant. I.e. the PPPP status is now correctly displayed for both M5 and M5C by expecting a PPPP message at least every 3 seconds. This makes the badge turn green, otherwise it is displayed as orange. The 3 seconds are a valid assumption IMO because the printer sends at least an AlivePkt every second.
A new VIDEO badge takes over the original PPPP badge.

This latest commit also adds conditions around parts of the web interface which are not applicable to the M5C. So M5C users will not see the rotating lines in the video area anymore, nor the controls for the camera or the VIDEO badge.

I have tested this with my M5C (which "luckily" drops the Wifi connection very often when connected to my Unifi AP), but tests with an M5 would be appreciated to see if things work the same as before (except for the added VIDEO badge).

I opened this PR almost one month ago, and while I admittedly added more changes later on, there was no comment to the specific code changes or prospects for when this can be merged from any of the maintainers of this great piece of software. In the meantime I direct people with various issues to my own integration branch, but this cannot be a permanent situation IMO.

Any thoughts about the changes and when this can be merged? Or is this project not actively maintained and developed further anymore?

Deployed this branch this morning. Works like a charm, way better than manually exporting gcode and opening Ankermake Studio!

Uploading files from prusaslicer gets stuck on "RESOLVING ADDRESS".

This is very likely an issue of PrusaSlicer and not of this PR or ancertctl in general, see prusa3d/PrusaSlicer#10944 . I saw the same issue a while ago but the latest versions of PS seem to have fixed it.

This is very likely an issue of PrusaSlicer and not of this PR or ancertctl in general, see prusa3d/PrusaSlicer#10944 . I saw the same issue a while ago but the latest versions of PS seem to have fixed it.

I'm running PS 2.8, so it isn't that.
Turns out the printer claims to have connected to wifi but doesn't actually connect.
They should really add a network test on the printer.

tldr: fck you ankermake

Was this work moved somewhere?

This and other PRs are now incorporated in https://github.com/anselor/ankermake-m5-protocol/tree/exiles-1.1 . Unfortunately, I have to admit that the documentation is still not up to date and matching the now recommended way (which is a simple login and printer search via the web interface).