… and while I’m on that, please use an allow_list (aka a white list).
@hsluis If you are here…
If you have a 2-way or a 4-way switch for your HVAC, could you please send me a packet log with you going through all its permutations. Thanks.
FWIW, the device ID is 59:160337 - it may belong to a neighbour?
@zxdavb Hi David, some time ago you have fixed this issue for Hometronic with with setpoint not being set because standard code uses W:2349 but Hometronic needs W:2309.
I have updated to the version 0.11.0 to do some testing and it looks like it’s broken. Everything else seems to be working fine (within Hometronic capabilities) except for this. Schema looks fine and all the devices are there.
Seems like a simple change in climate.py from
def svc_set_zone_mode(
self, mode=None, setpoint=None, duration=None, until=None
) -> None:
"""Set the (native) operating mode of the Zone."""
if until is None and duration is not None:
until = dt.now() + duration
self._device.set_mode(mode=mode, setpoint=setpoint, until=until)
self._req_ha_state_update()
to
def svc_set_zone_mode(
self, mode=None, setpoint=None, duration=None, until=None
) -> None:
"""Set the (native) operating mode of the Zone."""
if until is None and duration is not None:
until = dt.now() + duration
self._device.setpoint=setpoint
self._req_ha_state_update()
does the job but obviously this would only work Hometronic. I seem to remember you had/planned some config setting to allow specifying the controller type. Perhaps this would be a good way to use it and fix it for Hometronic.
Any chance you can have a look at this? I’m happy to write it up in an issue if that makes it easier for you to manage.
The issue with using
self._device.setpoint=setpoint
instead of
self._device.set_mode(mode=mode, setpoint=setpoint, until=until)
if obvious (no explicitly specified mode / until - they have inferred values). This will bother others greatly.
I have a solution in mind, but it will require testing. In the meantime, please:
- add this as an issue to the ramses_rf repo
- provide me with a packet log of the expected behaviour - I have very few Hometronics log files as they are relatively rare
Running 0.11.0 with hgi80 and when setting away, the state of the controller and anything else becomes unknown.
Logs are underway
@phdelodder I am sorry - as I said before - posts like this are not useful to either of us.
If you want help, I need your problem written in a way that is reproducible for me. For a start, I need log files.
@phdelodder You have sent me 7 days of logs, along with a vague description of your problem & left me up to it.
I am sorry - I did have a quick look, but I cannot find any information on your issue - at the very least, please tell me a date/time, or give me another hint?
To provide a more clear log I restarted HA, resulting in enabling the restore_state: false. After testing a few times now when setting the Controller preset to away, the state is set correctly and not to an unknow state. So I guess it’s solved.
@zxdavb , I submitted Hometronic setpoint adjustment broken in 0.11.0 · Issue #36 · zxdavb/ramses_rf · GitHub for you.
It’s a very nicely-written issue. Thanks.
I have a solution in mind - I’ll be implementing ‘profiles’ that will know the difference between evohome (the default) and other systems (e.g. Hometronics, RoundThermostat).
@zxdavb thanks for the great integration, I have everything up and running and I’m able to read the temperature from my Honeywell HCW80.
One thing is eluding me though: My receiver is a R6660D … Is it possible to send commands to this using evohome_cc (or ramses_rf) or do I need to upgrade to evohome for this?
Great - I would love to see some packet logs.
Yes, you can send commands to the relay (R6660D, aka HC60NG). No, you do not need to upgrade, you have all the hardware you need.
The specific mechanics how to do this are TBD, as the HC60NG will be listening only to the HCW80, but (some hints):
- you many have to ‘replace’ the HCW80 with evohome_cc pretending to be a HCW80
- you may be able to bind evohome_cc to the HC60NG ins addition to the HCW80 (BDR91s can do this)
OK, I think I have enough knowhow to do this given that I can see the messages coming in from my HCW80 - I also have evogateway set up which gives me some additional debug info for various messages - however, the bit I’m missing is the literal “how to send the commands”… Is there an existing API for broadcasting a given blob of data in evohome_cc, or do I need to use barebone ramses_rf and then integrate it with the former?
I’d imagine most of the logging is from ramses_rf ? - it has very extensive logging, but I’m happy to be wrong, and I’d be curious to see what he’s pulling out:
logger:
default: warn # prefer warn over info, avoid debug
logs:
homeassistant.core: debug # to see: Event state_changed, or not
# homeassistant.loader: info # You are using a custom integration for evohome_cc...
# homeassistant.setup: info # Setting up evohome_cc
custom_components.evohome_cc: warn # use info for Schema =
# ramses_rf: debug # for engine state
ramses_rf.message: info # for MSGs received (incl. sent & echo'd)
# ramses_rf.protocol: info # for PKTs sent (not retries) & received
# ramses_rf.transport: info # for RF Tx & Rx
ramses_rf.systems: debug
ramses_rf.zones: debug
ramses_rf.devices: debug
There is an (?) undocumented parameter for configuration.yaml:
evohome_cc:
send_packet: true
… and a magic service called evohome_cc.send_packet will appear:
service: evohome_cc.send_packet
data:
device_id: '01:123456'
verb: RQ
code: 1F09
payload: FF
I am sorry, impersonation is not yet implemented with this service call (i.e. you can set the destination device ID, but not the source ID).
Ah!!! I should have dug further into the source! This is plenty for me to go on … I’m not sure exactly when I’ll get around to trying it all but I’ll post back with progress (or lack thereof) soon!
Any chance I can see some log files from your system - not a configuration I see often, and it may offer some insights into the protocol.
If anyone has a HB05, HB15, HB85, HB95 (external weather sensor) attached to a Hometronics system, or an older evohome system, can they PM me? I am very keen to get a packet log of re-binding the sensor.
For those with an OTB (OpenTherm Bridge, R8810, R8820), what precision are you getting expecting for the following:
- temperature (I expect to 0.01 C)
- percentage (I expect to 0.5% - 0.005)
- pressure (bar)
- relative humidity (percentage, so 0.5% ?)
- flow (rate, L/min)
- burner current (µA)
@zxdavb Not sure if it’s possible but is there anyway to speed up the refresh interval for the Opentherm sensors? I have currently got the scan_interval in the HA config set to 60 seconds but this doesn’t appear to be having much effect?
When I had an Opentherm Gateway connected between the Opentherm Bridge and the boiler I was getting near real-time updates.
@DanRP The SCAN_INTERVAL is how often HA polls ramses_rf. (there is a long-term plan to use callbacks instead of polling)
However, ramses_rf polls the OTB every unit time according to this code:
if msg.code == _1FD4: # every 30s
if msg.payload["ticker"] % 60 in (1, 3): # effectively once every 30 mins
self._discover(discover_flag=DISCOVER_PARAMS)
elif msg.payload["ticker"] % 6 in (0, 2): # twice every 3 mins
self._discover(discover_flag=DISCOVER_STATUS)
In short, it asks for these variables every 90 seconds:
STATUS_MSG_IDS = (
0x00, # ..0: "Master/Slave status flags", # not native
0x11, # .17: "Relative Modulation Level (%)",
0x12, # .18: "Water pressure in CH circuit (bar)",
0x13, # .19: "Water flow rate in DHW circuit. (L/min)",
0x19, # .25: "Boiler flow water temperature (°C)",
0x1A, # .26: "DHW temperature (°C)",
0x1B, # .27: "Outside temperature (°C)", # TODO: any value here?
0x1C, # .28: "Return water temperature (°C)",
)
Asking for this data more often that seems a bit egregious to me, and may exceed the RF duty cycle in any case.
If the OTB ever broadcasts this data, then ramses_rf will have the latest value at that point, rather than having to wait for the next poll.