That’s perfect, thanks.
I was thinking…
I don’t know the utility of implementing percent_remaining as a separate sensor…
The better option would be to add it as an extra_stat_attr of days_remaining.
But to do that, I’d need to pull it out as a separate entity…
So, is it really needed?
I don’t think percent_remaining is just a percentage “days / lifetime”.
At least, I hope it’s not… I was hoping this was actually some kind of guesstimate of the filter usage. A clogged filter would show a different percentage from a new filter, independent from the lifetime in days.
Sadly, I no longer have logs from when I last replaced the filter. (early september).
I guess I can check when I replace my filter, without manually resetting the filter timer. days_remaining should still be low, but percent_remain should then go to 100% or so.
Sadly I have no clogged/old filter. And current lifetime is 110 days.
If it’s just a percentage of the days / lifetime, than just leave it out: That is not useful information.
Did you get this working? (BRDG-02R13) I would like to connect my ventilation system to Home Assistant, and this seems to be a possibility to do that (if I can find a place to buy one).
IIRC, I have never spoken to anyone who has one. I don’t imagine it would be impossible to get one working, but I wouldn’t know how much work that would be…
I’d be excited to speak with anyone who has one.
You may be better off with a SSM-D2 - why don’t you ask @ghoti57 at evofw3
There are similar projects like this: IthoEcoFanRFT and ithowifi
All the 10D0 packets I have calculate the percent remaining as a simple function of days_remaining / days_lifetime.
I am happy to re-visit this if required.
BTW, I think you can create your own sensor for this, if you wish:
ramses_cc:
advanced_features:
message_events: '(I|RP).* 32:134446.* 10D0' # is a regex
ramses_cc_message:trigger:
- platform: state
entity_id: event.ramses_cc_message
...
I can’t remember more, but have a play if you like, and ask here if you get stuck.
@zxdavb thanks for helping out.
I have set the enforce known list to false. Now some of the heat demands of the hru92 sensors have appeared. Some are still unavailable.
However, i am not sure what to add to the known list. The sensors have the name start 01_105262_01 to _07.
01:105262 is the controller and already added to the known list. How can i identify the right IDs?
You also mentioned to remove the appliance control (although the link you sent explicitly says to add it). When i remove it i get an error on my configuration yaml. Could you share an example of what you mean when the appliance control has been removed?
Have you looked at: the wiki - if it isn’t clear (and TBH, it is a little unclear), let me know.
It says:
18:xxxxxx status binary sensor will provide information for a known list."You can use a Jinga template (Developer Tools, TEMPLATE):
{{ state_attr("binary_sensor.18_140805_status", "known_list") }}
Whihc gives:
[
{
"18:140805": {
"class": "gateway_interface"
}
},
{
"04:189078": {
"class": "radiator_valve"
}
},
{
"10:048122": {
"class": "opentherm_bridge"
}
...
… you need to translate that JSON into YAML:
known_list:
18:140805: { class: HGI }
04:189078:
10:048122:
...
Note: you only have to specify the class for HVAC devices, and the gateway. HGI is an alias for gateway_interface.
01_105262_01 is the identifier of a zone, so:
sensor.01_105262_01_heat_demand is the demand from zone 1sensor.04_105262_heat_demand is the demand from a TRV with the device id 04:105262Generally, these two will be the same if the TRV is the only TRV in that zone.
… and 01:105262 is the device id of your controller.
Thanks this helps.
I think i found the reason for the complexity in my system. My neighbor has the evohome system. The 18: sensor picks up their valves also.
Is there a way to view which trv valves are connected to my own zones? Then i can set the known list to only my own devices.
Have a look at the state attributes of your controller.
{{ state_attr("binary_sensor.01_145038_schema", "schema") }}
All the
10D0packets I have calculate the percent remaining as a simple function of days_remaining / days_lifetime.
I checked, and (sadly) precent_remaining is indeed just that: days_remaining / lifetime. Not very useful.
I’ll have a look into the events, sounds useful
Hi David!
Can you please explain me what is the difference between the boiler output temperature value in Home Assistant and the boiler water temperature values in the packet log? And how can I forward the value of the boiler water temperature from the packets to Home Assistant?
Below I copied a short part of my packet log. In every 5 minutes the controller queries the OTB about many attributes, included the boiler water temperature. The OTB responds to this query and returns the temperature, but I can’t find this value in Home Assistant. Where should I look for it?
00:01:35.797 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 41.5, 'description': 'Boiler water temperature'}
00:06:39.505 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:06:39.887 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 41.09, 'description': 'Boiler water temperature'}
00:11:45.752 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:11:46.139 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 40.69, 'description': 'Boiler water temperature'}
00:16:51.999 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:16:52.322 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 40.3, 'description': 'Boiler water temperature'}
00:21:58.247 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:21:58.618 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 46.0, 'description': 'Boiler water temperature'}
00:27:02.893 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:27:03.409 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 44.39, 'description': 'Boiler water temperature'}
00:32:07.140 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:32:07.585 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 43.59, 'description': 'Boiler water temperature'}
00:37:11.587 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:37:11.998 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 42.89, 'description': 'Boiler water temperature'}
00:42:15.634 || 01:155672 | 10:102998 | RQ | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Data', 'msg_name': 'BoilerWaterTemperatur
e', 'description': 'Boiler water temperature'}
00:42:16.076 || 10:102998 | 01:155672 | RP | opentherm_msg | 19 || {'msg_id': 25, 'msg_type': 'Read-Ack', 'msg_name': 'BoilerWaterTemperature
', 'value': 42.39, 'description': 'Boiler water temperature'}
Since yesterday I found that the value of the sensor.10_102998_boiler_output_temp is almost always unavailable. Maybe 3-4 values coming in daily. In the attributes of the sensor.10_102998_rel_modulation_level the value of the boiler_output_temp is also null.
However, the boiler_output_temp attribute of the sensor.10_102998_rel_modulation_level_ot entity always has a value and it looks like it’s the actual output temperature of the furnace. I created a template sensor for this attribute and now I can monitor the output temperature, but I can’t decide if this is the right way to do this.
What version are you running, as this is not the behaviour I see (I’m still running 0.22.1). I don’t have boiler_output_temp as an attribute of rel_modulation_level_ot.
I had the 0.21.40, but now I upgraded to 0.30.2. Boiler output temperature is still null, and the sensor.10_102998_rel_modulation_level_ot entity is also gone. So right now no boiler output temperature.
IIRC, I think there may have been some refactoring of the OTB around 0.21/0.22
OK, I restarted HA with restore_cache: false in the ramses_cc section and it looks like I got back all of the sensors I got before the upgrade, except one: 10:102998 flame_active is unavailable since upgradeing to 0.30.2.
There is no need to do this, when upgrading to / downgrading from**0.30.x*.
I confirm that I also have the same problem The flame active sensor is now unavailable after upgrading. Except for this I have had no problem with the upgrade and all seems to work as expected.
Thanks again for all the work done.
I am taking this to say that all is fine with 0.30.2, except for this missing flame_active sensor?
It seems that @wonders is saying his issue is with 0.21.40 (but he did clear his packet cache, so that makes sense).
Please let me know if you are using:
ramses_cc:
ramses_rf:
use_native_ot: ...
… and if so, what value you have for that option.