Acova Taffetas2 "heat" mode is actually "frost protection", stuck at 7°C

[sven337]

What happened?

I have an Acova Taffetas2 heater Zigbee Model TAFFETAS2 D1.00P1.01Z1.00 It appears as supported in Zigbee2MQTT and exposes three system modes: "off", "auto" and "heat".

But, the "heat" mode actually enters "frost protection" mode at 7°C, and does not seem to correspond to "heat" at all. Changing the target temperature has no effect.

I am not sure where the problem comes from, there may be a mapping issue within Zigbee2MQTT. Help would be appreciated to get this device fully working.

What did you expect to happen?

"heat" should put the radiator in heating mode with a target temperature controlled by zigbee2mqtt.

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.30.2

Adapter firmware version

20211115

Adapter

CC2531

Debug log

debug 2023-03-08 10:26:44Received MQTT message on 'zigbee2mqtt/bedroom_radiator/set' with data '{"system_mode":"heat"}'
debug 2023-03-08 10:26:44Publishing 'set' 'system_mode' to 'bedroom_radiator'
info 2023-03-08 10:26:44MQTT publish: topic 'zigbee2mqtt/bedroom_radiator', payload '{"linkquality":15,"local_temperature":7,"occupied_heating_setpoint":12,"running_state":"idle","system_mode":"heat","unoccupied_heating_setpoint":7}'
info 2023-03-08 10:26:44MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/local_temperature', payload '7'
info 2023-03-08 10:26:44MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/running_state', payload 'idle'
info 2023-03-08 10:26:44MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/occupied_heating_setpoint', payload '12'
info 2023-03-08 10:26:44MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/unoccupied_heating_setpoint', payload '7'
info 2023-03-08 10:26:45MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/linkquality', payload '15'
info 2023-03-08 10:26:45MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/system_mode', payload 'heat'

Then, manually increasing temperature (no effect on the device, still showing 7° and frost protection) :

debug 2023-03-08 10:27:03Received MQTT message on 'zigbee2mqtt/bedroom_radiator/set' with data '{"occupied_heating_setpoint":14.5}'
debug 2023-03-08 10:27:03Publishing 'set' 'occupied_heating_setpoint' to 'bedroom_radiator'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator', payload '{"linkquality":15,"local_temperature":7,"occupied_heating_setpoint":14.5,"running_state":"idle","system_mode":"heat","unoccupied_heating_setpoint":7}'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/local_temperature', payload '7'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/running_state', payload 'idle'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/occupied_heating_setpoint', payload '14.5'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/unoccupied_heating_setpoint', payload '7'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/linkquality', payload '15'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/system_mode', payload 'heat'
debug 2023-03-08 10:27:03Received Zigbee message from 'bedroom_radiator', type 'attributeReport', cluster 'hvacThermostat', data '{"occupiedHeatingSetpoint":1450}' from endpoint 1 with groupID 0
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator', payload '{"linkquality":13,"local_temperature":7,"occupied_heating_setpoint":14.5,"running_state":"idle","system_mode":"heat","unoccupied_heating_setpoint":7}'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/local_temperature', payload '7'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/running_state', payload 'idle'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/occupied_heating_setpoint', payload '14.5'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/unoccupied_heating_setpoint', payload '7'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/linkquality', payload '13'
info 2023-03-08 10:27:03MQTT publish: topic 'zigbee2mqtt/bedroom_radiator/system_mode', payload 'heat'

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sven337]

Not stale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[PEGARifrouf]

Hello,

I tried to setup mine. I think you shall set the mode to BOX, then it will take orders from z2m.

It does not work well for me, I have only made one or two successfull commands the others leads to a timeout. But it an others issue I think.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sven337]

Not stale, I intend to debug this myself at some point.

[sven337]

This seems like a device bug. Z2M sets attribute 0x1c to value 4 (SystemMode = Heat) but the device interprets this as "enter frost protection mode". Critically, I do not see "frost protection" in the ZCL, so it's possible the manufacturer has fudged the meanings a bit.

ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Thermostat (0x0201)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 94
ZigBee Cluster Library Frame, Command: Write Attributes, Seq: 70
    Frame Control Field: Profile-wide (0x10)
        .... ..00 = Frame Type: Profile-wide (0x0)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...1 .... = Disable Default Response: True
    Sequence Number: 70
    Command: Write Attributes (0x02)
    Attribute Field, Enum8: 4
        Attribute: SystemMode (0x001c)
        Data Type: 8-Bit Enumeration (0x30)
        Uint8: 4 (0x04)

