Dashboard Switches Not Changing State

Came across a fix for the issue. I found someone who had made a driver for the Peanut Plug that was made to include support for the plug's power measuring feature. Imported that driver and switched my plugs over to using that driver and it works perfectly. Curious as to why the generic outlet driver wouldn't work properly but thanks again for all your help!

The Generic Zigbee Outlet driver should work with the Peanut Plugs. After you paired the device, you had to change the driver, correct? After changing the driver and saving the device, did you remember to Click CONFIGURE on the device details page? The configure command tells sends status reporting commands to the device. Usually this happens automagically IF the correct driver is assigned during pairing. However, any time you manually change a driver, you must remember to click the CONFIGURE button afterwards. I have a Peanut plug using the Generic Zigbee Outlet driver without any issues.

I did click configure but I'll go try changing it back to generic outlet and clicking configure to see if that works (I'm only human, it's very possible that I forgot to click configure lol)

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:

image

  • 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:

s-l500

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:

  1. 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"

  1. 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.

Thanks, however this is a zigbee device - It doesn't look like there are any clusters there?

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