UseeLink ZigBee power strip

I'm trying to stay away from Z-Wave with any new purchases, when possible. I checked the compatibility list, and do not see this listed. In fact the only power strip I see is the Zooz Z-wave.

Does anyone know if this will work with Hubitat? If not is there a ZigBee power strip that is supported?

https://www.amazon.com/UseeLink-ZigBee-Protector-Outlets-Required/dp/B086GYQLW9/ref=sr_1_2?dchild=1&keywords=smart+power+strip&qid=1586264515&refinements=p_n_feature_fourteen_browse-bin%3A6652766011&s=hi&sr=1-2

1 Like

I have a few of the Zooz Zen20 strips and they work well, however my guess would be that strip would pair but I'd be surprised if each socket is individually controllable by default. I'm guessing it could be made to work though it would likely require writing a custom driver.

Wow! Wish I had seen that strip sooner, or I might have bought it. Instead, I recently bought a Wi-Fi power strip I'm hoping to flash with Tasmota (yes, Wi-Fi, the thing I often recommend against for this purpose...but if it's possible to have way too many Z-Wave repeaters, then that is me, so I'm trying to diversity a bit--and not spend $70+ USD each time).

Like the above, I doubt you'll find any native driver that lets you control all four outlets and/or the USB ports individually. Actually, it looks shockingly similar to the one I bought (and it's only a few dollars more!), aside from the white vs. black plastic: https://www.amazon.com/gp/product/B07FM3P87S/ (wonder if they're all about the same with different firmware?). I'm tempted to return mine and give yours a try instead, but the likelihood of any of this shipping before May is...low. :laughing: My guess is that you'd get it to pair but might get on/off control of the whole thing, at best, instead of individual outlets--but that a knowledgeable person might be able to write a custom driver that works. It does say "Zigbee 3.0," and I assume the "Works with Alexa" thing might mean directly paired instead of just through a third-party app--both promising.

Yeah that is too close not to come off from the same beginnings somewhere.

That person is not me. I would not even know where to begin. I'll hope someone smarter than me wants one and writes the driver for it.

Yeah, I order some LED extensions today that won't be in until April 28th Ugh. However Amazon does seem to have this close to me anyway

image

If you do keep the WiFi based one and run Tasmota on it, my Closed Beta driver has support for all 4 outlets + USB (all USB ports are controlled together) using 1 parent + 5 child devices. PM me for access.

I got the zooz strip just a few days ago...

May I ask why you are avoiding z-wave?

I'd be wary of quality. Looks exactly like the tuya power strips. I had one partially melt yet continue to work like nothing was wrong.

1 Like

