[OBSOLETE] Moes 2 and 3 gang Zigbee wall switch ( cluster EF00)

@Andrew4
Unfortunately, dimmers are not supported by my DTH.

Hi @ygerlovin,

Thank you for the advice. Regarding the toggle option in automation, my virtual switches are working as expected after using two separate rules.

I have installed the virtual things edge driver, and I’ve created some virtual switches for controlling the devices via Google Home. Something that I couldn’t manage was to make a rule that “refreshes” the status of the virtual switch if I manually press the button. It’s frustrating to see the device as “On” in the Google Home app if the lamp is off.

As you mentioned, I tried creating another two rules for refreshing the status, but somehow it is triggering the other first two rules for the virtual switches.

About the possibility of managing the backlight in routines, unfortunately, it’s not working. If I change the backlight mode from the multi-gang switch page, it works as expected. But when trying to create a rule, when I hit the save button, I get the following error: “There was a connection problem. Try it again later”. Please check the screenshot of the routine.

Hi @iwry

I’m pretty sure I tested it during development, but I will retest it again. Could be an issue with recent hub updates. What fw version do you have installed on your hub?

I would suggest first to test the backlight automation with virtual switch and see how it goes. I will also try to test it on my side

Regards

Hi @iwry,

Some updates.
I have 42.00007 installed on my hub.
I have 2 gangs Tuya module (not Moes), which is very similar to Moes switch.
I created a virtual switch “vSwitch Gang1” to control switch1 on Tuya module.
Then I created 4 routines:
Tuya switch1, vGang1 On - if switch1 on Tuya is On - turn vGang1 on
Tuya switch1, vGang1 Off - if switch1 on Tuya is Off - turn vGang1 off
vGang1, Tuya switch1 On - if vGang1 is on - turn on switch1 on Tuya
vGang1, Tuya switch1 Off - if vGang1 is on - turn on switch1 off Tuya

Tuya switch1, vGang1 On looks like this.


The IF statement is for switch1 (gang1).

4 routines for a single gang seems to be working fine, even though with a slight delay. One thing to mention, I always wait for the previous operation to complete, before sending a new command.
Could you please check that you are creating routines the same?

Thanks

1 Like

@ygerlovin

Thank you for sharing your setup. I was probably doing something wrong unconsciously because I did recreate the 4 rules and it is working now.

About the hub, I also have the version 42.00007 installed on my hub.

I tried using a virtual routine but I’m getting the same error. Please check the screenshot below.

Hi @iwry,

Thank you for testing.

Cool, I’m glad it works now.

I don’t have a touch panel connected right now, but I was able to reproduce the error with another my custom capability (power on state).
I probably doing something wrong when defining my capabilities.
I will keep you updated

1 Like

Another question, will the edge driver be compatible with the 3 gangs and 4 gangs switches?

I can test for the 3 gangs if needed. (My 4 gangs switch burned out today :sleepy:)

Another comment, not really sure if it is possible, it would be great if we could rename Switch1 and Switch2 on the main page.

Moes 3 gangs should be working, even though I never tested 3 gangs modules.

I think a change request for this was opened a couple of months ago. Not sure whether ST team is planning to implement this

1 Like

Hi @ygerlovin I have a few updates.

I’m getting an “Open” and “Closed” status on the virtual devices. This impacts on the security system of smartthings for example.

Also in Google Home I get the status open and closed instead of on and off. And when I hit button an error occurs. (With voice command it is working)

About the moes 3 gangs I could add the device and it was recognized as 3 gangs but buttons were not working. And now the device got disconnected. I will try again tomorrow and I’ll collect logs if it fails.

@iwry

This is the current behaviour of virtual switch. Virtual switch was designed to serve as routine trigger in Alexa ( in addition to other things) and Alexa does not allow this for regular switches. Hence a hiden contact sensor capability was added to vSwitch.
There is a feature request in virtual switch driver thread tor this

And there is ongoing discussion how to solve this

@iwry

To investigate the error I will need a log from both drivers

Hello @ygerlovin ,

Please find log dump for Moes 1 gang with the off vs on command data

application: 42
endpointId: 01
manufacturer: _TZE200_amp6tsvy
model: TS0601

- ON COMMAND -
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350F04000102, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 35, 0F, 04, 00, 01, 02], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350F04000102
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350F04000102
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00340E04000100, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 34, 0E, 04, 00, 01, 00], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00340E04000100
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00340E04000100
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00330101000101, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 33, 01, 01, 00, 01, 01], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00330101000101
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:52:44 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00330101000101

