This is odd - send me a packet log & a HA log. AFAIK, there is no means for a relay to change its role (i.e. there is a bug).
Looking good. Thanks!
Iāve just noticed this error.
Logger: ramses_rf.protocol.message
Source: /usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py:363
First occurred: 27 September 2021, 6:00:36 (2 occurrences)
Last logged: 3:17:24
RP --- 10:051349 18:135447 --:------ 3220 005 00601B0003 << AssertionError(OpenTherm: Invalid msg-type|data-value: Data-Invalid|0003)
RP --- 10:051349 18:135447 --:------ 3220 005 00601B0FFF << AssertionError(OpenTherm: Invalid msg-type|data-value: Data-Invalid|0FFF)
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/message.py", line 354, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 116, in wrapper
return func(*args, **kwargs)
File "/usr/local/lib/python3.9/site-packages/ramses_rf/protocol/parsers.py", line 1580, in parser_3220
assert (
AssertionError: OpenTherm: Invalid msg-type|data-value: Data-Invalid|0003
This could be just a simple corrupt packet.
It looks like the faking has been causing my boiler some issues. Over the last few days, the temperature has dropped so my boiler has been firing up, but not getting my rooms up to temperature. Iāve sat and watched the flame light and call demand on the boiler and itās been all over the shop. With all rooms demanding 100% Iām getting the call light on but the flame is only on for around a minute at a time and then off for around 2 minutes, sometimes the call demand goes to 0 and then straight to call again. Which means the radiators never get hot.
I unplugged my SSM(R) and the boiler call for heat came on and the flame light stayed on until the radiators got so hot you couldnāt touch them! I then plugged back in my SSM(R) and reset home assistant and as soon as it started up it went back to the flame on-off all the time.
At the minute Iāve disabled the faking and everything seem as it should be.
(Edit)
It may not be the faking as it didnāt work correctly for long with the faking removed. SSM(R) unplugged and within a minute the boiler is doing what it should.
I doubt faking is to blame. The boiler relay will only do what the controller asks of it. Have a look at the zone temperatures / setpoint schedule, and especially the return CV tempā¦
This could be anything. You simply havenāt provided enough evidence to support your hypothesis.
Have a look at a graph like the following (13_237335 is my boiler relay):
type: history-graph
entities:
- entity: binary_sensor.13_237335_active
- entity: sensor.01_145038_heat_demand
hours_to_show: 8
This graph will connect heat demand with TPI (on/off of relay) (assuming you donāt have an OTB)ā¦
Also, seek to understand what your boiler will do when a call for heat is made (assuming you have a boiler)ā¦ For example, it may cut off if the return CV temp is too high (so that condensing is assured).
I understand how my boiler works and itās opentherm so shouldnāt be cycling on and off. All zones set to 30 and rooms around 20, boiler set to highest temperature and I can hold my hands on flow and return pipe work, as soon as I unplug the ssm usb stick the boiler acts like it should and heats up and stops the cycling.
Ah! - I am open to the idea that there is an issue with OpenTherm - could you kindly send me a packet log?
Are you able to try this and see if it makes any difference?
evohome_cc:
config:
disable_discovery: true
For clarityā¦ Whatever is going on, it wonāt be the fault of the faking.
Iāve not worked out how to set the packet logs up yet.
Iāve added the other part to my configuration.
Just in case anyoneās interested, I have put together a template for the button-card custom component that displays Evohome entities in clear tiles. Itās for my own personal use but I figured Iād share it in case anyone else found it helpful. Specifically I designed it to be quick and easy to read on a mobile screen, making it obvious which zones are calling for heat and any other useful information. It pulls together the various entities that make up a zone.
4 Likes
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
The file I am looking fro is this one:
evohome_cc:
packet_log: /home/dbonnes/home-assistant/.config/packet.log
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.
Thanks, Iāll try and work it out.
At the minute rebooting home assistant solves the problem for a while.
I understand some people are using ser2net - just be aware that support for this is somewhat experimental.
configuration.yaml
evohome_cc:
serial_port: rfc2217://localhost:5001
ser2net.yaml
# HGI80-like ser2net connection that allows multiple connections
connection: &con00
accepter: telnet(rfc2217),tcp,5001
timeout: 0
connector: serialdev,/dev/ttyUSB0,115200n81,local
options:
max-connections: 3
There are known issues with other versions of ser2net, but it does work for me.
Someone asked:
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.
Iāve got the packet logs working but itās too big to send to you?
dropped packets are a normal thing (RAMSES II has no QoS) - and worse, the controller can pick up a packet that ramses_rf doesnāt, and vice-versa
Here is an example:
~/c/ramses_rf (master) [0|1]> cat packet_2021010-08.log | grep '069003.* 3150 ' | python client.py parse
...
00:40:59.030 || TRV:069003 | CTL:197498 | I | heat_demand | 07 || {'zone_idx': '07', 'heat_demand': 0.0}
01:20:57.995 I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (200%)
01:20:57.995 || TRV:069003 | CTL:197498 | I | heat_demand | 07 || {'zone_idx': '07', 'heat_demand': 0.0}
02:20:57.473 I --- 04:069003 --:------ 01:197498 3150 002 0700 # has expired (300%)
02:20:57.473 || TRV:069003 | CTL:197498 | I | heat_demand | 07 || {'zone_idx': '07', 'heat_demand': 0.0}
02:40:57.574 || TRV:069003 | CTL:197498 | I | heat_demand | 07 || {'zone_idx': '07', 'heat_demand': 0.0}
03:00:56.158 || TRV:069003 | CTL:197498 | I | heat_demand | 07 || {'zone_idx': '07', 'heat_demand': 0.0}
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.
Place into file share website somewhere, and PM me the link.