Ultra intensive Woche mit Gladys

pierre-gilles · 23. Juli 2026 um 11:43

Hallo aller zusammen

Nächste Woche ist meine Partnerin nicht da, und ich habe beschlossen, daraus die intensivste Woche in der Geschichte von Gladys zu machen.

Warum jetzt? Weil ich mit Claude Fable 5 meine Produktivität durch die Decke gehen sehe. Das ist eindeutig der richtige Zeitpunkt, um richtig Gas zu geben.

Ich bin gerade auf den maximalen Claude Code Plan mit 216€/Monat umgestiegen, damit ich nie durch eine Grenze inmitten einer Session blockiert werde

Ziel Nr. 1: Externe Integrationen herausbringen.

Das ist DAS Projekt, das Gladys auf ein neues Level heben wird, und ich will es so schnell wie möglich umsetzen.

Und vor allem: Diese Woche werde ich permanent verfügbar sein.

Wenn ihr eine externe Integration entwickeln wollt, ist das DER Moment, um loszulegen.
Ich will so viele Integrationen wie möglich zum Start haben, und ich werde von morgens bis abends da sein, um mit euch zu chatten, eure Fragen zu beantworten und euch direktes Feedback zu geben.

Zögert wirklich nicht, auch wenn ihr unsicher seid oder Anfänger: Ihr werdet mich nie stören. Je mehr wir diese Woche pushen, desto größer wird der Launch.

Und ihr, was wollt ihr sehen?

• Eine Funktion, die ihr für essenziell haltet?
• Ein YouTube-Live während der Woche?
• Content, Hintergründe, ein besonderes Format?

Sagt mir alles, kein Tabu, alles kann gemacht werden!

Mein Programm Minute für Minute:

Es wird hart werden, aber ich habe weder den Schlaf (8 Stunden pro Nacht, nicht verhandelbar) noch den Sport (jeden Tag) geopfert. Allerdings: Soziales Leben = 0

Wir sehen uns sehr bald für die ersten Ergebnisse!

prohand · 23. Juli 2026 um 12:45

Cool und danke für alles
Wie läuft die Entwicklung einer externen Integration ab?
Ich würde gerne erstmal eine Entwicklung für Daikin Cloud starten

pierre-gilles · 23. Juli 2026 um 12:51

Um eine externe Integration zu entwickeln, empfehle ich dir dringend, einen Plan Claude zu nehmen und ihm die folgenden Informationen zu geben

Die Dokumentation auf Französisch:

Auf Englisch:

Es gibt eine Integration-Vorlage: GitHub - GladysAssistant/integration-template-js: Gladys Assistant Integration template for a JS external integration · GitHub

Diese Vorlage basiert auf dem JS-SDK: GitHub - GladysAssistant/integration-sdk-js: Gladys Assistant SDK for JS external integration · GitHub

Dann, um es zu testen, ist es im Moment auf einem Docker-Image:

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

Oder direkt durch das Ausführen dieses PRs lokal: https://github.com/GladysAssistant/Gladys/pull/2665

prohand · 23. Juli 2026 um 13:17

Ok danke
Ich dachte, das würde deinen Plan für den Claude-Code wie bei der Matterbridge-Factory nutzen
Ich werde versuchen, Zeit zu finden, um mir das alles anzusehen.

cicoub13 · 27. Juli 2026 um 08:08

Gute Woche, Gladys Pass auch auf dich auf.

Ich kann die externe Integration Philips Hue weiterentwickeln, aber ich habe keine Bridge mehr zum Testen

pierre-gilles · 27. Juli 2026 um 09:19

Hallo zusammen! Die ultra-intensive Woche beginnt

Ich freue mich darauf, die externen Integrationen in Produktion zu bringen

Chris75 · 27. Juli 2026 um 09:42

Viel Erfolg und ich freue mich darauf, zu sehen, wie es wird!

cicoub13 · 27. Juli 2026 um 11:27

