Is there a way to limit the precision of Number-Items?

Setup, Configuration and Use Items & Sitemaps
,
1

My Question: Is there a way to limit the precision of a Number Item even if the binding delivers a higher precision and how to do this?

The Background:

I have a Tempest Weather Station from WeatherFlow running. It is connected via the WeatherFlow SmartWeather Binding from William Welliver using the jar-File in the add-on folder (org.openhab.binding.weatherflowsmartweather-2.5.11-SNAPSHOT.jar).

The Item definition looks like

Number:Temperature   thorTemperature    "Temperatur [%.2f °C]"   (gThor) { channel="weatherflowsmartweather:tempest:HB-00xxxxxx:ST-000yyyyy:temperature" }

I persist the Temperature at every change to an InfluxDB Database and show the results in Grafana. Everything works fine. So far so good.

Strategies {
    everyHour   : "0 0 * * * ?"
}

Items {
    gThor*: strategy = everyChange, everyHour
}

Now my problem: Due to the fact, the precision of the Temperature Value is 2 decimals (%.2f) the temperature changes nearly every minute wich results in a database entry every minute. For me a precision of 1 or even 0 decimals (integer) would be totally fine.

Example: a change from 7 to 8 degrees or 7.5 to 7.6 would be sufficient for me. At the moment the data gathered in influx it looks like this:

[...]
2022-11-13T21:36:24.4Z   6.61
2022-11-13T21:37:24.385Z 6.62
2022-11-13T21:38:24.38Z  6.64
2022-11-13T21:39:24.351Z 6.65
2022-11-13T21:40:24.335Z 6.66
[...]

My idea was to change the dimension of the number item to 1 or 0 decimals, but I haven’t found out how. I spent several hours searching the docs and reading through the forum.

The formatter string [%.0f °C]seems only to effect the display of the data not the precision itself.

Neither

Number   thorTemperature    "Temperatur [%.0f °C]"   (gThor) { channel="weatherflowsmartweather:tempest:HB-00xxxxxx:ST-000yyyyy:temperature" }

nor

Number:Temperature   thorTemperature   "Temperatur [%.0f %unit%]"   (gThor)  { channel="weatherflowsmartweather:tempest:HB-00xxxxxx:ST-000yyyyy:temperature" }

works. The log still shows

23:05:23.914 [INFO ] [smarthome.event.ItemStateChangedEvent] - thorTemperature changed from 6.68 to 6.69

So my question: Is there a way to limit the precision of a Number Item even if the binding delivers a higher precision and how to do this

or

is there another way to solve my problem.

Help would be really appreciated!

  • Platform information:
    • Hardware: Synology NAS
    • OS: DSM 7.1
    • openHAB version: 2.5.7 running on a Synology NAS
    • Tempest weather station from WeatherFlow
    • Binding: org.openhab.binding.weatherflowsmartweather-binding
    • openHAB version: 2.5.7 running on a Synology NAS
2

Yes of course.

Nope. And it would be a silly thing to do.

And what’s the problem with that ?

You post is another XY problem statement.

3

Hello Markus,

thanks for your answer.

Okay … then what would be your not-silly suggestion to solve the problem?

The problem is, that the trigger to write every change into the database fires on the level of a hundredth of a degree. I do not want to flood the database with all those entries I don’t need.

So again my question: How can I achieve to write every change on the level of a degree or the tenth of a degree NOT of the hundredth of a degree ?

Thank a lot!

4

Yes, that is what it is intended to do.

That is probably a lot less overhead than you think. OH users commonly persist every minute regardless.

The problem is not with the Item, it is the value that you (the binding) updates it with.
Modify the update - either with a transformation at the channel (not available in all bindings)
or with a profile on the the link between channel-to-Item

5

Temperature is just one of many data points. I’ll do some calculations. Perhaps you are right.

Thanks a lot! I’ll try to figure out how this might work.

6

Note, the third party Smarthome/J openHAB add-on marketplace has a Round profile as part of the Basic Profiles add-on which will round the value coming from the Channel to the specified number of decimal places.

Of course that will only be available on OH 3. OH 2.5.7 isn’t supported anymore and I would be cautious in making any changes to such a system because when it breaks (not if) you’re going to have to upgrade. More changes means more opportunities for things to break.

As I hope was made clear here, that’s probably not the best idea most of the time. If you always round every value to a couple decimal places, when you do calculations you will get increasingly wrong answers depending on how many calculations and roundings take place. So this should be used with caution.

And I’ll second that if your main concern is the frequency of the database writes, one per minute is hardly a flood. These databases are designed to handle thousands of transactions a second. You are not overworking your database. But even so, since you are using InfluxDB, you could create a retention policy that rounds the values and consolidates those values that are too close after the fact.

1 Like
7

Allow managing persistence configurations and enable filters by J-N-K · Pull Request #2871 · openhab/openhab-core · GitHub will introduce threshold- and time-based filters for persistence services. But that will not happen before OH4 as it depends on Java 17.

