Strange numbers in kWh-meter display of NAS-WR01ZE

Setup, Configuration and Use Beginners
21

Thank you very much @rlkoshak for the very good explanation! :smiley: 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. :wink: 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.

Thank you again. :slight_smile:

22

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:

  1. stop openHAB
  2. navigate to /var/lib/openhab2/jsondb
  3. delete org.eclipse.smarthome.items.Item.json
  4. delete org.eclipse.smarthome.thing.link.ItemChannelLink.json
  5. restart openHAB

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.

2 Likes
23

Just to close this out - the log processing showed the message was corrupted as received by the binding -:

2020-05-03 18:14:56.162 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0C 00 04 00 19 06 31 05 03 0A 06 68 BB

The important bit is here -:

31 05 03 0A 06 68

31 05 is the command
03 is sensor type (luminance)
0A is scale=1, size=2
06 68 is the data = 1640 decimal / 10 (scale=1) = 164.0 = 1.64E+3

2020-05-03 18:14:56.165 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 25: Got a value event from Z-Wave network, endpoint=0, command class=COMMAND_CLASS_SENSOR_MULTILEVEL, value=1.64E+3
1 Like
24

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ā€¦ :crazy_face:
image

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:

Screen Shot 2020-05-07 at 20.59.56
Screen Shot 2020-05-07 at 20.59.56312Ɨ1114 43.4 KB

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:
image

Ahhh, once again, an OH-restart:

image
image942Ɨ606 57 KB

All fine now.

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. :slightly_smiling_face: :+1:

2 Likes
25

Hi, I have the same issue with negative energy values (based on firmware issue with flipping integer value) and solved it in my system (openHAB release 4.1.1) with a profile in the channel - item - link:
grafik
Maybe it will help someone else too ā€¦