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

demcas · 2023-11-26T11:21:07Z

What happened?

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 · 2023-11-26T17:43:25Z

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

demcas · 2023-11-27T12:20:50Z

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 · 2023-11-27T12:21:53Z

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 · 2023-12-16T03:33:15Z

@kirovilya hi, can you assist?

kirovilya · 2023-12-16T07:42:50Z

@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

demcas · 2023-12-16T09:01:29Z

@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 · 2023-12-16T09:03:31Z

kirovilya · 2023-12-17T08:59:03Z

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 · 2023-12-17T10:00:29Z

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 · 2024-01-05T01:08:06Z

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

demcas · 2024-01-05T03:57:57Z

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 · 2024-01-11T22:01:42Z

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 · 2024-01-11T22:12:24Z

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 · 2024-01-13T13:22:21Z

@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 · 2024-01-13T15:08:08Z

@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 · 2024-01-13T20:35:34Z

@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 · 2024-01-13T20:44:34Z

: 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 · 2024-01-13T20:53:25Z

: 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 · 2024-01-13T21:53:16Z

@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 · 2024-01-14T00:47:12Z

@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 · 2024-01-14T14:30:19Z

@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 · 2024-01-14T16:03:06Z

3-Gang would need a separate extender I suppose.

beam-d · 2024-01-14T17:24:57Z

: 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 · 2024-01-15T19:29:43Z

@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 · 2024-01-17T06:34:38Z

@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 · 2024-01-17T07:22:54Z

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

shamimrahim · 2024-01-17T18:45:45Z

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.

alectogeek · 2024-02-23T12:39:02Z

To summarize:

the dimmers of all three gangs can be controlled from HA UI, right?
it is not possible to turn on the light setting specific brightness for 2nd/3rd gang. It will turn on to the latest brightness level and after 5 seconds will change its brightness to one that we set from HA UI, right?
1 gang version works flawlessly and behaves as expected without any issues, right?

I was going to buy 2/3 gang versions of this dimmer switch. But the ability to turn on the light at a specific brightness is crucial for me.

beam-d · 2024-02-23T14:05:34Z

To summarize:

* the dimmers of all three gangs can be controlled from HA UI, right?

* it is not possible to turn on the light setting specific brightness for 2nd/3rd gang. It will turn on to the latest brightness level and after 5 seconds will change its brightness to one that we set from HA UI, right?

* 1 gang version works flawlessly and behaves as expected without any issues, right?

I was going to buy 2/3 gang versions of this dimmer switch. But the ability to turn on the light at a specific brightness is crucial for me.

