I never considered that anyone would do this (service call on multiple zones at once).
Thus, I never tested this scenario.
For now, try:
ramses_cc:
ramses:rf:
disable_qos: false
… and let me know how that goes.
With disable_qos to false and between each call 5 seconds it seems to work in my initial test.
Sorry I wasn’t clear - I mean for you to try disable_qos: false without the 5s gaps: that is, a single service call, but with an array of zones.
Only the first one of the array is set to temperature. All the others aren’t changed
I regularly set all my zones ‘at once’ when I trigger an Activity via EvoControl. When using TCC as skill-connector, I have a 200ms delay between the individual TCC API calls and it always works fine. When using Domoticz and a HGI-80 as the skill-connector, 200ms also works just fine for a burst of setpoint-changes. So I’m guessing there’s no fundamental reason for it not to work with HA/ramses_cc too.
I would expect that if you fired off a set_zone packet for all 12 zones, and ramses_rf should be able to make that happen via its internal QoS mechanism.
This is particularly important when the underlying transport can vary to much:
- serial port (evofw3 vs HGI80)
- ser2net (currently broken, will return)
- MQTT
- packet log (doesn’t apply to EvoControl)
I will have a look at this…
Hi all,
First post here.
I want to re-investigate an issue I have with my ‘ramses_cc’ environment which might be a little different than others (with search nothing similar came up). Not sure if ramses_cc/NanoCul is the issue!
Environment:
- Evohome with HGI80 connected to Domoticz (I know, this is a HA topic
) - I am slowly migrating to HA and on my test HA I connected a SchlauHaus NanoCUL with evofw3
- I have been able to identify my Evohome from my neighbors Evohome and get a lot of info from Evohome (more than I see in Domoticz). All good.
- I did not yet enforce the known_list yet, as I am trying to identify my ITHO HRU300 and humidity sensor. Of course I now get loads of (ghost) devices in the list (no real issue, once know_list is complete I want to copy the config to Prod HA and move the NanoCUL).
- I left this running for for a few days and suddenly I get a ‘COMMS FAULT, BLOILER RELAY’ error on my Evohome screen (never happend before, using Evohome for years). Pulled the NanoCUL from USB, restarted the heater, communication restored.
- Left if for a week without NanoCUL connected, no issues.
- Connected the NanoCUL again and after 3 or 4 days the same error message.
- Pulled the NanoCUL again, restart heater. Issue gone. This was 3 weeks ago. No issues since then.
- I now want to investigate this again (less dependency on heater now )
My plan:
- Log everything I can think off (packet.log, logging at lower layers of the stack) and in Domoticz also error log on.
Any advice in logging area? - Questions:
Anyone seen this before that an HGI80 is somehow interfering with NanoCUL or the other way around?
Does ramses_cc is purely listening with my confuration?
ramses_cc:
serial_port: /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
restore_cache:
restore_state: true
restore_schema: true
packet_log:
file_name: packet.log
rotate_backups: 100 # set to less once troubleshooting is ready
ramses_rf:
enforce_known_list: false # if not true, still enforces the block_list
disable_discovery: false
disable_sending: false # do not transmit any packets, ever
enable_eavesdrop: false # can be used to create an initial system schema, set to false asap!
known_list:
block_list:
00:000000:
logger:
logs:
custom_components.ramses_cc: info # show ramses_cc/ramses_rf state
ramses_rf.dispatcher: info # show packet payload
Thanks!
Hi,
I am a new user of Ramses_cc and seeing the same kind of weird issues with an otherwise typical UK CH/DHW system using an ATAG boiler as in this issue:https://github.com/zxdavb/ramses_cc/issues/53
I have been trying to narrow down the command causing issues, but I can’t get a config flow configuration of a ramses_rf outbound filter to “stick”. I’ve tried the following in a YAML checker and this checks out ok, but if I put it in the config flow dialogue, I get: Invalid ramses_rf config: extra keys not allowed.
disable_discovery: false
disable_sending: false
enable_eavesdrop: false
use_native_ot: never
outbound:
" 18:.* 10:.* ": " 18:000730 10:000000 "
If I put the filter in like this, it accepts it but then disappears:
outbound: " 18:.* 10:.* ": " 18:000730 10:000000 "
So any ideas on how I get it into the config flow box and to persist, please?
(I know the use_native_ot setting kind of conflicts with the filter, it’s just about getting it to stick in the config flow for starters…)
Thanks,
Jon.
@oeps you must be hitting an RF clash that is causing the Comms failure. Pure coincidence or your radio waves are quite chatty.
I can’t comment on it’s usage, but I believe it lives under use_regex. So:
use_regex:
outbound:
" 18:.* 10:.* ": " 18:000730 10:000000 "
This feature is not for general use by people - unless I have specifically advised a person to use it for a specific use-case.
Hi just upgraded my Home Assistant Rasp PI from a PI3 to a PI4.
I get this error on the startup of home assistant which I didn’t see on the PI3.
I’m running the latest version of Home Assistant
* Core2024.3.1
* Supervisor2024.03.0
* Operating System12.1
* Frontend20240307.0
ramses_cc 0.31.11
Logger: ramses_tx.transport
Source: runner.py:188
First occurred: 08:41:40 (1 occurrences)
Last logged: 08:41:40
# evofw3 0.7.1 < PacketInvalid(null frame: >>><<<)
And, I just noticed that it only shows on a reboot of the PI, not on a quick HA restart.
Ignore it - it’s logspam.
Cheers for that.
I wasn’t too concerned as everything seemed to be working fine, just thought I would report the error.
It’s getting to that time of year, where I begin to scale back some of the heating/temperatures/on-off times per zone - as we approach warmer weather.
Has anyone put together ‘something’ so that you can ‘back-up’ the current zone schedules, before making changes? So that the previous could be applied again, next year?
The thought being, I’d like to preserve the ‘Winter’ scheduling, so that I could apply it again - without needing to modify the schedule/zones manually.
… then continuing so I could have a Winter, Spring, Summer & Autumn schedule, that I could easily apply.
… I know I can retrieve and push schedules, for example:
service: ramses_cc.get_zone_schedule
data:
entity_id: climate.hallway
… but I’d like to be able to save the current schedule (presumably json format, as that is what ramses_cc.set_zone_schedule wants) somewhere, for easy recall… before I look into this myself and end up re-inventing the wheel.
EDIT: Just found the below in the wiki, gives a good starting point. Although ideally I’d like the schedules stored in HA, but I could certainly put a script together.
EDIT 2: I can get the YAML from the climate entity attributes then run it through a YAML → JSON converter, or:
{{ state_attr("climate.bathroom", "schedule") }}
… will return JSON format, tested in Developer tools → Template
EDIT 3: The below passes validation in Developer Tools:
service: ramses_cc.set_zone_schedule
data:
entity_id: climate.bathroom
schedule: '[{"day_of_week":0,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":1,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":2,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":3,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":4,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":5,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]},{"day_of_week":6,"switchpoints":[{"time_of_day":"07:30","heat_setpoint":20},{"time_of_day":"09:30","heat_setpoint":15},{"time_of_day":"16:00","heat_setpoint":19},{"time_of_day":"20:00","heat_setpoint":20},{"time_of_day":"22:00","heat_setpoint":15}]}]'
But then throws an error in the HA logs:
Logger: ramses_rf.protocol.message
Source: runner.py:188
First occurred: 09:06:11 (4 occurrences)
Last logged: 09:10:03
I --- 01:050858 18:068121 --:------ 0404 007 09200008290103 < Corrupt payload: Incorrect fragment length: 0x29
I --- 01:050858 18:068121 --:------ 0404 007 09200008290104 < Corrupt payload: Incorrect fragment length: 0x29
Still running 0.21.4 can’t currently upgrade.
EDIT 4: Found the below in this monsterous thread, seems to be a known issue … or was.
I use the evohome-async client library:
> pip install evohome-async
> python client.py -u [email protected] -p password -c get-schedules -f schedules.json
I will push a new version (that should have a fix, #163) by the end of this weekend.
1 Like
I did stumble on that as well - but perhaps testament to your work, I haven’t had the internet gateway (my controller is non-wifi, with a separate gateway) connected for a few years, at least 
… for a hoot, just checked out @honeywell_home on Twitter, doesn’t look like their infrastructure has improved in stability, still repeated outages!
@iMiMx and others…
Versions 0.31.16 and 0.41.16 (has config flow) and been released today.
Feedback welcome - if you have opened an issue in
… and it is now resolved - I’d be grateful if you close it.
Upgraded to 0.41.16, looks good to me - many thanks.
- #163 fixed
- set_zone_schedule no longer has the fragment error, the below now works
service: ramses_cc.set_zone_schedule
data:
entity_id: climate.bathroom
schedule: >-
[ { "day_of_week": 0, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 1, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 2, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 3, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 4, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 5, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] },
{ "day_of_week": 6, "switchpoints": [ { "time_of_day": "07:30",
"heat_setpoint": 20 }, { "time_of_day": "09:30", "heat_setpoint": 15 }, {
"time_of_day": "16:00", "heat_setpoint": 19 }, { "time_of_day": "20:00",
"heat_setpoint": 20 }, { "time_of_day": "22:00", "heat_setpoint": 15 } ] } ]