Sure - let’s try this: https://buymeacoffee.com/zxdavb
Enjoy your coffee. 
1 Like
Hi David,
The heat demands from the three floor zones are spot on.
But I can’t find any info or entity giving more details about the other things the HCC100 does, like valve positions and pump relais.
But happy with the demand info.
Only thing I’m strugling with is how I can prevent ramses to discover all types of ‘ghost’ devices and entities with the new ‘flow’ settings.
This is the Know device ID list in the new config setting:
“18:262143”:
class: HGI
“01:094566”: {}
“13:028301”: {}
“34:052245”: {}
“34:227157”: {}
“34:227159”: {}
“34:238787”: {}
“04:157356”: {}
“04:019491”: {}
“34:238785”: {}
“04:157354”: {}
“34:041481”: {}
“04:157358”: {}
“04:025691”: {}
“34:232285”: {}
“04:025739”: {}
“34:238783”: {}
“04:025733”: {}
“04:007750”: {}
“04:019489”: {}
But despite this list all types of strange and unwanted devices keep popping up.
Any help is welcome.
I was previously running HA with the HAC Ramses_CC integration on a stand alone install with an HGI80. Which worked, but had the downside of having to maintain a separate HA running on a RPI.
Ramses_ESP arrived, purchased, installed and working with my MQTT Broker, then with the latest release of ramses_cc MQTT support is included. I’v now turned off my HGI80 implementation. BUT I’m struggling to get the same performance / stability with the ramses_ESP.
Location on the HGI and Ramses_ESP Are identical, but I’m not for example getting device names (or is that zone names) and ramses_cc devices flip flop in and out of availability. I’ve even started seeing ‘device communication faults’ on my Evohome controller.
What are the best steps to begin to improve my situation. Pointers please.
UPDATE - Issue Resolved
I’ve resolved the issue with ramses_esp. Whilst looking at MQTT data (thanks to MQTT Explorer) I decided to take a look at the data coming from my ramses_esp, something didn’t look right eventually I worked it out. The data stamp was for 5th Jan 1970! Doh!
I’d not set sntp. A quick update over MQTT and bingo.
Now 100% working as expected, and gone is my reliance on a PI and HGI80 (which might be available if anyone’s interested).
1 Like
Yes, I noticed the same when I set up my ramses_esp dongle. I think it would help others if the sntp setup was marked as mandatory in the docs.
Dear David, thank you for supporting ramses_esp dongle.
Do you think that it might be possible in the future to support more than one dongles simultaneously?
For instance for large houses in order to increase network coverage (defining different device_ids for each dongle and then merging the information)
Thank you in advance for your response
It is possible - but there is so much outstanding work, and this would be a very low priority feature.
It wouldn’t be too difficult - just have the most recent received packet ‘win’, and went sending, just send to both (the destination would probably put up with receiving two packets instead of one).
Only issue would be those packets with a sequence number - e.g. some HVAC remotes.
Which docs you mean - ramses_cc, ramses_rf or ramses_esp?
I think the most obvious would be ramses_cc Wiki (“2. Configuration / MQTT”).
I have the same problem with the time stamp. Can you maybe share what syntax you have used to update your time via MQTT?
Hi all,
I am new in this topic and have question about sending commands with the HGI80, I red the following in the ramses_cc wiki:
Note: You need an evofw3 -compatible gateway for this feature: HGI80s are incapable of supporting impersonation, and their support for faking is very limited.
Are there other options to send commands to my Orcon fan with a HGI80 using ramses_cc?
No, not really.
The HVAC space is not consistent - different vendors do their own thing… There are at least three schemes I know of (orcon, itho & nuaire)…
In any case, you need to either:
- bind the HGI80 as it is was a remote
- have the HGI80 impersonate an existing remote
In either case, the HGI cannot do a) or b), because can’t change it’s (source) device id.
Just wondering, why can’t you do a)? For that you don’t need to change the source device id…
I think the correct TX option would be using the gateway that reported the best RSSI value. Sending via both crowds the bandwidth and increases the chance that neither will get through.
Nobody who can help me out here?
It appears that the latest core update breaks Ramses, fails to setup. Removing evohome from the config does nothing… Going back to 2024.7.4 fixes the problem.
Logger: homeassistant.config_entries
Bron: config_entries.py:604
Eerst voorgekomen: 01:14:38 (1 gebeurtenissen)
Laatst gelogd: 01:14:38
Error setting up entry RAMSES RF for ramses_cc
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 604, 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 184, 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 370, in load_schema
_get_device(gwy, device_id) # domain=key[-4:])
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/ramses_rf/schemas.py", line 343, in _get_device
return gwy.get_device(dev_id, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/ramses_rf/gateway.py", line 396, in get_device
traits: dict[str, Any] = SCH_TRAITS(self._include.get(device_id, {}))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 259, in __call__
return self._exec((Schema(val) for val in self.validators), v)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 315, in _exec
raise error if self.msg is None else AnyInvalid(self.msg, path=path)
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 307, in _exec
return func(v)
^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 205, in __call__
return self._compiled([], data)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 256, in _run
return self._exec(self._compiled, value, path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 315, in _exec
raise error if self.msg is None else AnyInvalid(self.msg, path=path)
File "/usr/local/lib/python3.12/site-packages/voluptuous/validators.py", line 309, in _exec
return func(path, v)
^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 779, in validate_callable
return schema(data)
^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 205, in __call__
return self._compiled([], data)
^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 549, in validate_dict
return base_validate(path, data.items(), out)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.12/site-packages/voluptuous/schema_builder.py", line 382, in validate_mapping
raise er.MultipleInvalid(errors)
voluptuous.error.MultipleInvalid: not a valid value for dictionary value @ data['class']
Same issue here!
@JeroenTogt Can you confirm you have this message too.
Can you post the ramses_rf: section from your configuration.yaml (please ensure you format it correctly).