FYI I've done some testing with a moes / tuya smart gateway, and it seem that those devices simply don't support setting luminosity while off (that's the same for the 1 gang btw). So it's not specific to HA or z2mqtt

ncodee · 2024-02-23T15:19:23Z

To summarize:
* the dimmers of all three gangs can be controlled from HA UI, right?

* it is not possible to turn on the light setting specific brightness for 2nd/3rd gang. It will turn on to the latest brightness level and after 5 seconds will change its brightness to one that we set from HA UI, right?

* 1 gang version works flawlessly and behaves as expected without any issues, right?
I was going to buy 2/3 gang versions of this dimmer switch. But the ability to turn on the light at a specific brightness is crucial for me.
FYI I've done some testing with a moes / tuya smart gateway, and it seem that those devices simply don't support setting luminosity while off (that's the same for the 1 gang btw). So it's not specific to HA or z2mqtt

Do you think that is something that can be added by an firmware update, or is it a hardware limitation? Might be a good idea for someone to get in contact with Moes and try to get these issues resolved once and for all.

demcas · 2024-03-04T23:59:06Z

To summarize:

the dimmers of all three gangs can be controlled from HA UI, right?

it is not possible to turn on the light setting specific brightness for 2nd/3rd gang. It will turn on to the latest brightness level and after 5 seconds will change its brightness to one that we set from HA UI, right?

1 gang version works flawlessly and behaves as expected without any issues, right?

I was going to buy 2/3 gang versions of this dimmer switch. But the ability to turn on the light at a specific brightness is crucial for me.

To summarize:

the dimmers of all three gangs can be controlled from HA UI, right? Yes
it is not possible to turn on the light setting specific brightness for 2nd/3rd gang. It will turn on to the latest brightness level and after 5 seconds will change its brightness to one that we set from HA UI, right? I am experiencing the same but mine adjusts and responds within a second.
1 gang version works flawlessly and behaves as expected without any issues, right? Correct
I was going to buy 2/3 gang versions of this dimmer switch. But the ability to turn on the light at a specific brightness is crucial for me. You need to turn the light on and then adjust the brightness. you can turn the light on via the brightness bar in HA UI but it still triggers the previous brightness state and then after a few seconds it adjusts itself

beam-d · 2024-03-05T10:33:33Z

Do you think that is something that can be added by an firmware update, or is it a hardware limitation? Might be a good idea for someone to get in contact with Moes and try to get these issues resolved once and for all.

Probably not something limited by the hardware, thought it might be a limitation of their mcu / tuya module, or it could just not be updatable. Anyway it is worth asking I suppose. Also we should ask them if they can reduce the on/off fade duration (or make a configuration).

demcas · 2024-03-30T22:52:25Z

This minor issue hasn't yet been resolved but it's not that much of a big deal. The lights switch still operates but if you turn on the light with the dimmer scroll bar it turns on with the previous brightness setting and with a double tap it quickly adjusts up to your desired level.

gregoriusus · 2024-04-09T21:27:26Z

I installed Moes Star Ring 2gang ZS-SR-EUD-2. It is working, but it is spamming network:
Received Zigbee message from 'bathroom1_lights', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[215,224,206,130],"type":"Buffer"},"datatype":2,"dp":20}],"seq":1792}' from endpoint 1 with groupID 0

Anyone find this issue?

demcas · 2024-05-02T22:46:41Z

I installed Moes Star Ring 2gang ZS-SR-EUD-2. It is working, but it is spamming network:

Received Zigbee message from 'bathroom1_lights', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[215,224,206,130],"type":"Buffer"},"datatype":2,"dp":20}],"seq":1792}' from endpoint 1 with groupID 0

Anyone find this issue?

I'm not experiencing any spamming. My logs only trigger when the switch is used.

Maeldor · 2024-05-03T07:45:23Z

I installed Moes Star Ring 2gang ZS-SR-EUD-2. It is working, but it is spamming network: Received Zigbee message from 'bathroom1_lights', type 'commandDataReport', cluster 'manuSpecificTuya', data '{"dpValues":[{"data":{"data":[215,224,206,130],"type":"Buffer"},"datatype":2,"dp":20}],"seq":1792}' from endpoint 1 with groupID 0

Anyone find this issue?

I get this too, but just a standard state update as if a button was pressed. It spams about every second. It only seems to happen with the dimmers. I have a 2-gang non dimmer version and it behaves fine.

I find it does it if it loses power. I was doing maintenance yesterday and turned the power off. When I turned it back on, all of these switches spam the log every second.

The only way to stop it is to remove each switch from Zigbee2mqtt and allow them to immediately rejoin, which then requires renaming them back to what they were before.

It's a right pain. I'm not looking forward to power cuts when I'm away. To be honest I regret buying these. They've been nothing but hassle and a buggy mess. Sometimes their state doesn't match what they're physically doing, e.g. I'll find a light left on which is showing as off in HA and Zigbee2mqtt.

I wish there was a firmware update for them, or a custom firmware option, because they're nice switches otherwise. I don't know any decent alternatives in the UK.

neyzm · 2024-05-08T11:12:00Z

It's a right pain. I'm not looking forward to power cuts when I'm away. To be honest I regret buying these. They've been nothing but hassle and a buggy mess. Sometimes their state doesn't match what they're physically doing, e.g. I'll find a light left on which is showing as off in HA and Zigbee2mqtt.

I wish there was a firmware update for them, or a custom firmware option, because they're nice switches otherwise. I don't know any decent alternatives in the UK.

They are indeed nice switches, but I'd returned mine as they're too much trouble than it's worth. Very noticeable lag on the 3 way switch, or no response at all. Also, my unit was listed as 'No neutral in the manual and box, but later found out it indeed requires a neutral wire, which is very misleading. As majority UK light switches have no-neutral wire, this was pretty much useless to me.

