Here’s mine from 4.0.0-SNAPSHOT - Build #3381:
# lsof -p $(pgrep -f java.*openhab) | wc -l
54219
After restarting, I’m down to 263.
Linking to my earlier post. Im thinking the recent posts and the PR are likely solutions to my post as well.
Since the post I upgraded to Bullseye, switched to recommended OpenJDK from zulu, shortened the log rotations and stripped down to just zwave and still see leakage. Output above is after two days from restart. I’ll give the snapshot a try.
edit: problem solved with #3392. Command above after start -228, 14 hours later -227. Also dramatic change in memory use graphs.
For me its:
lsof -p $(pgrep -f java.*openhab) | wc -l
16278
openhab service uptime is: 1 day 9h
Output of pgrep is ful of:
java 14369 openhab *110r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *111r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *112r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *113r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *114r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *115r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *116r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *117r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *118r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *119r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *120r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *121r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *122r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *123r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *124r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *125r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *126r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *127r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *128r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *129r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *130r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *131r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *132r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *133r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *134r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *135r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *136r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *137r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *138r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *139r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *140r DIR 0,5 80 456 /dev/serial/by-id
java 14369 openhab *141r DIR 0,5 80 456 /dev/serial/by-id
I’ll check mine for any open file issues, but I was seeing my zwave devices showing offline after my nightly heal would run, and they would stay off for 8+ hours, oddly though, they would work, but slowly, when I tried to use them.
Turning off zwave heal fixed that for me for now.
4.0 M1
Great work on the milestone build work! So happy to be off Java 11!
I have tried to migrate my version docker container version 3.4.0.M4 to 4.0.0.M1.
here is the output of update.log
Openhab does not start.
Openhab does not generate any further logs:
I do not know how to debug further, any idea.
Check the contents of $OH_USERDATA/etc/org.ops4j.pax.logging.cfg to see if it’s blank. If you look above that has been happing to a number of us. If it’s not zero length run docker logs -f openhab (or what ever your container is named).
it is not empty:
cat openhab_userdata/etc/org.ops4j.pax.logging.cfg
org.ops4j.pax.logging.log4j2.config.file=${karaf.etc}/log4j2.xml
I reinitiated the upgrade , here the output during startup:
sitemaps
sounds
things
m
.vscode' ']'
+ initialize_volume /openhab/userdata /openhab/dist/userdata
+ volume=/openhab/userdata
+ source=/openhab/dist/userdata
++ ls -A /openhab/userdata
+ '[' -z 'backup
cache
config
._.DS_Store
e
etc
jsondb
kar
logs
miio
openhabcloud
persistence
secrets
tmp
'
++ cmp /openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties
+ '[' '!' -z '/openhab/userdata/etc/version.properties /openhab/dist/userdata/etc/version.properties differ: byte 269, line 8' ']'
+ tee /openhab/userdata/logs/update.log
+ echo 'Image and userdata versions differ! Starting an upgrade.'
Image and userdata versions differ! Starting an upgrade.
++ date +%FT%H-%M-%S
+ backup_file=userdata-2023-04-03T17-25-04.tar
+ '[' '!' -d /openhab/userdata/backup ']'
+ tar --exclude=/openhab/userdata/backup -c -f /openhab/userdata/backup/userdata-2023-04-03T17-25-04.tar /openhab/userdata
tar: Removing leading `/' from member names
+ echo 'You can find backup of userdata in /openhab/userdata/backup/userdata-2023-04-03T17-25-04.tar'
+ tee -a /openhab/userdata/logs/update.log
You can find backup of userdata in /openhab/userdata/backup/userdata-2023-04-03T17-25-04.tar
+ exec /openhab/runtime/bin/update
+ tee -a /openhab/userdata/logs/update.log
################################################
openHAB Docker update script
################################################
The script will attempt to update openHAB to version 4.0.0.M1
Please read the following notes and warnings:
Important notes for version 3.4.0:
Warning: CORE: Default units have been added for all dimensions. A state description defining the unit should be added to each item that uses a different unit.
Warning: Automower Binding: Due to Husqvarna Authentication API change, bridge now requires application secret instead of username and password. Delete any existing bridge and re-add it, please make sure to update all automower things to use the newly added bridge.
Warning: JavaScript Scripting Automation: 'setTimeout' and 'setInterval' return a timerId (a positive integer value) as in standard JS instead of an openHAB Timer.
Warning: JavaScript Scripting Automation: ItemHistory min/max between/since returns now a number instead of a string.
Warning: JavaScript Scripting Automation: openHAB JavaScript library versions < 3.1.2 are not fully compatible anymore. If you have manually installed the JS library, please upgrade to a version >= 3.1.2.
Warning: JRuby Scripting Automation: The default `RUBYLIB` directory has changed to OPENHAB_CONF/automation/ruby/lib. Either explicitly configure the add-on to use the previous value, or move any files to the new location.
Warning: Konnected Binding: Things needs to be recreated because of added Konnected Pro panel support and manual configuration of things.
Warning: LG webOS Binding: The undocumented action "sendRCButton" was removed while it is possible to achieve the same action with "sendButton"
Warning: Miele@home Binding: The channel 'start' now contains date and time for start of scheduled program. Previously it was counting down duration until the program would start.
Warning: Miele@home Binding: The channels 'duration', 'elapsed' and 'finish' are now Number:Time. You may need to remove and create your things again in case your things were previously created using UI and you want to use these channels. Linked items need to be recreated.
Warning: Resol Binding: Item Type of solar controllers channels using time and weekday format changed from Date to String. Items need to be adjusted accordingly.
Warning: Systeminfo Binding: Multiple Number channels now have a dimension added. You may need to remove and create your things again in case your things were previously created using UI and you want to use these channels. Linked items need to be recreated.
Warning: Systeminfo Binding: The default state description for DataAmount channels is now MiB. If you relied on MB, you may need to adjust.
Warning: Velux Binding: On window things the semantic category of the position channel has been corrected from 'blinds' to 'window'. Window things with such channels that had been created via the UI will need to be deleted and re-created.
Warning: Xiaomi Wifi devices (Mi IO) Binding: Channel Type change for some yeelights. The brightness channels with the Number type now have the Dimmer type. This affects only nightlight and ambilight channels for some models.
Important notes for version 4.0.0:
Warning: CORE: core.GenericEventTrigger and core.GenericEventCondition parameters have have changed. See https://www.openhab.org/docs/configuration/rules-ng.html#system-module-types.
Warning: DanfossAirUnit Binding: The deprecated channel 'manual_fan_speed' has been removed. Please use channel 'manual_fan_step' introduced in 3.2.
Warning: Dark Sky Binding: Due to EOL of their API, this add-on has been removed.
Warning: Hue emulation: The uniqueid value has been changed to resolve discovery issues with Alexa. You may need to rediscover "devices" in all services that use the hue emulation (Amazon Echo, Logitech Harmony, etc).
Warning: Hunter Douglas (Luxaflex) PowerView Binding: Deprecated scene channels have been removed. Please use the scene channels introduced in 3.2 (in channel group 'scenes').
Warning: JavaScript: JavaScript engines have changed their MIME types: NashornJS is application/javascript:version=ECMAScript-5.1 and GraalJS is application/javascript. Please update your scripts to either make them compatible with GraalJS or change the MIME type to continue to use NashornJS. For Blockly migration, visit the Blockly documentation.
Warning: JavaScript NashornJS: NashornJS has been removed from core and isn't included by default. If you still need or want to use it, you can install it as an addon.
Warning: JavaScript Scripting Automation: The old "metadata" and "itemchannellink" APIs have been replaced by a new API with extended functionality on the "items" namespace.
Warning: JavaScript Scripting Automation: ItemHistory: historicState, maximumBetween, maximumSince, minimumBetween, minimumSince & previousState now return a HistoricItem instead of just the state. previousStateTimestamp has been removed, the timestamp is available on the HistoricItem.
Replacing userdata system files with newer versions...
Clearing cache...
Performing post-update tasks for version 3.4.0:
SUCCESS: openHAB updated from 3.4.0.M4 to 4.0.0.M1
+ chown -R openhab:openhab /openhab
+ sync
+ '[' -d /etc/cont-init.d ']'
++ wc -l
++ ls '/usr/bin/s6-*'
+ '[' 0 == 0 ']'
++ find /etc/cont-init.d -type f
++ grep -v '~'
++ sort
+ sync
+ '[' false == false ']'
++ IFS=' '
++ echo gosu openhab tini -s ./start.sh
+ '[' 'gosu openhab tini -s ./start.sh' == 'gosu openhab tini -s ./start.sh' ']'
+ command=($@ server)
+ exec gosu openhab tini -s ./start.sh server
Launching the openHAB runtime...
Nothing is written to the logs:
ls -l openhab_userdata/logs/
.rwxrwxrw- 0 haut 3 Apr 17:22 audit.log
.rw-r--r-- 0 haut 3 Apr 17:25 events.log
.rw-rw-rw- 1.5M haut 3 Apr 17:22 events.log.1.gz
.rw-rw-rw- 1.5M haut 3 Apr 17:22 events.log.2.gz
.rw-rw-rw- 1.5M haut 3 Apr 17:22 events.log.3.gz
.rw-rw-rw- 1.5M haut 3 Apr 17:22 events.log.4.gz
.rw-rw-rw- 1.1M haut 3 Apr 17:22 events.log.5.gz
.rw-rw-rw- 370k haut 3 Apr 17:22 events.log.6.gz
.rw-r--r-- 64k haut 3 Apr 17:25 events.log.7.gz
.rw-r--r-- 0 haut 3 Apr 17:25 openhab.log
.rw-rw-rw- 6.2k haut 3 Apr 17:22 openhab.log.1.gz
.rw-rw-rw- 882k haut 3 Apr 17:22 openhab.log.2.gz
.rw-rw-rw- 988k haut 3 Apr 17:22 openhab.log.3.gz
.rw-rw-rw- 998k haut 3 Apr 17:22 openhab.log.4.gz
.rw-rw-rw- 31k haut 3 Apr 17:22 openhab.log.5.gz
.rw-rw-rw- 24k haut 3 Apr 17:22 openhab.log.6.gz
.rw-r--r-- 8.2k haut 3 Apr 17:25 openhab.log.7.gz
.rw-rw-rw- 5.6k haut 3 Apr 17:25 update.log
All I can suggest is check log4j2.xml and make sure it looks valid and verify that the openhab user ID inside the container matches user haut. If not, that user doesn’t have permission to modify the log files.
It does
I have copied the configuration to another docker server, and there OH upgrades and starts without any problem.
Have to take a look at what sort of mess I made.
I’m seeing this with my Netatmo binding with 4.0.0-SNAPSHOT - Build #3392:
2023-04-03 17:57:48.828 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'nRainHour' updated to 0 ft
2023-04-03 17:57:48.835 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'nRainToday' updated to 0 ft
2023-04-03 17:57:48.837 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'nRainWeek' updated to 0 ft
2023-04-03 17:57:48.838 [INFO ] [openhab.event.ItemStateUpdatedEvent ] - Item 'nRainMonth' updated to 0.025590551181102362 ft
this should be converted to inches instead of feet
Please show the item definition and the metadata (if set).
Group nRain "Netatmo Rain Module" <rain> (outside) ["Equipment"] {synonyms="Netatmo Rain Module"}
Number:Length nRainHour "Rain Last Hour [%.03f\"]" <rain> (nRain) ["Measurement","Rain"] {channel="netatmo:rain:home:indoor:rain:rain#sum-1"}
Number:Length nRainToday "Rain Today [%.03f\"]" <rain> (nRain) ["Measurement","Rain"] {channel="netatmo:rain:home:indoor:rain:rain#sum-24"}
Number:Length nRainWeek "Rain This Week [%.03f\"]" <rain> (nRain) ["Measurement","Rain"] {channel="netatmo:rain:home:indoor:rain:rainThisWeek"}
Number:Length nRainMonth "Rain This Month [%.03f\"]" <rain> (nRain) ["Measurement","Rain"] {channel="netatmo:rain:home:indoor:rain:rainThisMonth"}
" is not a valid unit. The unit symbol for inch is in. Because of that the system default ft is used for length.
Since when? It displays correctly in the ui, and has worked this way since OH 1:
This is what is in default.sitemap, it works there:
Frame label="Rain" {
Text item=nRainHour
Text item=nRainToday
Text item=nRainWeek
Text item=nRainMonth
}
It has never been a valid unit. It’s just some arbitrary text that is used in the state description (you could also write %.3f ABCD and it would show up as 0.0026 ABCD. Unit conversion never worked with ".
The difference from before is that we now have a default unit for the item, which is used when no unit is explicitly set. This is ft for dimension “length”. With the refactored UoM handling in preparation ([uom] Add defaultUnit metadata for NumberItem by J-N-K · Pull Request #3481 · openhab/openhab-core · GitHub) you’ll be able to separate state description and item unit and can gain use " or ABCD for displaying and in as item unit for UoM handling.
Hi,
I have question: I want to download the openhab 4.0.0M1 and on the download page it says, that I need Java 11, but I thought I need Java 17 for version 4. Or is it only for the SNAPSHOT version?
I am running an old version of openhab and I want to set up from scratch. So, the idea is to start with milstone1 and upgrade to the release version later on, which I think is easier or smoother as upgrading from version 3.4.x. Is this right?
Thanks.
Openhab 4 uses Java17, including M1.
I would suggest using SNAPSHOT instead of M1. There are some important fixes that didn’t make it into M1.
Ok, then I will start with the SNAPSHOT version.
Thank you!
Or wait for Milestone 2 that should arrive (very) soon.
Can you provide the link to the exact page you are referring to? If it still says Java 11 for OH 4 it needs to be updated.
1 Like