I’m up and running on #3455 and I’m starting to see periodically a new warning from rrd4j.
2023-05-11 09:41:31.054 [WARN ] [d4j.internal.RRD4jPersistenceService] - Could not persist 'Dads_Motion_Timeout' to rrd4j database: Bad sample time: 1683819690. Last update time was 1683819690, at least one second step is require
Now, this could be related to a time problem. When I rebuilt my VM recently OH was running for a little bit using the wrong timezone. I’ve since fixed that problem but there was likely some data stored with a bad timestamp because of that. I only mention that in case it’s relevant.
However, the Item it’s complaining about above was never saved when the timezone was bad. So this warning is not caused by the timezone issue.
Also, what’s weird is that the sample time and last update time are the same.
The warning doesn’t occur every time the Item changes or every time the state is persisted. I can’t quite find the pattern. I can say that the warning above occurred the very first time the Item received a non-NULL state but not anytime after that (so far).
But I’ve updated other Items from NULL to another state and not received the warning.
This might be related to the latest refactoring to prevent performance problems in persistence. It would be great if you could come up with a way to reproduce that (a good chance, like 1 out of 10 would be sufficient).
I confirm I saw the same appearing from time to time since some days. As stated by @J-N-K , I suspected it to be related to persistance refactoring that took place past week.
Yes, working on something. Maybe if I can set up a loop to spam a test Item with changes I can force it.
I’m now on #3459 which seems to now have the new units and I’m fighting some weirdness there. Apparently Bq/m³ isn’t supported anymore (I’d rather use pCi/L anyway but that’s never been supported)?
It also doesn’t like my date time format string pattern for Number:Time Items any more.
2023-05-12 08:08:37.892 [ERROR] [rg.openhab.core.types.util.UnitUtils] - Unknown unit from pattern: %1$tH:%1$tM:%1$tS
If possible it would be nice if that error from UnitUtils would report the Item name too, though I’ve only got one Item that do this so I know what Item it is. Others might not be so lucky. Though you can use the developer sidebar now to search in metadata so searching for “%1$tH:%1$tM:%1$tS” will find the Items with that pattern in metadata.
I’m also seeing errors from some units that should be a problem, like:
2023-05-12 08:15:47.898 [ERROR] [rg.openhab.core.types.util.UnitUtils] - Unknown unit from pattern: ॰F
I’ve not tried the upgrade cli tool yet though. I did add Bq/m³ as a new unit metadata just to see what would happen and it still doesn’t like it.
More to follow once I run the upgrade tool to see what happens.
What dimension do you use for Bq/m3? I don’t think we have something that fits „specific activity“. In that case you can use a plain number item and put the unit in the state description (but lose UoM support),
If that is a common use-case, we can add a dimension for that.
Regarding the Fahrenheit error: it seems the the character before the F is not correct. Can you check that?
It was never listed as being officially supported but I tried it once just to see if it would work given units like W/m² exist in the docs. Surprisingly it seemed to work!
Note, they way I’ve implemented it was:
Added Bq/m³ as the unit in the MQTT Channel Config.
- id: radon_st
channelTypeUID: mqtt:number
label: Short Term Radon Average
description: ""
configuration:
stateTopic: waveplus_bridge/basement/radon_st
unit: Bq/m³
Set the State Description Pattern to %.0f Bq/m³.
I tried to add a transform to convert it to pCi/L but found that unit isn’t supported at all. I essentially did it the same as described above but Bq is the only supported unit for Radioactivity and it wasn’t important enough to me to file an issue. It’s just kind of annoying that the AirThings Wave+ shows in the app pCi/L but actually reports over the BTLE Bq/m³ for some reason.
I’ll definitely find a workaround, even if it’s to just revert to a unitless Number and just use the State Description (at which point I’ll add back in that transform).
But I might not be the only person using a slightly off the books unit that used to work but may no longer work.
I live over granite. As granite decomposes it releases radon which can cause lung cancer if the levels are high enough for long enough (before mitigation we were seeing levels around 4 pCi/l/100 Bq/m³. I have radon detectors to help keep track of the level and ensure that our mitigation is working (it’s basically a fan that sucks the air from under the foundation and vents it above the roof) and OH alerts me if there’s a problem.
A quick question about the upgrade tool. Does OH need to be stopped before running it or can it work on a running OH instance? I’ll add a note to the docs either way.
For the radioactivity Items I stripped out the units and am just using a plain number for now and things seem to work just fine. I still see my Bq/m³ in the UI. I have a rule to update but that’s not a big deal.
Number:Time State Description
For the Number:Time Item though I’m seeing unexpected errors though from UnitUtils.
Previously I was seeing:
2023-05-12 08:08:37.892 [ERROR] [rg.openhab.core.types.util.UnitUtils] - Unknown unit from pattern: %1$tH:%1$tM:%1$tS
Thinking the problem was that this type of formatting was no longer supported I decided to do some experiments. I create a JS transform to convert the seconds to the above format and I set the unit metadata to s.
The error persists.
2023-05-12 10:51:54.348 [ERROR] [rg.openhab.core.types.util.UnitUtils] - Unknown unit from pattern: JS(config:js:secsToStr):%s
Note, I didn’t check before but now I suspect that the original formatting was working (confirmed, I don’t need the JS transform to see HH:MM:SS and can use the date time formatting after all) and the problem is UnitUtils doesn’t know how to handle a State Description pattern that is more than just the units.
But what’s odd is shouldn’t it be using the unit metadata since it’s present? Why does it care what the State Description is when the unit is defined?
rrd4j
I still need to create a rule to see if IO can reproduce it but if I’m interpreting the sample time correctly, the error occurs when the sample time is less than 1 second from the last time a record was saved/created in rrd4j. However everything I’ve tried to force it to happen has failed.
created a Number Item TestNumber
rrd4j default persistence strategy so this Item should get saved. Verified that TestNumber.rrd exists
update the Item
a. 10 times as fast as possible
b. 100 times as fast as possible
c. 1000 times as fast as possible
d. 10 times with one second between updates
e. 10 times with half a second between updates
f. 10 times with 100 msec between updates
g. 10 times with 1100 msec between updates
h. 10 times with 999 msec between updates (Bingo, got it to happen once)
Running this script, at least on my system, causes the error to occur one in every five executions of the rule.
This has worked since openHAB 3.4 to 4.0.0.M2 (I’m not on the latest snapshots yet to test with the new units stuff). The binding posts in becquerels, and OH converts it internally to pCi. I don’t remember the units being per cubic meter though.
from above, I still can not install and uninstall persistence services from the UI
Can someone give me a hint about how to manually uninstall RRD from karaf or something
ok well now on 3460
See how it goes. Oddly now Influxdb is already installed and RRD is not
RRD4j: This happens when three state updates occur in two seconds. What happens is:
first state arrived and is persisted with t=1.
second state arrives 700ms later (t=1.7, truncated to 1): add-on detects the same timestamp and schedules a new attempt in 1s
third state arrives about 700ms (t=2.4) later and is persisted with t=2
the scheduled attempt for the second state is executed (t=2.7, 1s after the initial attempt, truncated to 2) and fails again because the third state was already persisted with t=2. Since this was already a second attempt, the warning is printed.
This is a bit more strict than before, where there were unlimited re-tries. I’m not convinced that this is better, because the “original” timestamp and the finally persisted timestamp could be very far apart for fast-changing items.
That would mean that some states could be not persisted in case you have more than one state update per second.
Not sure to understand your conclusion. Do you mean that it is better now because there is no unlimited re-tries ?
Queuing states and rescheduling a task every second until the queue is empty would be a solution. But I see a risk to make the queue always bigger and bigger in case the state is updated every 500 ms for example.
PS: I was not aware of these unlimited re-tries in the current version.
I guess because this is a rare case and the queue never fills up until all memory is consumed.
IMO a second state update in a second should be discarded right away and not retried at all. It’s just not supported by RRD4J to have so frequent state updates.
But it is probably important to have the most recent state persisted, for example for restore on startup. That was probably the intention behind the retry ?
Let’s take the Number:Time Item. It gets populated from the NUT Binding and represents how long the battery should last given the current load. The value is reported from the binding as seconds (which is the default for Time I think).
On the Item’s State Description I have “%1$tH:%1$tM:%1$tS” configured as the pattern, same as I’ve always had.
When I started to see the error I figured the problem was that it couldn’t figure it the unit because the pattern doesn’t mention the unit. So I manually added unit metadata to set the Item’s unit to "s’. The error persists.
I then tried to replace the date time formatting pattern with a JS transform but UnitUtils still didn’t like it, again pregnant because the unit still isn’t mentioned in the pattern.
It appears to generate the error every time the Item changes.
The Item metadata:
stateDescription
value: " "
config:
pattern: "%1$tH:%1$tM:%1$tS"
unit
value: s
config: {}
Item
label: Battery Runtime
type: Number:Time
category: time
groupNames:
- UPS
groupType: None
function: null
tags:
- Measurement
- Power
Since the error occurs during an update and not when loading it I. MainUI I’m assuming that it’s not caused by a widget. But just in case I have the following default list item widget
