Integración domótica MyNeomitis (Axenco), gratuita y de código abierto

Control your Neomitis / Axenco heaters and thermostats from Gladys.

• Publicado por Dreamthy
• Dispositivos
• Versión 1.1.0
• Requiere Gladys >=5.2.0
• ★ 0

Ver en GitHubTodas las integraciones

info

La documentación de esta integración la escribe su autor y, por ahora, solo está disponible en inglés.

Version 1.1 — Gladys ≥ 5.2: read the migration guide for native thermostat controls, the widget and scene actions. The following sections also describe the legacy features.

This integration controls the Neomitis / Axenco heaters, thermostats and modules managed by the MyNeomitis mobile app from Gladys. It is a JavaScript port of the Home Assistant myneomitis integration and of the pyaxencoapi library: same REST calls, same real-time channel, same supported models.

It goes through the Axenco cloud (there is no local API): your devices must already be paired in the MyNeomitis app, and an Internet connection is required.

Installation

1. Install the integration from the Gladys store.
2. Open the Configuration tab and enter the email address and password of your MyNeomitis account — the same ones as in the mobile app. Axenco offers no OAuth2 flow.
3. Leave the refresh interval at 300 s unless you have a reason not to: changes normally arrive in real time over the WebSocket, and this interval is only a safety net for a missed message.
4. Go to Discovery: every recognized device of your account shows up. Create the ones you want to use.

The connection indicator on the Configuration screen turns green once the Axenco session is established. If it stays red, the message tells a rejected credential apart from an unreachable cloud.

Supported devices

Model	Kind	What Gladys exposes
EV30	Thermostat / heater	Temperatures + 7 modes
ECTRL	Thermostat / heater	Temperatures + 8 modes
ESTAT	Thermostat / heater	Temperatures + 8 modes
RSS-ECTRL	Thermostat / heater	Temperatures + 8 modes
NTD	Sub-thermostat (behind a gateway)	Temperatures + 6 modes + heating/cooling
ETRV	Radiator valve (sub-device)	Temperatures + 5 modes
EWS	Wireless module, dry contact relay	3 modes: On / Off / Auto
EWS	Wireless module, fil pilote	7 modes (deviceType: 1), else 10
UFH	Underfloor heating / cooling	Heating / Cooling change-over

How an EWS behaves depends on how it is wired: Axenco reports it through state.deviceType (0 = dry contact, anything else = fil pilote), and the integration picks the right mode list on its own.

Sub-devices (NTD, ETRV, UFH) are driven through their gateway: the integration finds it in the device's parents field and addresses the device by its rfid.

Features created in Gladys

One Axenco device becomes one Gladys device carrying several features. It works independently: creating a Gladys thermostat is optional.

• Current temperature — sensor, in °C, with history (charts).
• Target temperature — writable setpoint. Its bounds come from the device itself (comfLimitMin / comfLimitMax) rather than a hard-coded 7–30 °C: a heater limited to 16–21 °C really shows 16–21 °C. On main devices it follows the effective target of the active mode. In standby it remembers the value without waking the heater; resume with a mode or an explicit override.
• Mode du radiateur — OFF/HEATING on EV30, ECTRL, ESTAT, RSS-ECTRL, NTD and ETRV; NTD also reports Cooling according to the installation changeover, which stays read-only. Select it with the target in a real Gladys thermostat. Protected stop/resume covers all six models; this project only has hardware observations for EV30 and EWS.
• Mode Axenco — one selector for the modes supported by the model: Comfort, Eco, Auto, Boost, Standby, etc. It works without a Gladys thermostat. On EWS it is named Mode du module, using Confort −1 °C, Confort −2 °C and Arrêt to match Gladys pilot-wire terminology. The Mode / Commande fil pilote (6 ordres) duplicate is removed when updating from Discovery. Replace any references before updating. The widget displays the full observed mode without a stale standard-order value. On temperature-regulating devices, Dérogation (consigne actuelle) applies the last observed Axenco target. To choose another temperature, change Température de consigne or use the widget.
• Mode details — the widget shows "Auto (Confort)", "Auto (Éco)" and unknown codes from observed hardware state. The selector stays on "Auto". The old text feature is retained as Mode actuel (compatibilité) only when already created. Devices without a selector keep their read-only mode.
• Fenêtre ouverte — one standard Gladys contact: 0 open, 1 closed. An already-created legacy contact with the opposite values remains as Fenêtre ouverte (compatibilité) to preserve existing scenes.
• Legacy mode switches — "Auto", "Confort", "Éco", "Hors gel", "Boost", "Veille"… These are retained only when already created in Gladys, preserving existing scenes. New devices use the selector instead. Auto is a mode like any other (targetMode: 0): picking it leaves the manual modes, and vice versa.
• Consigne Confort / Consigne Éco / Consigne Hors gel — the temperatures the modes use, writable. These are distinct from the shared target; writing that target while running starts an override. Neither pyaxencoapi nor the Home Assistant integration exposes them. Restricted to devices that actually regulate a temperature. An EWS does report the three fields but refuses to write them: it drives a fil pilote and has no sensor, so it has nothing to regulate. UFH is excluded for the same reason, sub-devices because the rfid-keyed payload has never been observed.
• Rafraîchissement — heating/cooling switch, writable on UFH, read-only on NTD.
• Read-only sensors — Signal (reception quality, drawn as antenna bars), Présence, Fenêtre ouverte, Verrouillage clavier and Défaut système. These values already travel in the state the device sends: no extra call, nothing to configure. A device only exposes the ones it actually reports. The system fault is published as-is — 0 means "no fault" on every device seen, a non-zero value is likely a code. Neither pyaxencoapi nor the Home Assistant integration exposes them.

