I am actively working with this, there are two issues:
Everyone needs to male a personal decision to be on:
You should be able to easily/safely roll forward to / back from 0.30.x and 0.22.x / 0.21.x.
NOTE: rolling to/from 0.31.x may not be as straight-forward, YMMV.
I started using Ramses_cc with an evofw3 a couple of weeks ago to get more insight into my Evohome installation. So far it has been running great and I already learned a lot about the behavior of the system.
Right now Iām using 0.31.1 and I see that my UFH config is complete in the schema but it doesnāt show demand on all of the UFH zones (I have 2 zones on a HCE80 and 10 zones with TRV).
Searching this discussion I read that UFH is supported but not on the level of insight in the separate zones. Are there things I can do to help with the possible addition of support for UFH status per zone? I could supply packet logs, log files etc.
I have 5 UFH circuits combined in to 3 heating zonesand while schema detects this, demand is shown as a combined
First, Iāll have to figure out how to find and send it.
Another thought,
When itās freezing, Iād like the cv pump to be active and open all the hr92ās.
It would be nice if Is there a command to open them at e.g. 10%, so to keep the water flowing (some pipes go through nonheated areas) without demanding heat.
Is something like that possible?
Direct Control of the exact heat demand/valve position of an HR92 would be a holy grail for me, so I could just tell my UFH to just send it and always open full bore 
but as I understand it, this is something the evohome panel controls and not something the HGI or evofw3 stick can do. Hope Iām wrong though
Maybe I am to early and this is not implemented yet.
I want to create a fake CO2 censor connected to the zone valve of my Orcon HRC425.
After starting the bind proces on the valve, how do I bind this fake sensor with the valve?
service: ramses_cc.bind_device
data:
device_id: "35:123456" # my fake sensor id in ramses_cc.yaml using 35:xxxxxx
offer:
??
Same question for a remote binding to the HRC425 zone valve.
After starting the bind proces on the valve, how do I bind this fake remote with the valve?
service: ramses_cc.bind_device
data:
device_id: "37:123456" # my fake remote id in ramses_cc.yaml using 37:xxxxxx
offer:
??
It works the same in my installation, I can see the demand for the UFH but I would like to see it per UFH zone. AFIAK that is not possible yet.
Remote serial port rfc2217 to HGI80 by ser2net seems not to work anymore after upgrading from 22.40 to 0.30.9 or 0.31.1
2024-01-13 11:51:04.000 ERROR (MainThread) [custom_components.ramses_cc] There is a problem with the serial port: Unable to find rfc2217://192.168.1.240:3331
2024-01-13 11:51:04.002 ERROR (MainThread) [homeassistant.setup] Setup failed for custom integration 'ramses_cc': Integration failed to initialize.
Might be due to code change?
3d2f52e ramses_cc will fail early if serial port is mis-configured
Anyone else experience same issue?
I know rfc2217 is YMMV
No. Itās here:
def is_hgi80(serial_port: SerPortNameT) -> bool | None:
# TODO: add tests for different serial ports, incl./excl/ by-id
if not os.path.exists(serial_port):
raise exc.TransportSerialError(f"Unable to find {serial_port}")
The TODO says it all !
Please provide a copy of your ser2net configuration file.
Ah thanks indeed, just some patience 
The ser2net.conf
3331:telnet:0:/dev/serial/by-id/usb-Texas_Instruments_TUSB3410_Boot_Device_TUSB3410-if00-port0:115200 max-connections=1
You may be out of luck - the rfc2217 protocol just wont work with pyserial-asyncio, and I have dropped support for the polled version of pyserial.
Even if I hack it, I get:
2024-01-13 18:40:20.925 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._ensure_reader(): File "/home/dbonnes/clients/ramses_rf/src/ramses_rf/gateway.py", line 179, in start
await super().start() # TODO: do this *after* restore cache
...
Traceback (most recent call last):
File "/usr/lib/python3.11/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/home/dbonnes/clients/hass/venv/lib/python3.11/site-packages/serial_asyncio/__init__.py", line 322, in _ensure_reader
self._loop.add_reader(self._serial.fileno(), self._read_ready)
^^^^^^^^^^^^^^^^^^^^^
io.UnsupportedOperation: fileno
Iāve been back to 0.22.40 since I couldnāt get 0.31.1 working properly, but Iāve been noticing some odd behavior with entities becoming unavailable if the value doesnāt change for about 2 hours or so.
I have had HR92s do it (becoming unavailable that is) but I never noticed if those were related to a value not changing for a few hours. This time, I was looking for it, for a faked sensor. The sensor itself is alive and well, but the faked entity (03:123456) becomes unavailable. Iāve noticed that when my temperature is very constant for something around 2 hours the entity will become unavailable. If I make the temperature change, the ramses entity also will come back to live.
I am not 100% sure of what you describe, so I am not sure if this is the answer you need, butā¦
ramses_rf has a feature where if it doesnāt hear from a device for a while (on a per command-code basis), then it treats that value as unavailable.
That is (for example), it is better to not know the temperature of a room than it is to believe the room is (say) 15 'C simply because it was so, 4 hours ago. It could be 20 'C at present!
These tombstone timers are usually 2.1x the expected interval between such packets.
I canāt recall the exact time for room temperature packetsā¦
Anyway, if you have a faked room sensor, and it only sends a faked packet when the temp changes, and - for various factors - the temp doesnāt change for a while, then your automation may not send such a packet for such a long period of time that the data expires.
This is why, in the wiki, we have this example:
- id: cast_faked_zone_sensor
trigger:
- platform: state
entity_id: sensor.room_temperature # rename to your temp sensor
- platform: time_pattern
minutes: /15
action:
...
Notice the second trigger?
Version 0.31.1 is not recommended.
In 0.31.1, binding should be working - faking is not working.
My plan is for this (faking) to be available within the week.
Ah, yes, I see now. Tnx for clearing that up. The previous example for an automation does not include a timed update, and if I recall correctly it explicitly advised against it. I guess what you say is true. Iād rather have the heating off when something goes wrong then a sauna. Tnx for clearing that up.
The past days Evohome seems to have adapted to the colder weather quite good. In the previous weeks I had quite some swings in temperature between +0,5 and - 0,5 degrees compared to the setpoint. At the moment though it holds temperature very well and the temperature can remain constant for hours on end. Hence I had sensors go unavailable and I went into panic mode, thinking that something went wrong.