Eek! One of the reasons I chose this one (over dozens of others that weren't--I had to search pretty hard) is that it was ETL listed. The Zigbee one above also claims to be the same. Was yours UL or ETL listed, by chance?

:astonished:

Eek, Tasmota's not looking good for me: tuya-convert logs say "WARNING: it appears this device does not use an ESP82xx and therefore cannot install ESP based firmware," and I'm too afraid to open it up and see. People say the SS30 works, but I see my model says SS30N and appears to be slightly different externally (no grooves around the outlets or ports). I'm not very familiar with Tasmota, so open to other ideas if this might still be worth exploring, otherwise I'm even more tempted to try the Zigbee one now. :slight_smile:

EDIT: Eeek again, now the price appears to have gone up on Amazon. I was curious to try it, but not if it costs about as much as the Zooz that I already know I like.

The difference is most likely that SS30N is using the Realtek chip RTL8710BN some Tuya devices have started to use. There is no custom firmware for that chip as far as I know. Probably best to return this and get something else. You can control Tuya devices though Google Home, but that is maybe not what you want?

I am struggling with Z-wave locks that have me one step from going back to ST. I have a bunch of Z-wave Plus outlets all around my locks and hub, no help. I have a Z-tools device and I can see the routes work 1 second and get dropped the next.

Today I am installing a Ring Range Extender as a "Beaming Extender". If that does not work I am about to throw all my Z-wave devices and the HE hub in the trash! Locks are very important to me and this experience is eating at my HE love. (25 Z-wave devices works great, 3 locks don't; Yale and Schlage)

I had a million issues with ST, but these locks were not on the list until I moved to HE (nothing else changed).

Since I have a decent existing Z-wave mesh (except the dang locks!!), my hope is if build out a ZigBee network, and switch the locks for ZigBee ones :crossed_fingers:

Currently my only ZigBee extenders are my 2x Halo Smoke/C0 and figure I should start getting more Zigbee.

1 Like

For you or anyone curious about this: I ordered one and it arrived today. Surprisingly, I couldn't even get it to work with generic drivers (I was expecting on() and off() to maybe at least control everything; obviously control of individual endpoints would not be there unless the driver provided them). With some playing around, I was able to make something work. Here are my results:

By default, this driver creates a "parent" device for the strip with five child devices, one for each of the four outlets and one for the USB plugs (which, unlike many others, are indeed controllable). No other drivers are necessary (the child devices are created using Hubitat's built-in component switch drivers; also, you can disable their creation, but I can't imagine why you'd want to, though I created custom commands you can use with endpoint IDs on the parent if you do). I'd welcome feedback from anyone familiar with Zigbee, because this device appears to have some oddities for me:

  • it is my understanding that endpoint 01 is often the entire device itself (i.e., all outlets), but that is not the case here; that is outlet 1
  • outlets 1-4 are endpoints 1-4, the USB ports are outlet 7, and I did not see reports from or successful commands send to any other endpoint ID
  • because of the above, I'm not sure that there is any one particular ID for the strip itself (device.endpointId is null ... assuming this couldn't have been something going wrong during pairing?), so the parent on(), off(), and refresh() commands just send multiple commands, one to each known endpoint

Hopefully this works for anyone who has this! I'll move it from my dev hub to my "real" Zigbee hub later tonight or tomorrow and see if I notice any other issues. :slight_smile:

8 Likes

@bertabcd1234 Thanks for the driver it is working good and so far no problems. It is fast at respondent to command.

If you send to endpoint FF (the broadcast endpoint), does that control all outlets? It is endpoint 0 that is for configuration and management of the whole Zigbee device according to the standard. Many devices don't follow the standard...

It does--thanks! I'm not well-versed with Zigbee and was trying to guess based on what I had seen written in similar ST DTHs (there don't seem to be a lot of Zigbee multi-endpoint devices like this and I'm not sure of any on Hubitat). I've updated the driver with this change. Still not sure if there is a way to get the 'on' or 'off' state for the whole strip ("he rattr 0x${device.deviceNetworkId} 0x$FF 0x0006 0 {}" doesn't work), so I'm still checking the state of all child switches and reporting the parent state. Open to better ideas if anyone knows of something there, as well. :slight_smile:

1 Like

Great, then it's standards-compliant in this at least :slight_smile: And if you read the attribute from endpoint 0? What do you get? That "should" represent the whole device state.

If I do "he rattr 0x${device.deviceNetworkId} 0x00 0x0006 0 {}", then it looks like nothing happens--parse() never gets called (also tried plain "0" instead of "0x00" in case that matters; 0xFF did something, and parse() was run 5 times, once each for endpoints 1-4 and 7). It is entirely possible I don't know what I'm doing, but if I'm specifically sending a "read attribute' command, then it should work even if I missed something in configure(), right? (Even though I did try to include this there, too...)

Then the device doesn't report a collected state attribute on endpoint 0, at least not through any standard means. I don't know how "he attr" really interpretes decimal vs hex values, I've stuck to hex since there is no spec saying anything about this. when using the zigbee.readAttribute() calls etc then the rules of Groovy apply and decimal or hex doesn't matter.
Looking at the other inclusters I doubt you'll get anything from anywhere else. Getting the states separately back when sending to broadcast is expected, so that would be a matter of collecting all states and just using that. Configure() would have nothing to do with this.
Here are some links to what the different clusters and attributes are, they're in decimal form so would need to be converted to hex to make more sense, but I do prefer it over the long-winded zigbee spec docs:


2 Likes

The UseeLink/Tuya Zigbee power Strip works with the Aurora Zigbee Switch driver.
It creates 5 child device (the last is for the 2 USB as a whole).
Hope it can help

3 Likes