Here you go:
ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2-arm64
@Will_71 Wouldn’t the Free Mobile integration become an external integration? 
Yes, absolutely. After that, I need to see how all this works. I had the thought over the weekend but didn’t have time to look into it further.
Lance Claude on the topic is really a 5-minute story in my opinion 
External TP Link integration currently in development/testing (I need to work on the network discovery part)
For the network scan, it’s in the SDK! It’s Gladys that performs the scan and provides the results to the integration.
Just give the SDK to Claude and he’ll do the job 
That side is too easy with Claude ^^
Hi @pierre-gilles,
UX feedback after putting the transport model + actions into service on gladys-tuya (by the way: the local/cloud badges, the GLADYS_PREFER_LOCAL toggle, the upsert of params, and the detect_protocol action all work perfectly in real life — bravo, it’s a game-changer).
The remaining difficulty is the DEVICE-SIDE READABILITY. Scenario experienced by a regular user: two devices display a « Cloud » badge while the local mode is enabled. Why? One wasn’t found by the UDP scan (no IP), the other refuses local sessions. Impossible to know from the device card: it only displays Name / Room / Features (DeviceBox.jsx doesn’t render any param outside the GLADYS_TRANSPORT badge).
Three requests, in order of priority:
-
Display « useful » params on the device card of an external integration — at least in read-only mode (IP_ADDRESS, PROTOCOL_VERSION), ideally with the IP being editable. Without this, the user can neither diagnose nor take action. Suggestion: a list of param keys to expose, declared in the manifest (e.g., « device_params_display »: [« IP_ADDRESS », « PROTOCOL_VERSION »]), with an « editable » flag per key — editing would go through the existing param upsert.
-
DEVICE-SPECIFIC ACTIONS: today, the actions from the manifest are only rendered in the Configuration screen (ActionsCard.jsx), at the integration level.
To « detect the local protocol, » the right place is the card of the concerned device: a « scope »: « device » flag on the action, rendered as a button on each card, with the device’s external_id injected into the fields transmitted to the integration. This would avoid asking the user to copy an identifier. -
Failing that (or as a complement), a DYNAMIC SOURCE for the select fields of actions: today, ConfigSchemaForm.jsx only renders static options from the manifest. A field
{ "type": "select", "source": "devices" }listing the devices created by the integration (label = name, value = external_id) would solve 90% of the need with minimal front-end changes.
In the meantime, we’ve put a workaround on the integration side: the action field accepts the NAME of the device as displayed in Gladys (or the Tuya ID). It’s a temporary fix, but it’s still free-form input with the risks of homonyms.
Additional note on transport badges — a « degraded » state (orange)
By using the local/cloud badges in real life, we encounter a case that the current three states (local / cloud / unreachable) cannot express: the device WORKS, but not as it should.
Concrete case experienced: a device is correctly identified by the local UDP scan (IP and protocol version known, local mode enabled), but it returns errors or timeouts on local reads. Our integration then falls back to cloud: the user sees a blue « Cloud » badge, perfectly normal in appearance… when in reality something is wrong (device refusing local sessions, rotated local key, another local client holding the connection, etc.). Nothing invites them to investigate.
The request: a « degraded » state (orange badge), orthogonal to the actual transport. Two modeling options, your choice:
- A separate health field in publishTransports, to avoid polluting the transport semantics:
[{ "external_id": "...",
"transport": "cloud",
"health": "degraded",
"reason": {
"en": "LAN found but local polls fail — using cloud",
"fr": "Seen in LAN but local read failures — cloud fallback",
"de": "Observed in LAN but local read errors – cloud fallback"
}
}]
→ the badge displays the transport, the orange signals the degradation, and the
reason is displayed in a tooltip / on click. This is my favorite: « degraded »
remains true regardless of the transport (a slow cloud or a local one losing frames are also degraded).
- At minimum, a « degraded » value added to the transport enum — less rich (we lose the info about the actually used transport), but trivial to add.
On the integration side, we already have everything to report this properly: our local circuit-breaker knows exactly when a LAN-capable device is parked on the cloud after N failures, with the reason. We just lack the channel to express it to the user.
And beyond this specific case, it provides a generic vocabulary for all « it works but poorly » scenarios: expiring cloud token, device responding one out of two times, sub-container in crash-loop but fallback active, etc.
Thanks!
Incredible, thanks for your feedback and these 2 integrations! To implement your feedback, it will probably be Thursday (I’m freelance today and tomorrow 
)
Yes yes I know, that’s why we’ve worked around it in the meantime, it remains functional after all 
!!!
Thank you for everything 
, this major evolution is a turning point for Gladys I think. Even if, but I don’t have too many illusions about you now knowing the quality, as @cicoub13 rightly pointed out, the next steps won’t necessarily be easy either to maintain a high quality and image for Gladys !!!
Come on!! Go to work me too ^^
Yes, that’s what I did, but the proposal needs to be reviewed (IP to be entered by the user and fallback on network scan). I would like it to be simpler and therefore understand what is really possible with the scan (I will reread the documentation).
Wouldn’t the Supervision section benefit from being in a separate part (outside of configuration)?
If you generate an example with Fable, I could review it.
I had explained the idea of a validation server for the SDK. You won’t need to validate if the SDK passes all the validation server’s tests. The developer can also do this locally. This will also allow for multiplying external SDKs. I think that officially supporting JS and Python covers 90% of needs and developers. Moreover, Python is used by HA and by extension, we have a lot of integrations that we can more easily port. However, we need to wait for the stable version of the JS version first. Let’s not rush
Why not, great idea!
Yes, I agree. I’d like to have a first production release in full JS, as well as a sufficiently mature JS SDK, before proposing a Python SDK.
However, once the JS SDK is stabilized and requires less evolution and maintenance from me, I’d be totally on board to port it to Python.
Well, it seems to work well all that ^^ OAuth perfect from the first try.
Image and video stream perfect!
But I don’t have sound on the video streams and stream delayed by 10/15s => Research tomorrow
Well, we’ll be able to work on it soon I think ^^ Weekend project surely!!^^
Amazing, these external integrations are really on fire
Ok, keep me posted on the latency story!
After discussing with Fable:
The three feedback points address real needs, but I wouldn’t take them all as-is. My point-by-point opinion:
1. Actions per device (scope: "device") — I would postpone this. The need is legitimate (not making the user copy an external_id), but the proposed solution opens a UI Pandora’s box: buttons declared by the manifest that inject themselves into device cards is exactly the kind of surface we wanted to avoid (requirement #3 of the framework: consistent UI, no rendering controlled by integrations beyond generated forms). And it raises questions without a good answer in v1: on which card? Only the Devices screen of the integration, or the dashboard? What to do when an integration declares 5 device actions × 40 devices? The developer himself says that the dynamic source covers 90% of the need. The remaining 10% (one click saved compared to a select) do not justify this complexity now. Candidate for phase 2 if usage demands it, not v1.
2. Dynamic source for selects ("source": "devices") — yes, frankly. This is the right solution to the same problem: small, generic, consistent with the existing config_schema, and the rendering remains 100% controlled by the core (label = device name, value = external_id, filtered by the service_id of the integration — zero leakage between tenants). Two safeguards to put in the spec: source is a reserved enum defined by the core (v1: only devices), not a URL or an expression — we don’t open a mechanism for injecting arbitrary data; and source is exclusive with static options. It works for the fields of actions[] and, for free, for the installation config_schema as well.
3. « Degraded » state — the need is real, but not as a 4th value of the enum. The described case (the device works in the cloud when it should be local) is generic, not tuya-specific, and the blue badge « all is well » that masks a problem is a real observability hole. However, adding degraded to GLADYS_TRANSPORT mixes two orthogonal axes: which transport is used and is it the nominal state. With a 4-value enum, the user who sees « Degraded » loses the info « it is in the cloud right now » — which is exactly what helps them understand. My proposal: keep local|cloud|unreachable as the transport value, and enrich the same endpoint POST /device/transport with two optional fields per entry: degraded: true and a multilingual message (e.g., « Local detected but sessions refused, switching to cloud »). Rendering: the badge keeps its transport color/label with an orange border or dot, tooltip = the message; the global counter on the Devices screen gains a line « n degraded(s) ». We keep both pieces of information instead of overwriting one.
In summary: I take the 2 as-is (with reserved enum), the 3 remodeled as an orthogonal degraded flag + message rather than as a 4th state, and I postpone the 1 to phase 2 since the 2 covers most of the need. If that works for you, I’ll write these two additions in the spec.
I’m rather in agreement with him!
I totally agree with that, and as mentioned for point 1, it works without it, it’s « just » possible improvement, to discuss and take the time 
It’s much better 
New version of the SDK, v0.7.0 with new features for @Terdious and @cicoub13:
- feat: degraded transport state and dynamic select source « devices » (spec update) by @Pierre-Gilles in #11
- feat: active broadcast network scan
udp-active-broadcast(spec B.16 update) by @Pierre-Gilles in #12