Implement list of local files and add a button to start a print. - #19
Implement list of local files and add a button to start a print.#19RedAces wants to merge 12 commits into
Conversation
The printer's stored files were not visible in Home Assistant and prints could only be started from the printer, the slicer, or the FlashForge app. Adds: - select.<printer>_print_file - lists the files the printer reports via the HTTP /gcodeList endpoint and records which one to print. Per-file print time, filament weight, tool count, and the Material Station flag are exposed through extra_state_attributes["files"]. - button.<printer>_print_selected_file - starts the selected file and stays unavailable while nothing is selected. - flashforge.print_file service on the print file select, with optional file_name and leveling_before_print, so automations can start any file on the printer - including files outside the reported list. - "Level the bed before starting a print" option (default off), used as the default for the button and the service.
Two fixes found by probing a real Creator 5 Pro (pid 41). Material Station entities never appeared on the Creator 5 series. The four slot swatches and the Active Material Station Slot sensor were gated on FFMachineInfo.has_matl_station, a verbatim copy of the raw hasMatlStation field from /detail. A Creator 5 Pro omits that field entirely - it parses as None - while reporting matlStationInfo with four loaded slots, so the gate never opened and the v1.3.0 move off is_ad5x had no effect on this model. Capability detection now lives in util.has_material_station(), which also accepts populated slot data (slotCnt / slotInfos) as proof of the station. Those entities are no longer decided once at setup either: platform setup can run before the station reports in, or after a failed first refresh, which left the printer permanently without them. The slot images and every availability_fn-gated sensor are now added when the capability first shows up on a later coordinator update. The print file select reported unknown metadata as 0 / false. /gcodeList carries per-file detail (gcodeListDetail) only on the AD5X; the Creator 5 returns plain file names, so printing_time stays 0 and every other field None. Running that through bool() claimed "single material" for a file we know nothing about - a three-color file showed up as single-color. file_attributes() now omits what the printer did not report, so absent stays absent. scripts/file_print_probe.py gained the matching diagnostics: --raw dumps the untouched /detail and /gcodeList payloads, --thumb checks whether /gcodeThumb serves a preview for an arbitrary stored file, and the file listing distinguishes "no metadata reported" from "the printer says no material station".
A Creator 5 Pro accepts and starts a three-material file sent via start_creator5_job without materialMappings - the firmware falls back to the tool/slot assignment stored in the 3MF. The print file service therefore needs no mapping input on this model. The test job was cancelled seconds after the start, so the resulting color assignment itself is not confirmed; the notes say so explicitly rather than implying an end-to-end verification.
A button entity is stateless - its state is only the last-press timestamp - so every write of that state is reported as a press. Gating availability on the selection meant picking a file flipped the button from unavailable to available, which the logbook showed as "Print Selected File pressed" although nothing was pressed and no print started. Availability now reflects the printer's reachability only, per the entity-unavailable rule, and selecting a file no longer notifies the coordinator's listeners. Pressing with nothing selected - or with a file that has since disappeared from the printer - raises a ServiceValidationError.
"Print File" reads like an action, so the logbook entry for picking a file looked like a print had been started. The entity only records a choice; the button and the service are what start a print.
The "Always show LED switch" option was handed to the library as led_control_override using its unset value False. The library reads False as "force LED control off" and only None as "no override", so with the option switched off - the default - the integration overrode the printer's own capability report and pinned led_control to False on every model. The switch stayed greyed out, and the library additionally refused set_led_on/off internally, which made enabling the override look like the only way to get a working switch. The option now passes None when off and True only when explicitly enabled. Verified on a Creator 5 Pro: /product reports lightCtrlState 1 and the lamp switches, so the endpoint was never at fault here. Capability diagnostics move out of file_print_probe.py into a new capability_probe.py: raw /detail and /product dumps, the flags entities are gated on, and a --led command that bypasses the guard. The file probe is back to file listing and print start only.
|
I found another bug and fixed it: my HA showed the LED switch as greyed out - which was weird. Because this printer has a lamp and it can be toggled remotely. The problem was that "override = none" was interpreted as "override = false" - off! |
|
Thank you for all your work with this and GhostTypes/ff-5mp-api-py#14 ! Rather than adding job listing / starting logic at this time , I'd like to implement that with support for the 5M series and AD5X further down the road. Each model does listing local files / staring local files a bit differently, and would need some work done in the python API too. Also, I would need to know for sure about a .3mf file working without material mappings, I don't think it's possible to start a job correctly without doing the "material matching" process (matching what's in the material station to the print). If you're able to verify the colors are automatically derived somehow that'd be great, but I'd still be more comfortable requiring them to be matched by the user each time to avoid wasted material or other issues. The rest of this work is great, and I appreciate all the testing and verification done! I'm thinking about cherry-picking all of that into a separate PR and adding you as co-author so you're properly credited, let me know if that works or if you'd like to do something else/ You can reach me a bit easier on discord (ghosttypes) , and I have a server here for my projects. I figure this would make it easier to discuss how the job listing and staring will be implemented. |
|
Do you want me to create 2 PRs for the two bugs I found so we can have this new feature here separately? |
|
I just started a multi-color print via the |
Correctly catch a connection error and exit early
I've reimplemented the bug fixes locally with you credited , I didn't want you to have to "redo" anything 👍
Thank you! This is the biggest unanswered question I have. If you could also provide the raw |
Sorry I forgot to answer: it came out perfectly. I used the "paint object (N)" method in the slicer and sent the file to the print. Afterwards I used the script and it started the print and it came out two-colored. |
|
No worries, that's great to know! Would you be able to upload the sliced 3mf file so I can see if paint object shows up differently that the metadata I check for now? Also, was this with OrcaSlicer or FlashForge's FlashStudio , and which version? |
|
The 3mf is here: https://we.tl/t-MNov4uh88LxuRfVV I used the newest version of Flash Stuide 1.7.12 |
Unfortunately it doesn't appear this was exported correctly, did you use the slicer to send the file to the printer directly, or export the .3mf and load via USB? This 3MF only has .model files, no gcode or anything else. Here's how to export the sliced 3mf file
I've pushed out updates including your bugfixes, where would you like to discuss plans for starting new jobs/the remaining work you contributed? |
|
This is the export of the sliced plate: https://we.tl/t-W4zrCrHXBPhvR7Ef |
# Conflicts: # AGENTS.md # CLAUDE.md # custom_components/flashforge/__init__.py # custom_components/flashforge/coordinator.py # custom_components/flashforge/image.py # custom_components/flashforge/sensor.py # tests/ha_mocks.py # tests/unit/test_setup_entry.py
|
Ive just merged in all of your fixes and it looks great! Ive added you on discord - should be the same name as here (RedAces). |
- Added German translations, contributed by @RedAces in #19 Co-Authored-By: RedAces <7756039+RedAces@users.noreply.github.com> Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TTAHC2CpkMXVLNWRB3nbFG
2 participants
Ive recently bought a Creator 5 Pro and using your wonderful homeassistant integration.
One thing I'd like to have is the ability to start print remotely via Home-Assistant. Currently Id have to connect with a PC running a slicer via VPN to my network, slice it and upload it. What I want to do is slice it before-hand and start the print remotely with my smartphone.
Implementing this I found an error with the creator 5:
Please tell me what you think!