- OFF COMMAND -
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00370F04000102, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 37, 0F, 04, 00, 01, 02], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00370F04000102
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00370F04000102
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00360E04000100, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 36, 0E, 04, 00, 01, 00], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00360E04000100
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00360E04000100
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug [raw:0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350101000100, profileId:0104, clusterId:EF00, sourceEndpoint:01, destinationEndpoint:01, options:0000, messageType:00, dni:FBF2, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:01, direction:01, data:[00, 35, 01, 01, 00, 01, 00], clusterInt:61184, commandInt:1]
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: warn DID NOT PARSE MESSAGE for description : catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350101000100
[b0edb04e-e988-47b0-9719-236e4a665e49] 9:53:42 pm: debug description is catchall: 0104 EF00 01 01 0000 00 FBF2 01 00 0000 01 01 00350101000100

Hi @ygerlovin,

Google Home commands are working now. We still get the open/close status but at least it works now. Thank you for explaining that Alexa needs this contact sensor.

Regarding the errors from the first time I installed the driver, I am getting again. When I try to switch on/off the lamps via the Smartthings app, it keeps loading and throws an error after a while. Strange thing is that it’s only happening with a specific switch, I have 2 more and they work fine.

These are the logs:

When turning on the lamp via app:

– Switch 2 –

2022-06-02T14:04:36.556340991+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 driver device thread event handled
2022-06-02T14:05:03.666267786+00:00 TRACE Zigbee Multi Gang Switch [YG] v2.0.3 Received event with handler capability
2022-06-02T14:05:03.673744952+00:00 INFO Zigbee Multi Gang Switch [YG] v2.0.3 <ZigbeeDevice: 4f71f951-0310-4eea-aabb-f085e958ee55 [0x5C41] (Tecla habitacion)> received command: {“args”:{},“capability”:“switch”,“command”:“on”,“component”:“switch2”,“positional_args”:{}}
2022-06-02T14:05:03.677627744+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:05:03.681169911+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 tuya_can_handle(): false ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:05:03.684656411+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:05:03.688232536+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 tuya_can_handle(): false ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:05:03.691720077+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:05:03.695227036+00:00 TRACE Zigbee Multi Gang Switch [YG] v2.0.3 Found CapabilityCommandDispatcher handler in Zigbee switch driver → Zigbee Moes switches
2022-06-02T14:05:03.698745577+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 HandlerSwitch.handle_event() Tecla habitacion event={args={}, capability=“switch”, command=“on”, component=“switch2”, positional_args={}}
2022-06-02T14:05:03.702010744+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 == MultiGangSwitch.handle_event for ep=2 component=switch2 ==
2022-06-02T14:05:03.707209869+00:00 INFO Zigbee Multi Gang Switch [YG] v2.0.3 <ZigbeeDevice: 4f71f951-0310-4eea-aabb-f085e958ee55 [0x5C41] (Tecla habitacion)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x5C41, dest_endpoint: 0x01, profile: 0x0104, cluster: 0xEF00 >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x11, seqno: 0x96, ZCLCommandId: 0x00 >, GenericBody: 00 96 02 01 00 01 01 > >
2022-06-02T14:05:03.714493119+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 Tecla habitacion device thread event handled
2022-06-02T14:05:06.558849078+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 driver device thread event handled
2022-06-02T14:05:36.566328748+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 driver device thread event handled

– Switch 1 –

