What is more likely is that this is a corrupt packet.
This suggest a hardware problem, which would explain all his issues.
Thanks for responses. The only change was an update to latest version, all was previously working so seems a slightly strange coincidence that hardware would fail unless the new version is a little fussier.
Indeed 01:000730 did not appear in known devices - I have now added it to my config, as per my below, however the log error is identical.
I do have a Honeywell opentherm connector on my boiler not located near the nanocul which never previously connected, could it be this got connected?
I am happy to change the nanocul (which is quite old) to latest whichever one you recommend.
Appreciate any help or advice, thanks.
ramses_cc:
serial_port: /dev/serial/by-id/usb-SHK_NANO_CUL_868-if00-port0
# baudrate: 115200
packet_log:
file_name: packet.log
rotate_backups: 7
ramses_rf:
enforce_known_list: true
known_list:
18:196881: #gateway_interface
#18:196881: {class: HGI}
01:081083: #main TCS
01:000730:
04:023774: #Hall Actuator
04:023780: #Studies Sensor class': 'radiator_valve
04:027356: #Studies Actuator and 80 above
04:027648: #Lounge class: radiator_valve and sensor
04:027358: #Lounge Sensor
04:027360: #Niamh SEnsor & Actuator class': 'radiator_valve
04:027646: #Ellie SEnsor & Actuator class': 'radiator_valve
04:027650: #Hall Actuator
04:027656: #TV Lounge sensor and actator class': 'radiator_valve
04:027714: #Hall Actuator
04:027716: #Master Bed SEnsor & Actuator class': 'radiator_valve
04:027718: #Craig SEnsor & Actuator class': 'radiator_valve
04:027720: #Hall Actuator
04:027722: #Hall Landing Sensor and actuator class': 'radiator_valve
07:025191: #Stored Hot Water Sensor
13:001489: #Kitchen Diner Actuator
13:001522: #Ensuite Actuator
13:055679: #Grnd Bed Actuator
13:173107: #Hot water Valve
13:224329: #games room Actuator
34:027677: #Grnd Bed Sensor class': 'zone_valve
34:063533: #games Room sensor class': 'zone_valve'
34:150571: #EnSuite Sensor class': 'zone_valve
34:150655: #Kitchen Diner SEnsor class': 'zone_valve
# seperate program
# logger:
# logs:
# custom_components.ramses_cc: info # show ramses_cc/ramses_rf state
# ramses_rf.dispatcher: info # show packet payloads
Why have you added this to your known_list? Can you point to the corresponding physical device in your house?
I wasnât clear: my suggestion was that is was a device id from a corrupted packet. The device doesnât exist.
The âOpentherm connectorâ has a device_id starting with 10:. If you look in your packet log, you should see lots of packets to/from this device.
I am afraid that all evidence I have is that you have a (virtual?) hardware problem.
Have you tried tuning it? What are your RSSI values?
Is there a method available now, or being worked on, that doesnât require the stick to be plugged in to the actual HA machine? I donât mean ser2net.
My physical box is about to die and I want to move HA back to my VM platform.
I am sure I saw mention of something either available or being worked on, but at over 4300 posts in this thread, finding it has been impossible!
MQTT is coming soon, see here.
I have one, and it works well. You can put them wherever it has USB power, and can reach Wi-Fi.
When heâs ready, heâll sell them here.
RuntimeError: no running event loop means the task is being created in the wrong thread. Please make sure any calls to self._loop.create_task(coro) are running in the event loop thread as creating the task from the wrong thread is not thread-safe and may crash Home Assistant.
Iâll need to put some time aside to review all this, afterall it was working before upgrade and as has been suggested it may be a problem associated to being on a VM (Proxmox). I added the 01:000730 as suggested above by Kars and no I dont believe it is a physical device. I have no idea about tuning the RSSI values so will have to go back to the drawing board on all this. Thanks
Rocksolid here on proxmox, as a VM. How have you mapped the USB device? This works for me:
As an aside, the original nanocul (software UART, Atmega 328p) has proved problematic for me in the past - many corrupted packets. The sticks with a hardware UART (Atmega 32u4 - SSM D2 and Busware) are significantly more stable. A decent external antenna may also help with RSSI and overall stability - I have other 868 MHz devices in the home so this really helps.
Actually mine was different as below:
Have changed to same as yours now I get a different error as below:
Logger: homeassistant.config_entries
Source: config_entries.py:575
First occurred: 12:17:23 (1 occurrences)
Last logged: 12:17:23
Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 575, in async_setup
result = await component.async_setup_entry(hass, self)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/config/custom_components/ramses_cc/__init__.py", line 89, in async_setup_entry
await broker.async_setup()
File "/config/custom_components/ramses_cc/broker.py", line 146, in async_setup
await self.client.start(cached_packets=cached_packets())
File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 183, in start
load_schema(self, known_list=self._include, **self._schema) # create faked too
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 353, in load_schema
load_tcs(gwy, ctl_id, schema) # type: ignore[arg-type]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 394, in load_tcs
ctl = _get_device(gwy, ctl_id)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 336, in _get_device
check_filter_lists(dev_id)
File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 332, in check_filter_lists
raise LookupError(
LookupError: Can't create 01:000730: it is in the schema, but not in the known_list (check the lists and the schema)
I also see there is now a configuration menu. Do I need any entry in the âadvanced serial portâ entry?
Is the Scema from this configuration menu taken
from the config file?
The entry 01:000730 Is clearly the problem I guesss, is there a way to remove this perhaps?
Ok great is there a link for a proven current device perhaps?
Really appreciate help.
Have you tried using the âclear cacheâ configuration options & reloading? This may remove the corrupted device from your schema.
For me, in a proxmox VM, both of these work. The busware one is a bit more fiddly as it uses a DFU bootloader, but perfectly capably of running evofw3
1 Like
Thank you so much for your advice. Its now working. I think maybe clearing the cache did the job. Really appreciate that. I will also get a more reliable stick.
It seems the new version is much more refined. I still have a few errors likely down to my original configuration file. I will go over the Wiki and try to tidy up. Again many thanks.
1 Like
Funnily enough I had the exact same error (including the 01:000730 device). Clearing cache resolved the issue. Using a nanocul with evofw3.
It isnât odd at all⌠the underlying protocol is very error-prone, with poor error detection, and no correction.
It takes a single bit flip to change from 18:000730 (a very common address) to 01:000730âŚ
This is one of the reasons why creating /enforcing a known_list is strongly recommended.
I also got the recommended indalo-tech device. It took all of one minute to swop out old and replace new, no idea if its any better but all working fine.
I added a suggested device from my error log and it deleted all of my known devices from the Ramses known devices list in the app itself, all still works fine but I need to review how to add these known devices back in from the Wiki instructions.
In shortâŚ
- use the config_flow version of RAMSES RF with an empty
known_list, and without enforcing aknown_list - it will auto-detect the gateway ID (18:xxxxxx) and you can look for that entity, it will be called
HGI 18:xxxxxx Gateway status - have a look at the attributes of that entity, it will have the suggested (minimal)
schema, and the workingknow_list
Then add the schema and known_list to the system configuration.
I am having trouble with a specific HR92 TRV which is not showing the heat_demand sensor value, it always reports unavailable. However, the climate sensor for the same TRV is working perfectly fine. It correctly reports the temperature, setpoint, etc. but the separate heat_demand entity doesnât work. All other HR92 TRVs are fine.
I am requesitng some guidance on how to troubleshoot and resolve the issue, thanks 