Gladys Assistant 4.84: External integrations are here 🚀

News
21

Example: Philips Hue Migration

1catalogdeprecatedbadges
1catalogdeprecatedbadges1280×860 124 KB

4migrationsuccess
4migrationsuccess1280×860 58.8 KB

2devicepagemigratebutton
2devicepagemigratebutton1280×860 54.9 KB

3migrationmodalmapping
3migrationmodalmapping1280×860 71.6 KB

22

Tested at home with Melcloud, and it works perfectly! I’ll merge.

23

Hello!

I ended up switching to HA for my part precisely because of that :man_shrugging:

With the latest newsletter, I realize you’ve backtracked to return to the principle of V3, which I don’t mind at all :face_with_tongue:

I’ll follow this a bit more closely to see how it evolves and surely set up an instance now.

Great job anyway!

24

Thanks @MathieuA, it’s really nice to read, and above all, I’m glad to see you back on the forum! :grinning_face_with_smiling_eyes:

In principle, yes. However, technically, the implementation has little in common with that of V3. This time, we have complete isolation between Gladys and each integration, with real decoupling. Dependencies are installed at build time, not at runtime as was the case in V3.

In the end, we get the simplicity and freedom of V3, while maintaining a much more robust architecture. In short, the best of both worlds!

25

Will we see @VonOx’s return too? :eyes: :grin:

That would be crazy!!

26

I’d love that!!

Welcome back @MathieuA,

At the beginning of Gladys V4, I read a lot of your posts! Also in the archives of the design of Gladys V4 with your exchanges, you, the « old-timers Â» of Gladys!!

It’s a pleasure to see minds like yours (and I hope others) passing through here again.

27

Hello super new :slight_smile:

The best of both worlds v3 v4 :star_struck:

Only issue:

2026-08-01T22:49:50+0200 <warn> errorMiddleware.js:71 (errorMiddleware) Error: (HTTP code 400) unexpected - NanoCPUs can not be set, as your kernel does not support CPU CFS scheduler or the cgroup is not mounted
    at /src/server/node_modules/docker-modem/lib/modem.js:336:17
    at getCause (/src/server/node_modules/docker-modem/lib/modem.js:366:7)
    at Modem.buildPayload (/src/server/node_modules/docker-modem/lib/modem.js:335:5)
    at IncomingMessage.<anonymous> (/src/server/node_modules/docker-modem/lib/modem.js:303:16)
    at IncomingMessage.emit (node:events:531:35)
    at endReadableNT (node:internal/streams/readable:1698:12)
    at processTicksAndRejections (node:internal/process/task_queues:89:21) {
  reason: undefined,
  statusCode: 400,
  json: {
    message: 'NanoCPUs can not be set, as your kernel does not support CPU CFS scheduler or the cgroup is not mounted'
  }
}

I’m on a Synology NAS 920+

28

A follow-up on the /data directory for Docker images of external extensions:

The VOLUME [« /data Â»] leaves the directory owned by root, while the container runs as node (uid 1000): the integration had no write access to the only location that the Dockerfile documents as writable.

Claude adds lines in the Dockerfile to work around this issue. Can we fix this in the template?

29

I found the source of the problem: on Synology NAS devices, the kernel is compiled without the
« CFS bandwidth control Â», which is the mechanism that allows Docker to limit the CPU of a
container. So when Gladys asked Docker to create the container for
integration with a CPU limit, Docker refused with the error « NanoCPUs can not be set Â»
and the installation failed.

The fix: Gladys now asks Docker if it can handle CPU limits at
startup, and if not, it simply does not send this limit.
The other limits (memory, number of processes, log size) remain in place
in all cases. On your NAS, integrations will therefore run without a CPU limit,
this is the standard workaround for this type of kernel.

Too bad for Synology users who will be a bit less protected than others, but well, that’s how it is :slight_smile:

Hi, thanks for the feedback, it was a real bug! :folded_hands:

