It is much, much much better to white list only those devices you have rather than black listing unwanted device.
This is because ghost devices (albeit with valid IDs) randomly appear all the time.
See: known_list, in the wiki
That’s exactly what I did, also see the logging and configuration I shared with you through PM.
I’m sorry for the confusion, I should have explained my thoughts better 
@zxdavb I get a strange error and the integration only runs for about an hour before its stops. If i restart HA it starts working again. I have tried rames_rf directly on my laptop with no issues with the device.
Any ideas?
Thank you
2022-11-12 17:38:32.810 ERROR (MainThread) [ramses_rf.protocol.transport] Exception raised by transport: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2022-11-12 17:38:32.818 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._call_connection_lost(SerialExcepti...ss on port?)'))
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 414, in _call_connection_lost
self._protocol.connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 754, in connection_lost
super().connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 583, in connection_lost
raise exc
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 115, in _read_ready
data = self._serial.read(self._max_read_size)
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)```Funny. I had exactly the same issue today. I had to restart the system.
I think it may have been caused by the USB dongle being accidentally removed.
@zxdavb This morning at 8.30 am, five out of eight HR92’s went to 100% as the schedule for the house asked for heating, and three other HR92’s remained closed due to the Warm Weather Saver setting forcing their setpoint to 5degC. The appliance demand as shown on the Evohome Controller system summary page updated to 85%. Is this what you’re interested in seeing?
I’m not yet moved on to evohome_cc, I’m still using Evogateway, but I do intend to install evohome_cc but on a separate install. However, the values I see obtained from Evogateway agree with what I see on the Evohome Controller summary page.
I’ve attached a link to today’s packet.log. Setpoints for all TRVs happen at 8.30. Eight TRVs, seven Zones. TRV:133207 & TRV133209 are together in Zone 6 and use a T87 remote thermostat
Mike
Interesting, as no one has been near my device. I originally had connected to a powered usb 2.0 hub and the issue occurred so I moved it to the Raspberry Pi directly and the issue continued.
FWIW, evogateway sits on top of ramses_rf, just like ramses_cc does, so they should (ignoring all commits to ramses_rf since 0.18.6) give the same values.
For now, I’m interested when the demand in HA doesn’t match the demand in the controller UI.
Thanks for the logs - I’ll have a look.
Cheers for the work you’re doing on this, it is very much appreciated, certainly, the data I get back on valve positions and the various demands have shown me some shortcomings in the software in this Evohome controller.
One of the issues that I would never have been aware of unless I had access to this data is seeing the Boiler being asked to fire when the Demand shows 0% on the controller and locally on all the HR92’s as well as selecting the system to OFF.
I see this occasionally when it appears that whatever TPI firing schedule the controller picks, once its mind is made up, if it has decided that’ll it’ll fire three times in the next hour it’ll carry out the last fire regardless of whether the demand drops to zero or not, all actuators showing zero locally. Sometimes I know it’s going to do it, so before it does I’ll select the system to off and it’ll still carry out what it thinks was needed.
My boiler cycles are set to three per hour in the Evohome controller. So sometimes before the third cycle is due that hour, the rooms have crept up to temperature, especially if there is an external factor like a sunny way, and it still fires. More of a nuisance, but is a waste heating boiler water around the bypass pipework.
So I’m hoping with evohome_cc and some other sensors I have around the house, that perhaps I can spot the conditions which cause this and alter setpoints earlier to avoid it. Either that or I’ll place a relay between the BDR91 and the boiler and block the hard-wired firing signal when evohome_cc clearly shows no need to fire:-)
I had this problem, and it occasionally caused boiler overheat last thing at night when all the rads shutdown and then the boiler fired for one last time. I ended up turning on dhw for 15 minutes 5 minutes before I knew the heating was going off. (My boiler at that time could not modulate so it would go full pelt)
New modulating boiler with OT and problem resolved
@Mike_H Im a new ramses_cc user, but before I did everything by hand and alot of walking. Since using ramses_cc and my own dashboards/cards Im observing the opposite, just right now:
- 70m since last boilers firing
- this zone had 1% heat_demand for 30mins (before that 0%)
- just went from 1% to 6% (you can calculate valve position yourself) (this is the only zone with heat_demand, and is the only one ‘calling’ for ~30mins already)
- bdr91 had relay_demand 1% at the same time and also it went to 3%
- boiler never fired up (interval is 3x5min)
Just as I was writing this, it stood like that for 5 mins, boiler still hasnt fired up and:
- zone went to 0%
- bdr91 still at 3%
So what Im observing the past days:
- all zones combined heat_demand != relay_demand
- relay_demand != Boiler firing
- zone heat_demand != Calling for heat (if im not mistaken)
- all zones combined calling for heat != climate.controller calling for heat
- calling for heat != Boiler firing (eventhough IMO till now this one has the most chance of firing boiler)
Still boiler is not firing… Relay_demand finally went to 0% (5-10mins later)
But the radiator in that zone got hot!!
Thats why I had that idea (noone found it interesting yet) for 10-30% openned valve position. The zone wouldnt have to go over 30% valve position, which increases the chances of firing heat_demand > relay_demand > calling for heat > firing bdr91/boiler, which now it stopped at last step (correct). If it wouldnt stop and actually fired bdr91/boiler then the 10-30% valve position ruke would be a fix worth trying for me!
So to kinda answer your question, if I would need to do anything in your system, the relay you mentioned would be the best way, but I would rather leave it as it is as maybe its still “learning” (whatever that means <== PID).
EDIT:
I was writing this post for so long I forgot to check the data. Boiler fired 5-10mins after everything was 0% (except valve positions). Thats why I think the system in your case and in mine is firing after the end, to make a buffer until the need arises so much that a new interval all over again has to be made. Imo its kinda logical because the system (PID) cant know if someone will open a door/fridge/window/whatever to suddenly *damp" that dip (boiler firing, hot water coming to the rescue and radiator increasing temperature across the room takes time = totally breaks a PID cycle) so it needs a buffer/reserve in advance (which again my 10-30% valve position rule should help).
EDIT:
My next project is to put DS18B20s everywhere in the boiler room. With them installed I will have lots more data to continue this study.
How are people getting on with the get/set schedule service calls please?
Both appear to be working OK on my testbed - I do note get/set DHW schedule is missing.
Please include in your response the version of ramses_cc that you are using.
Remind me - what was I looking for?
The remote is working, I removed the secondary fake remote per your advice. However, the fan info (humidity, speed etc) isn’t working (unknown or not available in HA).
Maybe humidity is a separate device which currently isn’t in the known_list, but I see fan_state messages in the logging.
@prescott this probably isn’t the forum to get too deep into this issue. I have already fitted DS18B20’s in six places on my Boiler pipework, which I was using to get a better picture of the operation of the flow bypass valve. I also have some monitoring on the boiler showing when it fires and its firing rate. This is what I see.
Last night the system is set to turn all zone setpoints down to 14DegC at around 22:00. I have OPTIMUM STOP set in the Smart Features, so the change to all setpoints down to 14DegC took was completed around 21:00. The System also decided to turn some zones to 5DegC due to WARM WEATHER SAVER. Essentially, by 21:00 there was no demand on the system.
But, if you look at my graph which shows Boiler Flow Temperatures and Evohome Demand, you can see it still carries out that last fire of the boiler exactly 20 minutes after the last expected boiler firing.
It’s as if the system has decided that since it’s set for three cycles per hour which are 20 minutes apart. It’s done the calculation and decided that there will be three firings of around 4 minutes for that hour period and unless the change in demand increases it’s going to carry them out regardless if whether the demand changes to zero.
So you can see the last cycle simply heats water round the bypass loop since all radiators are closed.
2022-11-12 21:00:17,105 [308] || CTL:196480 | | I | heat_demand | FC00 || {‘domain_id’: ‘FC’, ‘heat_demand’: 0.0}
2022-11-12 21:00:17,705 [308] || CTL:196480 | | I | relay_demand | FC00 || {‘domain_id’: ‘FC’, ‘relay_demand’: 0.0}
2022-11-12 21:00:45,826 [308] || CTL:196480 | | I | setpoint | 00057… || [{‘zone_idx’: ‘00’, ‘setpoint’: 14.0}, {‘zone_idx’: ‘01’, ‘setpoint’: 14.0}, {‘zone_idx’: ‘02’, ‘setpoint’: 5.0}, {‘zone_idx’: ‘03’, ‘setpoint’: 14.0}, {‘zone_idx’: ‘04’, ‘setpoint’: 5.0}, {‘zone_idx’: ‘05’, ‘setpoint’: 5.0}, {‘zone_idx’: ‘06’, ‘setpoint’: 5.0}]
2022-11-12 21:00:45,847 [308] || CTL:196480 | | I | temperature | 00077… || [{‘zone_idx’: ‘00’, ‘temperature’: 19.14}, {‘zone_idx’: ‘01’, ‘temperature’: 18.6}, {‘zone_idx’: ‘02’, ‘temperature’: 15.95}, {‘zone_idx’: ‘03’, ‘temperature’: 18.99}, {‘zone_idx’: ‘04’, ‘temperature’: 17.23}, {‘zone_idx’: ‘05’, ‘temperature’: 16.64}, {‘zone_idx’: ‘06’, ‘temperature’: 16.45}]
I have tried a test fresh install of HA and the same issue continues, any ideas why this disconnect is happening?
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:96
First occurred: 10:05:12 AM (1 occurrences)
Last logged: 10:05:12 AM
Error doing job: Exception in callback SerialTransport._call_connection_lost(SerialExcepti...ss on port?)'))
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 414, in _call_connection_lost
self._protocol.connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 755, in connection_lost
super().connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 584, in connection_lost
raise exc
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 115, in _read_ready
data = self._serial.read(self._max_read_size)
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2022-11-14 10:05:12.258 ERROR (MainThread) [ramses_rf.protocol.transport] Exception raised by transport: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2022-11-14 10:05:12.264 ERROR (MainThread) [homeassistant] Error doing job: Exception in callback SerialTransport._call_connection_lost(SerialExcepti...ss on port?)'))
Traceback (most recent call last):
File "/usr/local/lib/python3.10/asyncio/events.py", line 80, in _run
self._context.run(self._callback, *self._args)
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 414, in _call_connection_lost
self._protocol.connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 755, in connection_lost
super().connection_lost(exc)
File "/usr/local/lib/python3.10/site-packages/ramses_rf/protocol/transport.py", line 584, in connection_lost
raise exc
File "/usr/local/lib/python3.10/site-packages/serial_asyncio/__init__.py", line 115, in _read_ready
data = self._serial.read(self._max_read_size)
File "/usr/local/lib/python3.10/site-packages/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
@Mike_H understood. That can easily then be solved with a relay and an automation. Just turn off the relay when end of schedule && heat demand == 0.
I dont use those smart stops/starts or any of those weather features. As I said im very new to ramses_cc, Im figuring out important stuff first, but as I was ‘studying’ this system the previous seasons without ramses_cc, Im still convinced that in my situation its ALOT better to leave almost everything 24/7 (only 1 setpoint per day for most rooms). That was the first thing I tried when I set up ramses_cc and the boiler is firing atleast 50% less time with a 24/7 schedule (theres this little room in the middle of the house thats even more difficult to understand with ramses_cc because I got proof now that it takes 6-9h each day to heat up and its on average 7,5C outside, go figure, there must be some wind going on with all windows closed). Did you try a 24/7 schedule?
Schedule 7-22 with surrounding rooms also on heating
Schedule 24/7 (and setpoint 22,5 vs before 23) with only this middle “Miha Ucilnica” room having setpoint above actual (effectively only Miha Ucilnica had ‘calling for heat’ and any kind of changes in valves position)
This proves 24/7 schedule is better in my book, thanks to ramses_cc!
As far as I understand it - and with the caveats as before - this is what happens.
Your system’s TPI parameters include a cycle rate, (IIRC) default is 6.
CTL:169176 | I | tpi_params | FC || {'domain_id': 'FC', 'cycle_rate': 6, 'min_on_time': 1.0, 'min_off_time': 0.0, '_unknown_0': '00', 'proportional_band_width': None, '_unknown_1': '01'}
So, 6 times every hour (every ten minutes), the controller looks at the demand. Let’s say it’s 15%.
Since 15% of 10 mins is 90 seconds, the system (appliance controller) will wait until the 10 min cycle only has 90 seconds left, then call for heat until the beginning of the next cycle.
[ and what happens is the heat demand goes up to (say) 100% when you’re only just into that cycle - you’re nowhere near the 90 sec window as yet (and vice-versa) - I can’t remember ]
At the start of the next cycle, it might be 7%, and the on time would be 42 seconds. Only thing is 42 secs is less than the minimum on time, 1 minute, so the call for heat is made for 1 minute (remember: at the end of the cycle)
[ or maybe the call is not made, at all - I can’t recall ]
FWIW, There is a minimum off time too, but it is not configurable.
Here is a relay:
BDR:888888 | I | actuator_cycle | .. | {'actuator_enabled': False, 'actuator_countdown': 287, 'cycle_countdown': 587}
… it says the relay is off for the next 287 seconds of a cycle that has 587 seconds left - the demand must have been 50% (we’re 3 seconds into the cycle).
here is another just at the start of a 20 min cycle:
BDR:111111 | I | relay_demand | .. || {'relay_demand': 0.19}
BDR:111111 | I | actuator_cycle | .. || {'actuator_enabled': False, 'actuator_countdown': 972, 'cycle_countdown': 1200}
…it is off (False) for 81% (972/1200th) of this 20 min (1200s) cycle.
See:
It seems to me you need to look at your hardware configuration. ?loose connector ?running in a VM ?another integration using the serial port, dry solder joint on dongle, etc.
Has anyone got access to a HRA80 that they can provide to me free/cheap?
1 Like