The DHW valve ID can be detected from binary_sensor.01_078710_status
While I have seen many systems that don’t use any appliance control. I have yet to see a system that uses the Evohome HW kit but no HW valve device. So if there is a stored_hotwater 07: sensor, there should be a 13: hotwater_valve
The only time I can see that the hotwater_valve can have a relay that isnt detected is if someone managed to pair the old read only obsolete relay units. But I don’t even know if those would pair in HW mode. The HW kit always came with a BDR91
sensor.01_078710_hw_heat_demand does not track the HW heat demand. Infact it doesn’t appear to be updating at all. Maybe a bug. I have raised this.
FA_relay_demand is not an entity that is created by ramses_cc automatically you have to create it using a field template from the climate.01_078710 state attributes
sensor.13_109598_relay_demand does a better job at tracking the DHW demand. But it often has a delay.
However the binary_sensor.13_109598_active is by far the best indication of real demand on the DHW valve. And given that DHW can only ever be 0% or 100%, this is the sensor I prefer.
EC needs to be able to work with the default settings provided by HA and ramses_cc…Not everyone is a tinkerer.
I would have to check - but this looks like TCC JSON - I can’t recall if ramses_cc ever exposed it in this way… Even if it did, I have no short-term plans to do this in future with ramses_cc.
ramses_cc (not ramses_rf) did support the available attr in ver 0.22.40… But this was a mistake, and so was removed (it made the whole entity unavailable). I will not be putting this back, except if all comms with the controller is lost.
All that is moot really - EvoControl can simply check if the zone’s temperature attr is None: almost all the time this is will be equivalent to is_available is False.
It is when the zone’s sensor (current temp) is not reporting to the controller.
AFAIK, the equivalent for actuators only ever appears in the log file, and not in the controller UI.
Yes, I already do that as a fallback, where None in Python appears as null in JSON.
The TCC API returns an array activeFaults for every zone/dhw and also for the controller itself. These can report error states that are not necessarily shown on the Evotouch screen but still reportable. Here’s an example:
TempZoneSensorCommunicationLost is actually a separate concept to isAvailable (which is always nested as a sub-parameter of temperatureStatus so it seems to be related to temperature availability only and not to comms).
The equivalent for actuators does exist — TempZoneActuatorCommunicationLost is regularly reported in activeFaults. When I see it, I have an icon to report it.
Only 5% of EvoControl users have an RF device so 95% rely wholly on TCC which is therefore the definitive backbone of EvoControl. I only use an RF connector as a ‘nice to have’ to augment the dataset with measurements either not provided at all by TCC or only to a degraded extent by TCC. With regard to schedules, RF adds nothing that’s not already provided by TCC so while the skill makes heavy use of schedules for features like e.g. schedule-shifting and multiple schedules, there’s no need to use RF for those features. I don’t ever look at the packet log.
Where I do rely on RF is for heat demand, 0.1 deg resolution vs 0.5 deg for all temperatures, battery percentage instead of just a binary ok/low (for capable devices), and device level faults instead of just zone level in multi-device zones. I also use it to discern whether the DHW relay is on/off which is not necessarily aligned to the schedule due to the inherent hysteresis.
In normal use, EvoControl reads data via RF but never writes it, so any setpoint or state changes requested by the user go via TCC (again, because RF does not ‘add’ anything here). However, whenever TCC is down for maintenance, EvoControl switches to mode where it also writes via RF so that users can have some degraded usability of the skill.
Thanks, I went for another solution. An USB extender over UTP (I didn’t know it even existed). Because my house is fully UTP wired I can place the SMM-D2 wherever I want. Normally it is a bit an expensive solution, but I found this one second-hand: Aten UCE260-AT-G Usb 2.0 Extender
I’m struggling for a while now to configure the configuration.yaml file for a simple Evohome setup. I’ve read the FAQ of ramses_cc multiple times, but I have the feeling that I miss some information. Other ‘starters’ might experience the same.
I have started a simple configuration and all my devices are recognized (Evohome controller, Evohome bridge, 5 HR91 valves,1 room thermostat:
The ‘Woonkamer’ gets 4 actuators. In fact it has 3 HR91 valves (and currently only 3 because I’ve changed the setup recently and removed one). Room 02 ‘Kinderkamer’ has 0 valves in the setup.
I tried several versions in the configuration, of which this is one, which doesn’t work:
Can anybody provide an example of an Evohome setup, or explain a bit more in detail how I can move one of the actuators to room 02?
Lastly, is it possible to give the entities in HA custom names? I don’t like the ‘04:014742’ naming that much. It would be great if I can somehow rename this to Living room. I have tried to add an ‘alias’ as a parameter in the known_list of the configuration, that works but it becomes an attribute and not the main name.
Same here, I upgraded to 0.31.7 and added disable_qos: false to the config, as requested by David 7 days ago.
Logger: ramses_rf.gateway
Source: runner.py:188
First occurred: 16 februari 2024 om 13:42:52 (140 occurrences)
Last logged: 11:13:23
Failed to send 22F8|RQ|32:123456: 22F8|RQ|32:123456: Other error
Usually the schema doesn’t lie. Maybe, somewhere along the way, you removed one of the TRV’s from a zone and switched it around with another one without unbinding the TRV from the previous zone. You can try to unbind all the HR91s and then re-adding them. To unbind fully you have to both unbind in the controller/Evohome module AND the TRV’s themselves. Fastest way to unbind the TRV’s in the controller is to change the zonetype to electric in the controller. It warns you are about to remove all bindings. Confirm this step. Once you get the interface to bind a new device, back out of this menu with the red button. You are now left with a zone, unbound from all TRV’s. Do this for all zones. Next you have to unbind the TRV’s themselves. You so this by following these instructions: KCS UK
After that, you can bind the TRV’s to the appropriate zones by switching back from an electric to a TRV or radiator knob zone.
Thank you for the advise. In case the schema is normally created correctly, re-binding sounds as the solution indeed.
Do you also have a tip how to get rid of the older thermostats from the integration? I’ve removed this valve, but it keeps on being reported as ‘unavailable’. I cannot delete it through the HAS layout
The numbers won’t change, so once you’ll be setting it up again it will be instantiated and become available. Also, remove it from the “zone” line as you have it above, this shouldn’t be needed. It’s only needed if you want to use the evohome controller as the temperature sensor. If you’ve set it up as using the evohome controller as sensor in zone 00, it should be added there for zone 00. For other zones, it should automatically select the correct TRV
Very strange, I just did exactly what you said.
I’ve removed all TRV’s by long-press the pairing button. Switched the zonetype to electric on the controller, confirming that I loose all for all 3 of my zones. Switching all back to heating. Removed the batteries of 3 of the 5 TRV’s (just to be sure). Repaired the two remaining powered to the zone Woonkamer and Tuinkamer.
Deleted the ramses_cc integration, deleted all the entities in HA. Powered down the SMM-D2 receiver.
Plugged everything in again, installed ramses_cc. First the binary_sensor.01_236903_status entity was empty, but after a minute all (wrong) TRV’s appeared under ‘Woonkamer’ again. While they are pysically on my table, with the batteries removed.
I suspect that either the Evohome Controller or the SMM-D2 stick is remembering these devices somehow. Any idea how to get rid of this? I prefer to not reset the Evohome device, as this will have other consequences for me
“Configuration warnings
Invalid config for ‘ramses_cc’ at configuration.yaml, line 46: ‘restore_state’ is an invalid option for ‘ramses_cc’, check: ramses_cc->restore_state”
Just updated HAOS on my green to version 12.0 and I’m now getting this error logged:
Logger: homeassistant.components.climate
Source: components/climate/init.py:354
Integration: Climate (documentation, issues)
First occurred: 15:27:23 (1 occurrences)
Last logged: 15:27:23
Entity climate.01:215596 (<class ‘custom_components.ramses_cc.climate.RamsesController’>) implements HVACMode(s): heat, off, auto and therefore implicitly supports the turn_on/turn_off methods without setting the proper ClimateEntityFeature. Please create a bug report at Issues · zxdavb/ramses_cc · GitHub
This post from a couple days ago suggests it might relate to a change in HA 2024.2 update?
EDIT: sorry forgot to add, I’m using RAMSES CC version 0.41.7
mode where it also writes via RF so that users can have some degraded usability of the skill.
