No, I temporary moved to another integration for controlling my HRU. Now I have more time to try evohome cc.
This is my config:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache:
restore_schema: false
restore_state: false
packet_log:
file_name: packet.log
rotate_backups: 28
orphans_hvac: [18:126620, 37:154011, 29:060945]
known_list:
18:200467: # evofw3
21:038634: {class: RFS, _note: Spider Thermostat (CCU-12T20)} # Spider (CCU-12T20)
18:126620: {class: FAN, _note: HRU ECO 300 } # HRU i guess
37:154011: {class: CO2, _note: Co2 sensor (VMS-12C39)} # Co2 (VMS-12C39)
29:060945: {class: REM, _note: Co2 Remote} # Co2 Remote
block_list:
18:114076: # Foreign gateway
Now iām having the same issue of multiple 18:xx (more than one HGI80-compatible device message ) since my HRU has the same prefix as the gateway.
Edit:
To clarify iām using evohome_cc (0.20.22c) now and not ramses_rf. Is there a way to use use_regex in evohome cc? Porting the yaml does not seem to work as it does not know the [use_regex] is an invalid option for [ramses_cc].
I think weāve just got to give up on these warnings:
There appears to be more than one HGI80-compatible device (active gateway: 18:200467), this is unsupported, configure the known_list/block_list as required
use_regex is too powerful for everyday use - it is being deprecated.
Does the message get parsed regardless of this error? And since device classes can be set, why not pass through the messages which are not off class HGI?
In short, ramses_rf is split into two layers. The concept of HGI is in the upper layer, and the 18: is in the lower layer, where the checking for duplicate HGI80s is done.
Unfortunately, as the HVAC guys know, not every 18:xxxxxx is a HGI80: some of them are HVAC devices.
Generally, for:
logged warnings: Yes, the packet is passed up to the upper layers of the protocol
exceptions: No, the packet is not processed further.
< There appears to be more than one HGI80-compatible device (active gateway: 18:200467), this is unsupported, configure the known_list/block_list as required
It is currently the master branch - you can try that, via HACS, if you like.
So Iām finally giving up on trying to figure out why my HGI-80 will talk to my Raspberry Pi but not my Debian box. Iām gonna get a atmega328 or atmega32u4. Is one easier/better than the other or are they functionally identical? Thanks. Any other recommendations on specific hardware which is best? Iād like to just get a box with a case that I donāt have to monkey around with if possible (I hate hardware). The SSM-D2 is not in stock ATM.
In any case, there are good reasons to get an evofw3 based system, and the SSM-D2 is the best. I am sorry, if it is not in stock - I donāt know if @arjenhiemstra is selling something compatible?
Hi all,
yesterday i updated the home assistant operating system to 8.5. now it doesnāt recognize my HGI80 anymore. do other people have the same issue?
if you havenāt update yet, be warned!
Iāve just updated to 0.20.22c and am receiving the following error in the logs:
Logger: ramses_rf.protocol.transport
Source: runner.py:119
First occurred: 21:47:38 (68 occurrences)
Last logged: 22:23:41
have seen tx_rcvd( I ā 03:123000 --:------ 03:123000 30C9 003 000898), rx_rcvd=None
have seen tx_rcvd( I ā 18:131597 63:262142 --:------ 7FFF 023 00110182D6E3711A33304339204930333A313233303030), rx_rcvd=None
have seen tx_rcvd( I ā 03:123000 --:------ 03:123000 30C9 003 00088E), rx_rcvd=None
have seen tx_rcvd( I ā 18:131597 63:262142 --:------ 7FFF 023 00110182D6E3A84A33304339204930333A313233303033), rx_rcvd=None
have seen tx_rcvd( I ā 03:123003 --:------ 03:123003 30C9 003 000820), rx_rcvd=None
Iām also getting this warning:
Logger: ramses_rf.protocol.protocol
Source: runner.py:119
First occurred: 21:13:48 (38 occurrences)
Last logged: 22:24:29
Iāve also noticed that the accuracy of the zones has dropped from 1 decimal point to no decimal points. Is this intended as I canāt find any reference to it?
I also hadnāt realised that I would have to update all my automations to ramses_cc rather than evohome_cc. It might be worth adding this to the upgrade instructions/wiki.
The above are not errors in from your point of view:
ā¦ neither are these.
I will reduce this logging on the next drop.
This shouldnāt happen - although I have made changes to that code recently, so it sounds like could be a bug - I will investigate:
class EvohomeZoneBase(RamsesEntity):
"""Base for any RAMSES RF-compatible entity (e.g. Controller, DHW, Zones)."""
_attr_precision: float = 0.01 # PRECISION_TENTHS
ā¦ I recently changed it from a resolution of 0.1 to 0.01.
I am sorry it wasnāt clear - anyone can amend the wiki:
Thanks, David. Temps are now back at 1 decimal point of accuracy.
I hadnāt meant the comment about the changes to automations as a criticism, itās just it took me by surprise and hence took longer to upgrade than I expected, and someone else may miss it and wonder why none of their automations work anymore.
Hey all, given HR91s are out of stock and 92s are about Ā£95 - is there any way to emulate an Evohome TRV using a generic zigbee one? Or some other brand? Using HA as the conduit? I have a full Evohome system but 3 valves have broken recently
No - not currently, but this was always visioned, and would be simple enough to implement (note: simple is not the same as easy - it is simple to walk 10,000km: just stick one foot in front of other, and repeat until end).
Currently, all faking is for sensors and remotes (which is really just a special type of sensor): there is no faking for actuators.
An example of an actuator is a BDR91 (a relay).
In fact, TRVs are the most complicated thing to fake (other than a controller) - since they are both a sensor (and I am talking about valve position, not temperature), and an actuator.
And no-one knows the exact function, valve_position(current_temperature, setpoint)ā¦
So, I havenāt done it because it would be maybe a couple hundred hours of work to do properlyā¦
If there was demand from people, I could look at itā¦
Hi, Iāve updated to the latest version and all sensors got pickedup, including 3 UFH zones. I got one automation using āRAMSES RF: Set the DHW modeā and found that override duration set is actually in seconds then minutes, and it only accept 500 as the min.
Thanks,
Hi, If i put anyting below 500 and try to run , get mesage shown in the photo. When I put 3600 as per code below, it will run and sets override for 1 hour
Initially I thought that 500 may be taken as 0:05:00 as per the error message, but I tried with 3600 and 7200 as values and I get 1 and 2 hour overrides.
