Problems at reducing item-changes with REGEX

Setup, Configuration and Use Items & Sitemaps
1

Hi there,

I’m using OH4.1.0 and I’m impressed by the stability of the system - thanks for your great work.

My problem - I try to optimise the system a little bit and want to reduce change-count of items. In bindings like dwdunwetter, shelly or systeminfo there are many changes of items (windspeed or temperature) in decimal area. I don’t need this high precision.

I tried to use REGEX to cut the first numbers - but no one of the following lines works successfully:

Number:Temperature      Sensor_CPUTemp             "CPU Temperature"     <temperature> (GrpSYSmem) { channel="systeminfo:computer:raspi2:sensors#cpuTemp" [stateTransformation="REGEX(s/.*(\\d*)\\..*/$1/)"] }

Number:Temperature      Sensor_CPUTemp             "CPU Temperature"     <temperature> (GrpSYSmem) { channel="systeminfo:computer:raspi2:sensors#cpuTemp", REGEX="s/.*(\\d*)\\..*/$1/g" }

Number:Temperature      Sensor_CPUTemp             "CPU Temperature"     <temperature> (GrpSYSmem) { channel="systeminfo:computer:raspi2:sensors#cpuTemp", REGEX:(s/.*(\\d*)\\..*/$1/g) }

I can’t see any change in the Logfile. Have anyone an idea?

((change: use now the code fences for posting the code. thanks))

Log example:

2024-01-28 09:35:57.912 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'Sensor_CPUTemp' changed from 38.5 °C to 39.4 °C
2

Please use code fences when posting code, configs, and logs.

```
code goes here
```

I’d do this with a script transform and round the value instead of just throwing away the decimal part.

If we don’t care about errors when the update is NULL or UNDEF it can even be an inline script. In JS it would look something like this.

JS(| Math.round(parseFloat(input)))

I can’t say why the REGEX isn’t working but it’s important to understand that OH REGEX transform doesn’t support everything that a REGEX can do and it works oddly in some cases. Were I to use REGEX it would look something like this:

REGEX((\d+)\.?.*)

This assumes there is no space or anything like that before the number starts. The first matching group is what the REGEX returns.

3

Is your system sluggishly slow which prompted you to look at things to optimise?

If so, adding filters might add extra pressure on your CPU.

If it is just for output formatting so you won’t see the decimal points in your main UI or sitemap, you could simply use state formatting instead.

Now let’s solve your original problem, even though I don’t think it’s the correct approach.

Number:Temperature Sensor_CPUTemp "CPU Temperature" (GrpSYSmem) { channel="systeminfo:computer:raspi2:sensors#cpuTemp" [profile="transform:REGEX", function="(\d+)\.?.*"] }

I haven’t tested the regex, so have a play with it. Using s// is also possible

This assumes that your decimal point is a dot, not a comma.

You could also use Js or RB transform but that’s a more expensive way of doing it especially if your system is slow (eg rpi3 2gb ram?)

Discarding the decimal points won’t save you any CPU cycles. It adds more.

Letting the decimal points through without filtering, then using a display format is a better approach

4

Thanks for your inspiration. It seems I have found a solution:

Number:Temperature      Sensor_CPUTemp             "CPU Temperature"     <temperature> (GrpSYSmem) { channel="systeminfo:computer:raspi2:sensors#cpuTemp" [profile="transform:JS", toItemScript="roundItem.js"] }

and the JS-script:

(function(i){
   //var log = Java.type("org.slf4j.LoggerFactory").getLogger("org.openhab.model.script.roundjs");
   if (i != null) {
      //log.info("CPU round runs")
      var arrayOfStrings = i.split(" ");
      var resultvalue = Math.round(parseFloat(arrayOfStrings[0]));
      if (arrayOfStrings.length > 1) {
         resultvalue = resultvalue + " " + arrayOfStrings[1];
      }
      //log.info("CPU round runs: " + resultvalue);
      return resultvalue;
   } else {
      return 'ERR';
   }
})(input)

Looks good in the log up to now.

thanks

5

I didn’t say it in my reply but she with everything @JimT said about the approach over all. If you are trying to reduce CPU cycles this is going to make things worse. Better to let the values through unfiltered.

If you are trying to avoid decimal places in the UIs, the state description pattern is a better approach.

If you want to prevent these from being saved to persistence there are filters you can add so only changes above a certain amount get saved.

If you want to keep them out of event.log, a filter in log4j2.xml is a better choice.

This transformation has some areas for improvement.

  • i will never be null so there’s no need to test for that. However it is theoretically possible for the binding to send “NULL” or “UNDEF” which you can test for and return unmodified from the transform instead. Returning “ERR” is just going to generate an error in the logs.
  • Assuming the split and such is to preserve the unit, you can use Quantity instead of String manipulation to preserve the unit. I don’t know if it saved much code but it might be more clear.
