but system works ok otherwise? if not, i’ll push a hotfix
Yeah, everything seems to be working as it should.
all - I have settled upon a final configuration schema, as documented: the Wiki
It will necessitate further breaking changes:
- I am hoping that no further changes will be needed
- it offers all the features needed, going forward, especially for HVAC
Perhaps people could look at it and make comment?
Hello,
I had a look at the schema in the wiki. It looks good to me. I am just unsure about one point. How would you indicate the buttons of a remote for HVAC in this schema ? I guess every brand has different buttons (e.g. speeds, booster, away, …). With other faked sensors (temperature, humidity, …) a mapping between a real sensor measuring this value and the fake sensor is enough, but in the case of remote control should the schema offer the possibility to declare how many buttons are needed for instance? I understand the schema must remain generic to work with as many brands and cases as possible, but i am struggling to see how the mapping will work for remote controls. Feel free to disregard this comment if I am missing something obvious 
Thanks. The RF remote things is a WIP, and not fully resolved.
In short, there are bits of the schema that are not yet fully documented, but it would be a device trait, like:
ramses_cc:
known_devices:
29:123456: {class: REM, scheme: orcon}
29:222222: {class: REM, scheme: itho, faked: true}
There are many common remote layouts, e.g.: Away, 1, 2, 3, Boost (10, 20, 30 mins) & Auto.
I should add that the remote is not the limit - many ventilation units will likely take instructions that your remote doesn’t have a button for. This uncertainty is a common problem for any 3rd-party remote.
Anyway, the way the new schema is designed is that the above would be an extension to the schema, and not a breaking change.
Running 0.20.15 and yesterday and today some or most sensors/climate entities goes in a state of unknown.
Config isn’t changed.
Logs: Nextcloud
Restart of HA resolves it
I think I have most of the remote commands that itho remotes can send. If it helps, they can be found here:
Thanks.
Are you familiar with 31DA[36:38] (the 37th, 38th bytes of the payload of): ramses_rf/ramses.py#L1250
- do you know what the codes from 0x1A to 0x1F mean?
Here is an example of how we can provide more functionality that the existing remotes. For example, with 22F1 (0x0A = 10 minutes):
const uint8_t ithoMessageTimer1CommandBytes[] = {0x22, 0xF3, 0x03, 0x00, 0x00, 0x0A}; // 10 minutes full speed
- the obvious thing to do is set it to (say) 15 minutes instead of 10/20/30 minutes - actually, the protocol allows for hours, days too! I think this is how DF does 30, 60 minutes?
22F3 is not fully understood, esp. the fallback speed feature.
I’ve never seen 22F8 before - I would love to receive some packet logs of those.
const uint8_t ithoMessageAUTORFTAutoNightCommandBytes[] = {0x22, 0xF8, 0x03, 0x63, 0x02, 0x03};
const uint8_t ithoMessageDFLowCommandBytes[] = {0x22, 0xF8, 0x03, 0x00, 0x01, 0x02};
const uint8_t ithoMessageDFHighCommandBytes[] = {0x22, 0xF8, 0x03, 0x00, 0x02, 0x02};
Note the RFT has 0x03 at the end, whilst the DF has only 0x02. That tells me: that command class (code) supports up to 0x03 - so ventilation units may respond to packets with the send-last byte set to 0x00, 0x01, 0x02, and 0x03 - and maybe even 0x04, etc. Have you tested that? I have, on Orcon units… nothing happended.
Your code says setpoint for 22F8, but obviously there’s no setpoint in the payload - what can you tell me about it?
Does Itho have the equivalent of the 2411 command class? ramses_rf/ramses.py#1149
Finally, 31E0 is not fully understood - I am waiting for faking of RF remotes before exploring that further.
Are you familiar with 31DA[36:38] (the 37th, 38th bytes of the payload of): ramses_rf/ramses.py#L1250
do you know what the codes from 0x1A to 0x1F mean?
edit: looking at your code, no unfortunately I don't know the meaning of those codes. When do you see them?
Here are the error and info labels used by itho (31DA, 31D9 and general error codes):
Decoding of these messages is done here:
(this is not RF but I2C but in essence the message structure is largely the same. Itho uses the RAMSES-II protocol also internal, encapsulated in an I2C frame)
I think this is how DF does 30, 60 minutes?
Yes it does exactly that.
I’ve never seen 22F8 before - I would love to receive some packet logs of those.
edit:
These are of the DemandFlow remote:
26-7-2022 13:09:37: _W 157 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,02,02 (cmd:high)
26-7-2022 13:09:37: _W 157 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,02,02 (cmd:high)
26-7-2022 13:09:37: _W 157 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,02,02 (cmd:high)
26-7-2022 13:09:34: _W 156 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,01,02 (cmd:low)
26-7-2022 13:09:34: _W 156 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,01,02 (cmd:low)
26-7-2022 13:09:33: _W 156 --,–,-- --,–,-- 52,4E,AF 22F8 3:00,01,02 (cmd:low)
And the auto night command of the RFT Auto remote:
26-7-2022 13:13:01: _W 103 --,–,-- --,–,-- 74,F8,14 22F8 3:63,02,03 (cmd:autonight)
26-7-2022 13:13:01: _W 103 --,–,-- --,–,-- 74,F8,14 22F8 3:63,02,03 (cmd:autonight)
26-7-2022 13:13:01: _W 103 --,–,-- --,–,-- 74,F8,14 22F8 3:63,02,03 (cmd:autonight)
I’ll make some captures and send them.
Have you tested that?
No not yet but I sure can give it a try (somewhere next month I’m afraid because I’m leaving for holiday)
Your code says setpoint for 22F8, but obviously there’s no setpoint in the payload - what can you tell me about it?
Yeah that’s a remnant of my investigation. Not fully understood yet. What I remember is that the command is used by the CO2 sensor to regulate the speed of the itho. It seems to be able to regulate the speed on a continuous scale.
Does Itho have the equivalent of the 2411 command class? ramses_rf/ramses.py#1149
Not that I know of, there is a 2410 command class which is uses to change settings. As far as I know this is only possible on the I2C bus.
IIRC, what I see is a 31E0 sent after the sensor packet: e.g. 1298 (CO2) followed by a 31E0 - the 31E0 is the demand, from 0-100% (in steps of 0.5%).
So, if I code up sensor faking, my idea is that 1298 won’t be enough, you’ll have to send a 31E0 too (then the issue is at what % demand).
I have seen Orcon fans send 2410 via RF, and OpenTherm Bridges (from the Heat domain) too!
RP --- 10:048122 18:006402 --:------ 2410 020 000000-0000-00000000-00000001-00000001-00-000C # OTB
RP --- 32:155617 18:005904 --:------ 2410 020 000000-3EE8-00000000-FFFFFFFF-00000000-10-02A6 # Orcon Fan
(the dashes in the payload have been added for readability)
Ping me when you get back - I’m sure we can collaborate on some stuff if you’d like.
If you’re bored, all my parser info is in: ramses_rf/parsers.py
1 Like
This is what the Itho DF manual says about the RFT remote:
Laagstand: gedurende 24 uur ‘laag’ ventileren
ongeacht het CO2-niveau in de betreffende
ruimte.
Hoogstand: gedurende 24 uur ‘hoog’ ventileren
ongeacht het CO2-niveau in de betreffende
ruimte.
Auto: automatisch regelen op basis van het
CO2-niveau of luchtvochtigheid in de
betreffende ruimte.
Timer. Voor het inschakelen van de unit in
hoogstand voor een instelbare periode
I would guess the 22F8 controls the low/high mode and perhaps also the auto mode
CO2 faking might indeed not work for Orcon if you only send the 1298. That is what I meant when I said on gitter that the remote defines what happens with the fan. The logic is in the remote, not the HRU. It would be possible though to use the 31E0 command. The CO2 logic can than be made inside HA.
Upgraded to 20.15 yesterday, and it looks like my two zones that have more than one actuator, and where one of the actuators acts as the sensor (multiroom_mode = true), is not being handled correctly. It seems that the current temperature is missing:
hvac_modes:
- auto
- heat
min_temp: 5
max_temp: 21
preset_modes:
- none
- temporary
- permanent
friendly_name: Bedroom
supported_features: 17
temperature: 5
hvac_action: 'off'
preset_mode: none
zone_idx: '04'
heating_type: radiator_valve
mode:
mode: follow_schedule
setpoint: 5
config:
min_temp: 5
max_temp: 21
local_override: true
openwindow_function: true
multiroom_mode: true
schema:
_name: Bedroom
class: radiator_valve
sensor: '04:003434'
actuators:
- '04:003202'
- '04:003434'
params:
config:
min_temp: 5
max_temp: 21
local_override: true
openwindow_function: true
multiroom_mode: true
mode:
mode: follow_schedule
setpoint: 5
name: Bedroom
I have checked sensor.04_003434_temperature and that data is being updated.
This is my config:
ramses_cc:
serial_port:
port_name: /dev/serial/by-id/usb-SparkFun_evofw3_atmega32u4-if00
baudrate: 115200
packet_log:
file_name: packet.log
rotate_bytes: null
rotate_backups: 7
restore_cache: true
scan_interval: 10
schema:
controller: 01:185426
ramses_rf:
enable_eavesdrop: false
enforce_known_list: true
known_list:
- '01:185426'
- '04:003278'
- '04:003222'
- '04:003192'
- '04:003224'
- '04:003154'
- '04:003434'
- '04:003286'
- '04:003202'
- '04:003276'
- '04:003288'
- '04:026298'
- '04:026296'
- '07:046786'
- '13:164839'
- '13:197705'
- '18:136212'
- '22:220612'
Please PM me a copy of your ramses_cc file, or a copy of the packet log that includes all the 0005 packets.
ramses_cc sent to you via email
i noticed there are 2 different listings of the known list in the wiki:
known_list:
30:111111: {class: FAN}
known_list:
- 02:145038
i believe the correct listing is the lower one. as the upper type gave me errors in my logs. i corrected the wiki
Hi all,
question for the proxmox users with a HGI80: did you do anything special to pass the USB device to HASS?
i have added the USB device to my virtual machine, but i do not see the device in HASS. i have added 3 other USB devices and these are available in HASS. so are there any special settings? (btw i am a newby in proxmox)
Hm, that is a bit of a bummer. I hoped the HRU did the “smart” stuff, and only needed the CO2 value.
This is my fault - I haven’t make it clear - the wiki entry applied to >= 0.20.17, and not 0.20.15.
Thanks fro editing the wiki, though - that sort of behaviour should be applauded.