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:
In reality the value “-1” is 200, and the PIR Function IS actually enabled…
Is it the binding? I don’t know… There where a lot minus-values (or non-set value) issues, and since the kWh-meter is also minus-xxxxx, it was easy to suspect the binding.
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?
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.
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.
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.
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.
Thank you very much @rlkoshak for the very good explanation! Today I started with configuration files, and learned that (for zWave) I don’t need the .things file as it (currently) makes managing devices more complicated, and device configuration is not possible thru them (that would be cool), and then configuration is also not possible via PaperUI / Habmin, if a things-file is used.
So I had a look at the .items docs, and yes I get the concept, but didn’t manage the syntax by the examples, then I read the rules doc, and that they work with items - and since I already have items (auto-created by the zWave binding), I decided to give them a shot first. Because I’m in the state of “collecting proper hardware” and I was eager to try a just-arrived 12-button remote, and it worked, but, like this:
rule "Remote GA"
when
Item zwave_device_a0cc5df2_node28_scene_number received update // funzt, aber bei gedrücktem Button feuert nur ein Event
then
logWarn("Rules", "Node 28 changed: " + zwave_device_a0cc5df2_node28_scene_number.state)
switch zwave_device_a0cc5df2_node28_scene_number.state {
case 12 : { logWarn("Rules", "Node 28: button clicked short")
zwave_device_a0cc5df2_node22_switch_binary.sendCommand(ON) }
case 12.2 : logWarn("Rules", "Node 28: button held")
case 12.1 : { logWarn("Rules", "Node 28: button released") // fires only if 12.2 occurred.
zwave_device_a0cc5df2_node22_switch_binary.sendCommand(OFF) }
}
end
Just my first rule-experiment, and I have to get warm with the syntax…
Of course, I don’t want to use the auto-created item in the rule, instead I want to link it to an “alias” in one place, so if the device changes I only need to update it at one occurrence, as you wrote.
So I do this not in the rule-file, but in the items-file, where I can also give the item additional properties, that’s nice, thanks.
It is not clear to me how this will affect PaperUI / Habmin - will I see lots of “duplicate” items then - the auto generated ones, and my defined ones?
On other question: “DSL” means something like Direct Scripting Language?
Regarding OOP: What I saw today (the built-in scripting, with Visual Studio Code) looks already much much much (ad some more) nicer than what I had with my FS20-system (not too hard, haha), and apart from my very basic JS experience I guess I will stay with the built-in scripting, because the JS-scripting also creates another dependency, which will sooner or later strike back… It’s all complex enough for me, and the time I can put in. And if I read “Experimental” I put my legs into my hands an run as fast as I can. Reason to switch from FS20: Enough experiments, and countless hours of fiddling around. I want a stable and maintainable system. Today I have the impression it could happen with OH.
Regarding Design Patterns: Very interesting stuff! Can’t stop to read - to know how the language behaves, with timers, events, reentrancy, etc pp, that info will save some future headaches for sure, very nice.
Than please for the love of Pete disable Simple Mode (Configuration → System) and Items will not be created for you. To repeat one of the other experts on the forum here, Simple Mode is an abomination.
Disable it, delete all the Items that Simple Mode created and start creating your Model by manually creating Items (either in PaperUI or in .items files). Then you can control what Channel the Item get’s linked to and can change the device by simply changing the Link.
No, get rid of the auto generated ones after turning off Simple Mode. If you haven’t created any Items yourself in PaperUI:
Doing this will delete ALL your automatically created Items (and any Item you created through PaperUI which, if you had Simple Mode on would have been impossible) as well as their links to the Channels.
Domain Specific Language roughly based on Xtend.
The only reason that it is still called Experimental is because the UI for creating Rules in PaperUI is barely functional. But the Engine itself is rock solid and has been around for more than half a decade. When OH 3 comes out, I suspect Python will take over as the default language. Whether you know Python or not, you may as well spend your time right now learning a standard language that will be more of the standard language for OH in the near future rather than learning a custom language not used anywhere else in the world. Eventually we will have a new UI to replace PaperUI and new users who know nothing of programming will get started using the UI to build Rules. When using the UI, you don’t need to write any code at all for simple Rules. And even complex Rules are possible.
You should be able to see in the DP postings that for the most part, Python Rules created in .py files look very similar to Rules DSL. But with Python you will have way more power. And there are lots of problems with Rules DSL that will probably never be fixed which actually makes it less stable compared to Scripted Automation.
tl;dr; If stability is your goal, Scripted Automation is at this point a better choice over Rules DSL.
Ok, I have now created for all devices the .item descriptions.
I think it is good if you have new devices and just want to quickly toy with, effortlessly. And for new users a must have. On the other hand, there’s no chance to make OH work without going into configuration files, and copy required stuff to the right places (rrdj4.persist for example, could be written automatically when the add-on is installed).
And since I know that using the GUI makes nothing than problems, everything works muuuuch better.
From that point of view, I would have saved a lot of headaches, and countless hours of trying, if I where forced to use text configuration from the beginning.
Just if another Mac-user reads this. The path to look at is /openhab xxx/userdata/jsondb/
But… I have still the old items, they are in the UI, and show up as persistence files. The deleted json files have not been re-created, so where is it coming from?
Ahh, the backup folder…
After that the auto-items are gone, but in PaperUI all channels still showed, without values of course, except the ones defined in my .items file:
What now? Brave to death I’ve deleted the org.eclipse.osgi folder inside the cache folder.
Now the odd channels in PaperUI are gone, but all Labels are at their default value - the same as with auto-items:
Edit: I just found a notice I made (too late, untested):
On the OH console: smarthome:items clear smarthome:links clear
Should have the same effect.
Regaring rules: I had a look at that, and I think I will stay at the rules DSL for now, to see what OH3 finally comes up with, and I’m currently not ready (time is also an issue) to add more complexity / learning to what OH2 already requires (learned a lot the last days).
I have persistence finally working (I use your DP) - it was just the wrong path where I put the rrd4j.persist file, because at many occurences people wrote it has to be in the persistence folder, instead of /conf/persistence/). Surely laughable and obvious for experienced user, but not for newbies.
I have the .items file working, and some tiny rules. Sitemaps are on the list, and if I can program a rule-logic for my 12-button remotes, then I’m quite happy already. At that point I can finally secure-delete (military-grade, to be safe) my Windows XP VM, on which FS20 home automation is running (waaay lower learning curve, but at the end a nightmare compared to OH & Z-Wave).
I have now better hardware (reliable), can easily edit rules and maintain the hardware & automation-logic, and OH has never crashed, unlike the FS20-software, which dies silently every few days.
Thanks so much Rich, for all your helpful and understandable explanations & hints to me personally, and what you wrote elsewhere in the forum. It pushed me in the right direction.
Today I started with configuration files, and learned that (for zWave) I don’t need the .things file as it (currently) makes managing devices more complicated, and device configuration is not possible thru them (that would be cool), and then configuration is also not possible via PaperUI / Habmin, if a things-file is used.
