False Z-Wave Power Meter Readings

I have a new OpenHAB 2.5 installation and primarily am using this to monitor power usage around my house and report it to InfluxDB for viewing in Grafana. All of those pieces are working well.

The issue I am seeing is the occasional bogus power/voltage reading from my Aeon Labs ZW095 meters (I have 5 of them on various circuits/loads). I am in the USA so this is a 240v 200a power meter, should never be over 48kW period yet I see the occasional bogus reading like 135kw which is clearly either data corruption over z-wave or some other error internally on the sensor. It is not super frequent but is frequent enough that it blows up my auto-scaled charts for viewing power usage.

What would be the best way to put some filtering in place as part of the binding/device handler to discard these bogus readings and prevent them from reporting?

I saw this same behavior previously with SmartThings but it eventually calmed down. I recently switched to OpenHAB (And REALLY like it in comparison) but the bogus readings have returned. Things like 135kW reading on a clamp that is only rated up to 24kw (one side of a 200a 240v meter).

My ZW095 reporting that my house voltage 16.9 kV is another example…

With SmartThings I think the issue was data corruption in the z-wave transmission as I just had too many devices reporting too frequently on a single network - I ultimately introduced a 2nd hub to split things up some which seemed to alleviate the issue.

I am somewhat handy, but an atrocious programmer so please spoon feed me as much as possible haha.



So it looked based on those discussions, like adding some logic at the Channel level between Thing and Item to prevent the false readings from being persisted is the best way forward? Editing the binding itself would not be appropriate? I am new to the terminologies here and think I have those correct - and it is far easier for me to throw out these words than actually carry out the needed underlying tasks and code changes.

The binding is doing its job and passing along data as received. Leave it alone.

You wan to to massage a particular data value (in this case by filtering). There’s a number of ways to do that, but operating at the link between channel and Item is convenient. That’s where a profile can sit.

I came across this, seems like a similar use-case and possible solution. Would you say this is on the right track?

I am still working my way through the tutorial/guide for OpenHab 2.5 so will try to use these pieces and fill in the gaps with that. Thanks!

Except it’s for MQTT not zwave. You no option to apply transformations to zwave channels. This why I suggested profile.

So the way to do this would be to create a profile, and invoke a transformation from within it? Then I have to apply the profile to each Item receiving data from the Channel?

This seems like a possible method to achieve this? With the returned result for “out of range” readings being UNDEF?

I’m not sure how. You would have to specify every ‘in range’ discrete value that you wanted to pass through SCALE unmolested.

That should be easy enough, only 3 use cases really I would have to define a scale for.

0-1800w for the 120v ZW096
0-24000w for a single clamp of the ZW095 HEM
0-48000w for an entire ZW095 HEM

All other values should return UNDEF.

How can I set Input=Output for those 3 ranges so the legal readings are passed through? Or is this getting to the point where a JavaScript transform will make more sense with more flexible logic?


You can’t in SCALE.

Thank you for confirming, I suspected this was the case.

I programmed a JS transformation that I think applies the desired logic. I am unsure how to properly have this loaded in a profile and invoked against Item however, my initial attempt seems to have failed.

This is the JS Transformation I came up with

// filter to not capture values that are negative or over 1800w
(function(i) {
	var val = parseFloat(i);
	if (val > 1800 || val < 0 )
		{ return 'UNDEF'; }
		{ return val; }
} )(input)

And this is the .items file where I try to invoke it (I copied the channel id from the PaperUI page for the Thing:

String Servers_Test {channel="zwave:device:68b35267:node9:meter_watts"[profile="transform:JS",function="zw096.js" }

On doing this, no Item was created even after a restart of OpenHAB. I tried manually creating an Item with the same name but may have broken something.

The data is available for persistence in InfluxDB under the new name but no filtering is taking place as the same anomalous values show up in the original and _test data sets.

Any input is appreciated!


Always check your openhab.log for hints and tips about parsing errors.

In this case the [ needs a partner ]

If you are going to use file based configuration, I recommend using VSCode with openHAB extension as your editor and syntax checker.

Got that loaded up now and poking around. Going to be a lot of learning though haha as I have not used an IDE in over a decade since college

Ok, getting smarter, here is my current item definition (removed the item created by PaperUI I was playing with and this shows up now somewhat properly)

Number:Power Servers_Test "Electric Meter (watts) TEST" <energy> {channel="zwave:device:68b35267:node9:meter_watts"[profile="transform:JS",function="zw096.js" ]}

I THINK I need to do a source format or alter the format for data handling in my JS transformation as I am not outputting/persisting any value so I am guessing it is getting UNDEF’d as defined since the input is not falling in the defined range.

// filter to not capture values that are negative or over 1800w
(function(i) {
	var val = parseFloat(i);
	if (val > 1800 || val < 0 )
		{ return 'UNDEF'; }
		{ return val; }
} )(input)

Any input here would be greatly appreciated, I think I am very close!

That’s a Quantity type Item - that means it has units, and the units are part of the state.
I assume your zwave channel is also quantity type - number:power.

So what gets fed to your transform is always a string - in this case that will “1.5 kW” or “530 W” or whatever.
Your transform will need to analyse that into parts, do the maths, and if returning a number stick the unit back on the return string.

So I did Number:Power to try to make it match the OpenHAB created Items - that seemed like a good idea.

What do I need to add for source formatting in the profile or handling the values in the JS to achieve what you described above?

No idea what you mean, really.

Still making the assumption your channel type is number:power - you’d be well advised to make sure - you get a string like “530 W”.
Usual javascript methods can split a string on the " " character.
Now you can parse the numeric part and do your comparisons.
A little cleverness could scale your number according to other part being “W” or “kW”, the likely values.
If you are going to return a number, put a units string like " W" back on it first.

You might also like to consider what to do if the channel feeds you UNDEF to begin with.

I was thinking this may be something I should be using on the input before handing it off to the JS transform based in what you had said.

But the instructions on what values should be used and how they will work are lacking. The OpenHAB documentation pretty much assumes you are a mature developer it seems - I am just a relatively sharp guy who can reason his way through stuff and copy other peoples work well enough :slight_smile:

An example of the documentation lacking, I had no clue that Number:Power would be a quantity and not a number - I thought I had read through things pretty well and never once came across this distinction.