Feature names are in French, matching the MyNeomitis app and the Neomitis product range.

Legacy mode switches are exclusive: turning one on sends that mode to Axenco and turns the others off in the same batch. Turning one off does nothing — an Axenco device is always in some mode, there is no "no mode" to send, so the switch snaps back to reality.

Setting the target temperature creates a derogation: a setpoint differing from the one configured for the current mode. The integration sends the same call as the official app, targetTemp + overrideTemp + targetMode: 8 in one go. climate.py writes the mode first and then the temperature; that first call is a no-op, measured.

Standard modes and legacy compatibility

Version 1.1 adds a real ON/OFF control for EWS relays, a standard pilot-wire selector and an EV30 Mode du radiateur with a target shared by direct controls and the native thermostat. Existing preset switches retain their ids and semantics: switching one OFF is not a hardware stop. Supported choices are declared through supported_options. The Neomitis widget shows live temperatures and two controls: Mode and Setpoint. Auto and Standby remain available in the mode selection. Connection details are optional; anomalies and window status remain visible. Read the migration and thermostat guide for configuration.

Using it in scenes

Each mode switch is an ordinary feature: a scene can turn Salon – Éco on in the evening and Salon – Confort on in the morning. Use Mode Axenco on new devices. The legacy Mode actuel (compatibilité) text is retained only when already created.

Known limitations

• Cloud only. No local API exists. Each device carries a badge showing whether it is reachable; a device offline on the Axenco side shows as unreachable in Gladys.
• "Auto" is targetMode: 0, not 60. pyaxencoapi documents 60 and the Home Assistant integration sends it; measured on real hardware, 60 and 61 both answer 2xx and change nothing. The value the official app sends was captured from its network traffic: {"targetMode": 0}. Hardware in Auto reports 60 or 61 back, so all three decode to Auto on read — that read/write asymmetry is what made the reference library look right.
• An unknown code stays visible. A mode Axenco reports that the integration does not know shows as "Inconnu (42)" in the widget and in an existing legacy text feature, instead of being silently dropped — that is how the 61 case was spotted.
• EWS fil pilote: the mode list depends on deviceType. pyaxencoapi and select.py advertise ten presets for every fil pilote EWS — the union of what Axenco hardware can do, not what a given module offers. A verified module gets its real list; every other one keeps the reference list. One has been verified so far: deviceType: 1 (EWSFPNEOA), measured over the WebSocket and cross-checked against its manual. It emits seven orders — comfort, eco, eco -1, eco -2, frost protection, standby, boost — plus Auto through the autoProgram flag. Worth knowing: the MyNeomitis app menu only shows six of them, hiding eco -1 and eco -2, while the manual names them explicitly ("Mode Éco, Éco-1 ou Éco-2") and states the module drives "un fil pilote 4 ou 6 ordres". comfort_plus really is absent though, ignored twice by the hardware. And per the manual, Boost only does something when the connected heater understands that order over the fil pilote. If your EWS reports another deviceType, send the output of node scripts/sweep-modes.mjs <id> --apply and your list will be added. The default stays the wider list on purpose: a mode that does nothing is visible and harmless, a hidden mode is a silent loss of capability.
• UFH: a deliberate divergence from the Home Assistant source. select.py writes a UFH mode with set_device_mode on its _id, whereas a UFH is a sub-device whose mode lives on changeOverUser. This integration uses the dedicated sub-device route pyaxencoapi provides for exactly that case (set_sub_device_mode_ufh).
• The Axenco weekly program is not edited here. The client supports setDeviceProgram; keep editing this manufacturer schedule in MyNeomitis. The native Gladys thermostat offers a separate schedule. Axenco Auto follows the manufacturer schedule.
• Legacy commands publish optimistically. Their requested values are corrected by subsequent observations. Shared targets on all six thermostat models instead uses confirmed hardware feedback; see the migration guide.

Verification status per model

EV30 and EWS observations do not validate other models' protocols. The integration currently writes targetMode: 0 for Auto on every profile that offers it. Main devices share the targetTemp + overrideTemp + targetMode: 8 setpoint command captured on EV30; NTD and ETRV use their gateway with targetMode: 8, then targetTemp in a second call, as Home Assistant does. Applying these commands to untested models still needs hardware verification.