5 Likes
8

If there no sense to limit recording into DB the changes do we have a possibility to define a treshold for writing into the log? It’s hard to catch important message in the log when it’s flooded by temperature or voltage changes every .001.

I mean it’s ok to keep records on all temperature changes in DB but see only important (configurable) changes every 1.0 or 0.5 Celsius in the log?

1 Like
9

Not that I’m aware of. The event bus logger doesn’t have any state so it has no idea how much the Item changed from one log statement to the next.

But there are other options:

10

I habe turned off logging for item events complety. I don‘t see any good reason to those in the log.

11

Just out of curiosity - how do you debug your rules then?
And don’t tell me you just don’t make mistakes :smiley:

Do you log the states from the rules?

12

I don’t make mistakes xD.

Seriously: To minimize interference I usually setup the rule on my dev machine with the needed items and then use the console to set the item states. If necessary I log from the rule.

13

Thanks Rich! I’m planning to upgrade to the newest version, but wanted to get the weather data as soon as possible. One of the advantages of OH over Home Assistant is that I haven’t had to do any maintenance work over more than 2 years and the system is still in a stable condition and just works :wink:

Totally agree. I just have no need for the data …

Ah ok, I didn’t know this. I’ll have a look.

Thanks for the advices!

14

Conversely I’ve turned up the logging to events.log to show when my rules are running. But, whenever I’m following the logs, I use filters to get rid of the statements I don’t care about at that time. Everyone has their own approach and they are all good. I’m consistent enough in my naming that I can usually get it necked down to just those Items and rule that are relevant with just one REGEX. I also use multitail which can let me additionally set up a search term that highlights the rows of interest as they occur.

I like this approach (for me, YMMV) because I don’t have to change anything like adding log statements to rules or change logging levels to debug or follow along with what’s happening even as I change what I’m working on drastically from day to day.

I’m also not on an SD card so lots of writes isn’t a problem.

You might say you’ve neglected the maintenance. But, as with a car or a house, when you neglect maintenance now, you will have a lot more work later. You are mainly just delaying the effort, not reducing it in the long run.

1 Like
15

I use a regex filter to remove items that update continuously, such as temperature/humidity/light sensors , as well as other items that I don’t feel the need to see when I’m checking the log.

For example, the TP-Link Kasa binding can control the LED indicators on Kasa switches/outlets. I turn the LEDs off when I go to bed, and on again in the morning. I don’t need to see that in my log.

I’ve also set some handlers to ERROR, so that I don’t see any non-criticial updates from them.

<Logger level="ERROR" name="openhab.event.ItemCommandEvent"/>
<Logger level="ERROR" name="openhab.event.ItemStatePredictedEvent"/>
<Logger level="ERROR" name="openhab.event.GroupItemStateChangedEvent"/>
<Logger level="ERROR" name="openhab.event.ThingStatusInfoChangedEvent"/>
<Logger level="ERROR" name="openhab.event.ChannelTriggeredEvent"/>

It’s easy enough to comment these out from log4j2.xml whenever I’m debugging, since the edit takes effect within a few minutes in OH3 (without requiring a reboot). However, I usually don’t need to bother. I don’t get too complex with my rules, so all I usually care about is if an item state changes.

I suppose I could use WARN with pretty much the same results.

It’s also harder for us to help people upgrade from OH2 to OH3 at this point, since we haven’t done it ourselves in quite some time. As well, there are older discussions about upgrading that are no longer reliable due to subsequent changes.

I don’t think it’s necessary to be on the latest version all of the time, but it’s better to not fall too far behind. I usually upgrade somewhere between 3-6 months after a new version is released.

16

I upgrade every 3-6 days. :rofl:

1 Like
17

You‘re right. I started on OH 1.7 and since then upgraded to every stable release until 2.5.7. However, since I haven’t lived in my home regulary for the last two+ years, I didn’t want to do any updates without being on site. Now I‘m back and looking forward to learn about all the „new“ OH3.x features :star_struck:

18

This is a valid point. I hope I won’t get in too much trouble. One bigger thing for me might be that my whole configuration is file- and not UI based. I started reading migration threads to find out the best strategy, but as you said they might not be reliable for a migration from 2.5.7 to 3.3.

Thanks for your advices!

1 Like
19

Thanks for the answer. I will review filtering options suggested

20

All your 2.5 configuration and approach is still valid for OH 3 with only a few minor breaking changes (maybe more than a few given the time between versions). But you can configure and use OH 3 just like you always have.

But if you want to use some new stuff like MainUI, semantic models, custom widgets, the marketplace, etc. you may want to move some of that stuff to become managed instead of file based.

Be sure to review the Getting Started Tutorial. Even though you are an OH expert, Getting Started shows how to do most of the stuff you already know using MainUI, as well as introducing the new stuff. The people how have the most trouble moving to OH 3 are those who skip Getting Started.

1 Like