MOES Star Ring Dimmable 2 & 3 Gang Switch - Dimming is not working from HA HUI

[demcas]

What happened?

https://github.com/Koenkk/zigbee2mqtt/issues/18650

• On the HA HUi light cards, only the on/off works function is working, dimming does not work.
• The dimmer light card on HA HUI displays the dimming value change and replicates this on the Z2M GUI, but the light does not dim.
• Z2M GUI, Dimming does work but only if you light is switched on from this screen. If the light was powered on via the physical switch the dimming function works intermittently on the Z2M GUI.

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

[dankocrnkovic]

I can confirm this issue. 1 Gang dimmer is working fine, but 2 gang, diming is not working.

[demcas]

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

[demcas]

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?

[demcas]

@kirovilya hi, can you assist?

[kirovilya]

@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]

@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.

[demcas]

[kirovilya]

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}'

[demcas]

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.

[ncodee]

Just checking, has the latest commit fixed the issue with the 2-3 gang switches?

[demcas]

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.

[beam-d]

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 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 :

1. Only the state is send, not the brightness
2. 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...

[demcas]

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 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 :

1. Only the state is send, not the brightness

2. 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

[Koenkk]

@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 as ext_converter.js
• add it to configuration.yaml:

external_converters:
  - ext_converter.js

• start z2m, check if issue is fixed

[kvn1351]

@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 as ext_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.

[beam-d]

@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.

[Koenkk]

: 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)

[beam-d]

: 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.

[shamimrahim]

@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.

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!

[demcas]

@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]

@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.

[kvn1351]

3-Gang would need a separate extender I suppose.

[beam-d]

: 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 []

[Koenkk]

@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

[shamimrahim]

@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'"

[kvn1351]

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: @.***>

[shamimrahim]

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.

[Koenkk]

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]

@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.

[Koenkk]

So with utils.sleep(5000) it works?