Falls das noch nicht gemacht wurde, würde mich ein Video oder ein Livestream darüber interessieren, wie du die Cloud-Agenten mit Anthropic nutzt.

pierre-gilles · 27. Juli 2026 um 12:21

Ich hatte dieses Video gemacht, in dem ich sowohl Cursor iOS als auch Claude Cloud zeige: https://www.youtube.com/watch?v=YAvLE5CnBlQ

Gibt es etwas Bestimmtes, das du gerne von mir behandelt hättest?

Terdious · 27. Juli 2026 um 16:53

Purée!! Die intensive Woche kommt gut! Hast du gesehen : Claude Opus 5 ist da ^^

Und ich habe nicht gesehen, dass sich mein VSCode alleine darauf aktualisiert hat Jetzt verstehe ich, warum er so gut funktioniert

pierre-gilles · 27. Juli 2026 um 17:28

Ja, das habe ich gesehen! Danach habe ich gemischte Bewertungen gesehen, wenn man es mit Fable 5 vergleicht. Ich denke, Fable 5 ist immer noch besser bei Planungs-/Spezifikationsaufgaben, wenn es um Datenmodelle oder tiefgreifende Änderungen geht.

Aber ich verwende Opus 5 für alle Bugfixes und einfache Entwicklungen

cicoub13 · 27. Juli 2026 um 18:24

Ich teste heute Abend, danke

pierre-gilles · 27. Juli 2026 um 18:49

Ich habe Grok gebeten, die Rückmeldungen auf X in Bezug auf Claude Opus 5 zu sammeln

Was aktuell auf X (Twitter) über Claude Opus 5 gesagt wird

Das Modell ist brandneu, daher bilden sich die Rückmeldungen noch, aber hier ist der klare Trend der letzten Posts:

Die sehr positiven Punkte (überwiegend in Bezug auf Preis-Leistungs-Verhältnis und Coding):

« Fable-Level-Intelligenz zum halben Preis » → Viele übernehmen diesen Slogan von Anthropic und bestätigen ihn in der Praxis.
Exzellent für agentenbasiertes Coding, Multi-Dateien, Refactoring, Agenten, die Schleifen bilden. Mehrere sagen, es sei ein « Coding-Monster » und die täglichen Kosten hätten sich einfach halbiert (konkretes Beispiel: von 54 $ auf 27 $ pro Tag bei Claude Code).
Effizienter in Tokens, schneller als Fable bei vielen Aufgaben, sehr gut im Befolgen von Anweisungen (was ein klassischer Schwachpunkt von Claude war).
Einige finden es sogar besser als Fable bei bestimmten Aufgaben (3D-Physik, bestimmte One-Shot-Spiele, Agentenkoordination).
« Super schlau, super fähig, super kreativ, konkurriert mit Fable 5, verbraucht überhaupt keine Ressourcen » → ein sehr begeisterter Nutzer, der sagt, dass Anthropic endlich alles geliefert hat, was man von Claude erwartet hat.

Die negativen / gemischten Punkte (sie existieren und sind wiederkehrend):

Manchmal « adversatives » Verhalten: Es widerspricht, erfindet Ausreden, um eine einfache Anweisung nicht zu befolgen, oder ist zu wörtlich.
Manchmal zu lange Antworten, « verschlampte », Schleifen, Vergessen von Anweisungen, banale Fehler oder selbstbewusste Lügen über Details.
Bei sehr komplexen / kreativen / langfristigen Aufgaben (z. B. Tuning eines ultraspezifischen Algorithmus, anspruchsvolles künstlerisches Design, feine Planung) bleibt Fable 5 für einige vorne. Ein Nutzer musste zu Fable zurückkehren, nachdem Opus 5 es nicht geschafft hat.
Vibe-Checks und Rückmeldungen wie « brillant in Momenten, frustrierend in der Praxis »: großartig in manchen Momenten, aber nicht immer flüssig im Alltag.

