Open demcas opened 9 months ago
I can confirm this issue. 1 Gang dimmer is working fine, but 2 gang, diming is not working.
I can confirm this issue. 1 Gang dimmer is working fine, but 2 gang, diming is not working.
I am glad its not just me having issues, It was driving me crazy these past few weeks
Hi @kirovilya can you assist in isolating this issue on the 2 Gang and 3 Gang version. The 1 Gang switch operates flawlessly. Is it possible to replicate the code from the 1 Gang over to the 2 and 3 Gang switches?
@kirovilya hi, can you assist?
@demcas Hello. I don't fully understand the problem. I'm trying to control my device in z2m GUI - everything works.
the only problem that I sometimes see is that changes are not always displayed in the GUI, but if you refresh the page, then everything will be correct.
https://github.com/Koenkk/zigbee2mqtt/assets/8360230/7ea2c759-c5a6-4ae4-a339-4d4d634acb35
@demcas Hello. I don't fully understand the problem. I'm trying to control my device in z2m GUI - everything works.
the only problem that I sometimes see is that changes are not always displayed in the GUI, but if you refresh the page, then everything will be correct.
doc_2023-12-16_10-39-56.mp4
Can you create a a HA light card and trying dimming on the HA Dashboard light card not in Z2M GUI. This is where Iβm experiencing the problem.
![Uploading IMG_4805.jpegβ¦]()
Hmm.
Indeed, the brightness does not change from HA.
Perhaps this is due to the fact that 2 attributes are sent from the HA: the βONβ state and brightness. Accordingly, 2 commands are sent to the device. I'm still figuring it out...
Zigbee2MQTT:debug 2023-12-16 13:19:32: Received MQTT message on 'zigbee2mqtt/0xa4c138c9d1acda99/l1/set' with data '{"state":"ON","brightness":183}'
Hmm. Indeed, the brightness does not change from HA. Perhaps this is due to the fact that 2 attributes are sent from the HA: the βONβ state and brightness. Accordingly, 2 commands are sent to the device. I'm still figuring it out...
Zigbee2MQTT:debug 2023-12-16 13:19:32: Received MQTT message on 'zigbee2mqtt/0xa4c138c9d1acda99/l1/set' with data '{"state":"ON","brightness":183}'
I have a 1 gang version of the dimmer switch and the dimming function works perfectly on HA, but the 2 and 3 gang both experience this issue you just encountered.
Just checking, has the latest commit fixed the issue with the 2-3 gang switches?
Just checking, has the latest commit fixed the issue with the 2-3 gang switches?
Just tested and no it has not been fixed.. Not sure what to do here, I installed 40 of these light switched my house and my mother's house, frustrating I can't get the dimming to work on the HA light cards.
Hi,
I've been testing a 2-gang Moes dimmer and I got the same issue (or at least I think). I tried to investigate it myself but I have no knowledge of neither z2mqtt nor zigbee and tuya protocols, so maybe it will help someone more knowledgeable.
Anyway, the behavior is the following :
Now I've tried to investigate what's happening with Z2QMTT logs and I observed the mqtt calls used by HA and z2m UI are different, so I tried doing manual publishes on mqtt and here's what I found:
zigbee2mqtt/dimmer1/set
with data {"brightness_l1":114}
zigbee2mqtt/dimmer1/l1/set
with data {"state": "ON", "brightness_l1":114}
The second kind seems to have issues. Furthermore, the following work perfectly:
zigbee2mqtt/dimmer1/l1/set
with data {"state":"ON"}
zigbee2mqtt/dimmer1/l1/set
with data {"brightness":100}
The issue will only arise when publishing both state and brightness. Here, the brightness is ignored, only the state is set (I tried with state ON and OFF and different brightness values).
Note that if I send {"brightness":100,"state":"ON"}
(inverting the order of the field), it is now brightness that is sent, and state is ignored.
Here are some logs of Z2M. Note the 'set' 'state'
/'set' 'brightness'
, and also the dp
(1 being the tuya datapoint for state_l1 and 2 for brightness_l1 - and I get 7 and 8 for l2)
Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"state":"ON"}'
Publishing 'set' 'state' to 'dimmer1'
Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":33792}' from endpoint 1 with groupID 0
...
Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"brightness":100}'
Publishing 'set' 'brightness' to 'dimmer1'
Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,1,138],"type":"Buffer"},"datatype":2,"dp":2}],"seq":34304}' from endpoint 1 with groupID 0
...
Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"state":"ON","brightness":100}'
Publishing 'set' 'brightness' to 'dimmer1'
Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":37120}' from endpoint 1 with groupID 0
...
Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"brightness":100,"state":"ON"}'
Publishing 'set' 'state' to 'dimmer1'
Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,1,138],"type":"Buffer"},"datatype":2,"dp":2}],"seq":34816}' from endpoint 1 with groupID 0
Now, there is a second, different issue that come into the mix, and make thing difficult : if you set state to "ON" while it is already "ON", subsequent commands to the brightness will fail. You'll have to cycle the state OFF -> ON so that it can work again.
Example:
initial state: light is Off
zigbee2mqtt/dimmer1/l1/set
with data {"state":"ON"}
-- light is now ON
zigbee2mqtt/dimmer1/l1/set
with data {"brightness":100}
-- brightness changes to 100
zigbee2mqtt/dimmer1/l1/set
with data {"brightness":10}
-- brightness changes to 10
zigbee2mqtt/dimmer1/l1/set
with data {"state":"ON"}
-- nothing changes, it is already on
zigbee2mqtt/dimmer1/l1/set
with data {"brightness":100}
-- Problem, brightness stays at 10 (with "optimistic" disabled)
zigbee2mqtt/dimmer1/l1/set
with data {"state":"OFF"}
-- light is now OFF
zigbee2mqtt/dimmer1/l1/set
with data {"state":"ON"}
-- dimmer is now ON
zigbee2mqtt/dimmer1/l1/set
with data {"brightness":100}
-- brightness changes to 100 again
Note: this also affect the physically dimmer: after sending {"state": "ON"}
twice, you need to do an off/on cycle before being able to dim physically (work similarly if you use the physical switch or mqtt for the ON/OFF).
So in fact, with HA UI, this is what happens :
Now, I still have no idea on how to fix that, but somebody will...
Hi,
I've been testing a 2-gang Moes dimmer and I got the same issue (or at least I think). I tried to investigate it myself but I have no knowledge of neither z2mqtt nor zigbee and tuya protocols, so maybe it will help someone more knowledgeable.
Anyway, the behavior is the following :
On/Off always work, the only issue is with the dimmers
Dimming on the physical switches works (at first)
Dimming through Z2MQTT UI will work (at first)
Dimming on HA always fail.
After you tried dimming in HA, you will not be able to dim (neither with Z2M UI or physically) until you turn OFF then ON the light.
Now I've tried to investigate what's happening with Z2QMTT logs and I observed the mqtt calls used by HA and z2m UI are different, so I tried doing manual publishes on mqtt and here's what I found:
Z2M UI uses those kind of publish :
zigbee2mqtt/dimmer1/set
with data{"brightness_l1":114}
HA UI uses those kind of publish :
zigbee2mqtt/dimmer1/l1/set
with data{"state": "ON", "brightness_l1":114}
The second kind seems to have issues. Furthermore, the following work perfectly:
zigbee2mqtt/dimmer1/l1/set
with data{"state":"ON"}
zigbee2mqtt/dimmer1/l1/set
with data{"brightness":100}
The issue will only arise when publishing both state and brightness. Here, the brightness is ignored, only the state is set (I tried with state ON and OFF and different brightness values).
Note that if I send
{"brightness":100,"state":"ON"}
(inverting the order of the field), it is now brightness that is sent, and state is ignored.Here are some logs of Z2M. Note the
'set' 'state'
/'set' 'brightness'
, and also thedp
(1 being the tuya datapoint for state_l1 and 2 for brightness_l1 - and I get 7 and 8 for l2)Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"state":"ON"}' Publishing 'set' 'state' to 'dimmer1' Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":33792}' from endpoint 1 with groupID 0 ... Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"brightness":100}' Publishing 'set' 'brightness' to 'dimmer1' Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,1,138],"type":"Buffer"},"datatype":2,"dp":2}],"seq":34304}' from endpoint 1 with groupID 0 ... Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"state":"ON","brightness":100}' Publishing 'set' 'brightness' to 'dimmer1' Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":37120}' from endpoint 1 with groupID 0 ... Received MQTT message on 'zigbee2mqtt/dimmer1/l1/set' with data '{"brightness":100,"state":"ON"}' Publishing 'set' 'state' to 'dimmer1' Received Zigbee message from 'dimmer1', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[0,0,1,138],"type":"Buffer"},"datatype":2,"dp":2}],"seq":34816}' from endpoint 1 with groupID 0
Now, there is a second, different issue that come into the mix, and make thing difficult : if you set state to "ON" while it is already "ON", subsequent commands to the brightness will fail. You'll have to cycle the state OFF -> ON so that it can work again.
Example:
initial state: light is Off
zigbee2mqtt/dimmer1/l1/set
with data{"state":"ON"}
-- light is now ON
zigbee2mqtt/dimmer1/l1/set
with data{"brightness":100}
-- brightness changes to 100
zigbee2mqtt/dimmer1/l1/set
with data{"brightness":10}
-- brightness changes to 10
zigbee2mqtt/dimmer1/l1/set
with data{"state":"ON"}
-- nothing changes, it is already on
zigbee2mqtt/dimmer1/l1/set
with data{"brightness":100}
-- Problem, brightness stays at 10 (with "optimistic" disabled)
zigbee2mqtt/dimmer1/l1/set
with data{"state":"OFF"}
-- light is now OFF
zigbee2mqtt/dimmer1/l1/set
with data{"state":"ON"}
-- dimmer is now ON
zigbee2mqtt/dimmer1/l1/set
with data{"brightness":100}
-- brightness changes to 100 again
Note: this also affect the physically dimmer: after sending
{"state": "ON"}
twice, you need to do an off/on cycle before being able to dim physically (work similarly if you use the physical switch or mqtt for the ON/OFF).So in fact, with HA UI, this is what happens :
Only the state is send, not the brightness
when changing the brightness, we actually send a ON state when already ON, which bugs the brightness control
Now, I still have no idea on how to fix that, but somebody will...
@kirovilya @Koenkk
@beam-d thanks for the good analysis
Could you check if the situation improves with the following external converter:
configuration.yaml
as ext_converter.js
configuration.yaml
:
external_converters:
- ext_converter.js
@beam-d thanks for the good analysis
Could you check if the situation improves with the following external converter:
- save this as file next to
configuration.yaml
asext_converter.js
- add it to
configuration.yaml
:external_converters: - ext_converter.js
- start z2m, check if issue is fixed
Edit: Didn't use the latest Edge version.
Anyways, the 2-Gang switch still doesn't dim through HA.
@Koenkk
I found the issue: tuya.skip.stateOnAndBrightnessPresent
look at meta.state.state
, instead of meta.state.state_l1
(or l2).
Also, that skip function will skip when turning OFF the light (since we'll send {state: OFF, brightness: xxx}).
So, To make everything work, I used this:
[1, 'state_l1', tuya.valueConverter.onOff, {
skip: (meta) => {
const convertedKey = meta.mapped.meta.multiEndpoint && meta.endpoint_name ?
`state_${meta.endpoint_name}` : 'state';
return meta.message.hasOwnProperty('brightness') && meta.state[convertedKey] === meta.message.state;
}
}]
One issue remain : if state is not skipped, brightness is not sent (as described earlier, only the 1st property is sent). So with my code ON/OFF and dimming will work, but if you set the brightness from HA UI when the light is OFF, it will turn it ON with the previous brightness, not the new one.
I'll try to look into that later on.
: if state is not skipped, brightness is not sent (as described earlier, only the 1st property is sent). So with my code ON/OFF and dimming will work, but if you set the brightness from HA UI when the light is OFF, it will turn it ON with the previous brightness, not the new one.
I'm suprised it doesn't, could it be that brightness is set before state? All entries of the messages are iterated here (and thus should be sent)
: if state is not skipped, brightness is not sent (as described earlier, only the 1st property is sent). So with my code ON/OFF and dimming will work, but if you set the brightness from HA UI when the light is OFF, it will turn it ON with the previous brightness, not the new one.
I'm suprised it doesn't, could it be that brightness is set before state? All entries of the messages are iterated here (and thus should be sent)
It might be sent (the state.brightness is updated in optimistic mode so it reach that iteration), but the brightness is not changed on the device.
@Koenkk
I found the issue:
tuya.skip.stateOnAndBrightnessPresent
look atmeta.state.state
, instead ofmeta.state.state_l1
(or l2). Also, that skip function will skip when turning OFF the light (since we'll send {state: OFF, brightness: xxx}).So, To make everything work, I used this:
[1, 'state_l1', tuya.valueConverter.onOff, { skip: (meta) => { const convertedKey = meta.mapped.meta.multiEndpoint && meta.endpoint_name ? `state_${meta.endpoint_name}` : 'state'; return meta.message.hasOwnProperty('brightness') && meta.state[convertedKey] === meta.message.state; } }]
One issue remain : if state is not skipped, brightness is not sent (as described earlier, only the 1st property is sent). So with my code ON/OFF and dimming will work, but if you set the brightness from HA UI when the light is OFF, it will turn it ON with the previous brightness, not the new one.
I'll try to look into that later on.
Just to say, I tried this fix and it works brilliantly! Thank you all so much for your hard working in sorting this issue out. I really appreciate it!
@shamimrahim
I'm the least technical person here and was wondering if this fix would be released in the Feb version release of z2mqtt or if I need to manually make changes on my end for this to work? If the later could you help me with a screen record so I can follow your instructions on fixing this?
Thank you for helping to fix this issue.
@shamimrahim
I'm the least technical person here and was wondering if this fix would be released in the Feb version release of z2mqtt or if I need to manually make changes on my end for this to work? If the later could you help me with a screen record so I can follow your instructions on fixing this?
Thank you for helping to fix this issue.
I just added @beam-d's code to @Koenkk's external converter and restarted z2m. I can now dim the lights through homeassistant, which is amazing. I'm not that technical too, but I just followed the instructions in the previous posts.
Looking forward to the fix that solves the setting brightness directly instead of turning on first then setting brightness. Other wise, works brilliantly.
3-Gang would need a separate extender I suppose.
: if state is not skipped, brightness is not sent (as described earlier, only the 1st property is sent). So with my code ON/OFF and dimming will work, but if you set the brightness from HA UI when the light is OFF, it will turn it ON with the previous brightness, not the new one.
I'm suprised it doesn't, could it be that brightness is set before state? All entries of the messages are iterated here (and thus should be sent)
Looking at the log, I think the command is indeed sent :
Zigbee2MQTT:debug 2024-01-14 17:34:33: Received MQTT message on 'zigbee2mqtt/dimmer-office-staircase/l1/set' with data '{"state":"ON","brightness": 20}'
Zigbee2MQTT:debug 2024-01-14 17:34:33: Publishing 'set' 'brightness' to 'dimmer-office-staircase'
2024-01-14T16:34:33.189Z zigbee-herdsman:controller:endpoint Command 0xa4c138b03a8598b3/1 manuSpecificTuya.dataRequest({"seq":1,"dpValues":[{"dp":1,"datatype":1,"data":[1]}]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T16:34:33.190Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xa4c138b03a8598b3:57446/1 (0,0,1)
2024-01-14T16:34:33.190Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":57446,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":37,"options":0,"radius":30,"len":10,"data":{"type":"Buffer","data":[17,25,0,1,0,1,1,0,1,1]}}
2024-01-14T16:34:33.191Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,20,36,1,102,224,1,1,0,239,37,0,30,10,17,25,0,1,0,1,1,0,1,1,96]
2024-01-14T16:34:33.202Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2024-01-14T16:34:33.203Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2024-01-14T16:34:33.203Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2024-01-14T16:34:33.203Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2024-01-14T16:34:33.203Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.205Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,37,227]
2024-01-14T16:34:33.206Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,37,227]
2024-01-14T16:34:33.206Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,37] - 227
2024-01-14T16:34:33.206Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":37}
2024-01-14T16:34:33.206Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.208Z zigbee-herdsman:controller:endpoint Command 0xa4c138b03a8598b3/1 manuSpecificTuya.dataRequest({"seq":1,"dpValues":[{"dp":2,"datatype":2,"data":[0,0,0,79]}]}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T16:34:33.208Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xa4c138b03a8598b3:57446/1 (0,0,1)
2024-01-14T16:34:33.209Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":57446,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":38,"options":0,"radius":30,"len":13,"data":{"type":"Buffer","data":[17,26,0,1,0,2,2,0,4,0,0,0,79]}}
2024-01-14T16:34:33.209Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,23,36,1,102,224,1,1,0,239,38,0,30,13,17,26,0,1,0,2,2,0,4,0,0,0,79,47]
2024-01-14T16:34:33.221Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2024-01-14T16:34:33.221Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2024-01-14T16:34:33.222Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2024-01-14T16:34:33.222Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2024-01-14T16:34:33.222Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.226Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,38,224]
2024-01-14T16:34:33.226Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,38,224]
2024-01-14T16:34:33.226Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,38] - 224
2024-01-14T16:34:33.227Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":38}
2024-01-14T16:34:33.227Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.262Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,30,68,129,0,0,0,239,102,224,1,1,0,66,0,129,16,198,0,0,10,9,241,2,0,127,1,1,0,1,1,102,224,29,179]
2024-01-14T16:34:33.262Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,30,68,129,0,0,0,239,102,224,1,1,0,66,0,129,16,198,0,0,10,9,241,2,0,127,1,1,0,1,1,102,224,29,179]
2024-01-14T16:34:33.262Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 30 - 2 - 4 - 129 - [0,0,0,239,102,224,1,1,0,66,0,129,16,198,0,0,10,9,241,2,0,127,1,1,0,1,1,102,224,29] - 179
2024-01-14T16:34:33.263Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":61184,"srcaddr":57446,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":66,"securityuse":0,"timestamp":12980353,"transseqnumber":0,"len":10,"data":{"type":"Buffer","data":[9,241,2,0,127,1,1,0,1,1]}}
2024-01-14T16:34:33.265Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":241,"manufacturerCode":null,"commandIdentifier":2},"Payload":{"seq":32512,"dpValues":[{"dp":1,"datatype":1,"data":{"type":"Buffer","data":[1]}}]},"Command":{"ID":2,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"dataReport"}},"address":57446,"endpoint":1,"linkquality":66,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
2024-01-14T16:34:33.267Z zigbee-herdsman:controller:endpoint DefaultResponse 0xa4c138b03a8598b3/1 61184(2, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T16:34:33.267Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xa4c138b03a8598b3:57446/1 (0,0,1)
2024-01-14T16:34:33.268Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":57446,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":39,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,241,11,2,0]}}
2024-01-14T16:34:33.268Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,102,224,1,1,0,239,39,0,30,5,16,241,11,2,0,151]
2024-01-14T16:34:33.269Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:debug 2024-01-14 17:34:33: Received Zigbee message from 'dimmer-office-staircase', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":32512}' from endpoint 1 with groupID 0
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/office_light', payload '{"brightness":20,"state":"ON","state_l1":null}'
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase', payload '{"backlight_mode":"inverted","brightness_l1":20,"brightness_l2":99,"countdown_l1":0,"countdown_l2":0,"linkquality":66,"max_brightness_l1":254,"max_brightness_l2":254,"min_brightness_l1":3,"min_brightness_l2":3,"power_on_behavior":"previous","state_l1":"ON","state_l2":"ON"}'
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase/l1', payload '{"brightness":20,"countdown":0,"max_brightness":254,"min_brightness":3,"state":"ON"}'
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase/l2', payload '{"brightness":99,"countdown":0,"max_brightness":254,"min_brightness":3,"state":"ON"}'
2024-01-14T16:34:33.285Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100,254,3,68,128,0,1,39,225]
2024-01-14T16:34:33.285Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100,254,3,68,128,0,1,39,225]
2024-01-14T16:34:33.285Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2024-01-14T16:34:33.285Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2024-01-14T16:34:33.286Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,39,225]
2024-01-14T16:34:33.286Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,39] - 225
2024-01-14T16:34:33.286Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":39}
2024-01-14T16:34:33.286Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.465Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,30,68,129,0,0,0,239,102,224,1,1,0,69,0,33,66,198,0,0,10,9,242,2,0,128,1,1,0,1,1,102,224,29,186]
2024-01-14T16:34:33.466Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,30,68,129,0,0,0,239,102,224,1,1,0,69,0,33,66,198,0,0,10,9,242,2,0,128,1,1,0,1,1,102,224,29,186]
2024-01-14T16:34:33.466Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 30 - 2 - 4 - 129 - [0,0,0,239,102,224,1,1,0,69,0,33,66,198,0,0,10,9,242,2,0,128,1,1,0,1,1,102,224,29] - 186
2024-01-14T16:34:33.466Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - incomingMsg - {"groupid":0,"clusterid":61184,"srcaddr":57446,"srcendpoint":1,"dstendpoint":1,"wasbroadcast":0,"linkquality":69,"securityuse":0,"timestamp":12993057,"transseqnumber":0,"len":10,"data":{"type":"Buffer","data":[9,242,2,0,128,1,1,0,1,1]}}
2024-01-14T16:34:33.468Z zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":1,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":242,"manufacturerCode":null,"commandIdentifier":2},"Payload":{"seq":32768,"dpValues":[{"dp":1,"datatype":1,"data":{"type":"Buffer","data":[1]}}]},"Command":{"ID":2,"parameters":[{"name":"seq","type":33},{"name":"dpValues","type":1011}],"name":"dataReport"}},"address":57446,"endpoint":1,"linkquality":69,"groupID":0,"wasBroadcast":false,"destinationEndpoint":1}'
2024-01-14T16:34:33.469Z zigbee-herdsman:controller:endpoint DefaultResponse 0xa4c138b03a8598b3/1 61184(2, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false})
2024-01-14T16:34:33.470Z zigbee-herdsman:adapter:zStack:adapter sendZclFrameToEndpointInternal 0xa4c138b03a8598b3:57446/1 (0,0,1)
2024-01-14T16:34:33.470Z zigbee-herdsman:adapter:zStack:znp:SREQ --> AF - dataRequest - {"dstaddr":57446,"destendpoint":1,"srcendpoint":1,"clusterid":61184,"transid":40,"options":0,"radius":30,"len":5,"data":{"type":"Buffer","data":[16,242,11,2,0]}}
2024-01-14T16:34:33.470Z zigbee-herdsman:adapter:zStack:unpi:writer --> frame [254,15,36,1,102,224,1,1,0,239,40,0,30,5,16,242,11,2,0,155]
2024-01-14T16:34:33.471Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
Zigbee2MQTT:debug 2024-01-14 17:34:33: Received Zigbee message from 'dimmer-office-staircase', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[1],"type":"Buffer"},"datatype":1,"dp":1}],"seq":32768}' from endpoint 1 with groupID 0
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase', payload '{"backlight_mode":"inverted","brightness_l1":20,"brightness_l2":99,"countdown_l1":0,"countdown_l2":0,"linkquality":69,"max_brightness_l1":254,"max_brightness_l2":254,"min_brightness_l1":3,"min_brightness_l2":3,"power_on_behavior":"previous","state_l1":"ON","state_l2":"ON"}'
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase/l1', payload '{"brightness":20,"countdown":0,"max_brightness":254,"min_brightness":3,"state":"ON"}'
Zigbee2MQTT:info 2024-01-14 17:34:33: MQTT publish: topic 'zigbee2mqtt/dimmer-office-staircase/l2', payload '{"brightness":99,"countdown":0,"max_brightness":254,"min_brightness":3,"state":"ON"}'
2024-01-14T16:34:33.485Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,1,100,1,0,100]
2024-01-14T16:34:33.485Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,1,100,1,0,100]
2024-01-14T16:34:33.485Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 1 - 3 - 4 - 1 - [0] - 100
2024-01-14T16:34:33.485Z zigbee-herdsman:adapter:zStack:znp:SRSP <-- AF - dataRequest - {"status":0}
2024-01-14T16:34:33.486Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
2024-01-14T16:34:33.487Z zigbee-herdsman:adapter:zStack:unpi:parser <-- [254,3,68,128,0,1,40,238]
2024-01-14T16:34:33.487Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext [254,3,68,128,0,1,40,238]
2024-01-14T16:34:33.487Z zigbee-herdsman:adapter:zStack:unpi:parser --> parsed 3 - 2 - 4 - 128 - [0,1,40] - 238
2024-01-14T16:34:33.487Z zigbee-herdsman:adapter:zStack:znp:AREQ <-- AF - dataConfirm - {"status":0,"endpoint":1,"transid":40}
2024-01-14T16:34:33.487Z zigbee-herdsman:adapter:zStack:unpi:parser --- parseNext []
@beam-d we probably need a delay between state and brightness. Can you check with https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816 . If it works reduce the sleep in await utils.sleep(1000); // <- added this
as low as possible, the value is in ms
@beam-d we probably need a delay between state and brightness. Can you check with https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816 . If it works reduce the sleep in
await utils.sleep(1000); // <- added this
as low as possible, the value is in ms
I tried this new converter and got this error when I tried to turn on the dimmer:
"'TypeError: utils.sendDataPointBool is not a function'"
You have to redownload the latest Edge build.
On Wed, Jan 17, 2024, 07:34 shamimrahim @.***> wrote:
@beam-d https://github.com/beam-d we probably need a delay between state and brightness. Can you check with https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816 . If it works reduce the sleep in await utils.sleep(1000); // <- added this as low as possible, the value is in ms
I tried this new converter and got this error when I tried to turn on the dimmer:
"'TypeError: utils.sendDataPointBool is not a function'"
β Reply to this email directly, view it on GitHub https://github.com/Koenkk/zigbee2mqtt/issues/19874#issuecomment-1895063374, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2GR5HDPOUHSWN6JFEDPUDYO5WIRAVCNFSM6AAAAAA72ZBKLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGA3DGMZXGQ . You are receiving this because you commented.Message ID: @.***>
You have to redownload the latest Edge build. β¦ On Wed, Jan 17, 2024, 07:34 shamimrahim @.> wrote: @beam-d https://github.com/beam-d we probably need a delay between state and brightness. Can you check with https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816 . If it works reduce the sleep in await utils.sleep(1000); // <- added this as low as possible, the value is in ms I tried this new converter and got this error when I tried to turn on the dimmer: "'TypeError: utils.sendDataPointBool is not a function'" β Reply to this email directly, view it on GitHub <#19874 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC2GR5HDPOUHSWN6JFEDPUDYO5WIRAVCNFSM6AAAAAA72ZBKLSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQOJVGA3DGMZXGQ . You are receiving this because you commented.Message ID: @.>
I just tried with latest edge version and am getting the same error.
Pushed a fix to latest edge and updated https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816, should work now.
Changes will be available in the dev branch in a few hours from now.
@beam-d we probably need a delay between state and brightness. Can you check with https://gist.github.com/Koenkk/3e55da9665e4a50570af7bff210f5816 . If it works reduce the sleep in
await utils.sleep(1000); // <- added this
as low as possible, the value is in ms
I've tried with a delay and it seems the light need to be completely ON, which can take more than 5 seconds for full light.
So with utils.sleep(5000)
it works?
So with
utils.sleep(5000)
it works?
Yes, though from what I see, the issue is not so much that it cannot handle two commands at once, but specifically that setting the brightness doesn't work until the light is ON. Basically :
I can do this
(init state is OFF) -> send {state: ON} -> wait completely ON (up to 5 secs) -> send {brightness: 254}
or
(init state is ON) -> wait completely ON (up to 5 secs) -> send {brightness: 254} -> wait 1s -> send {brightness: 25}
What doesn't work is
(init state is ON, brightness: 50) -> send {brightness: 254} -> send {state: OFF} -> wait completely OFF (up to 5 secs) -> send {state: ON}
(init state is ON, last brightness: 50) -> send {state: ON} -> send {brightness: 254} -> wait completely ON
So the observed behaviour is the following:
When sending {state: "ON"}
, even if the light is already on, the device enter a "powering ON" state that:
When the light is OFF (or during powering OFF), changing the brightness will modify the dp value, but after turning ON, the brightness will the previous one, but in this case, subsequent updates to brightness you will work (given that you wait the 5s after the ON).
@beam-d then I propose the following, after setting the state
we wait 5 seconds until executing the next command, for brightness
1 second. Would that fix it?
@beam-d then I propose the following, after setting the
state
we wait 5 seconds until executing the next command, forbrightness
1 second. Would that fix it?
Can we store the last time state was changed ? If we want to cover all cases (state changed by command or physical button), we would need something like this:
Note that we can do that separately for l1 & l2. BTW, the delay varies with the brightness, so at full brightness, we need more than 5s. I'd put 10s to be sure.
But we also need to wait between brightness changes if I understand correctly? E.g. if you sent brightness 200, and 2 seconds after that brightness 100, it won't be applied?
Thank you guys for trying so hard with this device (1,3 and 3 gang). I made a huge mistake buying those for whole apartment. Very bad devices. 5 sec transition to turn lights on/off. Min/max brightness trim is useless (3 seconds delay to first light... driving me mad). And no OTA so no hope for firmware fix.
I'm afraid that if you dont manage to do some magic here, they are going to garbage.
Thank you guys for trying so hard with this device (1,3 and 3 gang). I made a huge mistake buying those for whole apartment. Very bad devices. 5 sec transition to turn lights on/off. Min/max brightness trim is useless (3 seconds delay to first light... driving me mad). And no OTA so no hope for firmware fix.
I'm afraid that if you dont manage to do some magic here, they are going to garbage.
I'm in a similar situation, ordered 1000 units to install into a few homes I'm building, fortunately the 1 Gang dimmer switch operates flawlessly with no issues, but the 2 & 3 gang dimmer switches are the two with issues in home assistant.
Amateur question here but why can't the values/setting from the 1 gang copy over to the 2&3 gang?
@Koenkk - I have a direct line to the Moes Factory because I order in bulk direct and have a relationship with the team, is there any feedback/questions the developers would like me to pass on to the factory to help solve the issue?
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition?
But we also need to wait between brightness changes if I understand correctly? E.g. if you sent brightness 200, and 2 seconds after that brightness 100, it won't be applied?
Nope, no brightness commands are applied directly, even if brightness is still "moving". Only the "powering ON" state cause issues.
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition?
Startup is also long (although shorter - about 5/6s), and brightness cannot be changed during that startup, but sending a brightness command during startup doesn't break subsequent commands.
Also, I'm wondering if it is something that only happens in home-assistant (ZHA integration has the same issues), or if the issue is the same with the tuya/moes gateway (and if there are other options with their gateway).
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition? @dankocrnkovic @beam-d
The 1 gang works flawlessly, quick to respond and no flickering. I recorded a video. Here is the youtube link to all my tests.
1 Gang - Z2MQTT - https://www.youtube.com/watch?v=2hAR3m4skjM 3 Gang - Z2MQTT - https://www.youtube.com/watch?v=FaaTukYTA1s 3 Gang - Z2MQTT Edge - https://www.youtube.com/watch?v=aemoQ6B8Et4
I also tested the 1,2 & 3 Gang on the Moes/Tuya Homebridge Zigbee Hub and they worked as expected, however the 3 Gang was slow to turning of the light when it was on 100% brightness. Startup was operating normally. https://www.youtube.com/watch?v=DT84vz1DtJE
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition? @dankocrnkovic @beam-d
The 1 gang works flawlessly, quick to respond and no flickering. I recorded a video. Here is the youtube link to all my tests.
1 Gang - Z2MQTT - https://www.youtube.com/watch?v=2hAR3m4skjM 3 Gang - Z2MQTT - https://www.youtube.com/watch?v=FaaTukYTA1s 3 Gang - Z2MQTT Edge - https://www.youtube.com/watch?v=aemoQ6B8Et4
I also tested the 1,2 & 3 Gang on the Moes/Tuya Homebridge Zigbee Hub and they worked as expected, however the 3 Gang was slow to turning of the light when it was on 100% brightness. Startup was operating normally.
From what I observed, the only difference is that the 1 gang has faster ON/OFF transitions (about 2x faster) and doesn't flicker at the end of those. But you cannot change the brightness until fully ON (in particular, turning on at a specific brightness in HA will not work and use the previous brightness).
for the transition speed I don't think we can do anything about it (unless it is somehow configurable, I suppose we would need someone with the tuya gateway to check).
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition? @dankocrnkovic @beam-d
The 1 gang works flawlessly, quick to respond and no flickering. I recorded a video. Here is the youtube link to all my tests. 1 Gang - Z2MQTT - https://www.youtube.com/watch?v=2hAR3m4skjM 3 Gang - Z2MQTT - https://www.youtube.com/watch?v=FaaTukYTA1s 3 Gang - Z2MQTT Edge - https://www.youtube.com/watch?v=aemoQ6B8Et4 I also tested the 1,2 & 3 Gang on the Moes/Tuya Homebridge Zigbee Hub and they worked as expected, however the 3 Gang was slow to turning of the light when it was on 100% brightness. Startup was operating normally.
From what I observed, the only difference is that the 1 gang has faster ON/OFF transitions (about 2x faster) and doesn't flicker at the end of those. But you cannot change the brightness until fully ON (in particular, turning on at a specific brightness in HA will not work and use the previous brightness).
for the transition speed I don't think we can do anything about it (unless it is somehow configurable, I suppose we would need someone with the tuya gateway to check).
Hi, I tested the 1 Gang in particular turning on by the brightness bar in HA and it works. No need to turn the light On first then adjust brightness. https://www.youtube.com/watch?v=00WPSjvyCcc
I also tested the 1,2 & 3 Gang on the Moes/Tuya Homebridge Zigbee Hub and they worked as expected, however the 3 Gang was slow to turning of the light when it was on 100% brightness. Startup was operating normally. https://www.youtube.com/watch?v=DT84vz1DtJE
@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition? @dankocrnkovic @beam-d
The 1 gang works flawlessly, quick to respond and no flickering. I recorded a video. Here is the youtube link to all my tests. 1 Gang - Z2MQTT - https://www.youtube.com/watch?v=2hAR3m4skjM 3 Gang - Z2MQTT - https://www.youtube.com/watch?v=FaaTukYTA1s 3 Gang - Z2MQTT Edge - https://www.youtube.com/watch?v=aemoQ6B8Et4 I also tested the 1,2 & 3 Gang on the Moes/Tuya Homebridge Zigbee Hub and they worked as expected, however the 3 Gang was slow to turning of the light when it was on 100% brightness. Startup was operating normally.
From what I observed, the only difference is that the 1 gang has faster ON/OFF transitions (about 2x faster) and doesn't flicker at the end of those. But you cannot change the brightness until fully ON (in particular, turning on at a specific brightness in HA will not work and use the previous brightness). for the transition speed I don't think we can do anything about it (unless it is somehow configurable, I suppose we would need someone with the tuya gateway to check).
Hi, I tested the 1 Gang in particular turning on by the brightness bar in HA and it works. No need to turn the light On first then adjust brightness. https://www.youtube.com/watch?v=00WPSjvyCcc
Kinda hard to see on your video, but what happen if you do : ON -> 10% -> OFF -> 90% Does it turn ON at 10% or 90% ?
Yes it work with this test
ON -> 10% -> OFF -> 90% Does it turn ON at 10% or 90% ?
Ok that's weird, because I'd get 10% doing that.
Just to be sure, can you check the version ?
Zigbee Model TS0601 Zigbee Manufacturer _TZE204_hlx9tnzb Description Star ring smart dimmer switch 1 gang
Ok that's weird, because I'd get 10% doing that.
Just to be sure, can you check the version ?
Zigbee Model TS0601
Zigbee Manufacturer _TZE204_hlx9tnzb
Description Star ring smart dimmer switch 1 gang
Looks like we have the same model. I posted an image of the models at the beginning of this thread.
Very interesting. I get very slow On on 1 gang also (5/6 sec). With HA, Z2M and physically on switch. And always it flickers at the end of long transition. Zigbee Model TS0601 Zigbee Manufacturer _TZE204_hlx9tnzb Description Star ring smart dimmer switch 1 gang Model ZS-SR-EUD-1
maybe we have different firmware version on the device... can you both check in dev console like in my screenshot (not sure how much that will tell).
And since it seem to work better with the moes gateway, I think I'll have to get one to try and figure it out...
Mine is just not reporting anything after clicking read.
maybe we have different firmware version on the device... can you both check in dev console like in my screenshot (not sure how much that will tell).
And since it seem to work better with the moes gateway, I think I'll have to get one to try and figure it out...
https://www.youtube.com/watch?v=CR2Nt6tZ1II
https://www.youtube.com/watch?v=LKoqv_G9jaI
A few more recordings
What happened?
https://github.com/Koenkk/zigbee2mqtt/issues/18650
What did you expect to happen?
The 1 Gang Version of this switch works flawlessly. Can the settings be replicated for the 2 & 3 Gang switches to fixt this issue?
How to reproduce it (minimal and precise)
No response
Zigbee2MQTT version
1.33.2-1
Adapter firmware version
Latests version
Adapter
Skyconnect
Debug log
2Gang Dimmer Switch - Turn on frontend dim does not work.txt 2Gang Dimmer Switch - Turn on physically - dim works.txt