I am running the Ramses RF integration on Home Assistant on a Rasperry Pi 5 which has MQTT running as another integration.
Screenshot-20241211-114924 hosted at ImgBB
Image Screenshot-20241211-114924 hosted in ImgBB
I am running the Ramses RF integration on Home Assistant on a Rasperry Pi 5 which has MQTT running as another integration.
How would you feel about increasing the timeout as an experiment?
How would you feel about increasing the timeout as an experiment?
Thatās too easy - I tried!
Thatās too easy - I tried!
This is certainly a bit odd. Iāve tried moving the evofw3 to my PC and sending the RQ packet via putty. And no response. I know my setup is ok as I tried to send a 0004 packet and got a valid answer. It is almost as if the 0404 packet is no longer being recognised by the controller.
Iāve tried searching for an old packet log when this was working but with no success.
For info, this is the RQ packet:
RQ --- 18:136212 01:185426 --:------ 0404 007 02200008000100
For info, this is the RQ packet:
RQ --- 18:136212 01:185426 --:------ 0404 007 02200008000100
ā¦ and I can add that it appears a valid RQ|0404|02xx
packet (to request the first fragment of the schedule for zone 0x02
).
Below is an actual RQ/RP pair (albeit for zone 0x00
)ā¦
2021-03-20T22:57:00.662479 000 RQ --- 18:139815 01:201047 --:------ 0404 007 00200008000100
2021-03-20T22:57:00.719326 081 RP --- 01:201047 18:139815 --:------ 0404 048 0020000829010268816DCA311100210C05D11F2019F08320B450A0E4A49C303AA0D82D779E745B26F53ADAB3345DFAE2
To me, it is simply like the controller no longer replies to these RQ
s.
Hi,
Iām not sure of the best place to post this but would appreciate any wisdom!
My boiler diagnostics as reported by Ramses RF show that there is 99% heat demand, itās calling for 70 degrees and the current flow temperature is 58, but the boiler isnāt firing, see screenshot for more:
Image Screenshot-20241211-114924 hosted in ImgBB
My setup is Evohome, with an RA8810 Opentherm controller, Nefits OT to EMS converter, and Worcester Bosch Greenstar 42CDi.
I also have a BBQKees EMS interface to monitor the EMS side of the equation. It also shows that the thermometer is calling for heat but the boiler isnāt firing. The āBurner selected max powerā stays at 0%.
Iāve written an automation that runs every 5 minutes and checks if Heat Demand is > 10%, and current flow temperature is below target, then set āBurner selected max powerā to 74% (this is the max for the boiler). This seems to fire up the boiler and the system performs as I would expect it to, albeit with more cycling than Iād like.
If I disable the automation the boiler will occasionally fire up but nowhere near enough to meat the demand.
Any ideas on why the boiler wouldnāt be firing without my crude automation?
To me, it is simply like the controller no longer replies to these
RQ
s.
I agree.
I think the latest version of Evohome firmware (02.01.01.01) was released April this year. Ramses 0.31.16 was released March 30th. First bug report I can find for get_zone_schedule service failing was April 16th. In my mind not beyond the realms of possibility that 02.01.01.01 has broken this.
I agree.
Yes - I had done all I could with it & ran out of ideas ā¦ Looks like weāve lost that functionality.
While setting up Ramses_cc I experienced sensor values going from their correct, recently received status to āUnavailableā all the time, in a time frame of about a minute.
Aforementioned did occur with Ramses_ESP over MQTT but not over serial port. As it turns out, when the Ramses_ESP SNTP server is not configured, MQTT messages are dated with year 1970, probably causing Ramses_cc to believe these are very old and therefore triggering the āUnavailableā status.
Fixing this is easy: configure the SNTP server (see Ramses_ESP docs) and reset the device.
Knowing this, it could helpful for new users if Ramses_cc would log a warning on reception of a message dated such a long time ago, or something similar.
@hsluis @brjhaverkamp reading backwards a bit I believe this might help you.
Last hour I setup the SNTP server and setup the RAMSES_ESP in MQTT mode again. First impression, no unavailable situations untill now. To be certain I need to evaluate longer, but I have a good feeling that this solved the issues. Your explanation is very logical, thank you so much.