I have several wall plugs from Neo Coolcam, NAS-WR01ZE Wall Plug Switch:
These show wrong numbers for the energy measurement:
The number is way to high - a little bit more than twice from what the real used energy is.
Is: 9.0 kWh
Should be: 4.4 kWh
The number toggles always from a decimal number to a strange number, like this:
Wish: Display two decimals.
I do have a couple of those meters as well and there is quite some spread in the accuracy of them.
I never dove into it, because if I do use the measurement I want to track the state of the device and not the exact energy consumption.
Regarding the strange numbers in the kWh measurement, if I do remember correct it was caused by the device itself and not the binding.
Normally this issue is caused by corruption from either the device, or an “over the air” error. The base error detection used in most ZWave devices is pretty poor - it’s just a simple checksum rather than something more robust. Therefore it’s relatively common for data to get corrupted “in flight” and the result is this sort of thing.
Newer devices may use the optional CRC encapsulation to help resolve this but as far as I’m aware it’s not mandated at this time.
And very unlikely in these cheap Chinese devices.
It happens not random, but in a very regularly interval. When the washing machine runs, like 20 seconds the number is “good”, then 20 seconds “-2147…”.
So I think this is not a random data corruption, but some translation issue in OH of the number format, and it displays garbage when the value after the decimal is within X.
Regarding that the “good” value is a little bit twice over the real value: It is probably a side effect of wrong format conversion, but here I could believe another reason, since this equation matches suspicious well:
4.4kWh / 110V * 228V = 9.1 kWh
In Europe we have around 230V voltage…
So IF the device is dumb enough to measure only A, and multiplies this with fixed 110V, then that value would explain.
If you have more information (eg logs) then please provide them. However I think it’s extremely unlikely to be the binding - this question comes up periodically, and every time it’s been the device at fault (or OTA corruption).
No doubt you’ve debugged this, but I’ve not seen the logs to confirm it. Can you please provide the information that supports your statement?
I’ve not debugged anything, only what I observed. I was wrong with that 20-30 seconds, that’s the normal value update… For the kWh-meter it’s about 5 minutes, but always toggles between a good value and a strange value:
2020-05-02 10:04:23.367 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.37 to 8.14
2020-05-02 10:09:22.135 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.14 to -21474828.32
2020-05-02 10:14:04.024 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.32 to 8.18
2020-05-02 10:18:36.811 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.18 to -21474828.28
2020-05-02 10:43:36.136 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to -21474828.28
2020-05-02 11:08:35.041 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to -21474828.28
2020-05-02 11:13:36.825 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to -21474828.28
2020-05-02 11:20:42.704 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.28 to 8.22
2020-05-02 11:43:58.062 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.22 to -21474828.24
2020-05-02 11:47:24.836 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.24 to 8.26
2020-05-02 11:50:08.098 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.26 to -21474828.2
2020-05-02 11:53:35.563 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.2 to 8.3
2020-05-02 12:30:32.901 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.3 to -21474828.15
2020-05-02 12:33:17.479 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.15 to 8.35
2020-05-02 12:36:23.011 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.35 to -21474828.11
2020-05-02 12:41:55.728 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to 8.4
2020-05-02 12:46:23.519 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.4 to -21474828.05
2020-05-02 12:51:22.755 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474828.05 to 8.46
2020-05-02 12:56:22.999 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.46 to -21474827.99
2020-05-02 13:01:23.253 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.99 to 8.52
2020-05-02 13:16:54.909 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.52 to -21474827.93
2020-05-02 13:21:55.162 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.93 to 8.58
2020-05-02 13:26:55.394 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.58 to -21474827.87
2020-05-02 13:30:56.760 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.87 to 8.63
2020-05-02 13:32:51.447 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.63 to -21474827.83
2020-05-02 13:35:07.101 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.83 to 8.67
2020-05-02 13:36:50.833 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.67 to -21474827.79
2020-05-02 13:38:51.518 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.79 to 8.71
2020-05-02 13:40:45.233 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.71 to -21474827.75
2020-05-02 13:45:33.547 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.75 to 8.75
2020-05-02 13:49:26.971 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.75 to -21474827.71
2020-05-02 13:55:17.113 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.71 to 8.79
2020-05-02 14:00:21.360 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.79 to -21474827.66
2020-05-02 14:05:21.603 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.66 to 8.85
2020-05-02 16:44:08.702 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.85 to -21474827.6
2020-05-02 21:34:08.920 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.6 to 8.91
2020-05-03 02:19:09.127 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.91 to -21474827.54
2020-05-03 03:59:08.271 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to -21474827.54
2020-05-03 07:04:08.754 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.54 to 8.97
2020-05-03 08:27:51.754 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to 8.97
2020-05-03 10:03:50.973 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to 8.97
2020-05-03 10:09:08.067 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from NULL to 8.97
2020-05-03 10:17:06.707 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 8.97 to -21474827.49
2020-05-03 11:33:08.776 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from -21474827.49 to 9.02
2020-05-03 16:23:08.661 [vent.ItemStateChangedEvent] - zwave_device_a0cc5df2_node23_meter_kwh changed from 9.02 to -21474827.44
This looks like what the translated data is. Is there a way to log raw data from the device?
But the binding documentation explicitly states to turn on debug logging when things do not go as planned. Without unfiltered debug logs the developer does not have the information needed to determine what is happening.
Interesting. And yet you conclude that the problem is with the binding? I’d strongly suggest to get a DEBUG log - please read the documentation - the binding docs describe what to do! The event log that you are looking at is completely useless here.
Also, please post logs using code fences so that they are well formatted.
Wow, next time I post in the Beginners section, haha. 
I suspected the binding because it shows odd values at other places. It did that a lot in the past, but most of this issues have been cured over the last ~2 years, so that was a software issue for sure…
This is left, in the settings of Neo motion sensors - it doesn’t happen always:
So, regarding the minus-values of the kWh meter, I’ve searched and found some interesting threads. For other users, as reference , it is a bug in the firmware of the Neo plugs, see links below.
Is it maybe possible the filter the nonsense-minus-values for this plug in the binding?
https://www.domoticz.com/forum/viewtopic.php?f=24&t=28987
https://www.domoticz.com/forum/viewtopic.php?f=24&t=26639#p206558
Rules are very customizable for that.
Normally -1 is 255 - this is normal and depends on the interpretation of the numbers from binary.
I’m a little confused. I think later in this post you say it’s not the binding and you refer to other systems. Have you looked at the logs? Or can you provide the logs?
No - this isn’t possible. You would need to do it through rules or something like that. The binding can’t really do this sort of thing as it would severely complicate the binding if we had to start coping with filtering strange values from devices - it’s just not viable.
Understandable (filtering -> complexity).
Regarding -1 = 255: In the normal world it is not normal. How shall the user know?
Regarding confusion: I just tried to explain why I suspected the binding - it did those minus-values in the past at other occurrences, but as we now know, it has nothing to do with the kWh-meter issue.
Regarding the log - I think it is useless, now that we know it’s the plug’s firmware, but anyway, I’ve learned how to enable it
2020-05-03 18:07:02.389 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Initialising cmd channel zwave:device:a0cc5df2:node23:meter_kwh for DecimalType
2020-05-03 18:07:02.389 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 23: Version = 4
2020-05-03 18:07:02.390 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Initialising state channel zwave:device:a0cc5df2:node23:meter_kwh for DecimalType
...
2020-05-03 18:07:18.202 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 23: Received COMMAND_CLASS_METER V3 METER_REPORT
2020-05-03 18:07:18.202 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 23: Meter: Type=Electric(1), Scale=kWh(0), Value=-21474827.44
2020-05-03 18:07:18.202 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got an event from Z-Wave network: ZWaveMeterValueEvent
2020-05-03 18:07:18.202 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_METER, value=-21474827.44
2020-05-03 18:07:18.202 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 23: Updating channel state zwave:device:a0cc5df2:node23:meter_kwh to -21474827.44 [DecimalType]
2020-05-03 18:07:18.203 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 23: Commands processed 1.
This is from another node, which is just by coincidence showing a “good” number:
2020-05-03 18:16:37.015 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 21: Received COMMAND_CLASS_METER V3 METER_REPORT
2020-05-03 18:16:37.015 [DEBUG] [.commandclass.ZWaveMeterCommandClass] - NODE 21: Meter: Type=Electric(1), Scale=kWh(0), Value=7.88
2020-05-03 18:16:37.016 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Got an event from Z-Wave network: ZWaveMeterValueEvent
2020-05-03 18:16:37.016 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_METER, value=7.88
2020-05-03 18:16:37.016 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 21: Updating channel state zwave:device:a0cc5df2:node21:meter_kwh to 7.88 [DecimalType]
2020-05-03 18:16:37.016 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 21: Commands processed 1.
If you want the full log, let me know.
Thanks. 
You could use a programmers calculator.
The log is filtered, so it’s not of any use to me here since all we see is the data AFTER the binding has processed it. However if you’re happy then let’s leave it at that.
Offtopic: So far I’ve just collected hardware and waited until it got functional (another story) and played only with PaperUI and Habmin. Rules didn’t work well when I tried them 1,5(?) years ago… Actually more things are NOT working well, or not at all (ie Charts).
In the long run I want to program everything by hand (wasted countless hours with non-working things-files, until I found out they require ASCII char 13 on a Mac, haha - another story).
So, I was more an observer than a real OH user, and I’m still using a very old FS20-system for my home automation.
Can I get to the question, pleeeeaase? Oh, yes, of course: Rules are nice, but is it possible in OH to program in an object oriented manner?
For example, I would like to make (or handle) the things as objects, with encapsulated functionality (like the filtering of odd values from the hardware), so the code doesn’t become spaghetti, like it is with my FS20 system…
Some people use Node-Red with openHAB. openHAB itself is not designed to be object oriented. The newew Jython automation might work though. Any comments on that, @5iver?
Indicator of something weird happening.
Items should not get set to NULL except at system startup.
It is possible to force NULL by rule.
Bindings can indicate problems by setting UNDEF, and should not set NULL, but it’s not impossible.
However both of those methods would leave a record of changed from xx to NULL- which is absent.
This Item has multiple times been silently changed from blah to NULL, we only see the change from NULL to blah.
Conclusion, Item is being initialized at some time in the same way as at system boot or Item editing.
(There won’t be a log of that because it doesn’t get on the event bus)
My betting is it is actually due to an associated Thing change event (not a Thing status change) which nowadays seems to trigger boot-like behaviours.
Have a look at unfiltered events.log preceding one of those changed from NULL records.
You could use a programmers calculator.
It’s not the first time that I oversee the most obvious and easiest solution.
The log is filtered, so it’s not of any use to me here since all we see is the data AFTER the binding has processed it. However if you’re happy then let’s leave it at that.
Hmm, happy, no, but I guess there’s nothing you can do about, as other software has the same problem. Anyway:
(Sorry, there was an error uploading that file. Please try again.)
I tried again, but it doesn’t work. Can I send it by email?
Yes but it’s important to understand the layers of abstraction built into OH. You can write Rules in an OO way if you choose if you use Scripted Automation where you can write Rules using Python, JavaScript or Groovy, all three of which I believe support OOP. But Rules almost never directly interact with Things. And they are defined complete independently from the Things.
As described in the docs, Things represent the device. Each sensor and each actuator on the device is represented by a Channel.
Items get linked to those Channels. Items are where you model your home automation. Items are where you give Zwave Node 23’s Switch a meaning (e.g. Switch Livingroom_Lamp) and representation (icon, label). When using scripted automation, you can also define metadata on the Item where you can define information that a Rule may need (e.g. the brightness to use for that Item at a certain time of day).
Rules, Sitemaps/HabPanel, Persistence, Charting, etc all work at the Items level.
Rules are event driven. An Item update, command, or change can trigger a Rule to run in response to that change. The way you code the response can be OO if you choose to do so, but you will not be coding Rules directly connected to your Things definitions or even your Items definitions. Rules are defined separately and if they are connected to anything at all, its connected to events that may occur. And that’s on purpose and a good thing. The abstraction from connection to the devices to the behaviors allows you to write your behaviors (i.e. rules) in a more generic and uniform way. For example, you can have one Rule that handles Hue, Shelly, and Zwave lights because all of them are represented using a Color Item so all are interacted with in the same way from Rules.
Your goal when writing Rules should be to make it so that if you change out hardware (e.g. switch from a Nest to an Echobee thermostat) the Rules don’t need to be touched. You set up the new binding, link your existing Items to the channels on the new Thing and are done. The Rules don’t change because the Rules don’t care what device Items are connected to (i.e. linked to a Things’s Channel). They just need to know that the current temperature is represented by a Number:temperature Item.
Furthermore, your goal in writing Rules should be to make them generic so if you add or remove devices you don’t have to change the Rules either. Look at the Design Pattern postings for lots of examples in both Rules DSL and Python.