Greenwave 6-outlet Power Strip -

🛎️ Get Help Devices
1

I bought 2 of the Greenwave $19.99 6-outlet powerstrips, because cheap and individual outlet control. They are working well with the driver "Greenwave PowerNode 6" (copycat73).

But they flash green - the manual says
"Two flashing green bars on each side of white flashing center: PowerNode cannot communicate with Gateway. This may occur if the PowerNode is out of range from the Gateway. You can move the PowerNode closer to the Gateway to improve reception."

This is a tiny house... the two power strips are about 8 feet and 14 feet from the Hubitat hub, nothing but wood and wallboard between the hub and the power strips.

If I do a "refresh" from the Hubitat device page for any of the outlets, the energy value updates, the "lastupdate" timestamp updates to "now", and I can flip outlets on and off at whim.

Any of these operations stops the green blinking, but eventually, they go back to blinking again.

So, why does the powerstrip think it has lost Z-Wave communications with the hub, if the hub can communicate with the power strip? If I leave things alone, both power strips will, after a few hours, start with the same green blinking again.

Yes, I can just ignore it, but I am concerned that I don't understand something basic here, and I am new to Hubitat, relatively new to Z-Wave devices in general, and I had HOPED that these things would help improve the Z-Wave "mesh", given that they are 120-Volt powered devices, not battery-powered like the deadbolts.

2

Read in some of the other forums for other home control systems, and the problem here is that these Greenwave devices expect to be polled. If they are not polled, they complain by flashing their little lights. All is not lost, one can disable the lights completely, or set a longer time-out interval before they complain. But this requires slogging through yet another document written in Korean by a native Cantonese speaker, run through Google translate several times, and then buried in a peat bog for a month before being dug up and sold as camping fire-starters.

But, it looks like the Z-Wave tool will allow one to set the correct bits in the correct registers, and this will (eventually) allow one to tweak the driver to add a button.

3

Set up a rule to refresh or poll every two minutes. If they don’t hear from the hub within two minutes, they’ll flash. This workaround stopped me going crazy.

There is an offset to turn that off, but I’ve never been successful in getting it right. Just when I thought I had, FLASH! Aaaaarrrggghhh!!

1 Like
4

I’ll look at incorporating this into the driver actually.

5

I stumbled upon this:

• param 0: Power change required to send a notification, in % from 1 to 100, default 10
• param 1: Keep alive time, in minutes from 1 to 255, default 2
• param 2: Color wheel selection, read only
• param 3: State after power loss, 0 = all off, 1 = remember last state, 2 = all on, default 2
• param 4: Led for network error, 0 = disable, 1 = enable, default 0
• assoc group 1: Color wheel change
• assoc group 2: Relay health
• assoc group 3: Power value change
• assoc group 4: Over-current protection

So, parameter 4 seems to be the one to get rid of the flashing without needing to poll, and instead, have the device report when there is a change in amps drawn.

The "full docs" for the device are at the link below, but they are far less than clear:

6

Some of those are also dependant on the firmware of the plugs. The ability to control the state after power loss is only available on 4.28 and above (from memory).

I’ll have another look at this as soon as I can. My single plugs were older than above.

The original driver I had on ST did stop the flashing, so I can refer to that too. :+1:

7

