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