Hi,
I don´t find ramses_cc in Homassistant HACS. Is it gone?
Edit: found it… needed to add it first.
Hi Jeroen,
Thank you very much, I really appreciate it!
Hi all, I regularly get this error in HA:
Logger: ramses_tx.message
Source: runner.py:188
First occurred: 15:22:31 (2 occurrences)
Last logged: 15:22:36
I 170 03:170776 --:------ 03:170776 30C9 003 010848 < Packet idx is 01, but expecting no idx (00) (0xAB)
Any idea why this is and how to solve it (if needed - or at least filter this message so I don’t see it anymore)?
My setup uses both OpenTherm and a HCE80 UFH Controller. I have been running this integration for several years solely to collect data about Evohome’s operation. I recently updated to the newer versions and have been seeing my HCE80 going into an error state for all zones (flashing yellow zones + red system leds) on a daily (at least basis). I have to power cycle the HCE80 to clear the error state.
Yesterday morning I shutdown the Pi + HA system that does just the Evohome stuff and the error has not (so far) happened again. The sample period is short so far and I will give it another day or two before switching the Pi back on.
Does the integration talk out at all? (I asked about this several years ago as saw this behaviour then and I have a vague recollection the integration did do some talking out, possibly for sorting out the schema?)
Appreciate a bit vague and need more correlation of Pi being on with error states happening, which I will be looking at in the coming days.
Sorry for my ignorance but how do I create this packet log?
This error can be ignored.
You can disable it, but I will remove it from ramses_rf at some stage.
You will have to supply me with a packet log before I could be sure…
Nonetheless, ramses_rf should not affect an UFC in this way.
You could try: running in read-only more, or simply black-listing the UFC.
I got my HGI80 Evohome system integrated into HA on my RPi4 via the Overkill Integration (because the HGI80 is connected t my Somfy system at the moment).
Unfortunately I only get the temperatures of my thermostats but cannot change them.
Can somebody explain me, how to do so? Do I have to connect the HGi80 to the RPi and what then?
Thanks in advance…
thx for the clarification!
I’ve been comparing 0.30.9 with 0.21.40 and I’ve noticed a few differences. None of these are causing me any problems and are mainly documentation related but thought I’d let you know anyway.
Environment: Home Assistant Blue, SSM-D2, Evohome colour controller, R8810A OTB, Intergas boiler
- Under 0.30.9 the “discovered schema”
binary_sensor.01_216136_schemadoesn’t see my OTB as the “appliance_control” and I get a warning that the schema is not minimal.
Discovered schema under 0.21.40 (partial):
schema:
system:
appliance_control: "10:064873"
orphans: []
stored_hotwater:
sensor: "07:050121"
hotwater_valve: "13:042605"
heating_valve: "13:016112"
underfloor_heating: {}
zones:
Discovered schema under 0.30.9 (partial):
schema:
system:
appliance_control: null
orphans: []
stored_hotwater:
sensor: "07:050121"
hotwater_valve: "13:042605"
heating_valve: "13:016112"
underfloor_heating: {}
zones:
-
Unless I specify “HGI” as the class for the SSM-D2 in the
known_listI see the warningThe known_list should include exactly one gateway (HGI), but does not (make sure you specify class: HGI). Previously the class could be specified asgateway_interface -
The configuration options for logging protocol and transport appear to have changed (i.e was
ramses_tx.protocol.protocol, nowramses_tx.protocol):
ramses_tx.protocol: info # for: (rcvd) PKTs (raw packets), e.g.: 0.30.9
# ramses_tx.protocol.protocol: info # for: (rcvd) PKTs (raw packets), e.g.: 0.21.40
ramses_tx.transport: info # for: Rx, Tx of PKTs, e.g.: 0.30.9
# ramses_tx.protocol.transport: info # for: Rx, Tx of PKTs, e.g.: 0.21.40
- Using the 0.30.9 default setting of
use_native_ot: preferI see changes in some OTB sensors. Switching touse_native_ot: neverreverts to 0.21.40 behaviour. The documentation suggests this should be expected but I’m just recording my own findings in case they’re helpful.
-
return_temp:unavailableunder 0.21.40, permanently71.66°Cunder 0.30.9 -
dhw_temp: under 0.21.40unavailableunless the boiler was actively heating DHW, in which case it was the boilers DHW (tank) sensor reading. Under 0.30.9 permanently71.66°C -
rel_modulation_level_ot: under 0.21.40 this returned a structure that contained several boiler parameters, under 0.30.9 it returnsunavailable
Here’s my configuration for reference:
# Honeywell Evohome ramses_cc integration
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: ramses_cc_packet.log
restore_cache:
restore_schema: true
restore_state: true
ramses_rf:
enforce_known_list: true
use_native_ot: prefer # always, prefer (default), avoid, never 0.30.9 only
01:216136: # Evohome controller
system:
appliance_control: 10:064873
known_list:
# 18:072981: { class: gateway_interface } # SSM-D2 radio 0.21.40
18:072981: { class: HGI } # SSM-D2 radio 0.30.9
01:216136: { class: controller } # Evohome controller
10:064873: { class: opentherm_bridge } # R8810A OTH interface
13:042605: { class: electrical_relay } # BDR91 DHW relay
13:016112: { class: electrical_relay } # CH relay (not used)
07:050121: { class: dhw_sensor } # Evohome DHW sensor
22:012299: { class: thermostat } # DT4R Kitchen
34:058721: { class: thermostat } # Y87RF Lounge
04:056673: { class: radiator_valve } # Garden room HR92
04:034720: { class: radiator_valve } # Garden room HR91
04:034682: { class: radiator_valve } # Kitchen HR91
04:034716: { class: radiator_valve } # Hall HR91
04:034726: { class: radiator_valve } # Hall (Landing) HR91
04:036050: { class: radiator_valve } # Lounge HR91 (L)
04:036076: { class: radiator_valve } # Lounge HR91 (R)
04:056677: { class: radiator_valve } # Dining room HR92
04:106557: { class: radiator_valve } # Office HR92
04:056675: { class: radiator_valve } # Master bedroom HR92
04:036066: { class: radiator_valve } # Bathrooms (ES) HR91 A (Outside wall)
04:034690: { class: radiator_valve } # Bathrooms (ES) HR91 B
04:036068: { class: radiator_valve } # Bathrooms (Family) HR91
04:034722: { class: radiator_valve } # Bathrooms (Cloak) HR91
04:208998: { class: radiator_valve } # Bedroom 2 HR92
04:208990: { class: radiator_valve } # Bedroom 3 HR92
04:208994: { class: radiator_valve } # Bedroom 4 HR92
04:034684: { class: radiator_valve } # Bedroom 5 HR91
04:034692: { class: radiator_valve } # Bedroom 5 (ES) HR91
04:208992: { class: radiator_valve } # Bedroom 5 HR92
logger:
# default: warn # prefer warn over info, avoid debug
logs:
# homeassistant.core: debug # to see: call_service & state_changed
custom_components.ramses_cc: info # for: Devices, Schema, Params, Status, etc.
ramses_rf.dispatcher: info # for: Tx/Rx at app layer, probably the logging you want (no RQs for readability), e.g.:
# || CTL:145038 | | I | system_sync | || {'remaining_seconds': 185.5, '_next_sync': '15:59:38'}
ramses_tx.protocol: info # for: (rcvd) PKTs (raw packets), e.g.: 0.30.9
# ramses_tx.protocol.protocol: info # for: (rcvd) PKTs (raw packets), e.g.: 0.21.40
# SENT: RQ --- 18:000730 30:082155 --:------ 22E5 001 00
# rcvd: RQ --- 18:006402 30:082155 --:------ 22E5 001 00
ramses_tx.transport: info # for: Rx, Tx of PKTs, e.g.: 0.30.9
# ramses_tx.protocol.transport: info # for: Rx, Tx of PKTs, e.g.: 0.21.40
# RF Tx: b'RQ --- 18:000730 30:082155 --:------ 2210 001 00'
# RF Rx: b'000 RQ --- 18:006402 30:082155 --:------ 2210 001 00'
Again, just to reiterate, none of this is causing any problems that I’m aware of and may all be expected behaviour. Thanks for all the effort going into this project. If you want any more information like packet logs please let me know.
I see very similar behaviours. My system is also an Intergas boiler controlled via OpenTherm (but not for DHW). It also includes an HCE80 for UFH control.
- Schema has “null” for applicance_control:
{
"system": {
"appliance_control": null
},
"orphans": [],
"stored_hotwater": {
"sensor": "07:046947",
"hotwater_valve": "13:120242",
"heating_valve": null
},
"underfloor_heating": {
"02:020364": {
"circuits": {
"00": {
"zone_idx": "08"
},
- I see a warning message for “one gateway”:
WARNING (MainThread) [ramses_tx.schemas] Best practice is exactly one gateway (HGI) in the known_list: []
-
Changes to logging were mentioned by zxdavb and I altered my config for this change.
-
I see the same behaviour for:
10:047712 boiler_return_temp
10:047712 dhw_temp
i.e. both now have a fixed value of 71.66°C
boiler_return_temp is not available on my boiler.
dhw_temp is only available when evohome calls for DHW via a BDR91 because the physical sensor is otherwise shorted. Previously the value was either “Unavailable” because the sensor is shorted, or reported the actual DHW tank sensor temperature.
- I also have WARNINGs for my known_list:
WARNING (MainThread) [ramses_tx.schemas] An empty known_list was provided, so it cant be used as a whitelist (device_id filter)
WARNING (MainThread) [ramses_tx.schemas] It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
- And I see WARNINGs for some packets:
WARNING (MainThread) [ramses_rf.entity_base] RP --- 10:047712 01:164379 --:------ 3220 005 00C01C47AB < Polling now deprecated for code|ctx=3220|1C: it appears to be unsupported
WARNING (MainThread) [ramses_rf.entity_base] RP --- 10:047712 01:164379 --:------ 3220 005 00C01A47AB < Polling now deprecated for code|ctx=3220|1A: it appears to be unsupported
- Finally, I mentioned my UFH controller going into an error state for all Zones. This happened previously (2 years ago) and reverted because (I think) I removed “disable_sending: true” from my config. I have added that back and the controller has not gone into an error state since. I am now pretty much certain that the errors are being caused by this integration when it is allowed to send. If this is of interest for investigation then I am happy to provide packet logs, etc; please just let me know.
My config looks like this currently:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: packet.log
scan_interval: 60
restore_cache:
restore_schema: true
restore_state: true
ramses_rf:
enforce_known_list: true
#enable_eavesdrop: false
#disable_discovery: true
disable_sending: true
01:164379:
system:
appliance_control: 10:047712
zones:
"0A": {sensor: 01:164379}
known_list:
01:164379: # Controller
02:020364: # HCE 80 UFH Controller (Zone 1 - Dining Room / 2 - Living Room / 3 - Hall)
04:062953: # HR92UK Bed 1
04:108214: # HR92UK Bed 2
04:108216: # HR92UK Landing
04:108218: # HR92UK Office
#04:108220: # HR92UK Ensuite 3 (DEAD)
04:108259: # HR92UK Bed 3
04:123249: # HR92UK Ensuite 1
04:245838: # HR92UK Kitchen
07:046947: # CS92A DHW Thermostat
10:047712: # R8810 OpenTherm Bridge
13:120242: # BDR91 DHW Demand
18:065802: # evofw3
34:144335: # T87RF Thermostat (Living Room)
34:159297: # T87RF Thermostat (Dining Room)
logger:
default: warn
logs:
#custom_components.evohome_cc: warn # use info for Schema
ramses_rf.message: warn # MSGs rcvd (excl. RQ/18:), is the one you usually want
#ramses_rf.protocol.protocol: warn # PKTs sent (excl. retries) & rcvd
#ramses_rf.protocol.transport: warn # RF Tx'd (incl. retries) & Rx'd
ramses_rf.dispatcher: warn # TIP: info for logging messages (excl. RQs)
ramses_tx.protocol: warn # TIP: info for logging packets Sent/Rcvd
ramses_tx.transport: warn # TIP: info for logging frames Tx/Rx
@jonboy @peternash Thanks for your report - you have both described a bug that I will be looking at.
This is a bug.
This is a regression that I am unlikely to address in the short term, if at all.
For now, se the suggested (3-letter) slugs, like HGI.
It should be a percentage.
FWIW, you do not need to specify the class for CH/DHW devices (a HGI (gateway) is not a CH/DHW device), with the possible exception of an RFG (RFG100).
I am that UFC (HCE80, HCC80, etc.) are not fully supported.
This is caused by the same bug as above.
Yes, this needs looking at - start by providing me with 72h packet log when this behaviour is seen, and I can have a look. You can PM me a message.
Not 100% related to ramses_cc, but is anyone else noticing the values of the official evohome integration now being rounded to 0,5 decrease to the setpoint i.e. like it’s displayed on the controller display?
In my living room I have 2 faked temperature sensors. When the setpoint is 19,5 and the temperature updates to let’s say 19,2, ramses_cc will say 19,2, as does the official one, but soon after, the official integration will round it to 19,5 again. Same for other zones. Ramses_cc displays 17,2, official says 17,0 or ramses_cc says 15,7, official says 15,5.
I think the API integration has always done that, i.e. rounded to 0.5
For me it hasn’t, started this night I believe right after updating HA. Before Home Assistant would give me the ungrounded number/value. You can see it changing in below screenshot:
I am not clear if you are talking about temperatures or setpoints.
If temperatures, maybe it is an issue with the high-precision feature (which I’ve just refactored), and - in that case - please submit an issue on HA’s github repo for core.
Sorry if my post wasn’t clear. It’s indeed current/measured temperatures which are rounded towards the setpoint. I’ll try to create a new issue. I’m still quite new to the whole HA scene hehe, so not really used to raising an issue and still much more in the mindset that I’m possibly doing something wrong.
In the meantime, can I help you with anything concerning my HCF82 like packet log or something? It isn’t reporting to the ramses_cc entities directly and the entities for temperature and battery are always unavailable in HA. On the back however it seems to be talking to ramses_cc just fine as the exact temperature is visible in the thermostat card.
I love these things since they stand perfectly on a shelve without needing a mount or stand and/or can be wall mounted if possible or required. Since they have no temperature dial or buttons to fiddle with, there’s no changing the setpoint. It’s a pure sensor in that sense. As a bonus, they can often be gotten for cheap second hand (at least over here) and show up on second hand selling sites quite frequently.
Version 0.31.1 has been released.
It has much better support for device faking - is now able to bind consistently / reliably.
It should also be easier for you to configure the system for your faked/impersonated devices.
I note that I have not received a sufficient quantity of packet logs to have tested this fully myself, so …
… to get HVAC switches working will require some tweaking to find the YAML that works best - this is up to you. Please see the wiki.
Have a go, and feedback any issues here.
If you have a problem and would like help:
- list the make/model of your sensor/remote and your ventilation unit
- provide the
10E0packets for the above - provide the YAML you used for the
known_listin the configuration.yaml for these devices - provide the YAML you used in the service call to initiate binding
- provide the packet log taken during the above service call
1 Like