Good news: the cause was not in your image, but on Gladys’ side. The /data is mounted as a bind mount from the host, and as the folder did not exist before the container was created, Docker created it itself as root:root, so the integration (which runs as node, uid 1000) could not write anything to it. That’s also why the workarounds in the Dockerfile could not work: a bind mount completely masks the contents of the image, so a chown done at build has no effect.

The fix is in this PR: Fix /data ownership of external integration containers by Pierre-Gilles · Pull Request #2743 · GladysAssistant/Gladys · GitHub. Gladys now creates the folder and gives it to the uid 1000 before creating the container (including the volumes of sub-containers for multi-container integrations). And it’s backward compatible: existing installations will repair themselves at the next container recreation (update, restart
), without any changes.

As soon as it’s published, you can delete the workaround lines from your Dockerfile: the official template documents /data as the only writable location, and it will be true without any tinkering. :blush:

30

I find that simply amazing :flexed_biceps:

For the Syno, we can set a priority on containers, and it’s interesting how sub-containers can’t be limited in CPU.
I should test it on zimaOS to see if the behavior is the same.

31

Thanks for your feedback! :ok_hand:

32

Both pull requests are merged into master and will go out today in another patch release! Thanks for your tests and feedback!

33

The fixes are live on Gladys Assistant 4.84.2:

34

Super good news. I’m on Home Assistant precisely because I use a lot of products that are not (or were not) recognized under Gladys, but I’m also on Gladys because the project really appeals to me. I regularly check (I have Gladys in test on a Rasp in addition to my HA) and I had the pleasant discovery that Airzone cloud is recognized.

However, I don’t understand: I have an Airzone with 5 rooms and a TADO that allows me to control a separate Hitachi air conditioner (non-Airzone).

When I integrated it into Gladys, it found everything. However, it only gives me the temperature of my veranda (TADO air conditioner) and my living room (room where my main Airzone zone is located). It finds my other 4 Airzone rooms but says « no temperature recorded recently Â». I’m not sure where to look.

Thanks for your help if any of you have an Airzone.

35

Hi @filbou40, glad to see you on Gladys!

Can you create a specific topic for Airzone in Configuration, and tag @Lokkye who is the developer of this integration :wink:

36

An idea to improve the tracking of external apps: a category with subcategories for each integrated external app. This would allow bug reports and make it more readable, and each developer could follow their own development without having to tag and therefore know who developed the external app.

Otherwise, we would need to switch to a bug tracker that can be linked to GitHub.

ex: a project would be an external app and each developer would be informed as soon as someone reports a bug in their project. A common mini lifecycle for a bug in an external app would need to be created. Even if it’s a bug tracker, we can also allow feature requests to be submitted.

The forum here would be more for the core Gladys or development requests for external apps

37

It’s done. I don’t know if I did it correctly (especially with the tag). Don’t hesitate to tell me if I messed up :wink:

38

I admit, that seems a bit heavy, and in itself, it’s the same issue as now, how do you know which account on the forum corresponds to the account on GitHub?

That’s already possible right now, it is possible to create an issue on the external integration repo, and at least the maintainer receives a notification via GitHub! It’s true that this might be the simplest way to communicate directly with the maintainer, but it requires having a GitHub account :slight_smile:

Perfect, thanks @filbou40!

39

Hello,
I just realized that we don’t have tags for external integrations apart from Community.
Is this intentional?

image
image897×809 127 KB

40

Well spotted @mutmut, that wasn’t intentional :sweat_smile:

The tags for the catalog cards (Local, Cloud, Gladys Plus
) are set based on the information from each integration, and for external integrations, I only display « Community Â», the status badge, and « update available Â» today.

The stupidest part is that the information already exists: the manifest of an external integration must declare its transports (local, cloud, or both), which is used for the « prefer local connection Â» setting and the Local/Cloud badges on each device. I just don’t use it yet on the catalog card.

I’ll take a look!