The comparison on 20 October 2026 uses the Home Assistant MyNeomitis source and its pyaxencoapi==1.0.7 dependency, whose listed repository is AXENCO-FR/ha-py-axenco-api. These sources use Auto 60 and overrideTemp alone for a main device's setpoint. They identify differences; they do not justify replacing existing commands without evidence for the particular model.

The latest PyPI release is actually 1.0.9, published on 21 April 2026. Comparing the 1.0.7 and 1.0.9 archives shows gateway ID extraction from parents and reorganized per-model mode maps, including EWS and UFH. This integration already handles those routes and maps. Version 1.0.9 retains Auto 60 and overrideTemp alone, so it does not resolve the EV30 differences. Home Assistant and the latest library release must therefore be checked separately.

Model	Mode list	Command routing
EV30	measured + app capture	measured
EWS fil pilote (deviceType: 1)	measured + capture + manual	measured
EWS relay (deviceType: 0)	inherited from select.py	inherited
EWS fil pilote, other deviceType	inherited from pyaxencoapi	inherited
ECTRL, ESTAT, RSS-ECTRL	inherited from pyaxencoapi	inherited
NTD, ETRV	inherited from pyaxencoapi	inherited, gateway never tested
UFH	inherited from pyaxencoapi	inherited, gateway never tested

"Inherited" describes the origin of a mode list or route, not hardware certification or a complete match with the current library. Automated tests check serialized commands and simulated readbacks for each profile; they do not prove that real devices apply those commands.

The most doubtful one is comfort_plus (code 20), which pyaxencoapi gives to ECTRL / ESTAT / RSS-ECTRL. It is ignored by an EV30 and by an EWS, both measured. It is kept for those three models because nothing proves it is absent there — a useless mode is visible and harmless, a hidden one is a silent loss.

If you own one of these models, two commands are enough to get the list fixed:

node scripts/dump-devices.mjs                      # the raw state of your devices
node scripts/sweep-modes.mjs <deviceId> --apply    # what the device really accepts

Send both outputs along with the mode list the MyNeomitis app shows for that device. The sweep only handles main devices for now: an NTD, ETRV or UFH goes through its gateway, whose response shape has never been observed.

Troubleshooting

• "MyNeomitis rejected these credentials" — check the email and password in the mobile app. The integration does not retry in a tight loop on an authentication error.
• No device in Discovery — only the models in the table above are picked up. The container logs say how many devices were seen and how many were ignored.
• "No recent value" — Axenco only emits on change. The known state is published when the device is created and on every periodic refresh; wait one cycle.
• Real-time updates stopped — the WebSocket channel reconnects on its own, and the periodic refresh covers the gap meanwhile. Set LOG_LEVEL to debug to see the events as they arrive.

Removal

Uninstall the integration from Gladys: the container is removed and the devices created along with it. Nothing changes on the MyNeomitis side — your devices stay paired in the mobile app.

Parámetros de configuración

Estos son los parámetros que MyNeomitis (Axenco) te pide en su pantalla de configuración en Gladys.

Parámetro	Tipo	Obligatorio	Descripción
Your MyNeomitis account	section	No	Use the same email address and password as the MyNeomitis mobile app. The integration talks to the Axenco cloud: your heaters must already be paired in the app.
Email address	string	Sí	The email address of your MyNeomitis account.
Password	secret	Sí	The password of your MyNeomitis account.
Refresh interval (s)	number	No	Safety net: updates normally arrive in real time, this is how often the full state is re-read anyway.

Cómo instalar MyNeomitis (Axenco) en Gladys

1. En Gladys, abre Integraciones: MyNeomitis (Axenco) aparece en el catálogo junto a las integraciones nativas, con una insignia de comunidad.
2. Haz clic en Instalar. Gladys descarga la imagen Docker (ghcr.io/dreamthy/gladys-neomitis:1.1.0), la ejecuta en un entorno aislado del núcleo y genera la interfaz de la integración (dispositivos, descubrimiento y configuración).
3. Abre la pantalla de Configuración de la integración, rellena los parámetros y guarda.
4. También puedes instalarla directamente desde la URL de su repositorio: https://github.com/Dreamthy/gladys-neomitis.

MyNeomitis (Axenco) requiere Gladys >=5.2.0. El catálogo de Gladys se actualiza cada hora, así que una nueva versión está disponible como máximo una hora después de publicarse.

¿Todavía no usas Gladys? Es gratuito y de código abierto: sigue la guía de instalación para empezar.

Sobre las integraciones externas

MyNeomitis (Axenco) es una integración externa: una integración comunitaria empaquetada como contenedor Docker y publicada en GitHub. Gladys la instala con un clic y la ejecuta en un entorno aislado del núcleo. La publica y mantiene Dreamthy, no el equipo principal de Gladys.

• Explorar todas las integraciones, nativas y de la comunidad
• Crear y publicar tu propia integración externa
• Código fuente en GitHub — fuente de esta documentación

Suscríbete a la newsletter de Gladys Assistant

Unos pocos correos al mes sobre nuevas versiones y novedades del proyecto. Enviados por Pierre-Gilles Leymarie, fundador del proyecto. Puedes darte de baja cuando quieras 🙂