The effective mapping of values seems to be: 0 off 1 heat 4 frost protection

https://github.com/Koenkk/zigbee-herdsman-converters/pull/4417 added support for the device

[molusk]

Same issue here but could not even try to issue a workaround for the device as I do not speak JS fluently. It could be interesting to know if other Acova heaters have the same issue (which is very likely as they share almost the same converter, I suppose the firmware is near from identical).

For your information, when I installed my first Taffetas2 heaters, I worked with the domoticz zigate plugin developer to integrate them. He somehow managed to have 4 modes working : frost protection, off, auto and eco. The difference between eco and auto is that motion sensor is disabled in eco mode and setpoint set lower. As you have noticed, frost protection mode does not follow standard protocol. Now I would like to understand how eco mode may work. I was not able to trigger it when playing with the parameters in Z2M. If you have any idea, it would be great to be able to disable motion sensor occasionally.

[molusk]

To reply @PEGARifrouf comment, indeed you have to set the heater in box mode in order to pair it at first but then when you change the mode in Z2M/HA the heater leaves box mode to switch off or to frost protection mode but you can still manage it remotely, turn it on and switch to auto mode (box mode on the device).

Hello,

I tried to setup mine. I think you shall set the mode to BOX, then it will take orders from z2m.

It does not work well for me, I have only made one or two successfull commands the others leads to a timeout. But it an others issue I think.

[PEGARifrouf]

To reply @PEGARifrouf comment, indeed you have to set the heater in box mode in order to pair it at first but then when you change the mode in Z2M/HA the heater leaves box mode to switch off or to frost protection mode but you can still manage it remotely, turn it on and switch to auto mode (box mode on the device).

Hello,

I tried to setup mine. I think you shall set the mode to BOX, then it will take orders from z2m.

It does not work well for me, I have only made one or two successfull commands the others leads to a timeout. But it an others issue I think.

Yes you are right, it leaves the box mode as soon as it recieve a remote command.

[sven337]

For your information, when I installed my first Taffetas2 heaters, I worked with the domoticz zigate plugin developer to integrate them. He somehow managed to have 4 modes working : frost protection, off, auto and eco. The difference between eco and auto is that motion sensor is disabled in eco mode and setpoint set lower. As you have noticed, frost protection mode does not follow standard protocol. Now I would like to understand how eco mode may work. I was not able to trigger it when playing with the parameters in Z2M. If you have any idea, it would be great to be able to disable motion sensor occasionally.

I don't know exactly where his code lives, but if it is https://github.com/zigbeefordomoticz/Domoticz-Zigbee.git as I think, then I don't see any logic there to handle the 4 modes. Here's the mapping they seem to use: https://github.com/zigbeefordomoticz/Domoticz-Zigbee/blob/stable6/Modules/widgets.py#L374 Only 3 elements there. And they disagree with me because they see 2 for frost protection and I see 4. (I'm playing in Z2M's dev console writing values to the systemMode attribute to see what's going on).

Unrelated, @molusk, but do your Taffetas2 produce noise while heating? Mine resonates to the point it's unbearable, it seems that the power supply produces noise which gets amplified by resonance against the plastic electronics body and the metal radiator.

[molusk]

To be honest, the implementation in domoticz may be incomplete as there was only one active dev to add devices and he did a lot each week on his spare time to help every single user... Once the solution was enough for my usage I stopped asking him for adjustments and I finally switched to HA and Z2M were I could play alone to make it work as I needed. Maybe the implementation in domoticz changed since then with other Acova customers requesting adjustments to pipiche or another zigbeefordomoticz dev. I never updated the plugin from stable5 to stable6, when they renamed the project and I think they changed almost everything under the hood at that time...

If I had the courage, I would disconnect one of the heaters from Z2M and install domoticz on a spare raspberry pi to compare implementations. Pipiche also told me it could be interesting to sniff and analyze zigbee traffic when the heater is connected to an Enki box (I have one somewhere in the basement, it was included for free with the heaters). So I bought a CC2531 dongle... but I still have no time to play with it. And if I remember well, Enki implementation was the bare minimal : just control over the setpoint, no modes, no access to configuration (enable/disable sensors, temperature calibration).

About noises, I have no issue with my heaters. The first 3 I installed were in the bedrooms, my kids would have been awake all night in winter if the heater had produced noise. The only issue I had with one of the heaters is the buttons on the panel that were a bit jammed. I could not pair it at first but after 1 day or 2, it worked well.

[sven337]

