External integrations in Gladys Assistant

[pierre-gilles]

@cicoub13

Is it possible to have an ARM v8 build?

Here you go:

ghcr.io/gladysassistant/gladys-preview:claude-magical-turing-qhh7q2-arm64

[pierre-gilles]

@Will_71 Wouldn’t the Free Mobile integration become an external integration?

[Will_71]

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.

[pierre-gilles]

Lance Claude on the topic is really a 5-minute story in my opinion

[cicoub13]

External TP Link integration currently in development/testing (I need to work on the network discovery part)

GitHub - cicoub13/gladys-tp-link

[pierre-gilles]

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

[Terdious]

@pierre-gilles

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:

1. 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.

2. 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.

3. 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:

1. 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).

2. 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!

[Terdious]

Otherwise, I only have the documentation left to write, but the first two external integrations seem ready to be released ^^:

• gladys-zendure in v1.1.0

GitHub - Terdious/gladys-zendure: Gladys Assistant Integration template for a JS...

The update works great!!^^

• and gladys-tuya in v1.0.1:

GitHub - Terdious/gladys-tuya: Tuya external integration for Gladys Assistant...

[pierre-gilles]

Incredible, thanks for your feedback and these 2 integrations! To implement your feedback, it will probably be Thursday (I’m freelance today and tomorrow )

[Terdious]

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 ^^

[cicoub13]

@pierre-gilles

For the network scan, it’s in the SDK! It’s Gladys who performs the scan and provides the results to the integration.

Just give the SDK to Claude and he’ll do the job

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)?

[ArMour85]

@pierre-gilles

The real issue is to see what examples we provide and in which languages. Personally, I have no experience with Python, so I could potentially have an AI generate an example, but I wouldn’t really be able to review it, validate it, or effectively help users with it.

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

[pierre-gilles]

@cicoub13

Wouldn’t the Supervision section benefit from being in a separate section (outside of configuration)?

Why not, great idea!

@ArMour85

However, we need to wait for the stable version of the JS version first. Let’s not rush

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.

[Terdious]

@pierre-gilles

Netatmo is normally covered, there is a whole OAuth management.

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

@pierre-gilles

Frigate is also managed with a sub-container management.

Well, we’ll be able to work on it soon I think ^^ Weekend project surely!!^^

[pierre-gilles]

Amazing, these external integrations are really on fire

Ok, keep me posted on the latency story!