@SvenH-01 and (any others using the new RAMSES_ESP dongle with MQTT), I have just released version 0.41.23 with fixes for MQTT.
Let me know how that goes.
1 Like
I am dropping support for the non-Config flow version of the RAMSES integration.
I have had no complaints about that branch.
Please migrate to the 0.41.x branch.
2 Likes
David,
many thanks for the new version. Working perfectly now.
Thanks again for the super fast fix. Is there any option to send a donation?
Sven
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?