External integration - Vigieau

[prohand]

The bug is fixed
I found another bug at the same time, basically when you update the address, it creates a new device instead of updating the existing one
Claude is on the subject
I’ll do a release when these 2 bugs are fixed

[prohand]

Version 1.2.0 is out and fixes 2 bugs
It should be available within 1 hour
If you’re impatient, you can click on « Force Update »:

Let me know when you’ve been able to update

[mutmut]

@prohand

Basically, now we no longer have to enter the INSEE code but the address

Is it not possible to retrieve the « location » of the Maison from Gladys?
Okay, if we have two, how would it work? → we choose the location via a selector

[Chris75]

@mutmut

Well if we have 2, how would it work? → we choose the location via a selector

On my side, I also have 2 locations to monitor?

[prohand]

That’s exactly the idea I had a few minutes ago
I’m going to ask Claude to add a button to retrieve the location directly in Gladys and inject the coordinates

And then be able to create multiple locations with a selector in the configuration

Edit: Once this integration is well completed, I’ll be able to do the same for pollen, air quality, and the UV index, each with a specific integration

[prohand]

For the part about retrieving the coordinates directly in Gladys, here’s what the AI responded:

1 & 2. Retrieving the location of the Gladys house — impossible, and there's no workaround

I cloned Gladys' core to verify rather than assume. The house does have coordinates (server/models/house.js: latitude/longitude), but nothing exposes them to an integration container:

    The host API for integrations (/api/integration/v1/*) has exactly 21 routes (server/api/routes.js) — none concern the house. getConfig() only returns the integration's own config.
    GET /api/v1/house is authenticated: true, so a user JWT: session.validateAccessToken requires audience: 'user', whereas an integration token has audience: 'integration'. The middleware states this explicitly — the two audiences never intersect.
    Detour via getDevices(): the response does include room, but getStandardDeviceIncludes() does not nest the house — the room only has a house_id, without coordinates.

The requested button would therefore require a PR on the core (a GET route /api/integration/v1/house + an SDK method). I haven't implemented anything on this side, and I've recorded the finding in CLAUDE.md so it's not re-taught.

I don’t know if @pierre-gilles can make the modification directly in the core

For the part about creating multiple locations, I’ll test this evening and will likely push a 2.0.0 if the tests are conclusive.

[prohand]

I had a bug on version 2.0.0-test that I fixed in 2.0.1-test

However, I no longer have a dropdown list for choosing locations that I had in 2.0.1-test
I also no longer have a token and the next reset is at 00:00, so I’ll continue later

[prohand]

I’m going to start again from 1.2.0 for v2 with multi-location management
I had a few small problems when I had Claude work on the first version of v3
I’ll keep you posted when it’s released

[prohand]

V2 is available with multi-location management
I couldn’t make each one display, so I did my best like in the screenshot:

Here’s the reason given by claude:

Why one location per line is impossible

The line break is sent — a real \n — and we see it in the container logs. It’s the Gladys configuration screen that consumes it, for three cumulative reasons:

1. ActionsCard.jsx renders the response as <div class="alert alert-success">{getLocalizedText(...)}</div>: a React text child. All markup is escaped, so neither <br> nor <pre> are possible.
2. In HTML, a \n in text is a space, unless the CSS says white-space: pre-wrap. Neither Gladys’ CSS nor Tabler’s .alert set it (the only pre-wrap in the entire external integrations front is on the LOGS page).
3. The Unicode separators U+2028 / U+2029, which the CSS spec presents as forced line breaks, have been measured in Chromium: they are also collapsed.

Verified at tag v4.84.4 and on master. There’s therefore nothing else to send: the fix is a one-line CSS rule in the heart of Gladys, not something this integration can deliver. Hence the « • » that opens each entry: it’s what keeps the list readable once everything is crushed on one line — a bare number gets lost between a postal code and two coordinates, a « • » cannot appear in an address.

[prohand]

I created 2 feature requests to improve the integration :

Retrieve the coordinates of the house configured in the Gladys core

Hello, When developing the vigieau integration, it would have been interesting to retrieve the coordinates of the house that we configured in Gladys. Here is claude’s feedback on the subject: 1 & 2. Retrieving Gladys house location — impossible, and there's no workaround I cloned the core of Gladys to verify rather than assume. The house does have coordinates (server/models/house.js: latitude/longitude), but nothing exposes them to an integration container: The integration host API (/ap…

Line breaks when displaying information in an external integration

It would be necessary to be able to make line breaks when displaying information in an external integration Here is claude’s feedback on the vigieau integration for example: Why one line per location is impossible The line break is sent — a real \n — and we can see it in the container logs. It’s Gladys’s configuration screen that eats it, for three cumulative reasons: ActionsCard.jsx renders the response as <div class="alert alert-success">{getLocalizedText(...)}</div>: a React text child. A…

[spenceur]

Dumb question but why don’t you retrieve the location of the house that Gladys already knows?
If I’m not mistaken, we provided her with the location, so Gladys should already have the latitude and longitude of the house, right?

Ah, I saw that it was mentioned after my mistake of not reading everything ^^’