Homematic Switch, hold

[gitti046]

Hello,

i migrated from switchmanager 2.0.5 from Sian to your Version 4.2.0 some days ago.

I have multiple switches from different vendors, all seem to work properbly after the migration.
But both Homematic (6way) switches have a problem with „hold“ actions. It still don‘t work, „press“ actions are working without problems.
In the version of Sian, all „hold“ actions are functioning.
Any ideas?

Thx for your work!
Jens

[Pingfragger]

I can confirm this issue and found the cause for classic Homematic BidCos-RF switches.

Affected device

• Model: HM-RC-2-PBU-FM
• Name: Homematic 2-channel wireless transmitter
• Interface: BidCos-RF
• Switch Manager blueprint: homematic-2-buttons.yaml

All of my HM-RC-2-PBU-FM switches are affected.

Actual Home Assistant events

A short press produces:

event_type: homematic.keypress
data:
  model: HM-RC-2-PBU-FM
  type: press_short
  subtype: 2

Holding and releasing the button produces this sequence:

type: press_long
type: press_cont
type: press_cont
type: press_long_release

However, the current homematic-2-buttons.yaml blueprint expects:

- title: hold
  conditions:
    - key: type
      value: press_long_start

The HM-RC-2-PBU-FM never sends press_long_start, so the configured hold action is not triggered.

Confirmed workaround

Changing both occurrences of:

value: press_long_start

to:

value: press_long

in homematic-2-buttons.yaml fixes the problem immediately. Long-press actions then work again for all of my HM-RC-2-PBU-FM switches.

Suggested solution

Please either:

1. add a separate blueprint for classic Homematic BidCos-RF devices such as the HM-RC-2-PBU-FM, using press_long, or
2. make the Homematic blueprint support both press_long and press_long_start.

Simply replacing press_long_start globally might break other Homematic devices or integrations that actually emit press_long_start, so a device-specific blueprint or support for both event types may be safer.

[macpit]

Fixed in v4.3.3. @Pingfragger, thanks — your event traces made this straightforward, and you were right that a blind replace would have been the wrong move.

This one is on me: v3.0.9 of this fork changed the hold condition in all three Homematic blueprints from press_long to press_long_start, and that change was never verified against real hardware. That is exactly why hold worked on the Sian-Lee version, Jens — nothing about your migration was wrong.

Going back to press_long alone would have broken Homematic IP, which sends press_long_start once and then repeats press_long while the button is held — the hold action would fire again on every repeat. So the condition now accepts press_long_start, plus press_long for devices whose model is not HmIP:

- title: hold
  conditions: "{{ data.type == 'press_long_start' or (data.type == 'press_long' and 'HmIP' not in (data.model | default(data.device_type) | default('') | string)) }}"

Verified against Home Assistant's own template engine for BidCos hold, HmIP hold start, HmIP repeats (must not retrigger), press_cont, releases, short presses, and an unknown model, which falls back to the original behaviour.

Applies to the 2, 6 and 8 button blueprints. Update via HACS; the blueprints are replaced automatically and your existing switch configuration is untouched. Please reopen if hold is still dead on your 6-way switches.