Niko 552-721X2 - Non detection of the physical action of the switch

[Argonautes64]

What happened?

Hello,
Home Assistant (Last).
Version Z2M 1.29.2-1
For Double connectable switch - Niko - 552-721X2
Start, both switches are off.
Actuate L1 physically ->
info 2023-05-22 09:30:57MQTT publish: topic 'zigbee2mqtt/EclairageSalon02', payload '{"action_l1":null, "action_l2":null, "led_enable":true, "led_state": "OFF", "linkquality":72, "operation_mode": "control_relay", "operation_mode_l1":null, "operation_mode_l2":null, "state": "ON", "state_l1": "ON", "state_l2": "OFF"}'
-> Result OK

Version Z2M 1.30.4-1
Same procedure
info 2023-05-22 09:30:57MQTT publish: topic 'zigbee2mqtt/EclairageSalon02', payload '{"action_l1":null, "action_l2":null, "led_enable":true, "led_state": "OFF", "linkquality":72, "operation_mode": "control_relay", "operation_mode_l1":null, "operation_mode_l2":null, "state": "ON", "state_l1": "OFF", "state_l2": "OFF"}'
-> Result BAD

The action on the switch remains "state_l1":OFF
Sincerely

What did you expect to happen?

after push on l1 ->
info 2023-05-22 09:30:57MQTT publish: topic 'zigbee2mqtt/EclairageSalon02', payload '{"action_l1":null, "action_l2":null, "led_enable":true, "led_state": "OFF", "linkquality":72, "operation_mode": "control_relay", "operation_mode_l1":null, "operation_mode_l2":null, "state": "ON", "state_l1": "ON", "state_l2": "OFF"}'

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.30.4-1

Adapter firmware version

CC1352P2_CC2652P_launchpad_coordinator_20220219

Adapter

Sonoff_Zigbee_3.0_USB_Dongle_Plus

Debug log

No response

[vyruz1986]

I have the same issue, although I can't confirm that it worked on 1.29.x since I installed my Niko switch on 1.30.4.
I did monitor the output from the zigbee coordinator (I'm using ZigStar OliZig POE over network), but I couldn't see any data being emitted from the coordinator when I pushed the physical switch and caused the relay to toggle, so I assumed it was a flaw of the Niko switch not sending any signal when the physical switch is pushed (which would be very weird...).
Perhaps it's some configuration which has changed in recent version that previously instructed the Niko switch to transmit physical pushes to the coordinator?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days

[vyruz1986]

This issue still persists for me with version 1.32.1

[yorickarens]

Current version: 1.32.1-1

Got the same problem when running the switches in relay mode. This is what I get when pressing L1.

Debug 2023-07-29 20:53:03Received Zigbee message from 'Badkamer_Schakelaar', type 'attributeReport', cluster 'genOnOff', data '{"onOff":1}' from endpoint 1 with groupID 0
Info 2023-07-29 20:53:03MQTT publish: topic 'zigbee2mqtt/Badkamer_Schakelaar', payload '{"action":null,"elapsed":1701470,"led_enable":true,"led_enable_l1":null,"led_enable_l2":null,"led_state":"ON","led_state_l1":null,"led_state_l2":null,"linkquality":69,"operation_mode":"control_relay","state":"ON","state_l1":"OFF","state_l2":"OFF"}'

This is the same but then for off:

Debug 2023-07-29 20:53:12Received Zigbee message from 'Badkamer_Schakelaar', type 'attributeReport', cluster 'genOnOff', data '{"onOff":0}' from endpoint 1 with groupID 0
Info 2023-07-29 20:53:12MQTT publish: topic 'zigbee2mqtt/Badkamer_Schakelaar', payload '{"action":null,"elapsed":2859,"led_enable":true,"led_enable_l1":null,"led_enable_l2":null,"led_state":"ON","led_state_l1":null,"led_state_l2":null,"linkquality":7,"operation_mode":"control_relay","state":"OFF","state_l1":"OFF","state_l2":"OFF"}'

When I look into niko.js

It looks like we have to look in these lines because the mqtt string is wrong.

            await reporting.onOff(ep1);
            await reporting.onOff(ep2);

And then it exposes this:
exposes.enum('operation_mode', ea.ALL, ['control_relay', 'decoupled']).withEndpoint('l1'),

It looks like the states are in ea.ALL right?

[jovandeginste]

Confirmed it works with v1.30.3, and misbehaves with v1.30.4

[jovandeginste]

Reverting this single line seems to fix the problem (for this specific device):

diff --git a/src/devices/niko.js b/src/devices/niko.js
index 400e43ab..acf1ad75 100644
--- a/src/devices/niko.js
+++ b/src/devices/niko.js
@@ -294,7 +294,8 @@ module.exports = [
         endpoint: (device) => {
             return {'l1': 1, 'l2': 2};
         },
-        meta: {multiEndpointEnforce: {'operation_mode': 1}},
+        meta: {multiEndpoint: true},
         configure: async (device, coordinatorEndpoint, logger) => {
             const ep1 = device.getEndpoint(1);
             const ep2 = device.getEndpoint(2);

Can anyone tell me what this change means?

[vyruz1986]

I can see the line you mention being changed back in this PR.
Does that mean that Z2M is using an old version of zigbee-herdsman-converters?

Also looking through these changes, I noticed that I am having this prroblem with a Niko 552-721X1 instead of the 552-721X2 which this issue is about.

For the 552-721X1 the meta line is not present at all (this is the relevant part in the current file).

Perhaps the multiEndpoint... parameter is for devices with multiple relays, which the X1 switch is not?

[jovandeginste]

I think you misunderstood me: the patch I pasted is the code I'm running now, so "master" niko.js but without the Enforce.

[Koenkk]

@sjorge since you made this change, could you take a look at this?

[sjorge]

@sjorge since you made this change, could you take a look at this?

I’ve not had the device in a while so those changes were from testing feedback from one of the issues here.

From memory operating_mose in multiEndpointEnforce makes sense as both eps seem get changed together when setting ep1 (as they seemed to be linked), but setting it on ep2 had no effect but somehow still toggled the atteibute. It could be that the logic for multiEndpointEnforce itself is broken though. I think it got added specifically for the X2 variant.

[sjorge]

We might need:

meta: {multiEndpointEnforce: {'operation_mode': 1},
multiEndpoint: true},

[Koenkk]

Could you check if the issue is fixed with the following external converter: https://gist.github.com/Koenkk/e9be4bf02adbe6101c3781a3446e451f

• save this as file next to configuration.yaml as ext_converter.js
• add it to configuration.yaml:

external_converters:
  - ext_converter.js

• start z2m, check if issue is fixed

[jovandeginste]

Could you check if the issue is fixed with the following external converter: https://gist.github.com/Koenkk/e9be4bf02adbe6101c3781a3446e451f

* save this as file next to `configuration.yaml` as `ext_converter.js`

* add it to `configuration.yaml`:

external_converters:
  - ext_converter.js

* start z2m, check if issue is fixed

I did a quick test and it seems to work (to the extent that I'm using it)

[jovandeginste]

When not in control_relay mode, the "led_state" actions seem not useful. When in decoupled, they do the same thing, ie. switching either l1 or l2 on, both leds are turned (permanently) on on the switch, switching either l1 or l2 off turns the leds back off.

In decoupled mode, I get the single, hold and release actions; in control_relay I don't get those actions... Unsure if this is expected?

[sjorge]

That would be expected, in control relay they toggle the relays. The device only reports new genOnOff.onOff state and z2m will update state_l<1|2> depending on which relay it was.When decoupled the device emits the manuNikoSwitch.switchAction report (i might have gotten the cluster name wrong, this is from memory) so z2m processes that and outputs the action event.The relay can still be toggled via z2m (device also reports the change when it has done so), sadly you can’t bind another remote to it.~ sjorgeOn 9 Aug 2023, at 20:22, Jo Vandeginste ***@***.***> wrote: When not in control_relay mode, the "led_state" actions seem not useful. When in decoupled, they do the same thing, ie. switching either l1 or l2 on, both leds are turned (permanently) on on the switch, switching either l1 or l2 off turns the leds back off. In decoupled mode, I get the single, hold and release actions; in control_relay I don't get those actions... Unsure if this is expected? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Koenkk]

Thanks, I've integrated the fix.

Changes will be available in the dev branch in a few hours from now. (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days