Honeywell CH/DHW via RF - evohome, sundial, hometronics, chronotherm

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?

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

ā€¦ 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 RQs.

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:

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?

moved to Itho / Orco / Nuaire: Fan metrics, Remote control & Sensor faking via RF - #14 by zxdavb

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.

Yes - I had done all I could with it & ran out of ideas ā€¦ Looks like weā€™ve lost that functionality. :frowning:

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.