WolfRevo
commented
3 years ago Hi,
I tried to understand other custom quirks to be able to adapt them to my issue. Prior to start testing I would really ask you to look at my first Idea of enhancing the existing quirk for Danfoss to see if I am on the right track or completely misunderstood the concept of ZHA custom quirks.
"""Module to handle quirks of the Fanfoss thermostat.
manufacturer specific attributes to control displaying and specific configuration.
"""
import zigpy.profiles.zha as zha_p
from zigpy.quirks import CustomCluster, CustomDevice
import zigpy.types as t
from zigpy.zcl.clusters.general import (
Basic,
Identify,
Ota,
PollControl,
PowerConfiguration,
Time,
)
from zigpy.zcl.clusters.homeautomation import Diagnostic
from zigpy.zcl.clusters.hvac import Thermostat, UserInterface
from zigpy.zcl import foundation
from zhaquirks.const import (
DEVICE_TYPE,
ENDPOINTS,
INPUT_CLUSTERS,
MODELS_INFO,
OUTPUT_CLUSTERS,
PROFILE_ID,
)
from zhaquirks.danfoss import DANFOSS
COMMAND_SETPOINT_COMMAND = "setpoint_command"
MANUFACTURER = 0x1246
OCCUPIED_HEATING_SETPOINT_ATTR = 0x0012
class DanfossThermostatCluster(CustomCluster, Thermostat):
"""Danfoss custom cluster."""
manufacturer_server_commands = {
0x40: ("setpoint_command", (t.enum8, t.int16s), False),
}
manufacturer_attributes = {
0x4000: ("etrv_open_windows_detection", t.enum8),
0x4003: ("external_open_windows_detected", t.Bool),
0x4010: ("exercise_day_of_week", t.enum8),
0x4011: ("exercise_trigger_time", t.uint16_t),
0x4012: ("mounting_mode_active", t.Bool),
0x4013: ("mounting_mode_control", t.Bool),
0x4014: ("orientation", t.Bool),
0x4015: ("external_measured_room_sensor", t.int16s),
0x4016: ("radiator_overed", t.Bool),
0x4020: ("control_algorithm_scale_factor", t.uint8_t),
0x4030: ("heat_available", t.Bool),
0x4031: ("heat_supply_request", t.Bool),
0x4032: ("load_balancing_enable", t.Bool),
0x404A: ("load_estimate_radiator", t.uint16_t),
0x404B: ("regulation_setPoint_offset", t.int8s),
0x404C: ("adaptation_run_control", t.enum8),
0x404D: ("adaptation_run_status", t.bitmap8),
0x404E: ("adaptation_run_settings", t.bitmap8),
0x404F: ("preheat_status", t.Bool),
0x4050: ("preheat_time", t.uint32_t),
0x4051: ("window_open_feature_on_off", t.Bool),
0xFFFD: ("cluster_revision", t.uint16_t),
}
async def write_attributes(self, attributes, manufacturer=None):
"""Send SETPOINT_COMMAND after setpoint change"""
if "occupied_heating_setpoint" in attributes:
setpoint = foundation.ReadAttributeRecord(
OCCUPIED_HEATING_SETPOINT_ATTR, foundation.Status.SUCCESS, foundation.TypeValue()
)
cmd_payload = super().Command()
cmd_payload.status = 0
cmd_payload.tsn = self.endpoint.device.application.get_sequence()
cmd_payload.command_id = 0x40
cmd_payload.function = 0
cmd_payload.data = [1, setpoint]
await super().command(
COMMAND_SETPOINT_COMMAND,
cmd_payload,
manufacturer=MANUFACTURER,
expect_reply=True,
tsn=cmd_payload.tsn,
)
return super().write_attributes(attributes, manufacturer)
class DanfossUserInterfaceCluster(CustomCluster, UserInterface):
"""Danfoss custom cluster."""
manufacturer_attributes = {
0x4000: ("viewing_direction", t.enum8),
0xFFFD: ("cluster_revision", t.uint16_t),
}
class DanfossDiagnosticCluster(CustomCluster, Diagnostic):
"""Danfoss custom cluster."""
manufacturer_attributes = {
0x4000: ("sw_error_code", t.bitmap16),
0x4001: ("wake_time_avg", t.uint32_t),
0x4002: ("wake_time max duration", t.uint32_t),
0x4003: ("wake_time min duration", t.uint32_t),
0x4004: ("sleep_Postponed_count_avg", t.uint32_t),
0x4005: ("sleep_Postponed_count_max", t.uint32_t),
0x4006: ("sleep_Postponed_count_min", t.uint32_t),
0x4010: ("motor_step_counter", t.uint32_t),
0xFFFD: ("cluster_revision", t.uint16_t),
}
class DanfossThermostat(CustomDevice):
"""DanfossThermostat custom device."""
signature = {
# <SimpleDescriptor endpoint=1 profile=260 device_type=769
# device_version=0 input_clusters=[0, 1, 3, 10,32, 513, 516, 1026, 2821]
# output_clusters=[0, 25]>
MODELS_INFO: [(DANFOSS, "eTRV0100")],
ENDPOINTS: {
1: {
PROFILE_ID: zha_p.PROFILE_ID,
DEVICE_TYPE: zha_p.DeviceType.THERMOSTAT,
INPUT_CLUSTERS: [
Basic.cluster_id,
PowerConfiguration.cluster_id,
Identify.cluster_id,
Time.cluster_id,
PollControl.cluster_id,
Thermostat.cluster_id,
UserInterface.cluster_id,
Diagnostic.cluster_id,
],
OUTPUT_CLUSTERS: [Basic.cluster_id, Ota.cluster_id],
}
},
}
replacement = {
ENDPOINTS: {
1: {
INPUT_CLUSTERS: [
Basic,
PowerConfiguration,
Identify,
Time,
PollControl,
DanfossThermostatCluster,
DanfossUserInterfaceCluster,
DanfossDiagnosticCluster,
],
OUTPUT_CLUSTERS: [Basic, Ota],
}
}
}In short I added some imports and three constants at the beginning to work with. In the class DanfossThermostatCluster I added the new command to manufacturer_server_commands (hopefully correctly interpreted) and last but not least I replaced the write_attributes function to issue the custom command every time the occupied_heating_setpoint for an thermostat is updated. I struggle a bit as I don't know how the corresponding thermostat should be adressed for which write_attributes is called.
So could someone please tell me if this is completely rubbish or if this should be the way to go?
Thanks in advance.
Adminiuga
Stefano0042
MattWestb
albalaing
sarangnemo
Hedda
github-actions[bot]
Describe the bug The problem is well described here: https://community.home-assistant.io/t/danfoss-ally-valve-slow-actuator-response-solved/254939
So if you issue a new temperature target setpoint for the thermostat using HA+ZHA the thermostat uses the internal PID mechanism to control the valve which results in slow (and sometimes unexpected) valve control movements.
# To Reproduce Steps to reproduce the behavior:
Expected behavior The pi_heating_demand should change much faster
Screenshots
Additional context The issue is already fixed in deconz (https://github.com/dresden-elektronik/deconz-rest-plugin/pull/4408) as well as in the Koenkk/zigbee-herdsman-converters (https://github.com/Koenkk/zigbee-herdsman-converters/pull/2592)
So mainly the solution is well described in the official document (https://assets.danfoss.com/documents/176987/AM375549618098en-000101.pdf):
The zigbee coordinator needs to send a Setpoint Command including the HeatingSetpoint itself aswell as a bitmask (enum8 set to 1) to circumvent the thermostats PID mechism.
Based on that I started to read carefully all instructions of the zha quirks because I wanted to sort out if I can create a custom zhaquirk (based on https://github.com/zigpy/zha-device-handlers/tree/dev/zhaquirks/danfoss) fixing this issue.
While I already identified that I need to add a custom output cluster in the replacement (and I guess for that I also need to add the thermostat output cluster to the signature itself?) I didn't find any good example (first I thought the tuya custom quirks were good to understand but I honestly gave up) on how to understand: 1) how do I implement a custom command in the quirk? 2) (in this specific case) how can I access the occupied_heating_setpoint sent by HA+ZHA to the thermostat (which is based on the solution above an int16) 3) how can I create a custom command like "setpointType (enum8) + HeatingSetpoint (16bit)" where the HeatingSetpoint is occupied_heating_setpoint from 2) and the setPointType is set to 1 (the final command input needs to be masked in hex I guess)?
Also just to recap how it works: ZHA is using the climate.py integration in HA and calls the function
which eventually calls (in the case of the Danfoss Ally):
which is implemented in core/homeassistant/components/zha/core/channels/hvac.py
so there in normal operation the following code should be executed:
That's where I got lost to find the appropriate calls into zigpy and how the zha quirks overwrite the zigpy code to be executed (or is this assumption already wrong?).
Any help appreciated. Surely you also can fix this yourself if you think this is faster than to teach me ;) (because I won't have time within the next 3 weeks). If you fix it yourself I can learn from your implementation to be able to handle such requests myself in the future.