Changed the plugs to the Generic Zigbee Outlet driver, and it behaved the same as before: one switch behaving properly(still unknown why) and two switches not behaving correctly. Changed them back to the Peanut Plug driver and they immediately started working properly again. Super weird.
Glad the community driver you found is working for you. I wonder if all of your Peanut plugs have the same firmware version? Might explain the difference? Just a guess.
Not sure as I believe I have to get their Almond Router to check that. I will most likely be getting one soon so that I can update the firmware on the plugs to get the power monitoring features, I'll try changing back to the generic driver once I update them all to the new firmware and see if that was it!
1 Like
I have about 16 peanuts all running as Generic Zigbee Outlet and they report fine through the dashboard. I did go through all my zigbee devices and eliminate most of the logging, which helped with reliability and responsiveness when I did group on/off stuff. So consider minimizing the logging traffic and trying again maybe?
Can you share the link to that driver or the driver itself?
Here you go:
1 Like
Hi all, this seems to be the most recent discussion on this topic as it seems there are several other threads. I'm seeing the same refresh issue with a regular zigbee switch
Fact sheet:
- Worked fine on ST.
- Tried both generic zigbee switch and generic zigbee outlet. No change
- Hit configure ad nauseum. No effect.
- Commands are going through nicely, but the reply is not: Clicking the ON button on the device properties in HE, the switch physically turn on immediately, however the Current states to the right is NOT updated:
-
If I flip the dashboard switch it gets stuck in "Sending..." when turning on the switch
-
Regardless nothing is logged, with debugging enabled.
-
If I subsequently hit refresh, then current state, log and dashboard switch is subsequently updated.
So far all I've seen are suggestions to move the hub, re-pair devices and similar. None of these suggestions seem decisive, thus I was wondering... and just thinking out loud here:
Would it be possible to mitigate (or rather McGyver) this problem by making a slightly modified driver which would issue a refresh() after either an On or Off event, possibly with a brief delay?
While my Groovy kung-fu is not especially strong, I'd be willing to give it a shot, but where does one find the driver for the generic zigbee switch? (yes I tried looking in the Hubitat public repository).
And if there is a setting to flip somewhere in the settings, kindly give me a nudge in the right direction.
Thanks!
1 Like
Specific model numbers and the manufacturer are really important in helping to troubleshoot the issue you’re experiencing.
Right, I should have elaborated on that. The switches are eWeLink switches:
I've had 10+ of these switches in ST for 2 years working great. I like them because they are easy to modify to work as a relay instead of powered output, or even serve as a 5VDC output. And they are small enough to build into other projects.
They detect as Generic Zigbee switches and this is how they primarily identify in HE
- endpointId: 0B
- application:
- model: SA-003-Zigbee
- manufacturer: eWeLink
Some of them however identitfy as this, but they all act in the same manner for better or worse.
- endpointId: 0B
- application: 01
- model: Lamp_
- manufacturer: SZ
In the regular log, this shows up as descMap: [raw:D2190B00060A00001000, dni:D219, endpoint:0B, cluster:0006, size:0A, attrId:0000, encoding:10, command:01, value:00, clusterInt:6, attrInt:0]
In the zigbee log, I get this on either on, off or refresh commands:
profileId:0x104, clusterId:0x6, sourceEndpoint:b, destinationEndpoint:1 , groupId:0, lastHopLqi:255, lastHopRssi:-76
If there's any additional details I can pull, pls let me know.
I doubt those on on Hubitat’s official list of compatible hardware, right?
If not, they will probably need a community developed driver. Did you use a custom DTH on ST? If so, perhaps that DTH could be ported to a Hubitat driver?
1 Like
@ogiewon, ah-yup, pretty sure that's the case (just checked). This thing is forged out of 99% pure Chinesium and needs a custom driver/DTH.
I was initially going with the built-in generic zigbee switch driver, however just had a brainwave and searched for the SA-003 model number - a few rabbitholes down I came across a custom driver which @Royski made/modified. (and 1000 karma points to you, sir!) (post here)
I just installed it a few min ago and gave it a whirl and whaddayaknow, instant update!
I'm going to test further, but so far it looks real good.
3 Likes
Excellent! Glad it’s working.
1 Like
Just tested it through on both switches and it works like a charm both in the logs, dashboard and on the current state. Everything is verified to be updating.
However, two followup questions to the esteemed panel:
- perhaps it's my OCD acting up here, yet I'd like to have new instances of this switch be identified properly and select this driver. Is it enough just to add another fingerprint in the driver code, like this: ?
fingerprint profileId: "0104", inClusters: "0000, 0003, 0004, 0005, 0006", outClusters: "0003, 0006, 0008, 0019, 0406", manufacturer: "eWeLink", model: "SA-003-Zigbee", deviceJoinName: "eWeLink KwangBong ZigSwitch"
- Where do I find the inClusters and outClusters for a given device? All I see in the log is the Cluster 0006, i.e. not entirely sure how to go about this?
Thanks,
/Max
Where do I find the inClusters and outClusters for a given device?
On the device’s page, near the bottom. Also on Z-Wave Details page, probably the easiest place to find.
My apology, I skipped over that fact.
Change the driver to "device" and save. Open logs in a new window. Go back to the other tab/window and hit "configure" in the device page. The output will display in the logs.
Don't forget to change the driver back, save, and hit configure again.
1 Like
@672southmain no worries 
@neonturbo Thanks! that's a neat trick - so this is what I'm getting in the log:
If I remember correct, the first digit group (0104) is the profileId, the next group (0006) before 0B is the incluster(s), but which groups above would be outclusters? (if there are any?)
Way above my paygrade, sorry.
It's all good. Perhaps somebody knows and we all get smarter 
