Hi, I’ve been using version 0.30.9 of ramses_cc successfully for a week or two, but since upgrading to 0.31.1 I’ve noticed that the following binary sensors are showing as unavailable and reporting as no longer being provided by the integration:
Is this normal/expected for 0.31.1? I can’t see any obvious warning/errors in the HA logs for the ramses components. When I switch back to 0.30.9, these entities are restored.
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
#packet_log:
# file_name: packet.log
# rotate_backups: 7
restore_cache:
restore_schema: true
restore_state: true
ramses_rf:
enforce_known_list: true # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema
01:215596:
zones:
"00": {sensor: 01:215596}
known_list:
01:215596: #controller
04:038777: #bedroom 2
04:038779: #kitchen
04:038781: #bedroom 1
04:038783: #lounge
04:172415: #bathroom
13:129802: #boiler relay
18:138258: {class: HGI} #gateway_interface
So reading the manuals on the Nuaire it looks like you could set a 5th button for those not using Humidity control maybe. this is Boost. (not to be confused with Boost button that is actually purge)
Boost only puts the unit up by 1 speed vs full speed of purge (the 4 way boost button)
I assume we can send the Boost command that the Humidity sensor uses to do this. then using any humidity sensor or similar you can then control the PIV using all these 5 options.
So practically the integration is not usable at this moment for what I want to achieve, no? Meaning in case a window is open to put the heat in that room to 5 degree celsius in permanent mode and than after the window is closed to return to the existing schedule (x degree celsius from let’s say 18.00 to 20.00).
I believe it has been looked at briefly, but that opens up a huge can of worms, as it would require “translation” of heat demand/valve position between something both evohome and the TRV understand (IF even available on the latter). The only way I see this being doable or possible is if you could fake a zone valve but that would mean open/close only and that’s something you should be able to create yourself by automations in HA if it’s a secondary or tertiary (etc) TRV. Because it would still need a possibility to tell the boiler/furnace/zone valve to “fire”. But building it into the integration seems daunting, not in the least because there are so many TRVs for sale.
Should be possible if you clear all your schedules and rely on HA for your scheduling. That way you will have HA set the desired temps. All optimizations for schedules are out the window then though and might have unwanted side effects, like evohome not learning the heating behaviour. For example, I have a few rooms with very short schedules for heating and it’s having trouble to learn how long and it should heat for and over shoots easily. Another identical room has a steady schedule and rarely overshoot.
BTW, I believe there is a distinction between the “off” setting on the controller and a zone being “off” i.e. 5 degrees set point and turning a HR92 to off.
Most thermostats save the current temperatur value if it switched to off. In your case you need to store the temperatur value manually to a number Helper. The Helper need to be created manually before you can use it in an automation.
You automation should store the current temperatur to the helper, then turn the thermostat to 5 and wait for the trigger close. If close is triggered then get the value from the helper and use it as set temperatur.
@ionutm80 Just created and tested an automation for you - let me know if it works
Some of the automations also failed after the upgrade
unknown service: ramses_cc.set_dhw_mode
when I checked, all dhw releted services are missing, but returned after the rollback