Add support for Virtual remotes

[dirixmjm]

As far as I understand the current remote implementation is for retrieving parameters of the non-CVE-based CO2 physical remotes.
However, the non-CVE module also allows creating virtual remotes which control the Demandflow / HRU unit.

in the following writeup there is a template for sending remote control commands, not sure if this is already enough or not:
https://www.vanwerkhoven.org/blog/2024/optimizing-itho-hru-350-control-via-mqtt-and-home-assistant/
YAML code

fan:
    - name: "itho_hru_fan"
      device:
        identifiers: ["mqtt", "nrg-itho-28ac"]
        model: ITHO Wifi Add-on
        name: itho_hru_fan_device
      #availability_topic: itho/state
      unique_id: itho_hru_fan
      state_topic: itho/lwt
      payload_on: "online"
      payload_off: "offline"
      #state_value_template: '{% if value == "online" %}ON{% else %}OFF{% endif %}'
      #      json_attributes_topic: itho/ithostatus
      command_topic: "itho/cmd"
      preset_mode_command_template: "{ vremote: '{{ value }}'}"
      preset_mode_command_topic: "itho/cmd"
      preset_mode_state_topic: "itho/ithostatus"
      preset_mode_value_template: >
       {% set am = value_json['actual-mode'] | int %}
         {% if am == 1 %}
           low
         {% elif am == 2 %}
           medium 
         {% elif am == 3 %}
           high
         {% elif am == 13 %}
           timer
         {% elif am == 24 %}
           auto
         {% elif am == 25 %}
           autonight
         {% else %}
           {{ am }}
         {% endif %}       
      preset_modes:
       - "low"
       - "medium"
       - "high"
       - "auto"
       - "autonight"
       - "timer1"
       - "timer2"
       - "timer3" 

[benjamin-dcs]

Duplicate with #49

[jasperslits]

Just reopening it to understand this set up.

With the demand flow I think you can control different rooms instead of just one setting for all exhausts in a room. So how does that work today?

For just the HRU fan support there's indeed #49 but what's the use-case? Remote X controls room 1 & 2 and Remote Y controls rooms 3 & 4?

[dirixmjm]

Each remote can be assigned to a different room.
So remote x controls room 1, and remote y controls room 3. Each of the rooms has a different valve setting.
With the exception of the default remote which controls the extractor hood valve as well as ventilation of the living room.
You can copy physical remotes, but it should also possible to add virtual ones only (although I don't know how the room assigned works in the case, it is certainly easier to add a physical remote and then copy it into the virtual remote).

I have two virtual remotes defined based off of a physical remote, one is the general one and the second one is defined for the sports room.

[jasperslits]

Ok, and these remotes support CO2 monitoring too?

Now, if we translate this to this integration with HA. How do you expect this to work? Because only actual remotes (remotes info MQTT topic) are integrated. So do you expect to have then 5 MQTT fans if you have 5 rooms / virtual remotes?

I am just wondering if this is not going to be too complex.

[dirixmjm]

With DF you have up to 12 channels (rooms).
In theory each room can have a single separate remote, this can be either physical or virtual (with virtual I mean defined in the Hiemstra ITHO module).
AFAIK the physical remotes are not exposed through the Hiemstra interface, and if so I am not 100% sure the CO2 ones for the CVE can be used at all with DF. Some remotes can and some can't be used.

Secondly, so far I have not been very successful defining a virtual-only remote to a channel. Assignation worked, but then the DF goes into error after the IBS has finished (I need some more testing).

In any case, combination of physical with virtual remote works.

Indeed I'd expect to have the same amount of MQTT fans exposed in HAS as there are virtual remotes defined in Hiemstra.

To be honest, I was expecting there that the virtual remotes would be added automatically already. Maybe the solution is in the Hiemstra interface exposed to HAS. But my knowledge on the topic is very limited here. This is the only MQTT interface I use.

[jasperslits]

This is a bit tricky because only if virtual remotes are included in the MQTT payload from Arjen's module then we can consider including it here. As today the virtual remotes are not exposed, this is not possible. Also, I cannot get fan creation to work in Python. The provided YAML code is actually something I am familiar with, I created the entry in the wiki myself a few years ago :)

You can still manually create entries in HA to support the remotes using the rfremotecmd & rfremoteindex combo. This integration is intended for 'standard' domestic scenarios but DF support with the multiple remotes.