Imhotep creation devices converter misses exposes.climate().withSystemMode

[AntoineBarj]

Disclaimer
(I originally posted a simialar issue here: Koenkk/zigbee2mqtt#25565, but I realized that this was not the right repo for this issue)

What happened?

The device PH25 from Imhotep creation is well recognized by z2mqtt, but its integration is only partial.
The current exposes for the heater mode are (according to https://www.zigbee2mqtt.io/devices/E-Ctrl.html):

Heater mode (Off or Heat).

But , when creating a climate card, all the default systemMode are available (not only "off" and "heat"), and switching between modes from the climate card has no effect on the actual systemMode:

When displaying the mqtt device properties, we can see this:

as you can see, there are two "SytemMode", and the climate.sytemMode is not linked to the exposed system mode.

What did you expect to happen?

The climate.systemMode should be 1:1 likend to the system mode that is exposed.

I think that there is a missing lines in the src/devices/imhotepcreation.ts.
I have no experience in such converters, but from what i guessed from other converters, i think we should add .withSystemMode(['off', 'heat']).

example below for the PH25 device

exposes: [
            e.enum('system_mode', ea.ALL, ['off', 'heat']).withDescription('Heater mode (Off or Heat)'),
            e.local_temperature(),
            e.climate()
            .withSetpoint('occupied_heating_setpoint', 5, 30, 0.5, ea.ALL)
            .withLocalTemperature()
            .withSystemMode(['off', 'heat']),

            e
                .numeric('min_heat_setpoint_limit', ea.ALL)
                .withUnit('°C')
                .withDescription('Minimum Heating set point limit')
                .withValueMin(5)
                .withValueMax(30)
                .withValueStep(0.5),
            e
                .numeric('max_heat_setpoint_limit', ea.ALL)
                .withUnit('°C')
                .withDescription('Maximum Heating set point limit')
                .withValueMin(5)
                .withValueMax(30)
                .withValueStep(0.5),
            e.occupancy(),
        ],

Am I right ? Is the author @nicolasaxenco of the PR https://github.com/Koenkk/zigbee2mqtt.io/pull/6478 in charge of the change ?

[nicolasaxenco]

Hi @AntoineBarj, after reviewing the implementation, it turns out to be even simpler than initially thought. We only need to use climate.withSystemMode(['off', 'heat']) directly, without requiring the enum previously defined in our converter.
I will test this solution and post the fix asap.

[AntoineBarj]

Thank you for you feedback.

---

Another topic is (maybe needs another issue):
I suppose that you work for Imhotep Creation, but we'll keep this conversion in English for better readability.

Is there a way to have the full system modes exposed, as for the mobile app ? I asked several time here and there, tried things by my own, but I never could access to the modes (auto/confort/eco/.../ off).
The thing is : the heater is "clever", and does not keep the temperature setpoints (through z2m or zigbee). After some delay, it automatically resets the setpoint to its previous value. So I made "dirty" automations, with setpoints every 5minutes. It works, but it is not as clean it should be. If I look into the thermostat history, we see sometimes the setpoints retutrning to its default heater's value:

Thank you

[nicolasaxenco]

Yes, I’m currently working with Imhotep creation :).
The fix is ready and will be pushed via a pull request.

Regarding your questions:

The heater mode (auto, comfort, eco, etc.) is not currently exposed.
In Auto mode, when you change the heating setpoint, you’re applying an override rather than changing the actual setpoint. This override is reset at the start of a new schedule period or every day at midnight.
If you don’t plan on using any program, I recommend setting your device to Comfort mode. In that case, changing the heating setpoint will directly update the Comfort setpoint.

[AntoineBarj]

I updated the Z2m integration, with the last fix, that includes the PR #8625 .

sadly, it is 100% broken now.

from HomeAssistant:

1- Changing the system mode heat-off has no impact on the thermostat/heater. It worked before
2- the temperature Setpoint is not exposed here

and finnaly, as before, the thermostat cards in HA are basically not connected to the thermostat:

there is no action that is effective on the heater.

And now : i can not even modify the temperature setpoint, and all the associated automations, that previously worked are currently broken.

below some logs from the thermostat:

error 2025-01-21 21:23:51z2m: Publish 'set' 'occupied_heating_setpoint' to 'radiateur_bureau' failed: 'Error: ZCL command 0x540f57fffebab954/1 hvacThermostat.write({"occupiedHeatingSetpoint":2300}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"reservedBits":0,"writeUndiv":false}) failed (Timeout - 7934 - 1 - 88 - 513 - 4 after 10000ms)'

---

info 2025-01-21 21:24:02z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/ZLinky', payload '{"MOTDETAT":null,"active_energy_out_d01":0,"active_power":0,"active_power_max":0,"active_power_ph_b":0,"active_register_tier_delivered":"TH..","apparent_power":880,"available_power":30,"average_rms_voltage_meas_period":0,"current_date":"","current_index_tarif":0,"current_price":"","current_summ_delivered":8069,"current_tarif":"BASE","current_tier1_summ_delivered":8069,"current_tier2_summ_delivered":0,"drawn_v_a_max_n1":0,"linkquality":240,"message1":"","message2":"","meter_serial_number":"022275026805","mot_d_etat":"000000","relais":0,"relais_breakout":{"relais1":0,"relais2":0,"relais3":0,"relais4":0,"relais5":0,"relais6":0,"relais7":0,"relais8":0},"rms_current":7,"rms_current_max":90,"rms_voltage":0,"site_id":"","status_register":"","status_register_breakout":{"cache_borne_dist":"ferme","comm_euridis":"desactivee","contact_sec":"ferme","depassement_ref_pow":0,"etat_cpl":"nouveau_deverrouille","horloge":"correcte","organe_coupure":"ferme","pointe_mobile":"AUCUN","preavis_pointe_mobile":"AUCUN","producteur":0,"sens_energie_active":"positive","surtension_phase":0,"sync_cpl":"non_synchronise","tarif_dist":"index_1","tarif_four":"index_1","tempo_demain":"UNDEF","tempo_jour":"UNDEF","type_tic":"historique"},"update":{"installed_version":14,"latest_version":14,"state":"idle"},"warn_d_p_s":0}'

@nicolasaxenco Can you please, as a hot fix revert back the PR #8625 ?
If you cannot test the integration/converter by yourself, can you guide me, so I can do it on my own in HA ? (as soon as there is an official converter, I do not know how to use a custom one, as i did before).

[AntoineBarj]

Update : after deconnecting and painting a thermostat again, it seems to work better. We should ignore the previous comment .

But the original issue is not fixed :(. 1:1 same behaviour

---

@nicolasaxenco : I would need furthermore to contact you directly . Sorry for the disturbance, but I noticed an additional issue that does not belong to this issue:
3 of my 5 thermostat are absolutely unable to leave the ZigBee network. Neither from the default instructions, not with the pro configurations. I've tried again and again, until I've had enough. So 3 of my heaters are currently stucked offline ... Is there a way to contact you directly ? Via linkedin ? I'm sure you're not please for additional work, but i'm conviced that i face a software/hardware issue.

[nicolasaxenco]

Sorry for the delay, I didn’t receive the notification.
Could you please send an email to [email protected] explaining your issue (in French or English)?
Both the support team and I will receive your message, and we’ll be able to assist you promptly.