What the module publishes over MQTT (from a computer with mosquitto-clients, or with MQTTX):
mosquitto_sub -h 192.168.1.10 -p 1883 -u user -P password -v -t 'clim_salon/#'
What the Calaos server says (over SSH on the box, see SSH access):
journalctl -u calaos-server -f
journalctl -u calaos-server --since "1 hour ago" | grep -i device
Messages about devices (link not found, command refused, output already taken, write on a protected output) contain the word device.
What the server sends to the interfaces: the get_home answer contains, for each device, the device object (capabilities, state, linked IOs). With curl and jq:
curl -s -X POST http://192.168.1.10:5454/api.php \
-d '{"action":"get_home","cn_user":"user","cn_pass":"pass"}' \
| jq '.. | objects | select(.gui_type? == "climate")'
A device missing from this output is not loaded or not visible (see below). A device’s state key gives the mode; device.state gives the temperature, setpoints, action, and connected, fault or lockout when they apply.
The device reads its mode on the topic <prefix>/climate/<id>/mode/state. Nothing arrives:
mosquitto_sub -v -t '<prefix>/#'. If the module publishes nothing, the problem is on the ESPHome side (Wi-Fi, broker, topic_prefix).topic_sub field). A typo or confusing the module name with the entity name is the most frequent cause: see ESPHome air conditioner.target_temperature_low/state and target_temperature_high/state, the device must have two setpoints; if it publishes target_temperature/state, one.The device is “offline” when the <prefix>/status topic is not online. ESPHome publishes it on connection and switches it to offline on disconnection (last will message). Check with mosquitto_sub -v -t '<prefix>/status': module off, lost on Wi-Fi, or a different topic_prefix than the device’s.
These are safeties, not thermostat failures: see the table in Internal thermostat. Check the linked sensor (value, connection); as soon as it delivers a valid reading, regulation resumes by itself.
off mode).heating, idle or off.heating but the relay does not move, the problem is downstream: the relay or its driver (Wago…).The <prefix>/calaos/remote_temp topic must receive a value every 120 s:
mosquitto_sub -h 192.168.1.10 -v -t 'clim_salon/calaos/remote_temp'
sensor_timeout, or the “Room sensor” link is missing. Calaos never relays a stale value.mqtt_subscribe sensor topic, remote_temperature_source and remote_temperature_timeout (longer than 120 s).To test the ESPHome side without Calaos: mosquitto_pub -h ... -t 'clim_salon/calaos/remote_temp' -m 21.5.
A setpoint outside the bounds is clamped. A field or value the device does not offer (a fan mode missing from the fan_modes parameter, cool without a cooling output) is refused and logged: look for the line in journalctl -u calaos-server. A gap between low and high setpoint that is too small (min_range) is refused the same way.
The widget type written by Calaos Installer is not known to the panel. Update Calaos Installer, open the panel page in the Remote UI editor (the widget takes the Climate type), send the configuration, then update the panel software if the problem persists: a panel too old has no Climate widget.
visible attribute of a device, which the apps require. Without an update, add visible="true" to the <calaos:device> element.get_home (curl command above)? If not, look at the log when the server starts: a malformed file or a load error is reported there.