I’ve added the below to my configuration file and now seem to have lots of messages in my home assistant logs, is that where I find what your looking for?
logger:
default: warn # prefer warn over info, avoid debug
logs:
# homeassistant.core: debug # to see: Event state_changed, or not
# homeassistant.loader: info # You are using a custom integration for evohome_cc...
# homeassistant.setup: info # Setting up evohome_cc
# custom_components.evohome_cc: info # use info for Schema =
# ramses_rf: debug # for engine state
ramses_rf.message: info # for MSGs received (incl. sent & subsequently echo'd)
# ramses_rf.protocol: warn
# ramses_rf.protocol.protocol: info # for PKTs sent (excl. retries) & received
# ramses_rf.protocol.transport: info # for RF Tx & Rx
# ramses_rf.devices: debug
# ramses_rf.systems: debug
# ramses_rf.zones: debug
How you get a copy of it to me depends upon what “Installation Type” of HA you are running. For example, for “Home Assistant OS”, I use the VS code add-on.
Either way, my 2nd problem, the head demand for TRVs and the Controller frequently shows “unavailable” and a bit later they again turn to normal. This is for ALL my TRVs as well as the Controller, no matter the distrance to my nanocul. Correspondingly, their graphs shows gaps, see pictures. And funny enough, all temperatures from all the STAs never show “unavailable”, their graphs have no gaps
Do you have any idea why is going on? Is there something I’m doing wrong in the configuration?
The answer is…
I have implemented ‘timeouts’ for packets, so that stale data is ignored.
An evohome system will spontaneously send I packets for all sorts of state data, and ramses_rf will augment that by sending RQ packets - the corresponding RP packets become part of the state data too.
If you stop ramses_rf from sending these RQ packets, or if there is another reason why they are not sent, then it is more likely that that state data will expire - you will see that sensor will become unavailable.
These 3150 packets should be sent at least every 20 minutes.
After the first packet was received at 00:40:59, the next packet was never received at approx 01:00:00), so the first packet expired before the 3rd packet was received at 01:20:57
Note (things have been simplified, above), the actual expiry of the packet would be as follows:
01:03:15.718 I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (111%)
That is, packets are expired at 110%, not 200% and so this particular heat demand would be unavailable from 01:03:15 to 01:20:57.
@zxdavb i think that a fan entity the right kind of entity is for an itho fan. What are the benefits of a climate entity? What do you need for kind of logging?
So, here is the challenge for Itho & Nuaire HVAC systems…
With Honeywell central heating / hotwater (CH/DHW) systems, you can tell what type of device you’re dealing with by looking at teh first part of it’s name, for example:
13:123456 starts with 13, and so is a BDR91 (BDR91A or BDR91T)
10:123456 starts with 10, and so is a OTB (R8810, or R8820)
With the ventilation system, that does not appear to be the case - devices need to be fingerprinted by what they’re saying, rather than their device id.
This necessitates a change in the code that will be a bit of an architectural change…
I would be curious what features people may be hoping for?
Please keep reporting bugs!
A little late, but as we became parents and the time for HA became a bit sparse.
I have no bugs to report everything is working very well. My OTB doesn’t seem to offer any more information then already implemented. The fake sensors work great and as it is working so well I found myself adding more zones (which is relatively easy with underfloor heating). My setup worked reasonably well, but adding zones cheap and easily makes for fine-grained control. Again thank you for all your efforts, it is really appreciated!
As for feature request I have quite some ideas and I don’t know what would be possible and what isn’t:
Fake BDR91 (using for example a Shelly 1 as a fake BDR-91, maybe possible to make any switch-domain device a possible ‘target’)
Group entities from the same Evohome device in a HA-device (so the temperature and the battery level of a thermostat would be grouped in one device)
More zone-info when combined with underfloor heating. Currently the climate-entities don’t show heat_demand for zones heated with under_floor heating (the attribute is always null).
A bit more of the above, but very likely protocol limited: make all underfloor heating zones status information available in HA. So I can see if the zone ‘open’ or ‘closed’ for all 5 or 8 (with the HCE80 extension). To take it even further: control the status of the relais (in our case it needlessly switches on/off as we have no separate water pump for the ufw.
End goal (but likely not possible) have the ability to completely fake a controller and make the Evohome unit obsolete (probably very few peoples cup of tea, but the Evohome controller has some quirks in my specific setup and I would love to get rid of them)
