It is. Generic calibration adds the calculated temperature difference on top of the thermostat target temperature. Just check if your thermostats provide an entity or service for calibration.
It is calibrated by AHC from the external sensor.
In addition, I cannot manually enter a higher temperature in the thermostat card because it keeps resetting it.
I canât understand why AHC does what it wants and doesnât adjust the set temperatures as it should.
Normally only 19 °C should be shown here. But these are incorrect settings.
I suspect that this setting is incorrect.
.
.
Do I need this? Should take over AHC.
Could you navigate to your template editor and paste this. Edit the climate entity to yours and share the result with me.
{% set valve = 'climate.YOUR_CLIMATE_ENTITY' %}
{{device_entities(device_id(valve)) |
expand |
map(attribute='entity_id') | list }}
Generic calibration is for thermostats that donât provide a special calibration entity. If you tick this option, the target temperature gets manipulated.
Also the calibration only gets triggered if there is a temperature change. You can force it by holding the sensor in your hands for example. Donât expect calibration just right after you saved the automation.
Proximity, fund a fix.
Created a template sensor
template:
- binary_sensor:
- name: "Lilli on way home"
state: >
{{ states('sensor.skovkrogen_3_2_nearest_distance') | int < 9100 and states('sensor.skovkrogen_3_2_nearest_direction_of_travel') == "towards" }}
and then add the âLilli on way homeâ, as a guest.
Hi, Iâm trying to make this blueprint work with no success so far.
We are starting spring and I wanted to use this for cooling rather than heating. Does it work for cooling?
You can pick a heat_cool HVAC mode, but I cannot make it work.
Every time I turn on my AC unit manually, itâs turned off by the automation a few minutes later.
Can reproduce it every time.
- Window open sets the TRV setpoint to a low temperature.
- When
Physical Temperature Change / Sync
is active, this triggers the script again and it sets myComfort Temperature
helper to this lower value.
- This change of the
Comfort Temperature
triggers the script again and it deletes the scene
When the window closes it stays on the low temperature because that is now set as Comfort Temperature.
It seems to be limited to add a maximum of 2° to the target temperature. In my case I will need a lot more, since my thermostat jumps to close to 30° measuremnt, due to itâs shitty installation location. Will also have to work on this, yeah.
I use a custom quirk, namely ts0601_trv_siterwell.py , which exposes the switches, but names them âswitchâ and adds an offset feature, which seems to hang/crash the thermostat when given decimals. I donât find the source for this quirk right now, but will see, if there is a better fitting one in the mentioned repo. Thx for this!
As for the requested YAML: Sure, this is what it is at right now. Tried everything that came to mind, thoughâŠ
Iâm not sure where âinput_mode_room_temperature_thresholdâ comes from, or what it doesâŠ
alias: đ„ Advanced Heating Control
description: ""
use_blueprint:
path: panhans/heating_control.yaml
input:
input_trvs:
- climate.tze200_hhrtiq0x_ts0601_thermostat
input_temperature_sensor: sensor.thermo_sensor_wz_temperatur
input_temperature_comfort: input_number.zieltemperatur_manuell
input_calibration_options:
- generic_calibration
input_temperature_comfort_static: 25
input_temperature_minimum_static: 22
input_temperature_minimum: input_number.zieltemperatur_manuell
input_calibration_timeout:
hours: 0
minutes: 0
seconds: 2
input_mode_room_temperature_threshold: 30
input_calibration_delta: 1
Besides from that, I need a second thermostat and I will not buy that one again.
Does anyone have a good recommendation, best available in Germany/Europe?
It should be able to take an external offset in ZHA, with a range as large as possible.
AHC does that for you, you should see the external sensor temperature as Local Temperature
in the Z2MQTT settings.
If it does not change, try to modify the âExternal Temperature Inputâ slider and see if it starts updating after a couple of minutes. I have seen the external temperature not updating correctly until I set a value with the slider once (was after a factory reset of the E1). Might be a bug in Z2M.
You should not use the Generic Calibration feature since the E1 will use the external temperature once it is working (so no further âcalibrationâ is needed).
Also according to your Z2M settings page your thermostat is not calibrated, so it probably just does nothing at all or drives the valve to the wrong positions.
So I looked for a quirk at the link given and also found the right one. This one though doesnât give ma additional switches and no offset at all. Either that, or the quirk is not loaded. I removed the old one and put the new file right in place, so I guess it should work. In the quirk itself I can find mention of my device tze200_hhrtiq0x. How would I verify the custom_quirk is actually used?
class SiterwellGS361_Type2(TuyaThermostat):
"""SiterwellGS361 Thermostatic radiator valve and clones (2nd cluster signa>
signature = {
# endpoint=1 profile=260 device_type=81 device_version=0 input_cluster>
# output_clusters=[10, 25]>
MODELS_INFO: [
("_TZE200_jeaxp72v", "TS0601"),
("_TZE200_kfvq6avy", "TS0601"),
("_TZE200_zivfvd7h", "TS0601"),
("_TZE200_hhrtiq0x", "TS0601"),
("_TZE200_ps5v5jor", "TS0601"),
("_TZE200_owwdxjbx", "TS0601"),
("_TZE200_8daqwrsj", "TS0601"),
("_TZE200_czk78ptr", "TS0601"),
("_TZE200_2cs6g9i7", "TS0601"), # Brennenstuhl Zigbee Connect 01
("_TZE200_04yfvweb", "TS0601"), # Appartme APRM-04-001
],
Great! But I also will check this in my revision.
Sadly I just can check this in my testing environment because I donât own a AC. But could you share me your automation configuration in yaml or a trace log after the AC turns off? (description in the first post)
Yes, this damn physical change workaround. I will check if I can get another workaround for this.
Most thermostats allows ± 5°C. Aqara, Popp / Danfoss / Hive / Nedis let you set an comoplete value of the measured temperature but I donât know how they handle it under the hood.
You have to remove the devices out of your zigbee mesh, delete / rename the extension of your old custom quirk, restart home assistant and pair the thermostat again.
Yes, delete the input first. This is just for testing purpose. You canât break anything.
Must admit, Iâd love to keep is simple and only use AHC with any hacks.
"update.thermostat_pc_raum",
"text.thermostat_pc_raum_schedule_settings",
"switch.thermostat_pc_raum_schedule",
"sensor.thermostat_pc_raum_device_temperature",
"sensor.thermostat_pc_raum_battery",
"number.thermostat_pc_raum_away_preset_temperature",
"binary_sensor.thermostat_pc_raum_valve_alarm",
"switch.thermostat_pc_raum_valve_detection",
"binary_sensor.thermostat_pc_raum_window_open",
"switch.thermostat_pc_raum_window_detection",
"switch.thermostat_pc_raum_child_lock",
"button.thermostat_pc_raum_calibrate",
"binary_sensor.thermostat_pc_raum_calibrated",
"number.thermostat_pc_raum_external_temperature_input",
"select.thermostat_pc_raum_sensor",
"climate.thermostat_pc_raum",
"binary_sensor.thermostat_pc_raum_setup"
Is that enough for you or do you need more?
That is exactly what I did. Maybe the quirk just makes it work better that without one, I donât know. Also not important atm, because I donât really care about setting the temperature offset, since it will be too small, anyway. Setting the target temperature should do the trick, I just have to get it to workâŠ
Btw the quirk I used before, which exposes a bit more but hast issues with non-rounded setoff-values, came from here: Status of tuya TRVs implanted in ZHA. · zigpy/zigpy · Discussion #653 · GitHub
A different issue
I have a normal schedule 08.30 to 21.30
I have a âPresence schedule 21.30-03.00â
(All motion, is group of all motion sensors and a mmwave in the living room, hence its constant on)
(AHC Stue, is the AHC sensor from the snip in OP)
(AHC tilstĂŠdevĂŠrelses tid, is the scheduler user for presence)
the issue is when normal scheduler end, and I must wait the (10 min in config) for the trvs to kick back it can take more then 10 min, and Danfoss Ally, will after a change from 23C->20C->23C, opens the valve quite a lot for the some time before reverting to normal.
I donât know if there is a way to prevent this ?
Using the quirk from the official zigpy/zha_handlers repository did not really work. It is loaded - found it in the logs - but while the device itself works, even though lacking some features, AHC gives me a warning in the logs: Your selected hvac mode auto isn't support by some of your climate entities: climate.tze200_hhrtiq0x_ts0601_thermostat
This goes for"heat" and âautoâ. In the end it shouldnât matter, since all I want AHC to do is set the target-temperature, but still, itâs ugly in the logsâŠ
Also it says I should install the âuptime integrationâ. Will look into that. In the meantime I will revert to my former quirk, which btw. is from here (posted a too generic link before): GitHub - jacekk015/zha_quirks: All quirks in one place
What do you mean with for Tado you should use the custom integration for calibration? Where can I find this custom integration?
Yes, the manufacturer:
{{ device_attr(âclimate.YOUR_THERMOSTATâ, âmanufacturerâ) }}
I have to add it to the aqara/xiaomi group.
Donât know the state of the official integration but last year calibration wasnât supported and the custom integration did it. Could you navigate to your services /action in the developer tools and have a look if tado.set_climate_temperature_offset exists?
This and a few others also show this error. Do you know anything about this?
Will there be a patch that fixes the calibration and is the error on the TRV related to the calibration?
As I said, I need the manufacturer. Just paste the code into the developer template editor and post the returned value here. There are 4 different calibration strategies depending on the manufacturer.
The manual said the exclamation mark means fault. But there is no further information.