2022-06-02T14:06:31.546268463+00:00 TRACE Zigbee Multi Gang Switch [YG] v2.0.3 Received event with handler capability
2022-06-02T14:06:31.550993671+00:00 INFO Zigbee Multi Gang Switch [YG] v2.0.3 <ZigbeeDevice: 4f71f951-0310-4eea-aabb-f085e958ee55 [0x5C41] (Tecla habitacion)> received command: {“args”:{},“capability”:“switch”,“command”:“on”,“component”:“switch1”,“positional_args”:{}}
2022-06-02T14:06:31.554751129+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:31.558504963+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 tuya_can_handle(): false ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:31.561957463+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:31.565429504+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 tuya_can_handle(): false ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:31.568795171+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:31.572002921+00:00 TRACE Zigbee Multi Gang Switch [YG] v2.0.3 Found CapabilityCommandDispatcher handler in Zigbee switch driver → Zigbee Moes switches
2022-06-02T14:06:31.575594088+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 HandlerSwitch.handle_event() Tecla habitacion event={args={}, capability=“switch”, command=“on”, component=“switch1”, positional_args={}}
2022-06-02T14:06:31.579163171+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 == MultiGangSwitch.handle_event for ep=1 component=switch1 ==
2022-06-02T14:06:31.584089296+00:00 INFO Zigbee Multi Gang Switch [YG] v2.0.3 <ZigbeeDevice: 4f71f951-0310-4eea-aabb-f085e958ee55 [0x5C41] (Tecla habitacion)> sending Zigbee message: < ZigbeeMessageTx || Uint16: 0x0000, < AddressHeader || src_addr: 0x0000, src_endpoint: 0x01, dest_addr: 0x5C41, dest_endpoint: 0x01, profile: 0x0104, cluster: 0xEF00 >, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x11, seqno: 0x97, ZCLCommandId: 0x00 >, GenericBody: 00 97 01 01 00 01 01 > >
2022-06-02T14:06:31.591218713+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 Tecla habitacion device thread event handled
2022-06-02T14:06:36.588957963+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 driver device thread event handled
2022-06-02T14:06:44.716195048+00:00 TRACE Zigbee Multi Gang Switch [YG] v2.0.3 Received event with handler zigbee
2022-06-02T14:06:44.722112339+00:00 INFO Zigbee Multi Gang Switch [YG] v2.0.3 <ZigbeeDevice: 4f71f951-0310-4eea-aabb-f085e958ee55 [0x5C41] (Tecla habitacion)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x5C41, src_endpoint: 0x01, dest_addr: 0x0000, dest_endpoint: 0x01, profile: 0x0104, cluster: OnOff >, lqi: 0xFF, rssi: -72, body_length: 0x0006, < ZCLMessageBody || < ZCLHeader || frame_ctrl: 0x18, seqno: 0x35, ZCLCommandId: 0x01 >, < ReadAttributeResponse || < AttributeRecord || AttributeId: 0x0000, ZclStatus: UNSUPPORTED_ATTRIBUTE > > > >
2022-06-02T14:06:44.733923464+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 moes_can_handle(): true ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:44.737468298+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 tuya_can_handle(): false ‘Tecla habitacion’ _TZE200_g1ib5ldv/TS0601
2022-06-02T14:06:44.740801839+00:00 DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 Tecla habitacion device thread event handled

I’m getting a lot of DEBUG Zigbee Multi Gang Switch [YG] v2.0.3 driver device thread event handled even when I’m not using anything. Is this normal?

Thanks and let me know if you need anything.

Hi @iwry

I updated virtual things driver to allow users to select device profile without contact sensor capability.
This option is available only for vSwitch and vMomentary types.

If you are not using Alexa (or don’t need trigger functionality), you can change the profile in settings and the device in the app will be updated. All automatons will be preserved, as long as you do not delete the device.
The logs you provided definitely show a problem. The last message is not expected for this device. I think it might have a different firmware version (either newer or may be non-standard). I currently have no solution for this, this will require some research.
Is it possible this device was connected to some Tuya hub and got updated? Or may be it was purchased recently?

@ge33ek ,
Thank you for the logs. The device uses proprietary Tuya messages and looks as standard Tuya switch.
The problem here is that the handler does not recognize the device.
My DTH is no longer maintained, as the new Edge platform is available and DTH integrations will not be supported in the near future.
I can try to add your device to my Edge driver, if you are interested.
Please be prepare to provide the logs from smarthings CLI, as I don’t have this device (in fact I don’t have Moes Zigbee switches at all), so will not be able to test the changes.
Cheers

Simple switch profile fixed the issue in the Google Home app. Thank you so much!

1 Like

Hi all, where can I find the ST EDGE drive that you are using? I’m avaible for testing tham in cli also
Thank you very mutch.

1 Like

This is @ygerlovin channel. His driver should be there.

Hey @ygerlovin !
all right?

Could you help with this?

Zemismart Zigbee Multi Switch “new updated model” - TS0601.

MarianoC said he doesnt use the TUYA cluster EF00 on his drivers
 do you think could include in a Multi Swtich Zigbee Driver?

Ty!

1 Like

Hi all again
I have bought a few of the Moes Zigbee 3.0 2 Gang switches from amazon.
MS-104BZ
All has been good, however one of them needs FActory Reseting and now refuses to pair with my STT Hub.
Originally it was seen by the hub in discovery mode when it was continuously beeping.

So my question is how do I Factory reset one of these and then get it into Pairing mode please?

I have tried holding the Reset button down, shorted the S1 5 times when connected to Live/Neutral etc but I still cant see the device when the hub is in Pairing Mode.
I would appreciate any advice as the instructions are confusing


Thanks in advance