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:
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
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.
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…
known_list, and without enforcing a known_listHGI 18:xxxxxx Gateway statusschema, and the working know_listThen 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 
The next step would be to look in the packet log for 3150 packets from that TRV, and see what their payload is.
I have just noticed that Pete is now advertising the RAMSES_ESP dongle that adds MQTT support (you can get on a waitlist to buy one):
And I can confirm that the RAMSES RF (was ramses_cc) integration currently supports MQTT - all my test / dev is using this device.
This means you can locate the dongle anywhere where it gets the best RF reception (to your CH/DHW / HVAC devices), and it can reach the MQTT server via WiFi.
Hello David, I am following up regarding my post in the forum about a missing heat_demand sensor on a specific TRV
Packet log shared privately.
The strange thing is that I can’t find any lines that match the TRV 04:107303 like I can for other TRVs but unexpectedly the climate entity climate.01_182924_03 works perfectly fine, I can change setpoint, read the temperature, etc. It’s just the heat_demand sensor is the problem. I also moved the TRV closer to the head controller, but that hasn’t made a difference either.
I appreciate your guidance on solving the problem.
Btw, I am using the heat_demand sensor to create a template sensor that is capped to the current temperature (rather than %). By doing so it allows me to replicate the standard HA temperature card using the custom button-card which can be then tweaked to my liking. Picture example below.
Taken delivery of my RAMSES-ESP, but no joy getting the hacs install of RAMES_RF to connect to my MQTT broker.
I’m getting the following error
Logger: ramses_tx.transport
Source: /usr/local/lib/python3.12/site-packages/ramses_tx/transport.py:1060
First occurred: 14:49:36 (6308 occurrences)
Last logged: 17:48:52
Disconnected with result code 5
MQTT broker is generally working with my HA install and other publishers and subscribers.
Welcome.
See: Types and enums — Eclipse paho-mqtt documentation
Reason code 5 is CONNACK_REFUSED_NOT_AUTHORIZED.
Please check the URL. Perhaps you could post it here (minus the password) for us to check. Does the username/password have any special characters?
Otherwise, check the configuration of your MQTT broker.