Greenwave 6-outlet Power Strip -

[james.fischer]

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:

Technical-Doc-for-the-powernodes.pdf

[Royski]

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.

[Rxich]

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)

[Royski]

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

}

[Rxich]

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
}

[Royski]

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

@Rxich

(hubitat.zwave.commands.multichannelv4.MultiChannelCmdEncap)

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

}

[vreihen]

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

[james.fischer]

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:

Greenwave Powernode 6 measurement always reported on instance 1

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.

[Royski]

My reservations with these went out of the window a long time ago 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

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

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

[vreihen]

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

[Rxich]

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

[Royski]

@Royski

private encap(cmd, endpoint) {
if (endpoint) {
	zwave.multiChannelV3.multiChannelCmdEncap

Is it showing the above, or below mate?

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

[Rxich]

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
}
}

[Royski]

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

[Rxich]

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

[Royski]

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

Greenwave Powernode 5/6 extension driver

Hello, since the Platform Update 2.2.1.113 the switch status and power metering of all Greenwave Powernodes is no longer updated and the Dashboard switch-tiles are unresponsive, I am still able to turn them on and off in their respective device window, but the status is not updated here as well. A rollback to the previous platform version 2.2.0.132 fixed it for now. I am a total noob when i comes to driver modification so my big hope is your expertise. The Log shows the following: [dev:954]2…

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

[Rxich]

@Royski

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

That would be my fault also. Although it is relative to the powerstrip and trying to use it on HE, HE, since C7's release, has been very rough, and leaves me concerned.
I'll leave it at that.
And Thank you for all your help

[james.fischer]

No need to "apologize" to me, I am happy to learn what others are doing. I have a C4 hub, running 2.2.3.135 and on the raw Devices page the individual outlets respond as expected to "on/off" button presses on the device driver detail page, updating their status as "on or off" as one would expect.

So, the problems seem to be a result of either the C5 / C7 platform, or the code specific to those platforms. Those of us sticking with the older, more stable hardware seem to be at a distinct advantage.

While I would dearly like the power-reporting data, I am more concerned with powering off things that consume power simply by being plugged in, and might be harmed by the random wackiness of "Island Power", not the same quality product as on any mainland.

But I do want the "smart vacation home" to power up things like the stereo when anyone is in the house, as the housekeeper has a right to enjoy the stereo while she works, even if powering it up is a prima facie violation of the nuclear test-ban treaties of 1963 and 1996.

[james.fischer]

Here is what I see in the logs, and this is what I want to be able to graph with Hubigraphs:

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 07:44:14.356 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 2 value 3.2

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 07:44:14.312 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 0 value 111.3340

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 02:47:39.927 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 2 value 3.6

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 02:47:39.884 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 0 value 111.3180

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 02:30:35.700 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 2 value 3.6

[dev:524](http://192.168.1.103/logs#pastdev524)2021-06-15 02:30:35.631 pm [debug](http://192.168.1.103/device/edit/524)Greenwave v3 meter report received for endpoint 2 scale 0 value 111.3170

The power strip is correctly reporting the turning on and off of a TV. 3.6 watts when "off", and 111 watts when "on". But the child devices only seem to get updated if manually "refreshed" from the Hubitat device page. So, this looks like something that could be parsed, and used to update each child (outlet) of the 6 outlets. But Hubigraphs wants a specific device to feed it data, not the parent device reporting on each "endpoint".

Any suggestions on how one might handle this kind of thing? I am thinking that I need to parse this data, and shove it into the proper place with a driver mod, but the driver was ported over from Smartthings, and there was no problem with the child devices being updated in the Smartthings version.