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: