Niko 552-721X2 endpoint actions not working #13737
Comments
|
Is it just home assistant not seeing the actions because it might be looking in the wrong property, or are you not getting them via mqtt either? |
|
Okay, just had a better look at this to answer your question. Current configuration of the device: When pressing the left button, I see these events in the Z2M logs: `Zigbee2MQTT:info 2022-08-30 11:40:52: MQTT publish: topic 'zigbee2mqtt/Interrupteurs toit cuisine', payload '{"action_l1":null,"action_l2":null,"linkquality":63,"operation_mode":"decoupled","operation_mode_l1":null,"operation_mode_l1_l1":"control_relay","operation_mode_l2":null,"operation_mode_l2_l2":"decoupled","state_l1":"ON","state_l2":"OFF"}'
You can see the action_l1 attribute remains to null. Z2M appears to see the relay event, but not the button click themselves. What's even weirder is this. When I press the right button, I see these events in the Z2M log:
The l2 state shouldn't change as it is in decoupled operation mode. I can confirm that the L2 relay DOES activate. If you provide me directions I can provide other logs if it can help. I'm really at loss here.. I can't really tell if the device is doing something wrong or if it's a Z2M issue. I bought this unit to have an outdoors dual Zigbee switch, by fitting it inside a Niko Hydro box. Really hope I can get this to work as there are not a ton of options here in Belgium for this use case. |
|
Can you set the log level to debug and press the buttons again, that should show what the device is sending. And hopefully that is enough for me to figure out what is wrong. 🤞
Yeah not much options, you got the generic TuYa stuff which I personally don't like, and well Ubisys ships to Belgium too. I love there stuff but rather expensive, especially compared to the Niko stuff. (Sadly the Niko stuff does not do binding which is a deal breaker for me personally). |
|
Starting from both relays off, nothing changed in the device config. L1 button first press:
L1 second press:
L2 first press:
L2 second press:
I also looked into what the feedback is when I try to set the switch behaviour to decoupled, as obviously L2 behaves as control_relay although it is configured as decoupled. Here is what I see in the debug logs :
When I do a get after that:
I'm not a Z2M expert, but I think the whole issue is excess/missing _l1 and _l2 things here and there. In particular, this:
Sounds extremely weird, and as control_relay is the default behaviour, I think it's our clue. I will be away from home for the coming 48 hours but happy to test any fix that might come up :) |
|
Yes the double _l2_l2 and _l1_l1 are not correct for sure, but it at least looks to be reading the info from the correct endpoint. Looks like I did set multiEndpoint correctly so as of now i am puzzled why it is not working. I think the actions are probably missing because the device never wrote the decoupled config for the 2nd endpoint correctly so it's not generating the actions, as I am still seeing the genOnOff reporting coming in. Edit: @Koenkk I probably messed stuff on in these convertors, can you have I look? @sephiroth1395 are you able to apply a diff to devices/niko.js and restart zigbee2mqtt to test? |
|
Not really how to do this with Z2M running as a HASS add-on.. Looking into it. EDIT: Okay, got it. Forgot it was just old plain Docker. In some ways it appears to be better:
There is still a lot of confusion between general attributes, l1 and l2. |
|
@sephiroth1395 issue should be fixed now, updated to the latest-dev, clear out @sjorge for toZigbee converters, the endpoint is added by z2m thus it doesn't have to be added in the converter. |
|
@Koenkk ok so as my diff showed, I think this is also needed for the action one as you missed that. |
We probably also need this to fully fix Koenkk/zigbee2mqtt#13737
|
@sjorge that should be fine, this is a fromZigbee converter so no endpoint will appended twice. |
|
OK, lets wait until we hear back form sephiroth1395 then to make sure everything is working. |
|
Sorry for the late feedback. Life happened. It's better! The duplicate state is still there but so is the "normal" one: And it appears to be obeyed. The relays are indeed decoupled from the switches ! Changing the operation_mode to control_relay also works as intended. What I'm still missing is actions. Things are still happening on a single action attribute, that appears when I press a button, instead on action_l1 and action_l2. |
|
Can you try applying the additional change I had in my diff for the switch_action function? Koenkk/zigbee-herdsman-converters@master...sjorge:zigbee-herdsman-converters:patch-2 |
|
No difference, but I noticed only the left (l1) button triggers events to HA. The second one, not so much. |
|
Can you grab another debug log with both of l1 and l2 in decoupled mode when you click each of the buttons? |
|
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 |
|
Hi all, Symptoms (on edge build)
State (for reference)Debug logsBelow are the logs I get when pressing the physical switches. Both are set to decoupled mode: Hope this helps. |
|
I no longer have the dual rocker one so I can't double check myself, so some follow up questions:
The value in your snipper above for 4096 16384 are things I have not see with my brief time with the device, so it probably means I did not capture all the data correctly before I send it back. I only had like 3 days to poke and collect data. My initial messing around (pre having any support) indicated that it should be possible to toggle the mode individually as the difference between single and dual seemed to be an extra endpoint mirroring all the clusters. This might have been wrong. Hopefully 1 above should that they are either in sync or not, if the former it's probably an all or nothing option. That would also explain why all actions arrive on endpoint 1 even when using the other button. If that's the case the action map probably also needs to be extended. Currently it is: But it might be that there is another set of 4 values for the 2nd button. |
These are the logs after setting operation_mode_l1 to decoupled and pressing the physical button for L2:
Right button (L2 & L1 decoupled) Right button (L1 decoupled, L2 control_relay) Hope this helps |
|
Hello, I am also struggling with this double Niko switch and recognize the problems described in this topic. I want to use it in decoupled mode and detect the individual switches. Not sure if I can help in debugging as I am not that acquainted with github and install a beta version to do some testing. Nevertheless, if I can do a test with the released version then let me know. |
|
I'm having the same problem. |
|
Can you try with this external converter? I modified the fz.switch_action, I took a guess based on the data in this thread but I did not test it, as no longer have any of the Niko switches. const fz = require('zigbee-herdsman-converters/converters/fromZigbee');
const tz = require('zigbee-herdsman-converters/converters/toZigbee');
const exposes = require('zigbee-herdsman-converters/lib/exposes');
const reporting = require('zigbee-herdsman-converters/lib/reporting');
const extend = require('zigbee-herdsman-converters/lib/extend');
const e = exposes.presets;
const ea = exposes.access;
const local = {
fz: {
switch_operation_mode: {
cluster: 'manuSpecificNiko1',
type: ['attributeReport', 'readResponse'],
convert: (model, msg, publish, options, meta) => {
const state = {};
if (msg.data.hasOwnProperty('switchOperationMode')) {
const operationModeMap = {0x02: 'control_relay', 0x01: 'decoupled', 0x00: 'unknown'};
state['operation_mode'] = operationModeMap[msg.data.switchOperationMode];
}
return state;
},
},
switch_action: {
cluster: 'manuSpecificNiko2',
type: ['attributeReport', 'readResponse'],
convert: (model, msg, publish, options, meta) => {
const state = {};
if (msg.data.hasOwnProperty('switchAction')) {
// NOTE: a single press = two seperate values reported, 16 followed by 64
// a hold/release cyle = three seperate values, 16, 32, and 48
const actionMap = (model.model == '552-721X1') ?
{16: null, 64: 'single', 32: 'hold', 48: 'release'} :
{16: null, 64: 'left_single', 32: 'left_hold', 48: 'left_release', 4096: 'right_single', 8192: 'right_hold', 12288: 'right_release'};
state['action'] = actionMap[msg.data.switchAction];
}
return state;
},
},
},
tz: {
switch_operation_mode: {
key: ['operation_mode'],
convertSet: async (entity, key, value, meta) => {
// WARN: while we can technically write 0x00 to the operationMode attribute
// this seems to brick the device and it will need to be rejoined
const operationModeLookup = {control_relay: 0x02, decoupled: 0x01};
if (!operationModeLookup.hasOwnProperty(value)) {
throw new Error(`operation_mode was called with an invalid value (${value})`);
} else {
await entity.write('manuSpecificNiko1', {'switchOperationMode': operationModeLookup[value]});
return {state: {operation_mode: value.toLowerCase()}};
}
},
convertGet: async (entity, key, meta) => {
await entity.read('manuSpecificNiko1', ['switchOperationMode']);
},
},
},
};
const definition = [
{
zigbeeModel: ['Double connectable switch,10A'],
model: '552-721X2',
vendor: 'Niko',
description: 'Double connectable switch',
fromZigbee: [fz.on_off, local.fz.switch_operation_mode, local.fz.switch_action],
toZigbee: [tz.on_off, local.tz.switch_operation_mode],
endpoint: (device) => {
return {'l1': 1, 'l2': 2};
},
meta: {multiEndpoint: true, multiEndpointEnforce: {'operation_mode': 1}},
configure: async (device, coordinatorEndpoint, logger) => {
const ep1 = device.getEndpoint(1);
const ep2 = device.getEndpoint(2);
await reporting.bind(ep1, coordinatorEndpoint, ['genOnOff']);
await reporting.bind(ep2, coordinatorEndpoint, ['genOnOff']);
await reporting.onOff(ep1);
await reporting.onOff(ep2);
await ep1.read('manuSpecificNiko1', ['switchOperationMode']);
await ep2.read('manuSpecificNiko1', ['switchOperationMode']);
},
exposes: [
e.switch().withEndpoint('l1'), e.switch().withEndpoint('l2'),
e.action(['single', 'hold', 'release']).withEndpoint('l1'),
e.action(['single', 'hold', 'release']).withEndpoint('l2'),
exposes.enum('operation_mode', ea.ALL, ['control_relay', 'decoupled']),
],
},
{
zigbeeModel: ['Single connectable switch,10A'],
model: '552-721X1',
vendor: 'Niko',
description: 'Single connectable switch',
fromZigbee: [fz.on_off, local.fz.switch_operation_mode, local.fz.switch_action],
toZigbee: [tz.on_off, local.tz.switch_operation_mode],
configure: async (device, coordinatorEndpoint, logger) => {
const endpoint = device.getEndpoint(1);
await reporting.bind(endpoint, coordinatorEndpoint, ['genOnOff']);
await reporting.onOff(endpoint);
await endpoint.read('manuSpecificNiko1', ['switchOperationMode']);
},
exposes: [
e.switch(),
e.action(['single', 'hold', 'release']),
exposes.enum('operation_mode', ea.ALL, ['control_relay', 'decoupled']),
],
},
];
module.exports = definition; |
|
helaas heb ook ik hetzelfde probleem. Unfortunately, I too have the same problem. |
|
Tested; the solution to this issue is setting attribute |
|
Thanks a lot everyone for looking into this! @RubenVerborgh can this attribute be set through Z2M or can you point me in the right direction? |
|
@Hansvank It will still need to be added to Z2M; looks like the place for that is here: https://github.com/Koenkk/zigbee-herdsman/blob/1e6ca6fc6cb84389f5c1c25102cf7b2461287dbe/src/zspec/zcl/definition/cluster.ts#L4041-L4053 |
That is not the right location any more, it should end up as a device specific custom cluster (e.g. https://github.com/Koenkk/zigbee-herdsman-converters/blob/master/src/lib/ubisys.ts) Exactly for the reason noted in the warning, as there is often overlap with other devices but with different attribute types. |
|
Thanks @RubenVerborgh for the hard work. |
|
Working ZHA code is available at zigpy/zha-device-handlers#3701 |
|
@RubenVerborgh Thanks for the work and the nice PR! I did some testing to implement this for zigbee2mqtt and got something working. I have attached changed files: Issues/Todo's:
Feedback on the Issues/Todo's are welcome! |
|
@svenjochems Thanks so much for taking the time to test!
Awesome, that's consistent, fortunately! Still wonder how the non-zero value ended up there, or rather how it stayed persistent after a reset. (Does it, actually? If you reset the switches, do the values stay?)
Interesting. So we know it to be a bit mask wherein each of the ones represent the four buttons. So that would be Main/Left (
That's weird, I do not observe such behavior with my switches. The value of I do observe that the state itself (
Confirmed to be working.
Ain't no party like a Niko Home Party 🥳
|
This parameter was only reset in zigbee2mqtt and not in the device itself. When reading the parameter again, it was reported correctly again. Probably an issue in my code 🙂
My first switches have always had this value (I guess because actions were reported). They were reset multiple times and were never connected to the Niko hub. |
Perhaps that's the key to the mystery: all devices I bought the past couple of weeks had |
|
Wait, the |
|
H!i I'm not sure how any of this works, but I've been waiting for this to be fixed for a while now. Does anyone know when this will be pushed to the release version? |
|
@Diepzeevogel I will create a PR once I have figured out the issues/todo's I have listed in #13737 (comment). |
|
I have create PR's Koenkk/zigbee-herdsman#1301 and Koenkk/zigbee-herdsman-converters#8635 with the changes I listed #13737 (comment). |
There seems to be a firmware difference as well. I tested the 0x0107 attribute. While this works on my newest devices, this attribute is not supported on my old devices. |
|
I have finished my PR Koenkk/zigbee-herdsman-converters#8635 |
|
Looks good, thanks @svenjochems! One issue I'm still bumping into is the fact that I use the connected switch for push2dim control meaning the relay should deactivate whenever the button is released. Is this a possible to achieve with the Niko Software? If so would it be possible to integrate this in zigbee2mqtt? |
|
@paddenstoeltje are you using homeassistant or something similar? I think this is possible of you set the switch to decoupled mode and create an automation:
|
|
Hi Sven, yes I'm using HA and it is already implemented with an automation. However, I'm trying to make the system as robust as possible: basically I want the lights to be able to switch all the time, even if HA or the coordinator is out... That's why I was asking if it is possible in the Niko Software to program the switch to act monostable (relay should follow the state of the button). Thx for looking into this |
|
I just ran a quick test and everything works like a charm! Thank you very much for fixing this!! |
I'm not sure if this is possible. We will need to test if this is possible using Niko Home Control and sniff the network to check which parameters are being sent to the device. I cannot do this myself because I don't have a Niko Home Control. |
Yes:
|
This is for switch behaviour (click->on, click->off). I think what @paddenstoeltje wants is push-button behaviour (press->on, release->off). Correct me if I'm wrong! |
|
In that case, presumed not possible: the Niko hub would implement such behavior explicitly. |
|
Correct, I'm looking for push-button behaviour (press->on, release->off). At the moment it is tackled via software. The only problem is that whenever zigbee2Mqtt / coordinator / ha is down, the lights fail to work. So when I'm updating something and the wife presses a button I get a lot of complaints :p ... |
What happened?
In both control_relay and decoupled modes, the actions remains null on both endpoints L1 and L2 when I activate the switches physically. When in control_relay mode, the relays do operate when pressing the button so I have every reason to believe the device is not broken. It is brand new.
I can see a single "single, hold or release" action exposed in Home Assistant at device level instead of the l1 and l2 endpoints.
What did you expect to happen?
See the single, hold and release actions exposed.
How to reproduce it (minimal and precise)
Push any switch of the device.
Zigbee2MQTT version
1.27.0
Adapter firmware version
20210708
Adapter
Sonoff USB Dongle
Debug log
No response
The text was updated successfully, but these errors were encountered: