Influxdb persistence adds decimal to the end of number items


(l1t7l3ph0o7) #1

Hey all, I just did a complete fresh install of openhabian on my rpi3b+ I decided to try out the influxdb + grafana in the options and opted to setup influxdb persistence. I enjoy the configuration a lot, the only problem I have is the decimal .0 is added to every number item I have when states are restored from persistence. I have a few rules that require it to not have a decimal after the number.
Is there a way to stop influxdb from adding the decimal when restoring item values?


(Rich Koshak) #2

I’m pretty sure the answer is no. InfluxDB has recently (last six months or so) made it so all numbers are stored as floating point numbers. If you don’t want the decimal points, you need to use some other persistence for restoreOnStartup. I recommend using MapDB for restoreOnStartup. It is faster and doesn’t grow because it only stores the most recent value.


(Scott Rushworth) #3

I have seen this too for quite a while in 2.4 snapshots, using JDBC-MariaDB, so I don’t think it is specific to InfluxDB. Very annoying when expecting an integer. Sounds like a good candidate for inclusion in the 2.4 release notes, assuming it is expected behavior. :slight_smile:


(Angelos) #4

could this: https://github.com/eclipse/smarthome/pull/6459 be the reason of the changed behavior?
i quickly checked the code here but I couldn’t identify what could cause this


(Scott Rushworth) #5

Based on the date, I’d say no. I’ve seen this for maybe 6 months… maybe more. I’d looked through the code and PRs a few times, but never spotted anything. I haven’t had a chance to run OH in an IDE to debug it. If I were to guess at a cause, it would be something to do with a change made for UoM.


(Angelos) #6

so: a temp value of 25 (integer) is getting persisted as 25.0 (float) or it is stored properly as 25 and then restored with a decimal?

I would expect that the Number Item state gets updated from its binding with a float to begin with… is this what you have seen also? (this could be linked to the UoM then, especially when using Number:Temp etc)

edit: I checked all my Number Items states and I see various results… some states are with integers, some with float… even when using the same binding… strange
It seems that whenever the binding has reported a value, the Item state uses a float. I have few integers but these Items don’t get state updates.


(Scott Rushworth) #7

For me, it is only Number Items that are always displayed with at least one decimal place, so 25 is 25.0. Dimmer Items are displayed properly. Some of my Items are not linked to Channels, and are not using UoM, but still behave this way. The data is stored without the decimal place, but the REST API and persistence service (Item states, logs, UIs, etc.) have the decimal even if stored as TinyInt. I looked back through a few years of data, and there were decimals (PersistenceViewer), but not when I went directly into the database.

EDIT: In looking at my database, Dimmer Items are stored as tinyint(4) and Number Items are stored as double. I’ve updated some of them for Items that hold integers to tinyint to see if this will change things… I suspect it will. Still a bug, but possibly a workaround.