J’ai réussis a me connecté a overkitz Atlantic
J’ai un device qui est trouvé « MODBUSLINK »
Mais absolument pas mon ballon d’eau chaude.
De quoi avez vous besoin ?
[2026-08-03T19:21:54.251Z] [INFO] [overkiz] Connected to the Overkiz API
[2026-08-03T19:21:54.312Z] [INFO] [overkiz] Fetched 4 Overkiz devices
[2026-08-03T19:21:55.674Z] [INFO] [overkiz] Connected to the Overkiz API
[2026-08-03T19:21:55.710Z] [INFO] [overkiz] Fetched 4 Overkiz devices
[2026-08-03T19:22:18.372Z] [INFO] onScanRequest -> refreshing Overkiz devices
[2026-08-03T19:27:47.425Z] [INFO] onScanRequest -> refreshing Overkiz devices
[2026-08-03T19:27:48.542Z] [INFO] onScanRequest -> refreshing Overkiz devices
mon ballon :
@spenceur pas sûr que ton ballon soit déjà dispo :
C’est pour ça que j’ai crée ce post pour que soit prise en compte (il manque quoi exactement ?)
Merci @mutmut
Je me suis fais un petit plugin matter pour l’intégré (bon il faut je le revois)
mais j’avais ces infos et cela était largement suffisant
ok je n’avais pas compris, je me suis permis de modifier le titre du post.
Je me suis fais la même réflexion que toi au début et j’ai ensuite vu le message dans l’intégration qui disait que cela n’était pas encore disponible.
Pour information j’ai donc vu avec @cicoub13 ce matin en MP et il devrait normalement bosser sur le sujet des ballons d’eau chaude mercredi
Bonjour. J’ai commencé à regarder mais je pense qu’il faudra une modification du cœur de Gladys pour ajouter un nouveau type d’appareil. On pourrait le faire actuellement mais c’est un peu de la bidouille et les libellés des fonctionnalités ne sont pas explicites.
Je suis en train d’écrire une spécification pour l’ajouter dans Gladys.
Une fois que c’est fait, je pourrai l’ajouter dans l’intégration Overkiz.
Merci pour la référence @spenceur , je te solliciterai sûrement pour des tests aussi
Est-ce que vous pouvez regarder la spécification ?
master ← cicoub13:claude/spec-chauffe-eau-integration-jxgobk
ouvert 07:26AM - 04 Aug 26 UTC
Gladys has no category for domestic hot water. A connected water heater can only… be published today as a makeshift assembly — switch/binary for on/off, heater/pilot-wire-mode (a room-heating concept) bent into a mode selector — so the user does not recognize their appliance in the dashboard, and scenes have no mode selector. Integrations have no target either: server/services/matter/README.md lists WaterHeaterManagement and WaterHeaterMode as not handled, for want of something to map them onto.
This adds a living specification for a `water-heater` category, written before the code as AGENTS.md asks for anything touching the data model. No code is changed: the spec is the deliverable, and it is meant to be challenged before implementation starts.
The design follows docs/specs/device-feature-categories.md, and section D answers its review checklist point by point:
- Six types, all intrinsic to producing and storing hot water: binary, mode, target-temperature, remaining-hot-water, heating, boost. The water temperature measured in the tank is published as temperature-sensor/decimal and the consumption as energy-sensor features on the same device — one physical quantity, one category.
- The mode enum carries the full generic set of eight operating modes; per-appliance subsets are declared through supported_options, including for appliances whose native interface is independent switches rather than a selector.
- Every type is mapped to its Matter cluster, with one divergence declared and argued: the category keeps its own target-temperature rather than reusing thermostat/target-temperature.
- heat-source, COP and absence-duration are deliberately deferred to the non-goals, with the reason for each.
Two reference device profiles are specified — a heat-pump water heater with a mode selector, and an electric storage tank exposing switches — so that no later change can quietly make any type mandatory.
Claude-Session: https://claude.ai/code/session_01JLunXRNfohakXDyqzwHHrw
### Description
## Forum
### Checklist
- [ ] Tests pass: `cd server && npm run coverage` (Codecov requires 100% coverage on changed lines) and Cypress (`npm run cypress:run`) if the UI changed
- [ ] Linter and prettier pass on both front and server (`npm run eslint`, `npm run prettier`)
- [ ] No undocumented breaking change
Je laisserai @pierre-gilles regarder pour le coup