6

Hello,

Thanks for this advice. My thought: For example, when there are temperature changes, Rules are triggered at every item change in decimal parts (which check if a threshold value is exceeded and, if necessary, report an alarm). Therefore, I wanted to achieve three things at the same time:

  • Reduction of rule calls by minimizing item changes
  • Minimizing of log entries (protects the write cycles of the SD card)
  • Minimizing of persistence entries in the influx DB
    In your opinion, are the goals achievable via “transform” or should I do config changes in several configs?

(Hardware: raspberry 4, 2G ram, Linux 6.1.0-rpi7-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64, openjdk version “17.0.9” 2023 -10-17 LTS, 64-bit Server VM Zulu17.46+19-CA, Openhab 4.1.0 stable - unfortunately I read too late that 64bit Java shall have performance problems on a Raspberry)
​
I made another observation: when I make the transform entry in the items file, the Openhab system does not respond to the change. After restarting Openhab it works as desired. Is it wanted like that?

7

Which gets replaced with calls to a transformation. And in your case it’s a JS transformation which “costs” exactly the same to invoke as it “costs” to trigger a rule, only now when the change is big enough for the rule to run you have to run the equivalent of two rules. You’ve not saved anything. You’ve just guaranteed OH will be doing more work all the time.

If you are using a standard openHABian config, logs are written to zram which do not touch the SD card.

If not, then maybe you should consider an HDD or SDD. Or you can filter those “noisy” log statements out of the logs entirely. If you are running straight off of and SD card I recommend turning events.log off completely. I wouldn’t have InfluxDB running on this machine either.

You can do this through a persistence filter now.

Not so much performance problems. In fact 64-bit improves the first run performance of JS Scripting/Blockly rules and transforms. However, 64-bit requires more RAM and on an SBC like a RPi, the most limited resource is often RAM.

It should pick up the changes immediately. But there have been some problems/PRs related to that over the past few months. Maybe it’s not working. I find text file configs to be a time sink so avoid them.

8

You could try renaming the items file instead of restarting openhab. E.g system.items to systems1.items

It was a bug, or perhaps wasn’t intended to be as thorough in checking for changes. I’m not sure when the fix was merged and whether it fixed/detected when profiles changed.

9

Thank you for your inspiration and food for thought. I will configure the log directory as zram soon.

What I like about the text-based configuration at OH is that I can easily add, update and remove things/items etc. in a bulk - and do it in a very organized way.
When upgrading to a new OH major version, I always do a clean install with raspbian, configure all other required services and at the end openhab. With the OH4 I only needed about 1 hour to activate, debug and correct all the items and rules one after the other. So I haven’t needed a real restore yet.
What I noticed: with openhab-cli backup, the influx-db used as persistence is not backed up. This is a pity.

1 Like
10

+1000

Unfortunately, influxdb isn’t part of openhab. openhab-cli should only deal with things within the openhab itself. However, if you are using openhabian, and if it installed influxdb for you, I think it would be very handy if it also offered a way to back it up and restore it.

11

I can do the same, with Items particularly but also with Things and Rules.

But I also don’t have to do this very often. If I did it all the time maybe I’d have a different opinion. But if I had to do it all the time I probably wouldn’t stick with OH in the first place as it’d be too unstable.

The time lost to using the UI where a text file would be more effecient is tiny compared to the time spent rooting through the docs, searching for examples, and fighting the syntax errors that make their way into the files no matter how careful one is. There are also missed opportunities because unless you watch the readmes and announcements and PRs you won’t even know about new options that have become available.

It’s just not worth it. But everyone has their own preferences. Go do you. But I’m not going to help fight other’s syntax errors any more (I stopped after finding myself spending most of my time here on the forum helping people shoehorn their Items into the semantic model because of misused or misspelled tags and other similar problems that are impossible to have when working through the UI). I want to fight home automation problems, not missing commas and wrong case, or going through all sorts of work because of ignorance of a new option that does exactly what is needed.

I would expect that would not be refused as a PR. It’s not that hard really, but backing up DBs like that usually require an export/import of the data rather than just taring up a folder, so it’s a little more involved.

12

There seems to be a small fundamental discussion - I didn’t want to trigger that.
I’m still developing my home automation world and had already tried to do it via the GUI with OH3. I use a lot of Shelly’s and ZigBee devices - the optimal solution for me in terms of rule logic including the use of proxy items was really easier for me to master with the files. I’m currently at the point where automation has reached a very good level and I can slowly get more involved with the other options (will probably be the case next winter). Rich - you’re way ahead of me. But I’m still following you… :wink:
Thank you for your and JimT’s help and suggestions - that helps a lot and it’s really great that there are advisors like you. :+1: :+1: :+1:

13