How would you feel about increasing the timeout as an experiment?
Screenshot-20241211-114924 hosted at ImgBB
Image Screenshot-20241211-114924 hosted in ImgBB
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.
Is there a way to change between heating/cooling mode from home assistant?
I can run tests if needed on my Evo Home.
I have an heat pump doing both heating and cooling with underfloor pipes.
Thanks
Given the Honeywell app can still retrieve and update the schedule, is there a way to eavesdrop on that traffic and work out what has changed?
I can grab all the schedules in json format using a python script and the evohome-client library. It is just I would rather not rely on accessing anything from the Honeywell servers.
Hi David - Slightly surprised at the minimal reaction to this news. This integration is pretty much the most important for me. Unfortunately, it is not in my skillset to offer to pick it up. I will keep an eye on updates in the hope that someone does come along and continue your fine work. Many thanks for all your efforts.
First, the (semi-) official RESTful API does not support cooling - you can raise this with Resideo.
Is there a way to change between heating/cooling mode from home assistant?
TL;DR: No, not with Ramses RF.
Certainly, you can send crafted packets to the BDR91T, etc, to make this happen, but I fear the controller won’t wanna know?
I have a few ideas how to test this, but I will not be in a position to do that work myself (I am currently selling all my evohome hardware).
If someone is interested, I could offer a few tips.
@zxdavb Aw man, say it ain’t so… This whole integration is what got me started with Home Assistant in the first place. Very sad to dee you move away from Evohome and the integration. Unfortunately my programming and coding skills are equal to a monkey on a typewriter I’m good with general ideas and throwing stuff at the wall, to see what sticks, but no lower level (or should I say higer level?) shenanigans unfortunately. Really hope someone is up to the task who can continue your work. I’m on district heating, so no way to move to a heatpump
Thank you for all your hard work David!
@everyone else:
I’m I the only one having some weird delays in reporting in HA which is almost instant on the controller? If I change the temperature and demand shoots up on the controller menu, the reporting used to be almost instant in HA, but nowadays it seems it takes ages for HA to reflect the changed heat demand. But also the controller itself can take it sweet time to change heat demand. For instance. I’ve upped the temperature requested at 0:02. The controller updates 3 or 4 minutes later. The zone heat demand in HA shoots up directly, and my BDR91 clicks on. The BDR91 heat demand though, takes anywhere between 5 and 30 minutes to reflect the heat demand. Is this something that has always been there and am I just seeing ghosts or is this something new?
Thank you so much for all your work on this @zxdavb !
Hoping someone can help! I’m trying out the wiki to pair the BDR91 to my Ramses-ESP.
I’ve prepared the string to send and am seeing packet logs coming into the Serial Monitor on the Arduino app. I put the BDR91 into pairing mode (flashing red) but when I send the string that’s required, I don’t see any “W” messages coming back. Any idea what could be wrong? I tried a few different baud rates as I wasn’t sure about that but it doesn’t seem to be working. I’ve tried skipping past the W message in case I have the old type BDR91 but that doesn’t work either.
See below the string I’m sending. Any help much appreciated - thank you!
Details
BDR91
13:184207
36CF8F
Gateway
18:103996
49963C
String to send
I — 18:000730 --:------ 18:103996 1FC9 012 00000849963c001FC949963C
Sad to hear this, but many MANY thanks for all the hard work you’ve put into this over the years, and for all the work you’ve done implementing and debugging our mostly unknown HVAC messages.
Hoping someone can help! I’m trying out the wiki to pair the BDR91 to my Ramses-ESP.
I’ve prepared the string to send and am seeing packet logs coming into the Serial Monitor on the Arduino app. I put the BDR91 into pairing mode (flashing red) but when I send the string that’s required, I don’t see any “W” messages coming back. Any idea what could be wrong? I tried a few different baud rates as I wasn’t sure about that but it doesn’t seem to be working. I’ve tried skipping past the W message in case I have the old type BDR91 but that doesn’t work either.
See below the string I’m sending. Any help much appreciated - thank you!
Details
BDR91
13:184207
36CF8FGateway
18:103996
49963CString to send
I — 18:000730 --:------ 18:103996 1FC9 012 00000849963c001FC949963C
I wrote that original Wiki page in 2022, after getting this to work. Somewhere in its history, that page has been changed. The string that I sent (and I still have my original notes) was
I --- 18:136212 --:------ 18:136212 1FC9 012 0B00084A14140B1FC94A1414
And in fact, my sample packet log still appears on that page. Note the difference is the first device_id is the same as the third device_id (2nd device_id is blank).
I’m positive there would have been very good reasons to update the page, to presumably match changes in the code.
You question whether you have the correct baud rate. If you do, you should be seeing all evohome messages that are being generated by the devices in your system.
Hi HA-Enthousiast and Hsluis.
Good to hear that this approach works. I haven’t gotten around to testing it. However, I will have to set up an sntp server internally first. I have my gadgets on an internal IOT wifi ssid, that don’t get internet access. So an external sntp server is no option.
@David, Isn’t there an other way to get the time for Ramses_ESP?