Hey Royski, Just updated last night to latest and now today these errors pop up. Do you have errors? How about @james.fischer
dev:26652020-09-05 01:30:41.062 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_copycat73_GreenWave_PowerNode_6_V2_2058.parse() is applicable for argument types: (hubitat.zwave.commands.multichannelv4.MultiChannelCmdEncap) values: [hubitat.zwave.commands.multichannelv4.MultiChannelCmdEncap@94b8635] Possible solutions: parse(java.lang.String), use([Ljava.lang.Object;), wait(), run(), ping(), poll() (parse)

8

Can you show me this section from your parent code please?

def parse(String description)

It should be like this.

def parse(String description) {
def result = null
def cmd = zwave.parse(description, [0x60:3])
if (cmd) {
	result = zwaveEvent(cmd)
	//log.debug "Parsed ${cmd} to ${result.inspect()}"
} else {
	//log.debug "Non-parsed event: ${description}"
}
return result

}

9

Sorry I meant latest hubitat firmware, and yes it looks exactly the same, I think....

def parse(String description) {
def result = null
def cmd = zwave.parse(description, [0x60:3])
if (cmd) {
result = zwaveEvent(cmd)
//log.debug "Parsed ${cmd} to ${result.inspect()}"
} else {
//log.debug "Non-parsed event: ${description}"
}
return result
}

10

Ok cheers, this would be the other area to check. Only as the error shows V4, when it should be V3.

private encap(cmd, endpoint) {
if (endpoint) {
	zwave.multiChannelV3.multiChannelCmdEncap(destinationEndPoint:endpoint).encapsulate(cmd)
} else {
	cmd
}

}

11

I'm starting to have reservations about the long-term viability of these Greenwave power strips. Last week, one of my four strips went into spasms every few hours, randomly flipping individual outlet relays off/on multiple times quickly and then returning to normal again.

Before I figured out what was going on and why my TV kept randomly shutting off, the rapid off/on power whacked the config in my TiVo back to factory default. :frowning: Since TiVo did not think to include a config backup/transfer function in the device, I'm just going to cut the cord on cable TV rather than spend hours trying to re-create my recording search lists from memory.....

12

I can be of no help with the revisions Roy did (Thanks!) as the hubigraphs "long term storage" feature solved my problem with "too many data points", so polling certainly is feasible, but I persisted in trying to figure out how to set up the "associations" that are required to get the automatic non-polled reporting working.

The manufacturer refused tech support, claiming that the device was so old, no one working there had worked there when they made the PowerStrips. The guy I spoke with did agree that it was strange to buy something from Monoprice claimed to be "new", and find out that one cannot even get one simple question answered from the manufacturer. When I asked if they could at least send me what they had on hand in the way of 'tech notes", he instead sent me a check for the Monoprice-listed price of 2 of the PowerStrips.

Yep, he refunded my purchase price rather than tell me how to make it work.

But other groups seem to have at least partial clues as to how to set the associations for the "report on change" power reports:

So, I moved on to other issues, as there are only so many hours in the day, and I'd like to get the bugs out of everything and installed at each residence before I die of old age. :wink:

1 Like
13

My reservations with these went out of the window a long time ago :smiley: They are very old, and I know they no longer make them or support them. That said, I do find they work very well in my system. I don't have a load of Z-wave devices, mostly Zigbee, so they're used mainly as a repeater, and then at Xmas, they control all my lights for the tree and outside. I don't much care about the power monitoring TBF.

I would love to get them auto reporting the power though, just because I like to tinker :wink:

I did include an auto-poll as a workaround to this, adding options to the parent for between 1 to 5 minutes. If anyone would like that I can share, although if someone with proper coding knowledge and the ability to add this feature, you're more than welcome to use whats been posted :+1:

If I happen to hit on a fix for it, I'll certainly share too.

1 Like
14

I need to dig into the archives here some day, to see what everyone is using the power monitoring data for. My OpenEVSE (DIY electric car charger) can output to Emoncms, and I'm thinking that it might be worth feeding the HE power reports as well unless there's a more useful analysis tool.....

1 Like
15

I noticed that, but I "think" the hub is saying applicable to argument types, wait I'm way out of my skillset here. It's saying something but not in my native language :crazy_face:

16

Is it showing the above, or below mate?

private encap(cmd, endpoint) {
if (endpoint) {
zwave.multiChannelV4.multiChannelCmdEncapate?

17

It's showing the above, sir.
Well not exactly tho

private encap(cmd, endpoint) {
if (endpoint) {
zwave.multiChannelV3.multiChannelCmdEncap(destinationEndPoint:endpoint).encapsulate(cmd)
} else {
cmd
}
}

18

which firmware and hub are you running?

Could you import the parent again, just to make sure?
https://raw.githubusercontent.com/Roysteroonie/Hubitat/master/Greenwave/PowerNode_6/GreenWavePowerNode_6.groovy

19

I have the greenwave 6 outlet on a C4 hub-firmware 2.2.0.126, however the error only started when I upgraded to the latest 2.2.3.145. Due to overall lag and slow performance I downgraded to 2.2.0.126. And the error is now gone

20

Yup, the issue appeared in 2.2.1, and I raised this at the time as I had exactly the same errors.

As reported here

I contacted HE and was advised that this line

def cmd = zwave.parse(description)

needs to be:

def cmd = zwave.parse(description, [0x60:3])

Which is what resolved it for me.
I'm just wondering if upgrading again, and hitting the save prefs may help this?
Its almost as if the new code hasn't taken effect?

And my apologies @james.fischer as this is now way off topic :frowning: Sorry.

1 Like