Camera switch permanently unavailable on Creator 5 Pro (availability gated on is_pro instead of is_creator5_pro)

[bberrevoets]

Summary

On a Creator 5 Pro (PID 41), switch.<printer>_camera is permanently unavailable. The camera entity works fine — only the switch that toggles the stream is dead.

The camera switch's availability is gated on client.is_pro, which means Adventurer 5M Pro, not "any Pro model":

https://github.com/GhostTypes/ff-5mp-hass/blob/main/custom_components/flashforge/switch.py#L52

FlashForgeSwitchEntityDescription(
    key="camera",
    ...
    availability_fn=lambda client: client.is_pro,   # <-- never true on a Creator 5 Pro
),

Everywhere else the codebase carefully distinguishes the two. select.py gates the very same "Pro-only feature" concept correctly:

# select.py
availability_fn=lambda data: bool(
    getattr(data, "is_pro", False) or getattr(data, "is_creator5_pro", False)
),

and sensor.py does the same in _has_air_quality(). So this looks like a single spot that was missed rather than a deliberate restriction.

Suggested fix

availability_fn=lambda client: bool(
    getattr(client, "is_pro", False) or getattr(client, "is_creator5_pro", False)
),

Note the switch platform passes the client to availability_fn (unlike select.py/sensor.py, which pass the coordinator data), so the fix belongs on the client attributes.

Environment

• Printer: FlashForge Creator 5 Pro, firmware 1.9.4
• Integration: v1.3.0, LAN mode, local HTTP API
• Home Assistant: 2026.7

The printer does report a camera and gives a working stream URL:

// POST /detail
"camera": 1,
"cameraStreamUrl": "http://<ip>:8080/?action=stream"

and camera.<printer>_camera streams correctly (MJPEG, confirmed serving real frames). Only the toggle is affected.

Possibly related: the LED switch

On the same printer the LED switch also comes up unavailable unless the "Override LED availability" option is enabled — even though /product explicitly reports light control as present:

// POST /product
{ "lightCtrlState": 1, "chamberTempCtrlState": 1, "nozzleTempCtrlState": 1, "platformTempCtrlState": 1,
  "internalFanCtrlState": 0, "externalFanCtrlState": 0 }

So client.led_control appears not to reflect lightCtrlState on this model. With the override enabled the switch works correctly end-to-end (verified: toggling from HA flips the printer's own lightStatus open → close → open). Might be worth deriving led_control from lightCtrlState so the override isn't needed here — happy to open a separate issue if you'd prefer.

Thanks for the integration — the Creator 5 Pro support (per-tool temps, chamber, TVOC) is otherwise spot on.

[GhostTypes]

Thank you for the detailed report! The switch itself for the camera is not purposely restricted for the Creator 5 series, more so that the behavior is "not confirmed" on those models. I'll fix this restriction and just need to know whether it actually disables the stream or not.

The Creator 5 series lacks some controls previous models had, like filtration for example. The 5m pro allows full control of this in LAN-only mode, and while the Creator 5 has the same commands in the firmware, it doesn't actuate the fans anymore.

Regarding "Override LED availability" , while some printers do correctly report availability, the /product endpoint is unfortunately unreliable between the 5M series / AD5X / Creator 5 series. I will look into making this more seamless in future updates, so it's detected automatically from the printer model rather than needing an extra toggle

[GhostTypes]

Didn't intend for this to be automatically closed, you should be able to use the camera switch now 👍

Let me know if the printer actually starts/stops the stream, if it "does nothing" then unfortunately the Creator 5 API removed the ability

[bberrevoets]

Thanks for the quick fix — confirmed the switch is now available on the Creator 5 Pro (v1.3.1, firmware 1.9.4).

On your actual question: it does nothing — the Creator 5 API removed the ability, as you suspected. Tested on hardware:

• streamCtrl_cmd (action: close) returns {code:0,"Success"}, but the stream never stops. 22 s after turning the switch off, port 8080 is still open and still serving live MJPEG frames (sizes keep changing frame-to-frame, so it's genuinely live, not a cached still). cameraStreamUrl in /detail is unchanged throughout. Same result sending the raw command directly and via the HA switch.

One extra thing you may want to handle while you're in here: on the Creator 5 the switch also can't reflect an off state. is_on_fn is bool(camera_stream_url), and the printer always advertises that URL (the stream is always up), so after turn_off the next coordinator poll flips is_on straight back to on. Net effect on the Creator 5 Pro: the switch is both inert and un-toggleable.

Given the API genuinely can't gate the stream on this model, might be cleanest to not create the camera switch for the Creator 5 series at all (the camera entity itself works perfectly — live RTSP-equivalent MJPEG on :8080). Happy to test any change against the printer.

[GhostTypes]

No problem, thank you for the information!

At your convenience let me know how v1.3.3 works for you