openHAB 4.0 SNAPSHOT discussion

ccutrer · May 12, 2023, 6:36pm

I totally use pCi with my Airthings Wave+! I have mine coming in via MQTT though. I add the units via a Ruby script:

def self.tech
  Java::Tech
end

PCI = tech.units.indriya.unit.TransformedUnit.new(
  "pCi",
  tech.units.indriya.unit.Units::BECQUEREL,
  tech.units.indriya.function.MultiplyConverter.ofRational(37, 1000)
)
tech.units.indriya.format.SimpleUnitFormat.instance.label(PCI, PCI.symbol)

And my item:

Number:Radioactivity Bunk_Radon "Bunk Room Radon [%.2f pCi]" <gas> (eBunkAirthings, gInflux, gMapDB) ["Measurement"] { channel="mqtt:homie300:mosquitto:airthings:2930082615#radon_2Dshort_2Dterm_2Davg" }

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.

J-N-K · May 12, 2023, 6:37pm

I have added “Ci”, “mCi”, “µCi” and “nC”. Will add “pCi” as well. “pCi/l”. should also work (at least “nC/l” does, there is a test for that).

rlkoshak · May 12, 2023, 6:42pm

Me too. I use GitHub - Drolla/WavePlus_Bridge: Airthings Wave Plus Bridge to Wifi/LAN and MQTT. I was trying to use pCi/L at the binding though, not adding it through a rule. Maybe that’s the difference.

Andrew_Rowe · May 12, 2023, 9:45pm

Is the fix for RRD persistence merged yet?

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

J-N-K · May 13, 2023, 8:27am

Regarding the UnitUtils: what exactly did you configure where? I would like to check why UnitUtils is called.

J-N-K · May 13, 2023, 9:14am

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.

Lolodomo · May 13, 2023, 4:42pm

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.

J-N-K · May 13, 2023, 4:51pm

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.

Lolodomo · May 13, 2023, 5:10pm

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 ?

rlkoshak · May 14, 2023, 3:25am

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

value: ""
config:
  icon: f7:clock
  iconColor: '=(Number.parseFloat(items.UPS_BatteryRuntime.state) < 600) ? "red" :
    (Number.parseFloat(items.UPS_BatteryRuntime.state) < 1800) ? "yellow" :
    "green"'

Andrew_Rowe · May 14, 2023, 10:37am

I’ve updated to snapshot 3460. I’m still seeing CPU usage go to 100% as discussed in this thread RRD is shown as not installed and influx is installed. Using the work around in that thread, setting safeCall to 100, brings things back under control
I’m wondering why no one else is reporting this issue. Is it something unique to my set up?

J-N-K · May 14, 2023, 10:52am

Which persistence do you use? It could be that others suffer the same issue.

JimT · May 14, 2023, 11:03am

I’m on snapshot version before the new unit metadata. openhab (java) is using < 2% CPU - most of the time it’s 0% CPU, 25G virt, 10G Res.

I haven’t changed my safeCall settings or anything special that I can recall because this hasn’t been an issue for me thankfully.

my addons.cfg:

package = minimal
legacy = false
binding = mqtt,airquality,astro,chromecast,lgwebos,mail,telegram,openweathermap,daikin,ipcamera,fronius
ui = basic
persistence = mapdb,influxdb
automation = pidcontroller,jythonscripting,jsscripting,groovyscripting,jsscriptingnashorn,jrubyscripting
transformation = jsonpath,map,regex
misc = openhabcloud

Andrew_Rowe · May 14, 2023, 11:08am

I was running snapshot 3416 and as reported here above I could not uninstall RRD or install influx. When I installed snapshot 3460 I found RRD was uninstalled and influx was installed???

Andrew_Rowe · May 14, 2023, 11:15am

When it is not running away typically I’m seeing single digit CPU usage myself

Everything in my addons.cfg is commented out except

package = standard

J-N-K · May 14, 2023, 11:48am

That’s really strange but I believe it is somehow related to Hue and UPnP, because it complains about a missing requirement org.openhab.core.config.discovery.upnp.

Andrew_Rowe · May 14, 2023, 12:21pm

You could be right Jan, I saw the mention of Hue in the warning
I have Hue binding installed and it works.

Mark_VG · May 15, 2023, 12:59pm

Hi

I have been seeing these warnings - I have not updated SNAPSHOTS since M2:

14:48:52.157 [WARN ] [.core.thing.internal.ThingManagerImpl] - A thing handler factory claims to support 'systeminfo:computer-MARK-HA-PC' for thing 'systeminfo:computer:MARK-HA-PC' for more than 120s, but the thing type can't be found in the registry. This should be fixed in the binding.
14:48:52.191 [WARN ] [.core.thing.internal.ThingManagerImpl] - Could not normalize configuration for 'systeminfo:computer:MARK-HA-PC' because the thing type was not found in registry.
14:48:52.215 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'systeminfo:computer:MARK-HA-PC' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
14:48:54.916 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'systeminfo:computer:MARK-HA-PC' changed from INITIALIZING to UNINITIALIZED
14:48:54.916 [WARN ] [.core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'harmonyhub:device:MarkHub:60277394' are missing in the respective registry for more than 120s. This should be fixed in the binding.
14:48:54.917 [WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'harmonyhub:device:MarkHub:60277394': {thing/channel=Type description for {0} not found although we checked the presence before.}
14:48:54.918 [WARN ] [.core.thing.internal.ThingManagerImpl] - Channel types or config descriptions for thing 'harmonyhub:hub:MarkHub' are missing in the respective registry for more than 120s. This should be fixed in the binding.
14:48:54.918 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:device:MarkHub:60277394' changed from UNINITIALIZED (NOT_YET_READY) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
14:48:54.919 [WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'harmonyhub:hub:MarkHub': {thing/channel=Type description for {0} not found although we checked the presence before.}
14:48:54.921 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'systeminfo:computer:MARK-HA-PC' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
14:48:54.925 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:hub:MarkHub' changed from UNINITIALIZED (NOT_YET_READY) to INITIALIZING
14:48:54.927 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:hub:MarkHub' changed from INITIALIZING to UNKNOWN
14:48:54.928 [WARN ] [.core.thing.internal.ThingManagerImpl] - Failed to normalize configuration for thing 'harmonyhub:device:MarkHub:60277394': {thing/channel=Type description for {0} not found although we checked the presence before.}
14:48:54.929 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:device:MarkHub:60277394' changed from UNINITIALIZED (BRIDGE_UNINITIALIZED) to INITIALIZING
14:48:54.932 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:device:MarkHub:60277394' changed from INITIALIZING to UNKNOWN
14:48:54.932 [INFO ] [hab.event.ThingStatusInfoChangedEvent] - Thing 'harmonyhub:device:MarkHub:60277394' changed from UNKNOWN to OFFLINE (BRIDGE_OFFLINE)

I think I saw something that indicated these were Binding issues? But I think these are common Bindings so would have been fixed by now?

Anyone have any advise?

ccutrer · May 15, 2023, 1:20pm

Those are just warnings having to do with dynamic thing and channel types. You can ignore them. In your case, those two bindings should be good to go in the latest snapshot - I just saw their PRs go through to save their type metadata to storage.

Mark_VG · May 15, 2023, 1:37pm

Thank you. I tried to find anything under the binding but could not. Is this part of a bigger PR? Just out of interest.

The WARN just does seem to delay the ONLIBE state of the THINGS - which is not the end of the world.