I’ve just updated to 0.22 and got the following error
Logger: homeassistant.config
Source: config.py:835
First occurred: 15:20:48 (1 occurrences)
Last logged: 15:20:48
Invalid config for [ramses_cc]: value None is of the wrong type for a regular expression for dictionary value @ data['ramses_cc']['advanced_features']['message_events']. Got None. (See /config/configuration.yaml, line 21). Please check the docs at https://github.com/zxdavb/ramses_cc
I don’t have any advanced_features set in my config, any idea what I should add?
Same issue for me, after update to 0.22, all entities became unavailable and I could not reboot until I’ve added below, and now all entities are back to normal
Deze fout is ontstaan door een aangepaste integratie.
Logger: homeassistant.helpers.script.websocket_api_script
Source: custom_components/ramses_cc/remote.py:135
Integration: RAMSES RF (documentation, issues)
First occurred: 18:55:01 (1 occurrences)
Last logged: 18:55:01
websocket_api script: Error executing script. Unexpected error for call_service at pos 1: must be exactly one command to learn
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
await getattr(self, handler)()
File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
await service_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
task.result()
File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 769, in handle_service
await service.entity_service_call(
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
future.result() # pop exception if have
File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
await coro
File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
await result
File "/config/custom_components/ramses_cc/remote.py", line 209, in svc_learn_command
await self.async_learn_command(*args, **kwargs)
File "/config/custom_components/ramses_cc/remote.py", line 135, in async_learn_command
raise TypeError("must be exactly one command to learn")
TypeError: must be exactly one command to learn
Hello and first of all thanks a lot for this project.
I am sorry to bother with my question, but I am getting a bit confused, since I am not familiar with the ramses protocol. I purchased this to communicate with evohome as recommended on ramses_rf and evofw3 github. It seems like I can see the communication in my network properly, but the opentherm bridge is not responding to the requests. Is there some kind of registration to be done between the devices or something like that?
I went down to try some simple request as I figured from this thread but does not seem to work. It seems strange that the request is being sent 4 times. And there is no reply. This is the output:
$ python client.py monitor /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00 -o packet.log -x "RQ 01:083384 1F09 00"
client.py: Starting ramses_rf...
- Discovery is enabled...
18:55:38.619 Best practice is exactly one gateway (HGI) in the known_list: []
18:55:38.619 It is strongly recommended to provide a known_list, and use it as a whitelist (device_id filter), configure: enforce_known_list = True
client.py: Starting engine...
18:55:38.620 Not using any device filter: using a known_list (as a whitelist) is strongly recommended)
18:55:38.654 Active gateway set to: 18:000269, configure the known_list/block_list as required
18:55:38.654 || HGI:000269 | 63:262142 | I | puzzle_packet | || {'datetime': '2022-11-04T18:55:38.620', 'engine': 'v0.22.0', 'parser': 'v0.22.0'}
18:55:38.691 || HGI:000269 | 01:083384 | RQ | system_sync | || {}
18:55:38.916 || HGI:000269 | 01:083384 | RQ | system_sync | || {}
18:55:39.123 || HGI:000269 | 01:083384 | RQ | system_sync | || {}
18:55:39.327 || HGI:000269 | 01:083384 | RQ | system_sync | || {}
Later in the outpu i can see that communication between Thermostat ( round ) and OTB is running correctly.
ramses_rf is trying to send opentherm request messages, but without a response from OTB. Can someone please give me a hint what I am doing wrong?
I am testing a few meters and one wall from the OTB. But I have tried to go just next to it and the result was exactly the same. I can even see low values in the packet.log ( below 60 ), so I guess this is not the problem.
I will take a look into the autotune. Thank you for the link. I was even considering it before asking the question. But there is said you should autotune when you have problems receiving and sending packets. I guess I can see the communication very well, but everyone is ignoring my requests.
EDIT: I have performed and saved the calibration ( !FT + !FS when finished ). But the behaviour remained the same.
I am sorry about 01:083384. Thats my misunderstanding. As I said I am not familiar with the ramses protocol and i misinterpreted some information from here and thought that the ID should start with 01: for the test message. Anyway, I have tried with the original 10: as well and the result is the same.
From the communication I have found theat THM is sending actuator state RQ to the OTB. So I tried to send exactly the same RQ but without a reply from OTB. If THM ( 34:182131 ) sends the RQ the OTB replies immediately. This is the packet log which will probably ilustrate better what I am trying to say:
Is there maybe some special RQ I can try to send to the OTB? Should the OTB reply to "RQ 10:083384 1F09 00" as you are suggesting elsewhere in this forum?
Perhaps you could make it more clear what you’re trying to achieve?
You cannot effectively send packets to a Round Thermostat, it is (well, almost all are) battery powered and so spends most of it’s time not listening (to save battery).
The OTB will never respond to an 1F09. Perhaps you could try (using your device_id):
What I would like to acheive is to talk directly to OTB and probably set the modulation level to control the heating even without round termostat and honeywell app involved. But I am not sure if this is even a bit realistic approach. So to start with something simple I was trying to get at least some response from the OTB.
Thanks for making it clear about the 1F09 request. It is meant to be sent to the evohome controller, right? Which i do not posses so it is probably irrelevant to me.
I was not sending packets to the Round Thermostat. I was trying to get a response from 10:083384 which is my OTB.
tried this. And as I understand it it is a opentherm status request message, ok? It seems like the same message ramses_rf is trying to send in the discovery mode ( the first of many opentherm requests ) and all of these timeouts as the OTB never replies.
I even tried to get 0.21.0 and run the -X scan_disc 10:083384 ( it is the OTB is that right? ). But to be honest I am not sure what this is supposed for?
But I am starting to feel I am getting this all wrong. My setup is
boiler Intergas HRE with builtin OTB
CM737 round thermostat
RFG100 internet gateway
and I had to pair thermostat with the boiler and then the gateway with thermostat. Is there not some kind of pairing needed even with the SSM-D I am using? Can that be the reason why OTB is not responding to the requests?
Thank you a lot for your time. I really appreciate that very much.
I believe the HRE does not include an OTB (OpenTherm Bridge) - instead, I think it has an OT (OpenTherm) slave.
The CM737 is not a round thermostat - don’t you mean the T87M - it is a round thermostat that does OT via a 2-wire bus (cable) connected to the OT slave.
The round thermostat will talk RAMSES to the RFG100 - but there is no R8810A/R8820A in your system.
you’d need something like the OTGW.
Or maybe you do have a CM737, talking TPI to the boiler (instead of OT) and a round thermostat as a room thermostat?
In either case, ramses_rf (and thus ramses_cc) may be able to pick up some sensors for you (by eavesdropping conversations to/from the RFG), but little more (as it was never written for your use-case).
I am sorry, it is not a good use of my time to help you more (i have a very long to-do list) - perhaps others can chip in.
(have you considered that the pckets you’re seeing belong to your next-doo neighbour?)
I’ve got an Nuaire Eco Heat HCS that I’d like to integrate with Home Assistant.
I haven’t bought the extra remote control for the unit as it’s a 1/4 of the price of the PIV in the first place. I was hoping that I could just get the control working through the 868mhz RF USB dongle running evofw3.
I’ve installed the ramses_cc from HACS. and then entered the required USB port within the configuration.yaml. I’ve restarted the system and the packet log finds the device OK.
To get things rolling I copied the entire example from the ramses configuration wiki
All, I’d be grateful if someone could write a tutorial in the wiki about what to do after step 1 and before step 2.
It might involve temporarily enabling eavesdropping.
Then it would be a matter of pulling out data from the extended sate attributes of the gateway (the device with an ID start 18:), and (say) the controller (device starting 01:).
Yes, you are totally right, I misread it, it seems to be RFT87. The termostat talks to both – the gateway and the boiler as seen in the ramses eavesdropped conversation. So i believe that the boiler has something like OTB builtin as there is no other device i have installed and there is some communication.
I am almost sure, that it is communication from my system. First of all, neighbors are pretty far to pickup their communication. And the communication i see corresponds to what is happening in my system. And the signal is pretty strong as seen in the second post i posted here. The only thing is, that if i sent the exactly same packet to the OTB as the termostat did. I receive no reply and the termostat does.
Anyway I totally understant that you dont have time for this. One last thing. Can you maybe point me out somewhere to study more about ramses protocol and device communication, so I can dig in? And i really appreciate effort. Thanks a lot for all the time and advices. I know its time consuming and I really really appreciate that.