I am not sure that the "Eco" mode really worked, and certainly it doesn't seem to work for me. The last relevant commit removes it https://github.com/zigbeefordomoticz/Domoticz-Zigbee/commit/70c677c6b50c3bf4c5e2377642ceefad323a68dc See here for more relevant history in that repo:

commit 70c677c6b50c3bf4c5e2377642ceefad323a68dc
Author: Patrick Pichon <[email protected]>
Date:   Mon Oct 18 19:34:35 2021 +0200

    Update way to handle Thermostat Mode for Acova TAFFETAS2

commit 31d1f55d1f6beb13411258be825c43250302ca40
Author: Patrick Pichon <[email protected]>
Date:   Wed Oct 6 21:18:47 2021 +0200

    Changes for Acova device

commit 4ec4887aaeda5eb3bfdbade7a8978c0cb07c68f2
Author: Patrick Pichon <[email protected]>
Date:   Sun Oct 3 20:22:02 2021 +0200

    ThermoMode for Acova back to standard

commit eb47d2aa65818ef46ab0f2a05f99410a9c1b9c6f
Author: Patrick Pichon <[email protected]>
Date:   Sun Oct 3 20:22:00 2021 +0200

    ThermoMode for Acova back to standard

commit bd0587825ebd4020a9f694a4f5a5b3d484867cc2
Author: Patrick Pichon <[email protected]>
Date:   Sun Oct 3 19:49:02 2021 +0200

    fix mistakes for Acova.

commit 43f2dd64cdd9170b15b0cdb58739c4b21854f3f6
Author: Patrick Pichon <[email protected]>
Date:   Sat Oct 2 10:27:19 2021 +0200

    changes for Acova Taffetas2

commit bbe99e07803ba934e9f64ec15731acbccb8dbeea
Author: Patrick Pichon <[email protected]>
Date:   Mon Sep 27 22:22:46 2021 +0200

    Adding what is needed for Acova Teffetas 2

Long story short - I do not think that Eco works on my device (and I do not care about it), so what I'll do is fix the mapping in Z2M to expose Off/Heat/Frost protection just as the latest version of zigbeefordomoticz does.

[molusk]

Great ! Don’t hesitate to share your custom converter if you need more testers 😃

I remember it was a pain in the ... to debug with domoticz as I could not do changes myself, there were a lot of exchanges with Patrick and I am not sure what was the final state. I think all the commits you listed are my requests until it was enough to manage my bedrooms for the winter. Perfect is the enemy of good 😆

[sven337]

@Koenkk I'd like your input on how to solve this. toZigbee.js's thermostat_system_mode reads from constants.thermostatSystemModes It feels wasteful to duplicate the code and make a acova_thermostat_system_mode that reads from a new constants.acovaThermostatSystemModes What do you think of using the "meta" parameter to store the system mode array to be used? I see that tuya.js does this meta: {tuyaThermostatSystemMode: tuya.thermostatSystemModes2, tuyaThermostatPreset: tuya.thermostatPresets},

Do you agree with that plan or would you rather I did it a different way?

Thanks

[Koenkk]

@sven337 this is the old tuya integartion, I suggest to integrate to the new tuya integration, example: https://github.com/Koenkk/zigbee-herdsman-converters/blob/9a375a90e459e82229961116fc039c792ae35a32/src/devices/tuya.ts#L2498

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sven337]

Not stale, I am planning to fix it.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sven337]

Not stale

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[sven337]

Not stale, still intending to fix at some point

[moose75]

@sven337 , did you where able to investigate the problem ? I just ordered an Alcantara 2 heater and I would like to manage it from HA ..

[sven337]

It's really just a mapping problem, see my comment above https://github.com/Koenkk/zigbee2mqtt/issues/16961#issuecomment-1615738365 Use "auto" in Z2M it means "heat" on the device.

This needs a fix in Z2M but it's only UI, it doesn't limit functionality.

[moose75]

Ah ! OK .. Thanks. Do you know if those heaters works the same way with ZHA ?

[sven337]

I'd assume anything from the company will work the same way yes. If it does not work right out of the box, sniff the Zigbee traffic, I may be able to help.

[daxter62]

Ha have the same with the percale 2 :'(

[sven337]

I should note, this device also mis-reports the target setpoint as the room temperature. It may need a Z2M quirk.

[daxter62]

Yes I confirm that too local temp and the heat comportment

[cyberden]

I have the same issue with local temp and heat. Can it be fixed with a custom mapping in Z2M or is it wrong in the device ? The manufacturer app didn't display the local temp so it might never be returned by the device.