Great work David (Bonnes). I’m using version 0.22.3 and it’s working better than ever with my R8810A.
I don’t have any problems, but I’m wondering about these messages in my log.
Message 1
Logger: ramses_rf.system.heat
Source: runner.py:119
First occurred: 17:00:07 (1 occurrences)
Last logged: 17:00:07
RP --- 01:127571 18:262143 --:------ 313F 009 00FC1101D11B0B07E6 < excessive datetime difference: 1:01:09.156259
Do you know what causes this error? I have this one since I started with this integration in 2021. And there are no other integrations complaining about datetime differences in HA.
Message 2
Logger: ramses_rf.entity_base
Source: runner.py:119
First occurred: 16:27:07 (9 occurrences)
Last logged: 16:59:16
RP --- 10:105590 18:262143 --:------ 3220 005 0070130000 < Polling now deprecated for code|ctx=3220|13: it appears to be unsupported
RP --- 10:105590 18:262143 --:------ 3220 005 0070310000 < Polling now deprecated for code|ctx=3220|31: it appears to be unsupported
RP --- 10:105590 18:262143 --:------ 3220 005 00700E0000 < Polling now deprecated for code|ctx=3220|0E: it appears to be unsupported
RP --- 10:105590 18:262143 --:------ 3220 005 00F00F0000 < Polling now deprecated for code|ctx=3220|0F: it appears to be unsupported
RP --- 10:105590 18:262143 --:------ 3220 005 00F0390000 < Polling now deprecated for code|ctx=3220|39: it appears to be unsupported
I’m just curious about this one. Is there an overview somewhere with all the codes? I’m wondering what codes like 3200, 3210, 3220 mean. I thought I had seen (a link to) a list with all the codes in this topic before, but I can’t find it.
The time I have to work on this project over the next few months will be limited - it would be really helpful to have the issues on github, to maximise my efficiency.
Also, some general advice: use the native (ramses_cc) service calls whenever you can, e.g.:
This looks like the timezone in your HA install is not the same as for your evohome controller? They are precisely 1 hour out (a few minutes is normal/OK (1min 9sec in your case).
You can ignore this if you like - it looks like a mere 1 min discrepancy. You wouldn’t ignore this if it was (say) 15 minutes.
Not all OTB (R8810A/R8820A) / OT slave (boiler) pairs behave the same - some support (say) data_id 13 (water flow rate in DHW circuit), some do not. The easiest way for ramses_rf to know is to try polling them all - it then deprecates (stops polling for) for those that do not respond to an RQ in a meaningful way.
Perhaps someone could add that explanation to the ramses_rf wiki/FAQ.
I’m the author of the EvoControl Smart Heat custom Alexa skill for Evohome which adds activities, groups, multiple schedules, constrained overrides, bulk switchpoint editing and more to Evohome controllability. It’s all detailed at the EvoControl website.
In addition to interfacing with the TCC REST-API using its own API-key, EvoControl already supports RF control of Evohome via a Domoticz integration I have implemented. The next integration I’d like to create is for HA. In particular, being also able to handle schedules via RF is of interest, as the Domoticz integration does not allow for that.
In browsing this topic, I have not seen a description of how I could remotely interact with the HA integration using an API. Does this integration expose API endpoints which an external AWS Lambda function could access? Sorry if it’s a dumb question but I’ve not even started installing HA yet and first want to do due diligence in the docs.
I’ve seen you around in the forums - I thinks we’ve spoken before about various things evohome, such as evohome-client? (I’m curious - I guess you use the RESTful API endpoints natively in your Amazon Skill?)
ramses_rf is intended to offer two sets of APIs:
command APIs that construct a (single) command packet that can (later) be Tx via RF
entity (i.e., TCS, zone, DHW) methods (some will produce a sequence of command packets)
There is also means to ‘subscribe’ to packet-level events - entity events are not currently so.
There are no developer docs for the above.
How the above would work with AWS is not my speciality, I’m afraid - you’d have to run ramses_rf in a Python venv in there somehow? There are plans for MQTT in evofw3, that may be useful - you could then add ramses_rf to your AWS stack.
Other than that - ramses_rf is designed for any python client - you’d just need to write such - evoGateway and ramses_cc are two examples of such.
Thanks for all the info. Everything works via TCC already (including schedule r/w) but having RF adds several possibilities to be as chirpy as we like without hitting Resideo rate limits and such. For example, Domoticz stores 5-min graphical data so my skill can draw plots without having to poll TCC every few mins because the user already has this data, not Resideo. RF also exposes stuff like Battery % and OpenWindow detection. My skill already does all that using Domoticz but I wanted HA users to be able to do it too. With the Domoticz integration, I just talk to the Domoticz JSON API which exposes the underlying EvohomeRF engine for me via http. From what you’re saying, it sounds like HA does not work that way. I don’t want to have to install or run anything of ramses_cc in the cloud because the end user already does that on his system. I just want to be able to talk to a user’s HA system via e.g. an endpoint like /api?system=evohome&zone=kitchen&setpoint=19.5&until=null (or whatever, you get the idea). When you account link my skill, you use a Resideo oauth flow to give me access to your TCC via an API. You optionally fill out your Domoticz proxy details so I can also talk to your HGI-80 (or equivalent) from the AWS cloud. The idea is to have the same for HA.
I’m trying to see when a DHW scheduled reheat starts, but I can’t seem to be able to determine this from water_heater.stored_hw (or for that case see the schedule). Am I missing something? (ramses_cc 0.22.1)
Thanks. Useful that integrations can be accessed by service. I’ll install and see how it goes. There’s a spare NanoCUL lying in my drawer because I use the genuine HGI for Domoticz.
I’m running ramses parallel to the traditional Evohome integration (which works great but has it’s limitations) for now. I have 10 zones. Most of them are single HR92. One zone with 2 HR92 (and which has the controller as it’s sensor) and one zone with 3 HR92 and a honeywell Round. I found all 10x climate entities.
But now I have issues linking the heat demand sensors correctly to all the zones and I find a lot of other stuff. Within the climate entity I some multiple actuators in some cases however these are not the zones that should have multiple actuators. And also the other way around; climate entities that only show 1 actuator while they should have several.
Few questions (I have read over 1000 posts + the wiki but still not sure how to approach):
What is the recommended order / approach of things to get this in order?
What are the “codes” for the different devices?
For instance I have 10x sensor.01_202227_XX_heat_demand (XX being 0 to 9) are these the zones and their demand (as a zone)?
Then I have many that start with 04_xxx but Not sure how to find out what zone they belong to.
I guess the ones starting with 10_xx are the boiler and 34_xx the honeywell round?
I also see a few with 20_x, 5_x, 18_x (evohome controller?), 37_ I have no idea what they are
I guess only after I have gone through above step I can create a good “known_list” and should I add anything at the top to declare it’s an EVOhome?
You haven’t provided a lot of detail - doing so always makes it easy to answer questions like this…
However, I can say something potentially useful: schedules are not obtained by ramses_rf by default - you have to use the service call - then they’re part of the entity state attributes.