I would like to see people’s evohome_cc files.
What do you need?
If you’re using release 0.11.0 of evohome_cc, and if you have an OpenTherm bridge, PM me a copy of your .storage/evohome_cc file.
I have also more sensors, the most are still unavailable.
I cannot help you without a log file.
First of all, thank you @zxdavb for your work. I am new to all of this but attempting to get a rPi set up to communicate with an orphaned Honeywell CS92A DHW sensor in my new house.
I’ve got evoGateway set up and the devices are detected - it picks up the DHW temperature transmission once per hour. I wanted to see whether I could request the current temp by sending a 1260 message to the sensor (I wasn’t clear whether the wiki meant the CS92 will not respond to requests). However I didn’t get that far. When I try to send, I get the following:
2021-07-13 22:38:38 | | MQTT -> | | | Received MQTT message: {"code" : "1260", "verb" : "RQ", "dest_id" : "07:008654", "payload" : "00"}
2021-07-13 22:38:38 |000| HGI evoGateway -> DHW DHW:008654 |RQ| dhw_temp | REQUEST: dhw_temp
PktProtocolQos.send_data(RQ|07:008654|1260): boff=1, want=RQ|07:008654|1260, tout=2021-07-13 22:38:38.535905: RE-SENT (1/2)
2021-07-13 22:38:38 |000| HGI evoGateway -> DHW DHW:008654 |RQ| dhw_temp | REQUEST: dhw_temp
PktProtocolQos.send_data(RQ|07:008654|1260): boff=2, want=RQ|07:008654|1260, tout=2021-07-13 22:38:38.773601: RE-SENT (2/2)
2021-07-13 22:38:38 |000| HGI evoGateway -> DHW DHW:008654 |RQ| dhw_temp | REQUEST: dhw_temp
PktProtocolQos.send_data(RQ|07:008654|1260): boff=2, want=RP|07:008654|1260, tout=2021-07-13 22:38:38.795694: EXPIRED (2/2)
PktProtocolQos.send_data(RQ|07:008654|1260): Expired callback
2021-07-13 22:38:38 | | evoGateway -> | | | COMMAND SEND FAILED for '{'code': '1260', 'verb': 'RQ', 'dest_id': '07:008654', 'payload': '00'}'
It looks like the error is arising at the ramses_rf level and not evoGateway, hence my question here. Is this pattern indicative of the TX error that other people were having above? My device is a cc1101 stick preloaded with evofw3 from the seller linked on the ramses_rf GitHub page. Any pointers would be much appreciated!
The CS92A is battery-powered… Almost invariably (i.e. with non-useful exceptions), all such devices will not respond to an RQ nor a W.
The CSA92A will send packets to its bound controller and listen for a response (e.g. 10A0, see next paragraph).
It will also send temperature packets (1260), at least every unit time (hour), and more (potentially much more) often than that as its measured temperature nears what it understands the DHW setpoint to be (its controller will have provided this information, see above).
In short, you cannot do this, you can only eavesdrop this data.
If there is a bound controller (you imply there isn’t), which is not battery powered, then it can be sent an RQ/1260.
Understood, thank you. I thought that behaviour might be implied from the wiki but hoped anyway that I might be able to query it live.
The separate issue I’m having is that it is stuck on the 1 hour frequency because the temperature it’s reading is about 20 degrees lower than the actual water temperature (as measured out of the tap) - I think I just need to re-seat the sensor against the tank, probably some leftover insulation impeding the measurement.
I guess I could also use a 10AO ’ W’ packet sent by a dummy controller to adjust the set point and thus prompt more frequent broadcasts? In which case the TX problem is relevant again. I note that when I start up evoGateway, it reports a long series of system_sync, device_info and other RQs that follow the same pattern above of a number of re-tries and then expiry so I am suspicious that nothing is actually transmitting.
Ultimately 1 hr frequency of temperature readings is probably fine for me so it’s not critical, I’d just like to understand if there is some deeper issue happening.
Not exactly - the DHW sensor will RQ a 10A0 and listen (only a short while) for an RP.
18:41:40.394426 062 RQ --- 07:014869 01:050858 --:------ 10A0 006 001B3C0001F2
18:41:40.410471 048 RP --- 01:050858 07:014869 --:------ 10A0 006 001B580001F4
So you want to send the RP after receiving the RQ.
I see, thank you. OK then, I think I’ll be set in any event with only listening for 1260’s from the sensor whenever they come. I’m still not sure if the TX bug is affecting my cc1101 device but I have no need to transmit at the moment anyway. Your guidance was much appreciated!
For those who don’t know: you can not run two instances of evohome_cc at the same time - they will drown each other out!
… 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.