So far I haven't found any dimmable zigbee based alternative, and will be just reverting back to smart bulbs instead for the time-being.

alectogeek · 2024-06-06T17:29:00Z

I compared this 3 gang switch to 1 gang switch (model EDM-1ZBB-EU) and the 3 gang switch is complete trash. It is too slow and laggy. I'm comparing it to the first gang and as mentioned above second and third gangs are even worse.

Does anyone have any multi-gang alternatives? Or should I go with single gang versions everywhere? I'll have to place many switches in a row on my walls...

Here is a video of a comparison (I hope you can see the difference. I have no idea how to show it on video properly tbh).

https://youtu.be/pB8Kce_wjyQ

gregoriusus · 2024-06-16T22:33:59Z

I also found out that, when using in automation, it doesn't turn on, if I set brightness_pct. Anyone has same issue?

miloumeeloo · 2024-06-25T12:08:48Z

I also found out that, when using in automation, it doesn't turn on, if I set brightness_pct. Anyone has same issue?

Same issue. I managed to get around this problem by adding 2 actions in automation. The first by setting the desired brightness (which will not turn on the light) and the second without any option (which will turn on the light at the brightness defined in the first one). Doesn't work if the light is already on or for transition.

gregoriusus · 2024-06-25T12:37:37Z

How do you set brightness? I cannot see entity?

miloumeeloo · 2024-06-25T12:54:41Z

How do you set brightness? I cannot see entity?

Use the Light "Turn on" action, select your switch as an entity and check the brightness option.

BillyMichael · 2024-08-06T14:01:03Z

I'm also struggling with XM-105-M-MS. It's continually spamming the logs and won't allow me to update the brightness from anything that isn't either the lowest or highest values.

gregoriusus · 2024-08-26T19:01:14Z

When I use brightness or brightness_pct, it even doesn't turn on.... Anyone successfully set brightness from automation on this Moes Star ring?

gregoriusus · 2024-08-26T19:03:02Z

I also found out that, when using in automation, it doesn't turn on, if I set brightness_pct. Anyone has same issue?

Same issue. I managed to get around this problem by adding 2 actions in automation. The first by setting the desired brightness (which will not turn on the light) and the second without any option (which will turn on the light at the brightness defined in the first one). Doesn't work if the light is already on or for transition.

Can you please describe more in detail how you did it or paste yaml. Thank you.

miloumeeloo · 2024-09-02T11:36:42Z

Can you please describe more in detail how you did it or paste yaml. Thank you.

Simply add 2 actions in a row in your automation.
The first one for setting the brightness:

metadata: {}
data:
  brightness_pct: 50 # your desired brightness here
target:
  entity_id: light.your_id # replace with your light entity id
action: light.turn_on

The second one for turning the light on:

metadata: {}
data: {}
target:
  entity_id: light.your_id
action: light.turn_on

gregoriusus · 2024-09-02T12:02:17Z

A, I see... First action will set brightness but will not turn on light. Second action will. Clever 😉👍

gregoriusus · 2024-11-06T00:40:10Z

For me, it is not working. I have to turn light on, wait 7 seconds, then set brightness.

gregoriusus · 2024-11-06T01:08:27Z

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

@shamimrahim how did you apply this fix?

gregoriusus · 2024-11-06T20:56:49Z

I just tried Moes 2 Gang Dimmer Switch and it just works. Why didn't they use hardware from this switch for Star Ring and just add buttons :-)

miloumeeloo · 2024-12-01T15:10:52Z

For me, it is not working. I have to turn light on, wait 7 seconds, then set brightness.

I also had to invert all my automations in HA. Setting the brightness before turning on the light doesn't work anymore.
This requires adding a delay between actions to let the light first reach the previous brightness state before setting the new one (due to this default transition effect, I guess). [Z2M v1.41.0-1]

github-actions · 2025-01-31T00:03:20Z

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

gregoriusus · 2025-01-31T06:48:15Z

Anyone wants to buy Star Ring Dimmable 2 & 3 Gang Switch? They are still in the box.

fifibest · 2025-02-02T23:19:57Z

Same issue with brightness on poweri on is also present in Homekit as well, via Homebridge.

