Here you see the automatic bypass of an Orcon HRU in action, first image is the measured air flow, second one some temperatures (all taken from the HRU):
To add to the nice graphs:
A graph showing supply flow (in wrong units, fixed in the latest release) and CO2 level of the CO2 remote driving the fan. Note the heavy oscillations. I’m working on fixing this, but these graphs help a lot!
I am thinking of adding probing - the system eavesdrops, and picks up fans/remotes/sensors (you can facilitate this by pushing buttons on your remote) - then probing the fan to:
determine if Orcon, Itho or Nuaire scheme
determine modes supported by the ventilation unit
automatically adding those modes to either a Remote / Fan or HVAC entity (I haven’t decided yet, which)
The issue here is that the probing will make the ventilation (e.g.) change fan speed, etc. - so would best be a service call?
If I understand you correctly, you want to ask the user to do a single button press, and then probe the addressed fan with all known commands for the detected fan scheme by impersonating the remote?
Can’t you determine the model of the remote, sensor or fan based on their ID packets, and derive the supported commands from them? That feels safer… but it does add the burden of managing some sort of capabilities database to the software.
So I have a Nuaire PIV Eco-Dri system. if I was to set this up how do I get it to start listening in on the RF signals. do I set it to a pairing mode for the button units? I have wanted to be able to control this unit remotely for ages.
I have a Nuaire 4-way connected to my PIV that I bound years ago. Relatively recently, I have been simply impersonating that 4-way with a faked remote.
The RF dongle you require will be a lot cheaper that the 4-way switch, and you have the added advantage of HA sensors, etc.
You will have to do the binding with the faked remote - you put the PIV in binding mode and press/hold boost on the 4-way - you do that via HA service call.
You’ll need to edit the configuration.yaml file too.
All the code for the above is in place, although if there is a problem, I can look at it for you.
There is no reason why ramses_cc can’t be used to impersonate a humidity sensor too - although this is a WIP - it would be eaiser to use an automation to trigger a boost when a humidity sensor rises above a set level.
Hi, I’m new to this CH/DHW/HVAC scene and installed a ORCON HRC 400 myself. I own a simple 6 button Orcon remote, but like to bind it to HA and control things like the bypass and fan level with automations.
Great work on ramses. There is a lot of documentation. However, after reading nearly all of it, and understanding half of it, I still struggle to bind faked sensors, and to control my setup. The Config Flow change hasn’t helped: most documentation refers to the old YAML approach and the mapping isn’t 100% clear nor validated. However, my real issues are with ‘magic’ parameters like device_info. The docs (5.2 Faking Remotes (switches) · zxdavb/ramses_cc Wiki · GitHub) contain a table with device_info payload, but the actual actions use a longer I/W sequence that somehow seems to adds some fields. Can someone point me at how to understand & formulate those payloads?
It would be great if there was some registry/wizard combination that contains dummy-proof controls that help with what is always the same, what was reversed engineered already, and what must be learned or gathered by the user themselves.
My Config Flow configuration is now the equivalent of the following.
ramses_cc:
orphans_hvac:
- "32:133288"
- "29:168696"
- "32:114444"
- "32:116666"
- "29:123456"
known_list:
"32:133288":
class: FAN
_note: Orcon HRC 400
"29:168696":
class: REM
_note: Orcon remote
"32:114444":
class: CO2
faked: true
_note: CO2 sensor
"32:116666":
class: HUM
faked: true
_note: humidity sensor
"29:123456":
class: REM
faked: true
_note: based upon an Orcon 15RF 6-button remote (VMN-15LF01)
commands:
away: " I --- 29:123456 32:133288 --:------ 22F1 003 000007"
low: " I --- 29:123456 32:133288 --:------ 22F1 003 000107"
medium: " I --- 29:123456 32:133288 --:------ 22F1 003 000207"
high: " I --- 29:123456 32:133288 --:------ 22F1 003 000307"
auto: " I --- 29:123456 32:133288 --:------ 22F1 003 000407"
auto2: " I --- 29:123456 32:133288 --:------ 22F1 003 000507"
boost: " I --- 29:123456 32:133288 --:------ 22F1 003 000607"
disable: " I --- 29:123456 32:133288 --:------ 22F1 003 000707"
bypass_open: " W --- 29:123456 32:133288 --:------ 22F7 003 00C8EF"
bypass_close: " W --- 29:123456 32:133288 --:------ 22F7 003 0000EF"
bypass_auto: " W --- 29:123456 32:133288 --:------ 22F7 003 00FFEF"
reset_filter: " W --- 29:123456 32:133288 --:------ 10D0 002 00FF"
I’m yet trying to figure our how to bind those 3 fakes. I know that the following is incomplete, because offer isn’t set (and I don’t know how to create an offer):
