If you cast your mind back I had this problem with my ideal boiler.
Just a question out of curiosity, is it possible to fake a R8810A1018 (opentherm bridge?)
Or is it possible to see the boiler setpoint without having a opentherm bridge?
Background info: I have a very old oil burner without any logic. (always on), which I converted to something smarter. (a few temperature sensors, a shelly relay and a few safety devices (analogue))
So I can now set the boiler temperature and set pump speed, see boiler temp and return temp, on/off status.
I now made a ācurveā in HA based on the RAMSES ā%demandā
But can I fake this to as an opentherm bridge?
I canāt get the send_packet service to work with any of the 0.30.x versions.
Iām trying to send a packet to turn on/off the BDR relay, using the example from the GitHub wiki, which was working most recently a couple of weeks ago on 0.28.
Essentially, I call send_packet, and nothing appears in the packet log and there are no errors shown in the HA log at the time of calling the service.
My config is as below.
ramses_cc:
ramses_rf:
enforce_known_list: true
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
scan_interval: 60
packet_log:
file_name: packet.log
rotate_backups: 7
restore_cache:
restore_schema: false
advanced_features:
send_packet: true
# message_events: true
# enforce_known_list: true
known_list:
01:172890: {class: controller}
04:033094: {class: radiator_valve} #BR1
04:032948: {class: radiator_valve} #BR2
04:033104: {class: radiator_valve} #Bathroom
04:032940: {class: radiator_valve} #LR1
04:032942: {class: radiator_valve} #Office Main
04:033100: {class: radiator_valve} #Kitchen
04:076615: {class: radiator_valve} #Toilet
04:076585: {class: radiator_valve} #BR3
04:076583: {class: radiator_valve} #Upstairs
04:076587: {class: radiator_valve} #Ensuite
04:032944: {class: radiator_valve} #Office2
04:033088: {class: radiator_valve} #LR2
01:000730: {class: controller}
01:136410: {class: controller}
13:086478: {class: electrical_relay}
52:000730: {class: hvac_device}
08:000730: {class: jasper_interface} #I think this is a corrupted packet - no idea what a jasper_interface is!
12:130337: {class: thermostat}
12:113499: {class: thermostat}
12:040870: {class: thermostat}
18:000278: {class: gateway_interface} #possibly the relay controller
12:194299: {class: thermostat}
03:123456: {faked: true} # faked thermostat for Downstairs hall
The send_packet action looks like this:
- service: ramses_cc.send_packet
data:
device_id: "18:000730"
verb: I
code: "0008"
payload: "0000"
Iām using an IndaloTech evofw3 USB dongle - I donāt know how to check the exact firmware version?
I can also try downgrading to 0.28 tomorrow evening and trying again and I have a packet log I can send if that is of use?
I also have a single heat demand sensor which remained as Unavailable despite restore schema/state set to false and the system running for 24h (prior to upgrade, more sensors were Unavailable, after, one remained).
Is there anything I can do to get send_packet working again, and the heat_demand showing correctly?
Most of the above devices IDs are have been eavesdropped from corrupted packets (some eavesdropping still takes place, despite the absence of enable_eavesdropping: true) - they shouldnāt be in your known_list.
This is the whole point of having a
known_list- you rationalise the device ids you see against the devices you have.
I guess one of them is your controller - you can work out which one it is, easily enough.
For CH/DHW devices, you do not need to specific the device class (the sole exception is the gateway, the device that starts with 18:, probably 18:000278 (look in your packet log to be sure).
Wow!
I think youāre asking if your evohome controller can be bound to a faked OTB that will then send instructions to your setup via HA automationsā¦
Yes, but ramses_rf is not geared up to do any of the heavy lifting, and the work required (e.g. HA automations) would be complicated and a little onerous.
But if youāre keenā¦
If itās any use, Iāve been doing this for a while. My boiler claimed to support OpenTherm, but when I bought the official bridge it turns out it only supports a pretty old version which isnāt compatible.
I ended up setting up a digital potentiometer to act as a fake outdoor reset sensor (ie ātellingā the boiler that the temperature outside is a certain level so that it sets the flow temperature) - with a script in OpenHAB initially, now HomeAssistant, to scale up and down the fake temperature to allow the flow temperature to be controlled.
Interestingly I note that EvoHome has a habit of jamming the OpenTherm demand up to 100% every time thereās a 100% demand from CH, even if itās actually turned the radiators on early to account for how long it takes to warm up the house - so my script deliberately has a lag to allow the boiler to stay at lower flow temperatures rather than going straight up to max.
You can check the evofw3 firmware version by typing !V in a serial console connected directly to the USB dongle. (e.g. Putty)
v0.7.1 is the latest, December 2021.
Also, in your config you show an 18:xxxx device in the known list. Thatās probably your evofw3 device, presumably you saw the 18:xxxx in the logs?
evofw3 uses a unique xxxx ID based on the hardware signature of the AVR CPU. You can either figure this out from looking for 18: in the ramses_cc log, or by a !I command to evofw3.
1 Like
Thanks - I think I know which device is which now - the known list was a hangover from leaving discovery on for a bit too long when I first set it up over a year ago.
Iām a bit more stuck with the send_packet service though - how can I get that working again in HA with 0.30.2?
Iāll add it to the list.
1 Like
Can those people who are using the ramses_cc.send_packet service call let me know what theyāre using it for?
This feature is to be made a first-class citizen.
Can those people who are using the
ramses_cc.send_packetservice call let me know what theyāre using it for?
Defeating the TPI aspects of the CH BDR so that the CH valve remains open as long as there is a demand.
Hi,
Could you give a bit more details on how you defeat the TPI to keep the valvle open as long as there is heat demand ? I am interested.
I have UFH and the behaviour of evohome is really annoying me. It keeps opening and closing the valve to the UFH zone which I find very inefficient (see example graph below of the oscillation of the water temperature in the UFH circuit which are generated by the valve opening and closing). I would like to force the valve to stay opened for the duration of the heat demand instead of oscillating
.
Simply put, if demand is above a threshold (6% from memory), I send an open packet to the BDR91. The BDR91 is double bound (to the Evohome Controller and to the dongle with fw3), and it operates in OR mode - either source can ask for the valve to open.
The Wiki article I wrote has some of the details, and some of the thinking that went into it can be seen here.
1 Like
Iām about to update to 0.30.2 (from 0.22.40) and would like to check whether my planned logger config is sensible:
logger:
default: warn
logs:
#custom_components.evohome_cc: warn # use info for Schema
ramses_rf.message: warn # MSGs rcvd (excl. RQ/18:), is the one you usually want
#ramses_rf.protocol.protocol: warn # PKTs sent (excl. retries) & rcvd
#ramses_rf.protocol.transport: warn # RF Tx'd (incl. retries) & Rx'd
ramses_rf.dispatcher: info # TIP: info for logging messages (excl. RQs)
ramses_tx.protocol: warning # TIP: info for logging packets Sent/Rcvd
ramses_tx.transport: warning # TIP: info for logging frames Tx/Rx
I also think that the rest of my config is sensibly minimal but possible Iāve missed something over the months:
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
packet_log: packet.log
scan_interval: 60
restore_cache:
restore_schema: true
restore_state: true
ramses_rf:
enforce_known_list: true
#enable_eavesdrop: false
#disable_discovery: true
#disable_sending: true
01:164379:
system:
appliance_control: 10:047712
zones:
"0A": {sensor: 01:164379}
known_list:
01:164379: # Controller
02:020364: # HCE 80 UFH Controller (Zone 1 - Dining Room / 2 - Living Room / 3 - Hall)
04:062953: # HR92UK Bed 1
TRUNCATED
07:046947: # CS92A DHW Thermostat
10:047712: # R8810 OpenTherm Bridge
13:120242: # BDR91 DHW Demand
18:065802: # evofw3
34:144335: # T87RF Thermostat (Living Room)
TRUNCATED
Finally, I am regularly seeing āUnavailableā for zone demand for short periods. Iām wondering if the timeout for 0% demand can be made longer i.e. display 0% rather than āUnavailableā? (There is a related issue with zone demand in the Amazon Echo integration which only ever shows āUnavailableā for the two zones that use T87RF thermostats which relate to two zones on the UFH controller.)
I am not needing to comment on your config/schema - it is OK.
The thing is, Unavailable has a distinct meaning, separate from 0%. You can create a filter for this (i.e. turn None into 0), but it may be that I have set the timeout too tight (IIRC, if the latest packet is >2.2x older that itās expected cycle time, then the data is considered stale)ā¦
I can have a look only if you can provide a packet log taken in a 24h windows when you saw this behaviour, and also indicate the datetimes when unavailable started / stopped.
ā¦ the alternative is that youāve poor reception, and a lot of packets arenāt being received by ramses_rf.
Other people are welcome to chip in here, if they have a similar problem.
I understand the Amazon ā HA integration leverages ramses_rf for this data.
Hi there.
What a rich threat, thanks for all the effort here!
I would like to get started with a HA instance connecting to my Hometronic system.
My system is 433MHz only. It consists of
HCM200T Hometronic manager,
two HCE60 floor heating controller,
and several HCW22 thermostats.
Here most people seem to be working with 868MHz. Can anyone recommend a RF USB device for 433MHz to communicate with Hometronic? Some seem to be using nanoCUL. How about this one?
Would this work with evofw3 and evohome_rf?
Thank you for any helpful hints.
I use Ramses_CC to read and steer my Orcon WTW (425).
By installing Ramses_cc 30.2, several entities are not available anymore.
Hopefully you can bring these back in a updated version
Thanks for confirming config is OK. Updated and all seems well. Same issue with āUnavailableā demand is persisting intermittently.
Iāll sort out a packet log, etc. once I have suitable dataset. Weāve talked about this previously and you had the same thought about the timeout possibly being a bit tight.
Iām also now wondering if the low battery state of the HR92 that is showing āUnavailableā demand might be relevant. So, Iām going to replace those batteries now.
The Amazon ā HA integration always shows āUnavailableā demand for two specific zones. They show correct demand information in HA. Iāll raise this in the relevant forum since Iāve seen you participate there previously. The developer of that integration says that he just collects the information from HA. There must be some variation / incompatibility in play.
Thank you all very much, all is solved now. renaming the entities did the trick