Looks like 0.17.1 has been published to the stable branch - not sure if that was intended? Or just to get a kick out of us all getting moaned at? 
Stumbled across this in HACs, which might provide some extra tweaks for people:
I don’t see any humidity sensors with Honeywell, do I need to use eg zigbee sensors?
That’s correct, I used ‘other’ sensors - air filter in the living room has humidity, in the laundry have one of the Xiaomi BLE sensors for humidity.
Have been testing with the 0.16.30 version lately. There are a few things I wanna share
I own a HGI80
Directly connected to my NAS where it is picked up in a VM running Hass
Do not intend to manipulate the Evohome system via Hass, not excluding it but currently I like the stability of the Evohome system very much. But offcourse in the need to log data
I own a (relative) old non-Wifi Evohome Application softeware 25-jan-2014 / Bootloader 6.0 aug 27 2013.
Configuration via seperate Yaml file which is called from the configuration.yaml file:
serial_port:
port_name: /dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0
baudrate: 115200
timeout: 0
dsrdtr: false
rtscts: false
xonxoff: true
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
schema:
controller: 01:059885
ramses_rf:
enforce_known_list: true
known_list:
- "01:059885": {"alias": "--controller--"}
- "10:030670": {"alias": "OT bridge R8810A"}
- "18:010642": {"alias": "HGI80 patchkast"}
- "30:051821": {"alias": "RFG100 Gateway"}
- "34:177047": {"alias": "T87RF2059 Thermostaat Woonkamer"}
- "04:126354": {"alias": "HR92RT knop1 Woonkamer"}
- "04:126368": {"alias": "HR92RT knop2 Woonkamer"}
- "04:126378": {"alias": "HR92RT knop3 Woonkamer"}
- "03:075455": {"alias": "HCF82 wandsensor Hal"}
- "04:126322": {"alias": "HR92RT knop Hal"}
- "34:176627": {"alias": "T87RF2059 Thermostaat Badkamer"}
- "04:126376": {"alias": "HR92RT knop Badkamer"}
- "04:126366": {"alias": "HR92RT knop Logeerkamer"}
- "34:155573": {"alias": "T87RF2059 Thermostaat Henriette"}
- "04:126382": {"alias": "HR92RT knop Henriette"}
- "34:162993": {"alias": "T87RF2059 Thermostaat Marco"}
- "04:126374": {"alias": "HR92RT knop Marco"}
restore_state: true
current schema resulting from this (left out the packages section below this)
{
"version": 1,
"minor_version": 1,
"key": "evohome_cc",
"data": {
"client_state": {
"schema": {
"main_controller": "01:059885",
"01:059885": {
"system": {
"heating_control": "10:030670"
},
"orphans": [],
"stored_hotwater": {},
"underfloor_heating": {},
"zones": {
"00": {
"_name": "Woonkamer",
"zone_type": "radiator_valve",
"zone_sensor": "34:177047",
"sensor_alt": "34:177047",
"devices": [
"34:177047",
"04:126354",
"04:126368",
"04:126378"
],
"actuators": null
},
"01": {
"_name": "Hal",
"zone_type": "radiator_valve",
"zone_sensor": "03:075455",
"sensor_alt": "03:075455",
"devices": [
"03:075455",
"04:126322"
],
"actuators": [
"04:126322"
]
},
"02": {
"_name": "Badkamer",
"zone_type": "radiator_valve",
"zone_sensor": "34:176627",
"sensor_alt": "34:176627",
"devices": [
"34:176627",
"04:126376"
],
"actuators": [
"04:126376"
]
},
"03": {
"_name": "Logeerkamer",
"zone_type": "radiator_valve",
"zone_sensor": "04:126366",
"sensor_alt": "04:126366",
"devices": [
"04:126366"
],
"actuators": [
"04:126366"
]
},
"04": {
"_name": "Kamer Yet",
"zone_type": "radiator_valve",
"zone_sensor": "34:155573",
"sensor_alt": "34:155573",
"devices": [
"34:155573",
"04:126382"
],
"actuators": [
"04:126382"
]
},
"05": {
"_name": "Kamer Marco",
"zone_type": "radiator_valve",
"zone_sensor": "34:162993",
"sensor_alt": "34:162993",
"devices": [
"34:162993",
"04:126374"
],
"actuators": [
"04:126374"
]
}
}
},
"orphans": [
"30:051821"
],
"device_hints": {}
},
There are a couple of things I notice
- As one of the previous participants noticed it fails to identify the HR92 as actuators. Manually editting the evohome_cc file (while it is deactivated) by adding the HR92 items under the actuators section does not work. If the evohome_cc is activated it will remove those again from this actuators section. My Idea is cant we introduce another flag that will freeze the evohome_cc file so manually changing this file is possible? So forcing certain things instead of relying on the packages sniffing algorithm.
- I have tried to reinclude the HR92 deviced which the Evohome did succesfully and tested the heating system to be 100% sure. Evohome does work without a problem, only this Zone Woonkamer (zone 0 as was already suggested) seems to have this problem.
- It discovered my OpenTherm bridge, but declared it an orphan. Manually adding this bridge under heating_control in evohome_cc it did work. Not like the actuators from zone 0 which it removed it did not remove this item. But it did not discover this by itself.
- The first time it starts it records a error which lookes to refer to maxzones (not in my configuration file)
2021-12-29 16:55:07 ERROR (MainThread) [ramses_rf.protocol.message] RP --- 01:059885 18:010642 --:------ 000C 016 00000011EDAA000011ED92000011EDA0 < AssertionError()
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 364, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 132, in wrapper
return fnc(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 414, in parser_000c
devices = [_parser(payload[i : i + 12]) for i in range(0, len(payload), 12)]
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 414, in <listcomp>
devices = [_parser(payload[i : i + 12]) for i in range(0, len(payload), 12)]
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 399, in _parser
assert seqx[4:6] == "7F" or int(seqx[4:6], 16) < msg._gwy.config.max_zones
AssertionError
- What do the “alias” comments (Wiki) do? I was under the assumption it would use aliases instead of the numbers for the names in HA. (Could be this is my lack of knowledge still of HA…
)
- "10:030670": {"alias": "OT bridge R8810A"}
- The thing I noticed here is that the packetlog rotate does not seem to work. Could this have to do with the fact that my evohome_cc is configured in a seperate yaml file?
- I saw that one of the participants here also had a HCF82, also one here…
So far so good… Currently my system is what I wanted. But just to update all the readers here with what I noticed…
Please send me a packet log of your HA starting up with restore_state: false I still am trying to understand what is going on here…
NB: you should definitely re-bind the TRVs to make sure, as the much more common scenario is that they were simply not bound properly.
Don’t ever edit this file. I can see what you’re trying to achieve, and this is not the way to do it (see below):
You have not expressly identified what you’re trying to achieve, but I think you want to manually add the TRVs as actuators to their respective zones.
The only reason why one would want to do this (other than having a ‘correct’ schema) is to ensure the zones have a heat demand - this is a ‘good’ reason.
To understand the above, you should know that a zone’s heat demand is not available directly (there is no packet to eavesdrop, nor will you get an RP from the controller for any such RQ), but is calculated using the heat demands from the zone’s actuators (when the zone is a Radiator zone).
The proper (supported) way you do this is by adding them to the schema in configuration.yaml, for example:
schema:
controller: 01:059885
zones:
00:
devices:
- 04:126354
- 04:126355
- 04:126354
… or, this should work too:
devices: [04:126354, 04:126355, 04:126356]
You are not exactly right - most ‘sniffing’ (I call it eavesdropping) is disabled by default. However, probing (I call it discovery) is enabled by default. If the discovery fails, you can use eavesdropping to learn what you need to know (but beware what I said about about re-binding), and you can get that data from the 01:xxxxxx (schema) attributes.
After you have this data, be sure to turn eavesdropping off. Then hard-craft a system schema as above.
Just be sure to use the ‘thinnest’ schema you can get away with, and leave the rest up to discovery, and do that only after you have checked by re-binding your TRVs.
Note: You must (also) do the above ‘trick’ for the OpenTherm Bridge, as discovery wont work for it:
schema:
controller: 01:145038
system:
heating_control: 10:048122
This is a limitation of the protocol, there is nothing I can do about it.
(perhaps someone could add the above to the wiki?)
1 Like
Hmmm… I had thought it was the TRVs, not the zone…
Certainly, you cannot discover the sensor for a zone, if it is the controller (you can via eavesdropping) - there is no need to do this, however (unlike for zone heat demand).
Just create a new zone (assume you have enough unused zones), add the TRVs to it, and then delete the old zone 0 (NB: make sure to copy across any schedule first).
You wont have a zone 0 any more - this is fine.
I think I know what is going on here… This is the cause of your invalid schema… Hang on…
This feature is simply not working at the moment.
Yes - a known bug - I had a look & I cannot see why it is broken - it appears not to work with daily log files, but works OK if you use a size limit for the rotation policy.
All, there is a new ‘beta’ release - 0.17.2 - testers please.
You can see it by:
- go to HACS, then select integrations
- use RAMSES_RFs three-dots menu, select Update information, then Redownload
- enable Show beta versions, and select 0.17.2 and then DOWNLOAD (then restart HA)
One nice feature is that heat demand for each zone should now match that in the evohome controller’s UI.
There are bugfixes (@MDIGIT1971 & @iMiMx): some zones not picking up the TRVs
There are a lot of new sensors for OTB relays - a lot.
There is a new feature, where you can listen for particular packets in automations.
Version 0.17.1 is considered ‘stable’, although it has a few known bugs.
@zxdavb I have some further info on the bad 0008 001 08 packets I see for zone_valve zones:
RQ --- 18:204306 01:225826 --:------ 0008 001 08 < Corrupt packet: Invalid verb/code for 01:225826 to Rx: RQ/0008
I started seeing these again after a HA restart. After some experimentation it seems:
- The messages appear every 15 mins if HA is restarted with restore_state: true
- The messages don’t appear after restarting with restore_state: false, except for three times immediately after starting (and then never again)
@iMiMx @ademobile @rbrommer @MDIGIT1971 You all may have been affected by the 000C bug, and had to add TRVs manually via your hand-crafted schema
- you can try 0.17.2 to see if that makes a difference (you can look to see if they appear as
actuatorsin the01:xxxxxx (config)binary sensor
Useful post. Can I ask, when devices are added to configuration.yaml like this, does the list need to be a complete device list for that zone? In other words, does it turn off device discovery for that zone completely, or will discovery still happen and supplement this manual list?
Is it necessary/advisable to add heating_control to configuration.yaml for a BDR91 boiler control relay?
For me discovery has always resulted in heating_control: null in my schema, but if I turn on eavesdropping I’ve found it gets populated with my boiler relay BDR91. Are there any benefits to adding something like heating_control: 13:032648 to my configuration.yaml?
The first thing you need to know is that there are only two possible options, in order of preference:
- start with a cached schema (from a previous run of HA - in .storage/evohome_cc), or
- start with a hard-crafted schema (in configuration.yaml), which can be null (empty)
Regardless of which of the two, the system will try to fill in any gaps. Like, if the temperature sensor is missing for a zone, it will try to discover (probe for) that piece of information during start up.
If there are no devices (actuators) for a zone, it will also attempt to discover. However, if there are any devices for a zone it will not - even if that list is incomplete.
But eavesdropping could fix up the missing bits - NB: eavesdropping is not recommended for this.
Yes, see above.
No, as there are other things disovered for a zone, besides the list of devices (child actuators)
No, the list of child actuators will be considered ‘complete’, as above.
No, it is not necessary - and - as a hand-crafted schema should be as thin as possible - it may well be undesirable.
For most systems, the BDR will be simply discovered. If it is not: then you need to understand why it was not, before you take this step.
For example, some systems don’t have a heating_control BDR (and that is OK), so why stick one in there?
@BuSab I would like to see a packet log just to check your system…
No, unlike TRVs in a zone, where it is necessary to get the correct zone demand.
I’ve updated and have no new errors or warnings.
The boiler and heat demand don’t seem to have changed for me, at the minute my controller service menu says
Appliance, Opentherm bridge 20% which is always correct.
Living Room 1 13%
Living Room 2 13%
Kitchen 0%
Bedroom 0%
Harry’s Room 0%
Spare Room 20%
Home Assistant says
Opentherm bridge 20%
Living Room 1 47%
Living Room 2 47%
Kitchen 0%
Bedroom 10%
Harry’s Room 22%
Spare Room 56%
Yes, the heat demands have not been transformed. For example,Spare Room 56% transforms to 20%, which is what you’re seeing in the UI.
The question is: why is it not transforming?
I was going to write how it is working in my production system and you need to check your system, etc…
… but it isn’t working there either!
Fix coming. Thanks for reporting.
Thanks for the comments on my tour. I tried to help the system by adding the TRVs as actuators to the scheme. What you pointed out configuring the scheme in the configuration file was exactly where I was looking for. I picked it up in the other comments but was not exactly sure where to put it.
I did rebind the TRVs and let the software do its magic but the result stayed the same. Wil do some tests with your comments.
Thanks for a copy of your packet log.
You have identified a regression in ramses_rf - I have since identified, and fixed this bug. Thanks for reporting it. The fix will be included in 0.17.3.
1 Like
Will pick this up, will keep posted. Thanks for all the work!
Hmm… Usefull. I also saw when I was reseaching the matter that the Evhome picked up other socalled devices which I was 100% sure of that I did not have. Also one of them I believe was a boiler relay as was mentioned. Which I found extremely strange since a boiler relay was never attached to this heating system…