Duplicate Multi-Press on slave switch when not pressed

[RGarrett93]

I've migrated over to your official integration but unfortunately my automations (Node Red) for monitoring event type Multi-Press lightwave_smart.click no longer works like previously. When I multi-press on a switch that has a slave linked it now triggers a duplicate event on the linked switch even though that button wasn't pressed for Multi-Press, it also occurs vice versa if I do the same on the slave, it triggers a duplicate multi-press event on the master switch even though it wasnt pressed.

event_type: lightwave_smart.click
data:
  entity_id: light.dining_room_lights_3_v2
  code: 4354
origin: LOCAL
time_fired: "2023-12-19T10:44:29.508363+00:00"
context:
  id: 01HJ0TTN6412G50EC4C6Q6J8ED
  parent_id: null
  user_id: null

event_type: lightwave_smart.click
data:
  entity_id: light.kitchen_lights_v2
  code: 4354
origin: LOCAL
time_fired: "2023-12-19T10:44:29.456326+00:00"
context:
  id: 01HJ0TTN4G9EV5DGTGVM2X2499
  parent_id: null
  user_id: null

[ikb42]

Hi, thanks for raising this. There is improved support for this in this version of the integration, see the attached screenshot. That being said, I'm not sure why the old method is not working for you, it could be due to some of the refactoring. The old method will likely be removed in the future. Can you take a look at the new implementation and let me know if this works for you?

[RGarrett93]

Hi, I should of mentioned but even the new method is exactly the same when it comes to Multi-Press with the Master and Slave switches. Below both showing Down.Short.2 even though only one of the paired switches was pressed:

I was comparing your fork with the previous integration (bigbadblunt) and I'm wondering whether the identifiers that were removed might be the reason why it can't differentiate between the paired switches event?

- if kwargs["feature"] == "uiButtonPair" and self._lwlink.get_featureset_by_featureid(kwargs["feature_id"]).featureset_id == self._featureset_id: + if kwargs["feature"] == "uiButtonPair":

[ikb42]

Hmm, I tested and I see what you mean. The Mirror feature is producing the same UI event on both devices - I'm guessing that is as intended, hence the name mirror. That explains why you see both events as they are both produced. Strange that this would have changed between integrations - with the previous integration / button press method you should still see both events as they are both being produced?

[RGarrett93]

Yeah unusual as this never occurred on the previous integration unless something has changed recently with the Lightwave server API and it was coincident when I changed over. I have light switches either end of the room which triggered different automations based on their multi-press.

There is an option on the Lightwave UI to mirror buttons with each other but I haven't done that: Ive done the 2 way lighting automation which creates a Master and Slave switch.

I haven't studied this integration enough but do think it has anything to do with the identifying being removed: - if kwargs["feature"] == "uiButtonPair" and self._lwlink.get_featureset_by_featureid(kwargs["feature_id"]).featureset_id == self._featureset_id: + if kwargs["feature"] == "uiButtonPair":

[ikb42]

Ok, I thought you used the mirror option - I'll test with the automation option and see what I get.

I'll check the code you mention too to see what's going on there.

[ikb42]

With the automation "Two-Way Switching" I get the same behaviour, 2 UI button events.

I also checked the condition you mention above, it's not useful anymore as the async_update_callback is now only called for each entity when it is the entities featureset_id that is involved - whereas before this was called for all entities when there was a change. In other words this: self._lwlink.get_featureset_by_featureid(kwargs["feature_id"]).featureset_id == self._featureset_id Is aways true when async_update_callback is called.

It may have been that previously only the one / first event was processed for some other reason.

[RGarrett93]

Okay, thanks for investigating this. It will be a pain but should I migrate back to the original integration that worked for me and see if it returns back?

[xela1]

Okay, thanks for investigating this. It will be a pain but should I migrate back to the original integration that worked for me and see if it returns back?

I'll try and put an earlier version on my test instance of HA tomorrow and see how it behaves

[xela1]

I can confirm it's the same behaviour on the original bigbadblunt integration

[RGarrett93]

Thank you for testing this, really appreciate it as you've saved me alot of renaming entitles. I find it really odd though why it's now doing that, I've had my Multi-Press automation for a while on 2 way lighting.

Not an issue though, I will adapt my automations.

I wrote my own Mirroring / 2 Way Lighting automation using data template (prevents double triggering) which replicates the 2 way lighting but via HA automation instead of via the Lightwave UI automation, this would then create seperate events as the switches are not linked together on Lightwave.

I've opted to stick with Lightwave UI Automation as should HA fail my lighting would not be reliant on it (independent).

I've copied both automations to here for mirroring the light switches and mirroring the brightness as you hold the button up or down. It uses the homekit entities for local control, should anyone come across the same issue and want a workaround solution.

Mirror Switch Automation

alias: Landing Lights Mirror
description: ""
trigger:
  - platform: state
    entity_id: light.hall_lights_2, light.landing_lights
    from: "off"
    to: "on"
  - platform: state
    entity_id: light.hall_lights_2, light.landing_lights
    from: "on"
    to: "off"
condition: []
action:
  - service_template: >-
      {% if trigger.to_state.state == "on" %} light.turn_on {% elif
      trigger.to_state.state == "off" %} light.turn_off {% endif %}
    data_template:
      entity_id: >-
        {% if trigger.from_state.entity_id == "light.hall_lights_2" %}
        light.landing_lights {% elif trigger.from_state.entity_id ==
        "light.landing_lights" %} light.hall_lights_2 {% endif %}
mode: single

Mirror Brightness Automation

alias: Landing Brightness Mirror
description: ""
trigger:
  - platform: state
    entity_id: light.landing_lights
    attribute: brightness
  - platform: state
    entity_id: light.hall_lights_2
    attribute: brightness
condition:
  - condition: and
    conditions:
      - condition: state
        entity_id: light.landing_lights
        state: "on"
      - condition: state
        entity_id: light.hall_lights_2
        state: "on"
action:
  - service: light.turn_on
    data_template:
      entity_id: >-
        {% if trigger.from_state.entity_id == "light.hall_lights_2" %}
        light.landing_lights {% elif trigger.from_state.entity_id ==
        "light.landing_lights" %} light.hall_lights_2 {% endif %}
      brightness: >-
        {% if trigger.from_state.entity_id == "light.landing_lights" %} {{
        states.light.landing_lights.attributes.brightness }} {% elif
        trigger.from_state.entity_id == "light.hall_lights_2" %} {{
        states.light.hall_lights_2.attributes.brightness }} {% endif %}
mode: single

[xela1]

saved me alot of renaming entitles.

This is exactly why I did it, been there, done that, too many times :)

I can only assume something change on the Lightwave API when they released the scene selectors, but that's just a guess @ikb42 would hopefully know more.

To that point, are there public release notes for the API?

[ikb42]

@RGarrett93 glad you've got a way forward.

@xela1 in terms of API change re the uiButton events and scene selectors, I'll see if I can find anything out.

Re API release notes, the websocket API used by this integration is not documented currently.