Strange, do you remember how you paired the switch to your hub? Maybe the wireless version works differently compared to the wired one?
I’ve already tried reseting the switch by holding down the left button for 10 seconds. But the switch automatically pairs itself again with all the Zigbee lights instead of with the hub.
probably the issue is that you have a wireless version. As far as I remember ST does not work well with Zigbee binding groups. I have the same issue with the Opple switch.
The proper way in Zigbee is to create a group of lights and then assign the switch to the group.
But in ST devices are in one group so switch controls all of them.
And custom drivers are isolated so it is not possible\not easy to pass the group id between devices.
nope this thread for wired DHTs,
I can recommend you to Google for Opple solutions, it’s also Zigbee 3 wireless switch.
But as far as I know there is no solution and you can try to work with binding table (see in the end of my DHT) by yourself.
I see the errors after I try to switch from the “Thing” DTH to your DTH. Although it’s not recognized I should be able to change the DTH nevertheless. With other Zigbee/Zwave devices it works, but not in this case, due to I get this error:
Error
500: Internal Server Error
URI
/device/update
Reference Id
f6578251-1107-4ae6-b640-3f8c7be3a299
Date
Thu Sep 16 16:35:51 UTC 2021
My raw data from IDE is the following:
Sorry for the late response
Few things:
I am not sure if this has to do with the changes in line 231 or the new version I downloaded. The rest of the switches still seemed to be fine. I will revert it to the original new version of your DTH and see if some of these problem persists.
On the new EU devices.
As far as I can see the Data and the Raw Fingerprint are as I would expect. I’m therefore puzzled by the fact that this isn’t being recognised automatically. I wonder whether there’s something earlier in the long list of fingerprints that is causing an issue. A simple experiment would be to move the fingerprint for your switch to the top of the list, so that it’s the first one that’s found.
Also the code looks for a child DH with the name “Aqara Wall Switch Child”. Anything else won’t be found.
What happens in the debug log when you do a ‘refresh’? Go to the DH in the app, and put your finger on the toptile and slide down. You should see a rotating arrow for a second or so.
The triple switch ( I’m tried to avoid confusion between several conversations taking place on the forum):
I have tried several times to reproduce the issue with the multiple duplicates but without success.
You can set debugging mode by going to Settings within the DH in the App. Just make sure the last 2 are set to True.
What happens in the logs when you press each of the physical switches?
I don’t think I follow. I don’t know how to control the Device Handler from the app, only from the IDE website
I’m surprised, as all these DH’s have been designed to be used from the app.
However, you can force a refresh from the IDE by going to the device within the IDE, clicking Edit at the bottom, and then Update at the bottom, without actually changing anything. I’d like to know what appears in the logs when you do that (assuming you have debuggLogging and infoLogging set to true in the Preferences)
Does this help?
11:24:27 PM: debug Thing Parse returned: [[name:switch, value:off, isStateChange:true, linkText:Thing, descriptionText:Thing switch is off, displayed:true], [name:lastCheckin, value:23:24:27 Thu 23 Sep (EEST), descriptionText:Check-In, displayed:true, linkText:Thing, isStateChange:true]]
878e80fb-956b-4817-b633-857e69542405 11:24:27 PM: debug Thing SmartShield(text: null, manufacturerId: 0x0000, direction: 0x01, data: [0x00, 0x00, 0x10, 0x01], number: null, isManufacturerSpecific: false, messageType: 0x00, senderShortId: 0x6710, isClusterSpecific: false, sourceEndpoint: 0x01, profileId: 0x0104, command: 0x0a, clusterId: 0x0006, destinationEndpoint: 0x01, options: 0x0000)
878e80fb-956b-4817-b633-857e69542405 11:24:27 PM: debug Thing Parsing 'catchall: 0104 0006 01 01 0000 00 6710 00 00 0000 0A 01 00001001'
878e80fb-956b-4817-b633-857e69542405 11:24:07 PM: debug Thing Parse returned: [[name:lastCheckin, value:23:24:07 Thu 23 Sep (EEST), descriptionText:Check-In, displayed:true, linkText:Thing, isStateChange:true]]
878e80fb-956b-4817-b633-857e69542405 11:24:07 PM: debug Thing SmartShield(text: null, manufacturerId: 0x115f, direction: 0x01, data: [0x22, 0xff, 0x86], number: null, isManufacturerSpecific: true, messageType: 0x00, senderShortId: 0x6710, isClusterSpecific: false, sourceEndpoint: 0x01, profileId: 0x0104, command: 0x01, clusterId: 0x0000, destinationEndpoint: 0x01, options: 0x0000)
878e80fb-956b-4817-b633-857e69542405 11:24:07 PM: debug Thing Parsing 'catchall: 0104 0000 01 01 0000 00 6710 00 01 115F 01 01 22FF86'
878e80fb-956b-4817-b633-857e69542405 11:24:05 PM: debug Thing Parse returned: [[name:lastCheckin, value:23:24:05 Thu 23 Sep (EEST), descriptionText:Check-In, displayed:true, linkText:Thing, isStateChange:true]]
878e80fb-956b-4817-b633-857e69542405 11:24:05 PM: debug Thing SmartShield(text: null, manufacturerId: 0x115f, direction: 0x01, data: [0x86, 0x22, 0xff], number: null, isManufacturerSpecific: true, messageType: 0x00, senderShortId: 0x6710, isClusterSpecific: false, sourceEndpoint: 0x01, profileId: 0x0104, command: 0x04, clusterId: 0x0000, destinationEndpoint: 0x01, options: 0x0000)
878e80fb-956b-4817-b633-857e69542405 11:24:05 PM: debug Thing Parsing 'catchall: 0104 0000 01 01 0000 00 6710 00 01 115F 04 01 8622FF'
Yea for some reasons, when i re-add the switch via ST app, it shows in ST app (multiple duplicates of them) but not showing in the IDE devices tab.
I do not know what has went wrong - i tried loading back the previous version of DTH (which i was originally using) and see if that helps but it doesn’t. Will try cutting off power to the switch to see if that helps but it is bizarre. Will update
What exactly did you do to generate this log?
I note that it contains 3 ‘catchall’ responses from the switch, the first 2 of which (counting from the bottom) I have never seen before and contain the code ‘manufacturerSpecific: true’, which speaks for itself. These have been ignored by my code.
The last one has been interpreted as a message that the switch has been turned off. The switch in the app should now be ‘off’.
What appears in the logs when you do a ‘refresh’. Go to the app, hold the top tile and slide down for a second or so. You should see a rotating arrow for about a second, then lots of stuff should appear in the logs.
I want to know what it says about the number of switches and whether it tries to create more children.
Maybe you can post a screenshot. I don’t understand what tile you want me to press and hold. In which screen? If I do that on device tile, it will ask where to move that device and that’s it.
That happened to me also, with previous version. Now it’s just see it as a “Thing” but looking at the code it shouldn’t do that.
Actually the switch is on all the time…
This is how it looks on All Devices page…2 of them off, and one on.(this is how a double rocker switch is detected)
I seem to have the same error. When I scan for new devices, it will duplicate the switch twice. So a double rocker will have 3 switch’s and 3 child’s (6 in total). Only 2 (the last 2 (1 switch and 1 child) will work. And only for about a day before losing connection. Nothing shows up in the groove’s device list. Nor any command like turn on / off.
I do get and error on discovery.
Thanks for this. These errors give an important clue. Can you try the following:
Insert before line 627:
settings.infoLogging = true
settings.debugLogging = true
and try to reinstall the device.
That won’t solve the problem, but, with luck, it will help with the diagnosis.
