Does anyone have drivers for Martin Jerry Zigbee Smart Switch [US-ZB-SS01] I got it to work with generic drivers but it creates child devices and they look messy. Thanks!
Seems like e rebranded Tuya …
Can you make a screenshot of the Device details, Data section (at the bottom of the HE device web page) ?
1 Like
Try some Tuya drivers… for example this one : Zemismart Zigbee 1/2/3/4 gang light switches - #36 by kkossev
1 Like
Do you think those would remove the "Component devices" in the screenshot I sent or those will always be there?
No, simply changing the driver will not remove the fake F2 child switch ( this is a bug that Hubitat has to fix yet).
You can either delete the switch ('REMOVE DEVICE' red button at the bottom of the device page) and pair it again to HE, or switch temporarily to the HE inbuilt driver named 'Device', then click on 'Remove All Child Devices' button, then switch back to the Zemismart driver.
2 Likes
Well that was simple. lOl, thanks a ton man. This community is simply amazing, everyday I am thankful this product exist. One of the best decision was to leave Smartthings.
1 Like
@gopher.ny when you have a chance, can you add the necessary lines of code that will skip the Green Power cluster F2 from being counted as a switch endpoint, please?
This issue has been reported many times in the past few years.
1 Like
what driver are we talking about here?
This isn't something that we would deal with at the hub level
@kkossev that's awesome, I've been using these for a year and just lived with that mess. Just figured it is what it is.
2 Likes
@mike.maxwell isMultiEP device data value should have been created by the Generic Zigbee Multi-Endpoint Switch driver.
I suppose this driver was selected automatically when the device has been first paired to HE.
So yes, skipping the F2 endpoint could be implemented on the driver level here.
This seems to be the official specification for the use of endpoint 0xF2 (242) :
On hub/system level there is another problem - for some devices, the default endpoint is wrongly determined to be the F2. Perhaps some exception happens during the initial pairing when processing the endpoint 01 (or whatever the first ep in the list is), so it is skipped and the device data endpointId is set to F2. This makes the device unusable for most of the drivers. This issue is shown here, but there are other posts showing the same problem.
Do you know if the device is responding with this as the first endpoint, and 01 is the second one?
The inbuilt driver will be updated to ignore this EP when creating child devices.
2 Likes
F2 is always the last endpoint.
This is an example when such a problematic device is first paired to HE :
| Manufacturer: | _TZ3000_zirycpws |
|---|---|
| Endpoint 01 application: | 40 |
| Endpoint 01 endpointId: | 01 |
| Endpoint 01 idAsInt: | 1 |
| Endpoint 01 inClusters: | 0004,0005,0006,0102,0000 |
| Endpoint 01 initialized: | true |
| Endpoint 01 manufacturer: | _TZ3000_zirycpws |
| Endpoint 01 model: | TS130F |
| Endpoint 01 outClusters: | 0019,000A |
| Endpoint 01 profileId: | 0104 |
| Endpoint 01 stage: | 4 |
| Endpoint F2 application: | unknown |
| Endpoint F2 endpointId: | F2 |
| Endpoint F2 idAsInt: | 242 |
| Endpoint F2 initialized: | true |
| Endpoint F2 manufacturer: | unknown |
| Endpoint F2 model: | unknown |
| Endpoint F2 outClusters: | 0021 |
| Endpoint F2 profileId: | A1E0 |
| Endpoint F2 stage: | 4 |
But:
I recently noticed a strange effect. The F2 endpoint was wrongly selected when there was not a matching fingerprint for this new device, both in HE inbuilt and in the custom drivers.
However, after I add the new fingerprint in a custom driver, remove the device and then pair it again to check whether the custom driver is selected automatically - this and all subsequent times HE determines the correct endpointId as the default one! ( 01 for most of the devices, 09 for some Develco devices, etc).
Thank you! : )
2 Likes
interesting, i'll have to see if I have one of these so i can make this happen.
2 Likes
