@llevering I am wondering what sort of electrical device you’re turning on/off?
There’s no need to explain how to do it - I can handle that - I am wanting to know the use-case.
Well the thing is that UFHs and the OTB for the boiler don’t work well together. The heater is often providing hot water, while floor heating loops are closed and all the hot water is looped through the bypass. At least this is a theory that is discussed in a lot of dutch communities. I would like to test and see the difference, but buying a BDR91 just to see what happens was a bit to much for me. But one would be able to do a lot of cool stuff with it. You could use it to drive zone valve’s without having a real BDR91 and replacing UFH units, as you could directly put power on the thermal valve of a underfloor heating unit and there are a lot of devices that could switch 5 to 8 zones that are way-way less expensive than a HCE80 for example (to late for me, but other people could benefit greatly from it I guess).
I can provide it tonight if you want
I never understood the reason for this, but we have a hot water UFH setup in one of our bathrooms that our installer for evohome said could not be integrated into the evohome setup. I really don’t understand why a standard TRV can’t work here, but apparently it can’t? Would be interested if anyone knew why.
I have one device (04_231770), that is from time to time unavailable. Any recommendations on how to fix this?
Should it do a rebind?
Rebinding wont make any difference.
Either packets are getting lost, or my code needs tweaking - packet logs please.
It looks to me like you’re getting dropped packets:
> cat .secrets/phdelodder/evohome_cc_packet.log.* | grep ' 04:231770 .* 12B0 '
2021-10-20T23:20:04.642997 074 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-20T23:20:04.923837 075 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T00:20:07.062562 081 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T01:20:07.104232 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T01:20:07.893072 078 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T02:20:07.707579 078 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T03:20:03.766998 082 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T03:20:06.078988 082 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T04:20:06.301629 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T04:20:09.426612 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T05:20:05.891841 084 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T05:20:07.594819 085 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T18:20:05.843089 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T18:20:06.733112 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T19:20:02.894329 080 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T20:20:02.990842 076 I --- 04:231770 --:------ 01:223036 12B0 003 010000
2021-10-21T20:20:03.068817 075 I --- 04:231770 --:------ 01:223036 12B0 003 010000
You can see there is supposed to be a pir of these every hour - sometime you get only 1, sometimes none.
Any idea on how to resolve this dropping?
Another thing I have a zone and it’s constantly being set to 5°C, it’s not coming from HA. What could be the reason of that?
2021-10-24 02:20:26 INFO (MainThread) [ramses_rf.message] || CTL:223036 | HGI:005567 | RP | zone_mode | 00 || {'zone_idx': '00', 'mode': 'temporary_override', 'setpoint': 5.0, 'until': '2021-10-24T07:00:00'}
I am madly trying to get version 0.15.0 to drop (current version 0.14.24) - lots of bug fixes, and preparing the way for HVAC.
The issue is the device IDs (e.g. 10:123456):
- for CH/DHW, the number in front of the colon will definitively tell you the type of the device (
10:is an OpenTherm bridge) - for HVAC, this is not the case
So, for HVAC, I need to shoe-horn in a way of setting a device type using something other than the device_id, and get that into the schema.
I am also needing to fix some other very fundamental design issues - at the moment a cached schema ‘overrules’ a hand-crafted schema, and this shouldn’t be the case.
Answers to the above issues are unfortunately non-trivial.
Thanks for the great work. I have three faked zones and it works well on my side.
I have UFH with OTB. Do you still need some packet logs ? If yes let me know what you need and I’ll try to capture them.
I have been using evohome-Listener, but decided to move to evohome_cc. I seem to have it basically working, but I do have a couple of queries. Firstly, why is only my first room being named in the schema, and secondly, where is it getting that from?
All zones should be named (although a zone name is not part of the schema - they are there for your convenience only). The usual cause for missing data would be dropped packets - look in your HA log
ramses_rf simply asks the controller for the zone name of each zone (the zone identifier is a 2-character hex number, 0x03 in the below example):
12:49:05.499 || HGI:006402 | CTL:145038 | RQ | zone_name | 03 || {}
12:49:05.525 || CTL:145038 | HGI:006402 | RP | zone_name | 03 || {'zone_idx': '03', 'name': 'Kitchen'}
I generally always welcome packet logs - especially if they have OTB and/or UFH.
Thanks - I think disabling eavesdropping may have solved that issue.
I’m seeing lots of ‘expired’ messages in the logs - is that anything to be concerned about?
I would never recommend eavesdropping, unless required.
It depends on how many expired packets there are…
@cinnamon @bishop and others
I intend to supply full support for these HVAC systems - they use the same RAMSES-II protocol.
The issue is as described above, they take a different approach to naming devices, and this obligates fundamental changes to ramses_rf, that I am fitting in now.
1 Like
If you need anymore packets from my PIV let me know.
Around 40 in the last 30 minutes?
Can you explain what the message is trying to warn me about, and what the percentage at the end of the message indicates?