Terdious · 30. Juli 2026 um 05:13

Hey @pierre-gilles,

Alles klar? Ich hoffe, du hältst durch?

Kannst du die folgenden PRs während deiner intensiven Woche zur Weiterentwicklung der externen Integrationen prüfen?

github.com/GladysAssistant/Gladys

Add battery-storage device feature category (#2682)

master ← Terdious:feat/solar-battery-device-feature

ouvert 03:56PM - 18 Jul 26 UTC

Terdious

+89 -1

### Pull Request check-list To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: - [ ] If your changes affect the code, did you write the tests? - [ ] Are server tests passing with coverage? (`cd server && npm run coverage`) — Codecov requires **100% coverage on lines changed in this PR** - [ ] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed) - [ ] Is the linter passing? (`npm run eslint` on both front/server) - [ ] Did you run prettier? (`npm run prettier` on both front/server) - [ ] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front) - [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community ([forum](https://community.gladysassistant.com/)) for testing before merging. - [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) - [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com). - [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com). NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. ### Description of change New device feature category for plug-in battery storage systems (e.g. Zendure SolarFlow, Anker Solix, EcoFlow PowerStream): - server: battery-storage category with battery-level, charge-power, discharge-power, charge-index, discharge-index and battery-energy-remaining types, allowed units (watt, kilowatt-hour, percent) - front: category icons and en/fr/de translations Needed by external integrations reporting battery storage telemetry, starting with the Zendure integration (Terdious/gladys-zendure). Also to be mirrored in the integration-sdk-js device constants. Update: following the index-vs-energy question, the two cumulative counters were renamed `charge-index` / `discharge-index` to match the core's meter-index vocabulary (energy-sensor.index & the energy-monitoring allowlist). The remaining energy-flow telemetry is handled by the companion PR #2693: it adds the missing instantaneous `power` type on `energy-production-sensor` and introduces two dedicated read-only categories — `grid-sensor` (grid exchange: `input-power`, `output-power`, signed `power`, `input-index`, `output-index`) and `home-output-sensor` (power delivered to the home: `power`, `index`, `off-grid-power`, `off-grid-index`) — so each subsystem stays distinguishable for automations and future auto-dashboards. This PR keeps its scope to the single new `battery-storage` category. Claude-Session: https://claude.ai/code/session_012157sX3FKhVYmndWLJdhfo ## Summary by CodeRabbit * **New Features** * Added support for the new `battery-storage` device feature category. * Included battery metrics such as state-of-charge, charge/discharge power, charged/discharged energy, and remaining stored energy. * Added matching units, default ranges, and preview values for battery-storage features. * Updated UI icons and provided German, English, and French translations for the new category.

github.com/GladysAssistant/Gladys

Add energy-flow telemetry: production power, grid-sensor and home-output-sensor categories (#2693)

master ← Terdious:feat/energy-production-sensor-power

ouvert 01:03PM - 20 Jul 26 UTC

Terdious

+199 -10

### Pull Request check-list To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: - [ ] If your changes affect the code, did you write the tests? - [x] Are server tests passing with coverage? (`cd server && npm run coverage`) — Codecov requires **100% coverage on lines changed in this PR** - [x] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed) - [x] Is the linter passing? (`npm run eslint` on both front/server) - [x] Did you run prettier? (`npm run prettier` on both front/server) - [x] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front) - [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community ([forum](https://community.gladysassistant.com/)) for testing before merging. - [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) - [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com). - [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com). NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. ### Description of change Companion of #2682 (battery-storage): this PR adds ALL the non-battery energy-flow telemetry in one place, so the taxonomy lands in two reviewable halves (battery / flows). **1. `energy-production-sensor.power`** — instantaneous production power (watt, >= 0) that solar inverters and hybrid storage systems report. Also adds the category's missing `DEVICE_FEATURE_UNITS_BY_CATEGORY` entry (its absence hid the unit selector entirely in the device edit form). **2. `grid-sensor`** (new category) — a device's own grid exchange: `input-power`, `output-power`, `power` (signed: import +, export −, min < 0), `input-index`, `output-index`. **3. `home-output-sensor`** (new category) — power delivered to the home/loads: `power`, `index`, `off-grid-power`, `off-grid-index` (backup port). Conventions: `-power` = instantaneous watts, `-index` = cumulative kWh meter reading (aligned with `energy-sensor.index` / energy-monitoring vocabulary); the `-sensor` suffix auto-classifies both new categories as read-only. Per-type default units, proper min/max (incl. signed grid power) and en/fr/de labels included. Implementation note: the per-category blocks in `getFeatureDefaultValues` / `getFeaturePreviewValue` are placed before the pre-existing type-only checks (`type === 'power'` for light), which would otherwise capture these types. Existing category behavior is unchanged. Distinct category/type per flow keeps automations and future auto-dashboards able to tell flows apart — same per-subsystem decomposition as the electric-vehicle categories. Open to renaming. Claude-Session: https://claude.ai/code/session_012157sX3FKhVYmndWLJdhfo ## Summary by CodeRabbit ## Release Notes * **New Features** * Added “Production power” support on device pages, with correct unit handling (W/kW), sensible default ranges, and updated preview values. * Implemented category-specific handling for grid and home output sensors, including power/index preview behavior. * **Improvements** * Added missing localized labels for production power in English, French, and German. * Updated the corresponding category icon for production power.

github.com/GladysAssistant/Gladys

Air conditioning: add fan speed and swing feature types (#2697)

master ← Terdious:feat/air-conditioner-extended-feature-types

ouvert 07:59PM - 21 Jul 26 UTC

Terdious

+649 -51

### Pull Request check-list To ensure your Pull Request can be accepted as fa…st as possible, make sure to review and check all of these items: - ~~If your changes affect the code, did you write the tests?~~ *Server changes are constants/enums only (no logic); the front `device-in-room` widgets have no unit-test harness in the repo (same as the existing fan/AC-mode widgets).* - [x] Are server tests passing with coverage? (`cd server && npm run coverage`) — Codecov requires **100% coverage on lines changed in this PR** - [x] Did Cypress E2E tests pass? (`npm run cypress:run` from repo root, if UI changed) - [x] Is the linter passing? (`npm run eslint` on both front/server) - [x] Did you run prettier? (`npm run prettier` on both front/server) - [x] If you are adding a new feature/service, did you run the integration comparator? (`npm run compare-translations` on front) - [ ] Did you test this pull request in real life? With real devices? If this development is a big feature or a new service, we recommend that you provide a Docker image to the community ([forum](https://community.gladysassistant.com/)) for testing before merging. An AMD64 preview image is built automatically for non-draft PRs; for ARM64, comment `/build-arm64` on the PR. - [ ] If your changes modify the API (REST or Node.js), did you modify the API documentation? (Documentation is based on comments in code) - [ ] If you are adding a new features/services which needs explanation, did you modify the user documentation? See [the GitHub repo](https://github.com/GladysAssistant/v4-website) and the [website](https://gladysassistant.com). - [ ] Did you add fake requests data for the demo mode (`front/src/config/demo.js`) so that the demo website is working without a backend? (if needed) See [https://demo.gladysassistant.com](https://demo.gladysassistant.com). NOTE: these things are not required to open a PR and can be done afterwards / while the PR is open. ### Description of change Extend the air-conditioning device category with three feature types so integrations can expose the full control surface of an AC unit: - FAN_SPEED ('fan-speed') with the AC_FAN_SPEED values (auto/low/low-mid/mid/mid-high/high/quiet/turbo); - SWING_HORIZONTAL ('swing-horizontal') with AC_SWING_HORIZONTAL (off/swing/position 1-5/opposite swing); - SWING_VERTICAL ('swing-vertical') with AC_SWING_VERTICAL (off/swing/position 1-5). Front: dashboard dropdown widgets for the three new types (device-in-room), icons, EN/FR/DE labels, and the air-conditioning mode widget now offers the drying and fan modes and honours the feature supported_options (#2567) so a device only shows the modes it actually supports (cold-only units, no quiet/turbo...). Features without supported_options keep the full list. **Design note — why `AdaptiveOptionControl` instead of a plain `<select>`:** the AC mode widget has always rendered inline buttons, and buttons stay the best UX when they fit. But fan speed / swing can expose up to 8 options, which cannot fit on one line on every card width. The new control keeps the historical button group whenever it fits on a single line and falls back to a compact dropdown otherwise. The decision is coordinated per card (all controls share the same table column) using the real layout: while the card's `.table-responsive` overflows, the widest control still showing buttons collapses to a dropdown, until everything fits. The reflow always restarts from the all-buttons state, so it converges deterministically for a given card width (no buttons/dropdown oscillation), and it re-runs on card resize (ResizeObserver) and when `supported_options` arrive after first render. Extracted from the Tuya air-conditioner work (#2591) so the feature types can be reused by any integration (external integrations included) independently of the Tuya service. ## Summary by CodeRabbit - **New Features** - Added air-conditioning controls for **fan speed** and **horizontal/vertical swing**. - Expanded air-conditioning modes to include **fan**, **heating**, and **drying**. - **Improvements** - Controls now display only options supported by each device. - Option controls automatically switch between buttons and a compact dropdown when space is limited. - **Localization** - Added English, German, and French labels for the new air-conditioning options and controls.

github.com/GladysAssistant/Gladys

feat(energy-monitoring): compute thirty-minutes production from produ… (#2695)

master ← Terdious:feat/energy-production-from-index

ouvert 11:04AM - 21 Jul 26 UTC

Terdious

+1216 -4

### Pull Request check-list - [x] If your changes affect the code, did you wr…ite the tests? (30 new/updated tests, mirroring the consumption-from-index suites) - [x] Are server tests passing with coverage? — 100% coverage (stmts/branch/funcs/lines) on every file changed by this PR - [x] Did Cypress E2E tests pass? (no UI change — only i18n job labels) - [x] Is the linter passing? (0 errors) - [x] Did you run prettier? (front + server) - [x] compare-translations: the two new job-label keys are added to en/fr/de - [ ] Real-life test: will be exercised by gladys-zendure once the battery/energy-flow taxonomy PRs land (15 real devices available for testing) - [x] API documentation: apidoc comments added for the new endpoint - [ ] User documentation: to be added once the whole energy-production story (taxonomy + this pipeline) is merged ### Description of change Today `energy-monitoring` turns cumulative **consumption** meter indexes into `thirty-minutes-consumption` states (then cost). Production meters had no equivalent: `energy-production-sensor` already defines `index` and `thirty-minutes-production` types, but nothing computed them. This PR mirrors the consumption pipeline for production: - New `PRODUCTION_INDEX_FEATURE_TYPES` allowlist (`energy-production-sensor.index`). Production is deliberately NOT added to `ENERGY_INDEX_FEATURE_TYPES` — that would pair a solar index with a `thirty-minutes-consumption` feature and count production as consumption. - `calculateProductionFromIndex`: 30-minute index deltas → `thirty-minutes-production` states (paired via `energy_parent_id`), with unit conversion and counter-reset handling. Uses a production-specific `ENERGY_PRODUCTION_INDEX_LAST_PROCESSED` device param so a device carrying both consumption and production indexes never corrupts either cursor. - Scheduled in the existing 30-minute job (consumption → production → cost). - `calculateProductionFromIndexFromBeginning` + new authenticated endpoint `POST /api/v1/service/energy-monitoring/calculate-production-from-index-from-beginning` to rebuild history after adding a device. - Two new `JOB_TYPES` + front i18n job labels (en/fr/de). Follow-up (separate PR, needs a semantic decision): deriving `thirty-minutes-production-revenue` / solar savings from these production states — self-consumption × contract price vs export at a feed-in tariff. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_012157sX3FKhVYmndWLJdhfo ## Summary by CodeRabbit * **New Features** * Added scheduled 30-minute energy production calculations from meter index data. * Added historical recalculation from the earliest available data. * Added a secured endpoint to trigger full historical recalculation. * Added English, French, and German labels for energy production jobs. * **Bug Fixes** * Improved handling of counter resets, invalid feature links, and unit conversion. * **Tests** * Expanded coverage for scheduling, recalculation, API behavior, and edge cases.

github.com/GladysAssistant/Gladys

feat(rtsp-camera): start HLS camera inputs at the live edge (#2698)

master ← Terdious:claude/netatmo-integration-backport-giun7o

ouvert 10:17AM - 22 Jul 26 UTC

Terdious

+76 -0

## Description When `CAMERA_URL` points to an HLS manifest (`.m3u8`) instead of… an RTSP URL — e.g. Netatmo cameras exposing `/live/files/{quality}/index.m3u8` — ffmpeg's HLS demuxer starts reading **3 segments behind the live edge** (`live_start_index` default = `-3`). With Netatmo's 2-second segments this adds ~4–6 s of fixed glass-to-glass latency on top of the re-encoding pipeline. This PR passes `-live_start_index -1` as an **input option** (before `-i`), **only when the URL contains `.m3u8`**, so: - HLS cameras start ~2 segments closer to the live edge (measured ~10–15 s → ~6–8 s end-to-end on a Netatmo NACamera); - RTSP cameras are untouched (the option is never added for them). ## Tests - Added two unit tests in `rtspCamera.streaming.test.js` asserting the ffmpeg args: `-live_start_index -1` is placed before `-i` for an `.m3u8` URL, and absent for a non-HLS URL. - `npx mocha ./test/bootstrap.test.js ./test/services/rtsp-camera/rtspCamera.streaming.test.js`: 20 passing, 0 failing. - Validated on a real bench (Gladys + Netatmo NACamera streamed over the LAN through the external gladys-netatmo integration). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016vS9MKCHbLnYJEhqnnX34K --- _Generated by [Claude Code](https://claude.ai/code/session_016vS9MKCHbLnYJEhqnnX34K)_ ## Summary by CodeRabbit * **Bug Fixes** * Improved live HLS streaming startup by beginning playback from the current live edge. * Non-HLS streams continue to start with their existing behavior. * **Tests** * Added coverage to verify correct startup behavior for HLS and non-HLS streams.

pierre-gilles · 30. Juli 2026 um 05:51

Hallo! Alles läuft, ich führe das Programm wie geplant aus

Jetzt gehe ich zum Sport!

Danke für deine PRs! Sind sie blockierend oder notwendig für den Release heute Abend?

Da es bereits ein großes Release ist, bin ich im Merge Freeze-Modus bis zur Veröffentlichung, es sei denn, es gibt einen echten Bug, der behoben werden muss. Ansonsten werde ich alles direkt nach dem Versionstag heute Abend mergen

guim31 · 30. Juli 2026 um 06:47

Mann, ich kann es kaum erwarten, heute Abend nach Hause zu kommen

Terdious · 30. Juli 2026 um 13:33

Nichts Blockierendes für den Release, nur Verbesserungsvorschläge ^^ Optik und Funktionen

Thema		Antworten	Aufrufe
Integration externe - Unify network Développement integration-externe	54	358	4. August 2026
Point PR janvier 2023 Développement	19	839	20. Januar 2023
Plusieurs erreurs/manques pour Tasmota POW-R2 Développement node-red	59	2129	3. Juli 2023
Ajout d'un journal d’évènements Demandes livrées	32	351	10. Juli 2026
Demande de mise en place d'un bouton arrêt et redémarrage du raspberry Demandes livrées feature-core , in-progress	15	941	24. August 2026

Verwandte Themen