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

demcas commented 7 months ago

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 commented 7 months ago

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

demcas commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

@kirovilya hi, can you assist?

kirovilya commented 6 months ago

@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 commented 6 months ago

@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 commented 6 months ago

![Uploading IMG_4805.jpeg…]()

kirovilya commented 6 months ago

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 commented 6 months ago

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 commented 6 months ago

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

demcas commented 6 months ago

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 commented 5 months ago

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 :

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

demcas commented 5 months ago

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 :

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

Koenkk commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

: 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 commented 5 months ago

: 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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

3-Gang would need a separate extender I suppose.

beam-d commented 5 months ago

: 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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

So with utils.sleep(5000) it works?

beam-d commented 5 months ago

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}

brightness change to 25 even if the previous change wasn't completed

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}

brightness is still 50

(init state is ON, last brightness: 50) -> send {state: ON} -> send {brightness: 254} -> wait completely ON

brightness is still 50

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:

always last about 5s (there is a slight flicker at the end)
will not respond to changes brightness -- will still change the value of the dp for brightness (at least according to incoming messages from the device) -- will not apply any subsequent change of the brightness afterwards until turned off an on again (though the dp value still change on the device) - not even the physical switch will work for brightness

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

Koenkk commented 5 months ago

@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 commented 5 months ago

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

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:

when the state is changed => store current time
when a command to brightness is sent, and currentTime - lastChangeTime < 10s => wait

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.

Koenkk commented 5 months ago

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?

dankocrnkovic commented 5 months ago

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.

demcas commented 5 months ago

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?

dankocrnkovic commented 5 months ago

@demcas you don't have issue with long startup (transition) on 1 gang, and short flicker at the end of transition?

beam-d commented 5 months ago

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 commented 5 months ago

@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

beam-d commented 5 months ago

@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 commented 5 months ago

@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

demcas commented 5 months ago

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

beam-d commented 5 months ago

@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% ?

demcas commented 5 months ago

Yes it work with this test

ON -> 10% -> OFF -> 90% Does it turn ON at 10% or 90% ?

beam-d commented 5 months ago

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

demcas commented 5 months ago

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.

dankocrnkovic commented 5 months ago

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

beam-d commented 5 months ago

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

dankocrnkovic commented 5 months ago

Mine is just not reporting anything after clicking read.

demcas commented 5 months ago

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

Koenkk / zigbee2mqtt