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?
Which persistence do you use? It could be that others suffer the same issue.
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
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???
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
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.
You could be right Jan, I saw the mention of Hue in the warning
I have Hue binding installed and it works.
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?
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.
1 Like
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.
1 Like
@J-N-K : I’m having some issues with the latest snapshot and units. I’ve dug a little, but not much.
I have an item:
Number:Dimensionless MasterDeckDoor_Battery "Master Bedroom Deck Door Lock Battery Level [%d %%]" <battery> (eMasterDeckDoorLock, gWarningVisibility_Battery, gInflux, gMapDB) [ "LowBattery" ] { channel="zwave:device:512:node150:battery-level", unit="%", alexa="BatteryLevel", homekit="Battery.BatteryLevel, Battery.BatteryLowStatus" }
When I inspect the item, though, this is what I get:
logger.info(MasterDeckDoor_Battery.unit) # %
logger.info(MasterDeckDoor_Battery.dimension) # javax.measure.quantity.Dimensionless
logger.info(MasterDeckDoor_Battery.state) # 30
logger.info(MasterDeckDoor_Battery.state.unit) # one
Showing this item in a sitemap, it displays as “3000 %”. I’m surprised that the item’s state has unit one, even though the item’s unit is %. I suspect that’s why when it gets displayed, it’s converting to percent again, and 30 is 3000%.
The linked channel is a vanilla Number type, so it makes sense that it’s sending a one unit type, I just thought that would get interpreted as the item’s unit on update. Perhaps that was part of CommunicationManager code that got ripped out?
I’ll check that. But it seems that the communication manager is doing too much here.
Edit: It works perfectly fine for me. I added the magic binding and linked the number channel of the chatty thing to a Number:Dimensionless item with metadata unit=“%”. Some updates are send as QuantityType with unit °C and rejected (because the unit is incompatible, which is correct) and the other ones are plain DecimalType between 0 and 100 which correctly results in
22:07:42.360 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'Magic_ChattyThing_Number_to_show' updated to 39.176797268355514 %
I just tried to update my 4.0.0.M2 to SNAPSHOT (On a Windows Machine) and get the following error from the update script:
Starting JSON database update...
Error: Unable to access jarfile C:\Users\Mark\AppData\Local\Temp\openhab\update\runtime\bin\runtime\bin\upgradetool.jar
Update-openHAB : Update tool failed, please check the openHAB website (www.openhab.org) for manual update instructions.
At C:\openHAB\runtime\bin\update.ps1:584 char:22
+ ... exit Update-openHAB -OHDirectory $OHDirectory -OHVersion $OHVe ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Write-Error], WriteErrorException
+ FullyQualifiedErrorId : Microsoft.PowerShell.Commands.WriteErrorException,Update-openHAB
I can confirm that the JAR file is in the specified location:
Checked the 4.0.0.0 Windows Install (and update) instructions nad don’t see anything there.
Please can you assist?
BTW I have reverted back to 4.0.0.M2 in the meantime.
EDIT:
Found this:
EDIT: Tried to run the UpgradeTool manually (from the TEMP folder and got the following:
PS C:\Users\p8900019\AppData\Local\Temp\openhab\update\runtime\bin> java -jar upgradetool.jar --dir c:\openhab\userdata --command itemCopyUnitToMetadata
Error: LinkageError occurred while loading main class org.openhab.core.tools.UpgradeTool
java.lang.UnsupportedClassVersionError: org/openhab/core/tools/UpgradeTool has been compiled by a more recent version of the Java Runtime (class file version 61.0), this version of the Java Runtime only recognizes class file versions up to 55.0
Wrong Java version. Your runtime supports up to class file version 55, about probably is 11, not 17 (which supports up to 61).
Thank you. You are right. Java 11 was before Java 17 in the path, even though JAVA_HOME was correct. I suppose because the command was (takes first java in path):
java -jar C:\Users\p8900019\AppData\Local\Temp\openhab\update\runtime\bin\runtime\bin\upgradetool.jar --dir c:\openhab\userdata --command itemCopyUnitToMetadata
Do I need to run the command manually as it is not found using the path etc?
I changed to the directory and ran:
java -jar upgradetool.jar --dir c:\openhab\userdata --command itemCopyUnitToMetadata
Which produced:
[main] INFO org.openhab.core.tools.internal.Upgrader - Copying item unit from state description to metadata in database 'c:\openhab\userdata\jsondb\org.openhab.core.items.Item.json'
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalEnergy_Monthly: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] INFO org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_TotalReturnedEnergy: Wrote 'unit=kWh' to metadata.
[main] INFO org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_VA: Wrote 'unit=VA' to metadata.
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_UPS_TotalEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_MAINS_TotalReturnedEnergy: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
[main] WARN org.openhab.core.tools.internal.Upgrader - ShellyEM_Mains_TotalEnergy_PreviousMonth: State description contains unit place-holder '%unit%', check if 'unit' metadata is needed!
This seems to imply further action is required?
And, does the UpgradeTool have to be run while openHAB is shutdown?
ok I want to report that I’m running 3460 and as in above post I’m still experiencing the cpu getting pinned occasionally. It used to take only a day or two but now it goes a week. It does not crash the box or OH but things get sluggish. (host i3 HDD 8GB Dell desktop Mint Linux)
When I restart the host, I must manually set safeCall to 100 (default 10) as describe by Cody here I have the script from the bottom of that same post and if I manually run it when the CPU is pinned it calms down after a few minutes.
I have RDD uninstalled and influx installed
I use DSL and Jruby rules 48 things 240 items
This problem seems unique to me so I’m guessing it is something in my config which is an OH3 upgrade. If anybody wants me to investigate further, I’ll do my best but eventually if no one else reports it (which no one seems to be) I’ll probably just wipe it and start from scratch load fresh clean install and start adding stuff back
Some weeks ago I updated the well running OH snapshot version on Raspi 4 using openhabian. This ended with the appended message . The system is completely locked afterwards. When I make a fresh installation and manually copy all files to conf and userdata, everything works fine until I do an update again. Is there anything I should modify or delete before I make an update or do I have to generate all items again. I only use UI installation.
Press Ctrl-C/Strg-C and abort the script.
Please send the metadata.json to github@klug.nrw. I‘ll try to fix the NPE.
The modified script and upgrade routines are now working. I had to setup a new system , cause I couldn‘t convince openhabian to restart the upgrade routines.
The only disadvantage I have now, is that all metadata are gone, no expire dates or state descriptions.