Check code not working.

[kd5dmg]

The same check code that works in the slicer does not work in the integration. It will not allow me to add the printer. It auto discovers the Creator 5 and ask for the code. I enter the code and it errors out and says that it is not correct.

[vahurvilta]

I have a same issue but i think it is caused by printer or my network as i cant get response from 8899 port. Claude helped to combine response Title: Creator 5 (firmware 1.9.4): config flow fails with "cannot_connect" — TCP port 8899 refused, but HTTP API (8898) works fine

Printer: FlashForge Creator 5
Firmware: 1.9.4
Integration version: (fill in your installed version)
Home Assistant version: 2026.7.4

Description:

The config flow (both automatic discovery and manual entry) fails at the credentials/validation step with cannot_connect, even though the printer's IP address, serial number, and check code are all verified correct.

What I've confirmed:

1. UDP auto-discovery works correctly — the config flow's "Automatic Discovery" step successfully finds the printer at its correct LAN IP.

2. The HTTP API on port 8898 works perfectly. Manually testing with curl:

   curl -X POST -H "Content-Type: application/json" \
     -d '{"serialNumber":"SNMxxxxxxxxxx","checkCode":"xxxxxxxx"}' \
     http://192.168.68.65:8898/product
   

   Returns:

   {"code":0,"message":"Success","product":{...}}
   

3. TCP port 8899 is closed on the printer:

   curl -v telnet://192.168.68.65:8899
   * connect to 192.168.68.65 port 8899 failed: Connection refused
   

   This is a "Connection refused" (RST from the device), not a timeout, so it's not a network/firewall issue — the printer is actively not listening on that port. Confirmed both before and after updating firmware to 1.9.4.

4. The config flow's credentials step (which appears to call InitControl(), requiring the legacy TCP connection) fails with cannot_connect as a direct result of Bug: Print Progress showing 0 % #3, despite the HTTP API validating successfully.

Expected behavior:

Since the Creator 5 (at least on 1.9.4) only exposes the HTTP API and not the legacy TCP control port, the config flow's validation step should either fall back to HTTP-only validation, or skip the TCP InitControl() requirement for printers that only support the "new" HTTP API.

Additional notes:

A related community project (FlashForgeWebUI) shows the same pattern — its printer-type auto-detection defaults to the "Legacy API" client and also fails with ECONNREFUSED on port 8899 for this printer, while the HTTP API works fine. This suggests the issue is in the shared underlying client library's assumption that TCP 8899 is always available.

Happy to provide further debug logs or test builds if useful.

[GhostTypes]

@kd5dmg @vahurvilta Please update to 1.3.3 and let me know if this resolves your issue

It appears the firmware added/changed some fields in the response from /detail, which caused some ValidationErrors in my python api

[vahurvilta]

Thank you for rapid reply. unfortunately still not working for me. i used claud to help me to check the logs again and here is what it thinks:
UPDATE after upgrading to v1.3.3:

The port 8899 issue mentioned above is not the (only) cause. After updating to v1.3.3 and re-enabling debug logging, the config flow still fails with cannot_connect, but now I can see the actual underlying error in the logs:

WARNING (MainThread) [flashforge.api.controls.info] Could not read /detail; callers cannot tell
this from an unreachable printer or a rejected check code, so this line is the only record of
the real cause. 1 validation error for DetailResponse
detail.chamberTemp
  Input should be greater than or equal to -50 [type=greater_than_equal, input_value=-108, input_type=int]

My Creator 5 apparently doesn't have a heated-chamber temperature sensor, and the firmware returns a sentinel value like -108 for chamberTemp in the /detail response instead of a real temperature. The DetailResponse Pydantic model in ff-5mp-api-py has a ge=-50 constraint on chamberTemp, so this sentinel value fails validation, and the config flow's overall cannot_connect error hides this real cause.

This also means the config flow's generic cannot_connect message is currently swallowing validation errors — it would help future debugging (mine included) if validation errors were surfaced distinctly from actual network/auth failures.

Would it be possible to loosen the chamberTemp constraint (or treat out-of-range values as "no sensor" / None instead of raising), for printers without a heated chamber?

[GhostTypes]

No problem, thank you for the same! Not the ideal result but exactly why I added those logs!

I'll be doing some more work on the API and have a new version shortly to test

[GhostTypes]

I just updated to 1.3.4 , you should be able to complete setup properly and hopefully this is the last of the validation errors!
I removed all strict validation where it's not necessary or beneficial

[vahurvilta]

Thank you so much, working now!