I am not sure what this means, exactly - but there should be no need to delete any files from the file system: you should be able to downgrade via HACS.
All of them. They are all marked as restored but all say “This entity is no longer being provided by the ramses_cc integration. If the entity is no longer in use, delete it in settings.”
I used the “Remove” option in HACS, restarted HA and then reinstalled using HACS. I assumed something left over from 0.30.0 was lingering in master because the very thing you say (and I can see) you’ve fixed was still broken after installing the master branch.
Well, that was reasonable.
What does the system log say? Did you make a typo when you edited the configuration.yaml?
I have my ramses_cc config in a separate file which is included by configuration.xml - all I’m doing is commeting in/out the include between restarts, I haven’t edited the config itself at all.
There are no errors relating to ramses_cc in the logs, only the following warnings;
The known_list should include the gateway (HGI) but doesn't, configure the known_list/block_list as required
23:58:24 – (WARNING) RAMSES RF (custom integration)
Using a merged schema (cached schema is not a superset of config schema), if required, use 'restore_cache: restore_schema: false'
23:58:24 – (WARNING) RAMSES RF (custom integration)
I think I know what caused the initial confusion - there is an annoyance (bug I’d say) with HACS that when you select a version you must wait until the UI element becomes editible again before continuing, if you don’t it does not select the option you think it has. I’ve seen this mentioned on several HACS repos so I will report it as a bug against HACS.
I tried once more before giving up for the night and master is installed and my entities are “recovering” for want of a better word. I have some which are now unavailable (mostly heat demand but these seem to go unavailable for me periodically anyway) but I can see some “live” data again.
Apologies if I came across as being unhelpful, that wasn’t the intention.
This may be your problem.
Add the gateway (USB dongle) device ID to the known_list, or stop enforcing the known_list.
The new library autodetects the gateway ID much more reliably and now is intolerant of this configuration.
I actually don’t like this behavior - it will be addressed - see issue #73
This should be self-explanatory.
Weird, because it is in my list;
known_list:
01:062988: { "alias": "--controller--" }
18:202528: { "alias": "HGI:evofw3" }
13:100804: { "alias": "Boiler Relay"}
04:170346: { "alias": "Living Room" }
22:017642: { "alias": "Living Room Remote" }
04:013551: { "alias": "Dining Room Valve 1" }
04:170348: { "alias": "Dining Room Valve 2" }
22:017632: { "alias": "Dining Room Remote" }
04:170344: { "alias": "Kitchen"}
04:013549: { "alias": "Master Bed" }
22:017653: { "alias": "Master Bed Remote" }
04:170342: { "alias": "Kids Bed" }
22:017620: { "alias": "Kids Bed Remote" }
04:013545: { "alias": "Bedroom 3" }
Just to add this config has been working fine for 12 months at least.
EDIT: Regardless of the warning it seems to be working so I’m not gonna stress about it. Added the fix to my config for the second warning. Heat demand entities are returning so looks fine.
You need:
18:202528: { class: HGI, alias: "HGI:evofw3" }
1 Like
This is likely because the state cache (packets) was not restored when HA was restarted.
1 Like
I’ll try to move the antenna to another position and I enabled the packet log, to check the packets.
While restarting the home assistant I found this in the log:
2023-11-12 08:57:45.228 WARNING (MainThread) [ramses_rf.processor] RP — 01:123456 18:123456 --:------ 000C 006 000F0036D090 < CorruptStateError(Inconsistent schema: 01:123456 (evohome) changed app_cntrl (from 10:123456 (OTB): None to 13:123456 (BDR): None)
Can you tell me what does this means? I recognize my Evohome controller, my BDR, my OTP but can’t recognize the 18:123456 device. I manually created my schema (the appliance control it the OTB, and the BDR is a actuator in the one and only zone), but where should I put this in my schema and under what type of device?
Oh, and one more thing: based on the documentation the value of the use_native_ot can be always, prefer, avoid, never. But if I try to set it to always in the config, I get this error while running the configuration checker in home assistant:
Invalid config for [ramses_cc]: expected bool for dictionary value @ data[‘ramses_cc’][‘ramses_rf’][‘use_native_ot’]. Got ‘always’. (See /config/configuration.yaml, line 309).
There is no need to redact device IDs, they are more like MAC addresses than IP addresses, however it is up to you. But doing so makes it difficult for me to help.
When people post text here, be sure to start with a triple-backslash on the line before, so the formatting is preserved.
It is frustrating to unpick the changes people make, before I can see what the issue is.
I should note that the above packet states that the appliance controller is a BDR relay with the address 13:184464. Thus it is the case that:
- this is a corrupted packet (the
0Fis corrupted, say), and it was safely ignored by ramses_rf - this is not a corrupt packet, and the controller is telling you its truth
Maybe your OTB is 10:184464 and your BDR is 13:250731, and we’d have a better idea where the corruption was?
Anyway, in the case of the former, the corrupt packet is now in your cache for 24h, so you should restart HA with restore_cache: false (then remove that option after restart).
In the case of the latter, Your BDR/OTB may not be bound correctly to the controller, inter-alia.
Please provide the ramses_cc section from your configuration.yaml, and I will comment on it. Please PM it to me if you like - I would prefer you not to edit it.
If you want a guaranteed answer to this issue, then send a packet log that includes a restart of HA (a 24h log is definitive).
I just tried this - works for me:
ramses_rf:
enforce_known_list: true
use_native_ot: always # will still RQ|3EF0|00
# use_native_ot: never # will still RQ|3220|00
Perhaps others could test and let me know.
Please report any other bugs - I will drop another release today.
Hi,
I use ramses_rf for a few weeks now, monitoring and controlling my Orcon HRC 425 SmartComfort.
I updated to 0.30.0 and command-out the ‘enforce_known_list: true’ line.
After that I am missing a few HRC sensors (unavailable):
sensor.32_139773_exhaust_temperature
sensor.32_139773_indoor_temperature
sensor.32_139773_supply_temperature
sensor.32_139773_outdoor_temperature
sensor.32_139773_remaining_time
I installed the master code (f516293): the same sensors are unavailable.
My logs (master version) show (not compleet):
###
Logger: ramses_tx.message
Source: /usr/local/lib/python3.11/site-packages/ramses_tx/message.py:282
First occurred: 11:07:47 (7 occurrences)
Last logged: 11:52:44
I 175 32:131922 --:------ 32:131922 31D9 017 0104040020202020202020202020202004 < AssertionError(What!! (AA))
I 177 32:131922 --:------ 32:131922 31D9 017 0104040020202020202020202020202004 < AssertionError(What!! (AA))
I 179 32:131922 --:------ 32:131922 31D9 017 0104040020202020202020202020202004 < AssertionError(What!! (AA))
I 181 32:131922 --:------ 32:131922 31D9 017 0104040020202020202020202020202004 < AssertionError(What!! (AA))
I 183 32:131922 --:------ 32:131922 31D9 017 0104040020202020202020202020202004 < AssertionError(What!! (AA))
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_tx/message.py", line 270, in _validate
return {**self._idx, **result}
^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/message.py", line 196, in _idx
assert self._pkt._idx == "00", "What!! (AA)"
^^^^^^^^^^^^^^^^^^^^^^
AssertionError: What!! (AA)
###
Logger: ramses_tx.message
Source: /usr/local/lib/python3.11/site-packages/ramses_tx/message.py:282
First occurred: 11:05:27 (2 occurrences)
Last logged: 11:35:28
RP --- 32:139773 18:072982 --:------ 2210 042 00FF00FFFFFF0000000000FFFFFFFFFF00FFFFFF0000000000FFFFFFFFFFFFFFFF000000000000020800 < AssertionError(Support the development of ramses_rf by reporting this packet)
Traceback (most recent call last):
File "/usr/local/lib/python3.11/site-packages/ramses_tx/message.py", line 263, in _validate
result = PAYLOAD_PARSERS.get(self.code, parser_unknown)(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 173, in wrapper
result = fnc(payload, msg, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/site-packages/ramses_tx/parsers.py", line 1349, in parser_2210
assert payload in (
^^^^^^^^^^^^
AssertionError: Support the development of ramses_rf by reporting this packet
###
Deze fout is ontstaan door een aangepaste integratie.
Logger: ramses_tx.transport
Source: custom_components/ramses_cc/coordinator.py:50
Integration: RAMSES RF (documentation, issues)
First occurred: 11:05:08 (1 occurrences)
Last logged: 11:05:08
/dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00: the gateway type is not determinable, will assume evofw3 (check you have the rights to enumerate USB attrs?)
###
Deze fout is ontstaan door een aangepaste integratie.
Logger: custom_components.ramses_cc
Source: custom_components/ramses_cc/__init__.py:58
Integration: RAMSES RF (documentation, issues)
First occurred: 11:05:08 (1 occurrences)
Last logged: 11:05:08
Disabling QoS (disable_qos=True)
I have no problems to go back to version 0.22.40 - with a reboot of HA and restore_state: false - I have the unavailable sensors again with values.
OK, I know what this is - it is past due to be fixed.
I have added this ‘edge-case’ to my test suite (it is probably not an edge-case).
Fix coming.
See: 0.30.0 - for I|FAN|31D9 - AssertionError: What!! (AA) · Issue #77 · zxdavb/ramses_cc · GitHub
Hi
I’ve just installed 0.30.0 in a temporary VM so that I could test it.
On the first run, it found these devices, but I don’t recognise all the devices, the 17 and the 08? Could these be a neighbour, and what is ‘08’?
Other than that it’s installed and seems fine. I’ll play with it a bit.
It’s looking at an Evohome system with eight HR92 TRV’s, seven zones, two T87 thermostats, the controller and a boiler relay. My other HA Server runs version 0.21.40 of ramses_cc and never gives me any issues, it’ll be interesting to see how this new version works out:-)
known_list:
- ‘01:196480’:
class: controller- ‘18:006659’:
class: gateway_interface- ‘13:194054’:
class: electrical_relay- ‘17:000730’:
class: outdoor_sensor- ‘04:133361’:
class: radiator_valve- ‘04:133363’:
class: radiator_valve- ‘04:133365’:
class: radiator_valve- ‘04:133195’:
class: radiator_valve- ‘04:133207’:
class: radiator_valve- ‘04:133209’:
class: radiator_valve- ‘34:162301’:
class: thermostat- ‘04:133211’:
class: radiator_valve- ‘34:213191’:
class: thermostat- ‘08:000730’:
class: jasper_interface
Cheers for the hard work.
Mike
Here’s my complete configuration:
ramses_cc:
serial_port: /dev/ttyUSB1
packet_log:
file_name: ramses_packet.log
rotate_backups: 7
restore_cache: false
01:155672:
system:
appliance_control: 10:102998 # an OTB
zones:
"00": {
sensor: 01:155672,
actuators: [ 13:184464 ]
}
known_list:
01:155672: { alias: "Evohome controller" }
13:184464: { alias: "BDR" }
10:102998: { alias: "OTB" }
18:069890:
ramses_rf:
enforce_known_list: false
enable_eavesdrop: true
# use_native_ot: always
I set the restore_cache to false and restarted Home Assistant. Now I get this in the log:
2023-11-12 17:47:55.220 WARNING (MainThread) [ramses_rf.processor] RP --- 01:155672 18:069890 --:------ 000C 006 000F0036D090 < CorruptStateError(Inconsistent schema: 13:184464 (BDR): None cant change parent (01:155672_00 (VAL)_00 to 01:155672 (evohome)_FC)(try restarting the client library))
I’ll send the packet log to you in PM tomorrow after the 24 hours and I’ll turn of the enable_eavesdrop feature too.
About the boiler output temperature and the DHW temperature: it looks like the data is coming in after restarting Home Assistant, but after a couple of hours these sensor are changing to unavailable, while other sensors from the same OTB are fine.
I you have any advice on my config, I’d appreciate it!
The 17:000730 is clearly a corrupted packet (of 18:000730) - that is why a known_list is needed, and why it should be enforced.
Same for 08:000730!
It’s just with 0.30.0, a bug stops you from enforce_known_list: true!