Also, I have a different variant: “Star ring smart dimmer switch 2 gangs”, model is ZS-SR-EUD2.

Can this be fixed?

demcas added the problem Something isn't working label Nov 26, 2023

kirovilya mentioned this issue Dec 20, 2023

WIP feat: Tuya datapoints modernExtend Koenkk/zigbee-herdsman-converters#6733

Merged

Koenkk mentioned this issue Jan 13, 2024

[New device support]: MOES Star Ring ZigBee Smart Dimmer Switch Dimmable 1-3Gang #18650

Closed

DNAngelX mentioned this issue Mar 2, 2024

MOES 2 Gang Dimmer (undefined) since V1.8.25; MS-105BZ; Zigbee V1.9.6 ioBroker/ioBroker.zigbee#2040

Closed

github-actions bot added the stale Stale issues label Jan 31, 2025

github-actions bot removed the stale Stale issues label Feb 1, 2025

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

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

Comments

demcas commented Nov 26, 2023

What happened?

What did you expect to happen?

How to reproduce it (minimal and precise)

Zigbee2MQTT version

Adapter firmware version

Adapter

Debug log

dankocrnkovic commented Nov 26, 2023

demcas commented Nov 27, 2023

demcas commented Nov 27, 2023

demcas commented Dec 16, 2023

kirovilya commented Dec 16, 2023

demcas commented Dec 16, 2023 • edited Loading

demcas commented Dec 16, 2023

kirovilya commented Dec 17, 2023

demcas commented Dec 17, 2023

ncodee commented Jan 5, 2024

demcas commented Jan 5, 2024

beam-d commented Jan 11, 2024

demcas commented Jan 11, 2024

Koenkk commented Jan 13, 2024

kvn1351 commented Jan 13, 2024 • edited Loading

beam-d commented Jan 13, 2024 • edited Loading

Koenkk commented Jan 13, 2024

beam-d commented Jan 13, 2024 • edited Loading

shamimrahim commented Jan 13, 2024

demcas commented Jan 14, 2024

shamimrahim commented Jan 14, 2024

kvn1351 commented Jan 14, 2024

beam-d commented Jan 14, 2024

Koenkk commented Jan 15, 2024 • edited Loading

shamimrahim commented Jan 17, 2024

kvn1351 commented Jan 17, 2024 via email

shamimrahim commented Jan 17, 2024

alectogeek commented Feb 23, 2024

beam-d commented Feb 23, 2024

ncodee commented Feb 23, 2024

demcas commented Mar 4, 2024

beam-d commented Mar 5, 2024

demcas commented Mar 30, 2024

gregoriusus commented Apr 9, 2024

demcas commented May 2, 2024

Maeldor commented May 3, 2024

neyzm commented May 8, 2024

alectogeek commented Jun 6, 2024

gregoriusus commented Jun 16, 2024

miloumeeloo commented Jun 25, 2024 • edited Loading

gregoriusus commented Jun 25, 2024

miloumeeloo commented Jun 25, 2024

BillyMichael commented Aug 6, 2024

gregoriusus commented Aug 26, 2024

gregoriusus commented Aug 26, 2024

miloumeeloo commented Sep 2, 2024

gregoriusus commented Sep 2, 2024

gregoriusus commented Nov 6, 2024

gregoriusus commented Nov 6, 2024

gregoriusus commented Nov 6, 2024 • edited Loading

miloumeeloo commented Dec 1, 2024 • edited Loading

github-actions bot commented Jan 31, 2025

gregoriusus commented Jan 31, 2025 • edited Loading

fifibest commented Feb 2, 2025

demcas commented Dec 16, 2023 •

edited

Loading

kvn1351 commented Jan 13, 2024 •

edited

Loading

beam-d commented Jan 13, 2024 •

edited

Loading

beam-d commented Jan 13, 2024 •

edited

Loading

Koenkk commented Jan 15, 2024 •

edited

Loading

miloumeeloo commented Jun 25, 2024 •

edited

Loading

gregoriusus commented Nov 6, 2024 •

edited

Loading

miloumeeloo commented Dec 1, 2024 •

edited

Loading

gregoriusus commented Jan 31, 2025 •

edited

Loading