I’m using it to force the heat demand to on in order to keep a heat pump running rather than cycling.
Is anyone here adept enough with github workflows to help me out? - I just don’t have time to make it work.
See: https://github.com/zxdavb/ramses_rf/tree/master/.github/workflows
I want a package pushed to PyPi whenever the code gets a tag
- will first need to change code so that all debug flags are false
_DEBUG_something_blah = True # should be False for end-users
- then needs ruff / mypy / pytest to pass
- the hatch to build / deploy
PRs gratefully accepted.
I’d not thought about this until now, but could it be used for weather compensation?
Does anyone have an example of the JSON format for sending a weekly schedule to a zone? I’ve been trying for a few hours now but with no success.
Only if it makes sense to the device who hears the announcement.
This would be limited to a the original (generation 1) Evohome controller, or a Hometronics system.
I’ve made some progress on this. Using this JSON:
[
{
"day_of_week": 0,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 1,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 2,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 3,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 4,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 5,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
},
{
"day_of_week": 6,
"switchpoints": [
{
"time_of_day": "07:00",
"heat_setpoint": 18.5
},
{
"time_of_day": "22:00",
"heat_setpoint": 15
}
]
}
]
I can now call the service without error. However, nothing changes and the following appears in the log:
Logger: ramses_rf.protocol.message
Source: runner.py:188
First occurred: 21:54:54 (9 occurrences)
Last logged: 21:58:00
I --- 01:065252 18:131597 --:------ 0404 007 06200008290102 < Corrupt payload: Incorrect fragment length: 0x29
This looks like a bug.
Perhaps you could use GitHub - zxdavb/evohome-async: An asyncio Python client to access the Evohome web service for now:
python client.py -u [email protected] -p pwd get-schedules > schedules.json
python client.py -u [email protected] -p pwd set-schedules -f schedules.json
I could use some help. I am trying to get the heat demand percentage from each of my radiator valves. These should be disclosed by the controller in a sensor. But they are not. Only one zone is returning a sensor value, which is the one that has a bdr91 actuator.
The others are empty. I dont have my valves in the known list, but i dont think this is necessary?
This is my config:
Blockquote
ramses_cc:
serial_port: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
restore_cache:
restore_schema: false
ramses_rf:
enable_eavesdrop: true
enforce_known_list: true # if not true, still enforces the block_list
disable_sending: false # do not transmit any packets, ever
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
01:105262: # Temperature control system (evohome)
system:
appliance_control: 13:046120
orphans_hvac: [37:154000, 37:162571, 37:256681, 37:008647, 37:033917, 37:103131, 37:103135, 37:198186]
known_list:
37:256681: {class: CO2} #maa
37:008647: {class: CO2} #flo
37:033917: {class: CO2} #woonkamer
37:103131: {class: CO2} #te
37:103135: {class: CO2} #ma
37:198186: {class: CO2} #eet
37:020555: #hru400
34:162785: #thermostat ma
34:136871: #thermostat zitkamer
13:046120: #bdr91 relay buffer
13:052098: #bdr91 relais floor heating
03:256006: {faked: true} #temperature sensor woonkamer
01:105262: # evohome controller
37:154000:
37:162571:
Anyone knows how to get these values?
Firstly, it would help if you provided a correctly formatted config.
Secondly, everything you want sight of must be in your known list if you have enforce_known_list: true. Else they will be ignored.
Your uncertainty leads me to believe that you tried both with and without the TRVs to see what would happen? At least to add one in?
To be clear:
- your devices, all your devices, and nothing but your devices must be in the known list, before your enforce that list
- the above includes your gateway
- only the controller (and only if it is a zone sensor) and the OTB (if you have one) should be in the schema - very rarely, there are exceptions to this rule
In your specific case, stop enforcing the known list, and go from there.
Also…
Remove the appliance_control section
I (finally) updated my HA to 2023.11.x and updated rames_cc tot 0.30.2
Everything seems to work for my HVAC system (Orcon WTW HRC4xx). Although I had to change the entity names in my dashboad outside_temperature → outside_temp. Nothing Major.
I did notice, however, that the ‘filter remaining time’ is not stored into an entity. It is being polled every day (I see the 10D0 requests/answers in my packet.log), but not stored.
Apperently there is an old PR to fix this: Update sensor.py by janvkem · Pull Request #62 · zxdavb/ramses_cc · GitHub
I manually updated my previous version of ramses_cc to include it. I applied this to 0.30.2 as well.
However in the latest ramses_rf the const SZ_FILTER_REMAINING in not imported from ramses_rf.tx.const. It’s a little bit more broken in this version, it seems.
Thanks for 0.30.2, it works great!
Should I submit a bugreport/issue to github for the filter time thing?
Done! Thanks
1 Like
Fixed - will be in next release.
Hmmm…
What about this:
if msg.len >= 3:
result.update({"days_lifetime": int(payload[4:6], 16)})
if msg.len >= 4:
result.update({"percent_remaining": hex_to_percent(payload[6:8])})
My Orcon HRC WTW only sends the length 3 version with days remaining.
I’ll send a packet.log when I get home
2023-11-29T11:08:48.500836 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-11-29T11:08:48.521825 081 RP --- 32:134446 18:203011 --:------ 10D0 006 006FB47B0000
I have both info in 10D0:
00-6F-B4-7B-0000
6F: days remaining (111)
B4: seems to be always B4 for my setup. I would guess “total lifetime of filter” (180 days)
7B: Filter percentage.
I have a packet.log collection where days remaining decreases 1 every day and the filter percentage seems to increase.
(I noticed ramses_rf already parses this packet.log correctly)
Will you implement an entity for “percent_remaining” or should I implement/test and send a PR?
Ping me the packet log, and I’ll just add it in.
1 Like
Only a single 10D0 per day, so I “grepped” all packets logs from this month: packet.log.2023-11-01:2023-11-01T20:25:49.215961 000 RQ --- 18:203011 32:134446 - Pastebin.com
I realise this grep output has the packet.log filename in front, so not the standard packet.log
Today’s packet.log only has:
2023-11-30T06:42:49.653463 000 RQ --- 18:203011 32:134446 --:------ 10D0 001 00
2023-11-30T06:42:49.677596 084 RP --- 32:134446 18:203011 --:------ 10D0 006 006EB47A0000
That’s perfect, thanks.
I was thinking…
I don’t know the utility of implementing percent_remaining as a separate sensor…
The better option would be to add it as an extra_stat_attr of days_remaining.
But to do that, I’d need to pull it out as a separate entity…
So, is it really needed?