That file contains all the add-ons. If you open it with a Zip program you will see all the add-ons that openHAB supports as part of the distro. I think it get’s put there when installing openhab-addons which makes them available for offline installation. I’m not surprised that deleting it causes everything to stop working as everything is uninstalled.
I can’t comment on how/why it appeared now.
That makes sense. Except its kinda strange howcome its suddenly there. No previous openhab versions had it like this at least since openhab 2.2 where I started to use openhab.
I really makes me wonder if this setup is just screewed up somehow… I have a few issues with it since I moved to use the public released Rpi4 firmware where USB boot is enabled (a few weeks ago). Its a test setup, where I test Ipcamera binding and then run the system binding. Thats all it´s doing.
The worse problem seems to be the frontail logviewer which seems to have its own life somehow. It wont start after restarting openhab… (I posted this issue in another thread). Before I was running on a SD card using openhab 2.5.5, and it worked just fine…
Another issue seems to be, that the speed openhab is running is kinda slower than when I used the SD card. (at least it feels that way)… Guess I need to start all over again. But I would have prefered to perhaps find the cause of this 
Did you somehow install openhab2-addons in apt?
Nope, I did nothing except using openhabian-config to update, (the usual/normal way).
I noticed when I updated through openhabian-config that it downloaded the addins. I hadn’t noticed that before either. I can’t remember which option in the menu I chose
Seems like there may be an obvious reason. (and unfortunaly known reason, to some).
Since my issues started with a fresh “image” install a coupple of weeks ago for USB boot, Bruce´s comment could be the true cause here. Before I went to use the SSD (USB boot) I was running an older version on SD card and not having issues.
I just tried install a fresh install (again) on the same SD card… And again I have the same issues, (ofcouse since its the same image).
I wonder, when exactly did the term “stable” ever became unstable.
Btw… I found the reason why Frontail logviewer isnt running.
For openHAB, stable has always and probably will always mean simply unchanging. It doesn’t mean bug free. It doesn’t mean runs perfectly. It just means that at one point in time, there were no known bug that were of a nature to prevent snapping a release. Honestly, that’s a large part of the reason why I recommend to either never upgrade or to upgrade to the milestones. If you wait of a full release than the number of changes have built up to the point where it’s going to be a lot of work and hard to upgrade.
And these point releases (e.g. 2.5.7) are kind of like milestone releases, only the core of OH has remained unchanged since 2.5.0. It’s only the bindings that are changing.
I dont demand bug free. But I simply dont get it when there are something that seems like known issues to an image, howcome its:
But again, that just my opinion… I dont expect others to share the same. In my situation I´m knowlegde openhab user, meaning I kinda know and expect issues somehow and often can deal with them myself. This time I couldnt, (except I found the cause of some of the issues).
how do you come to claim it’s a known issue ? It isn’t.
If it really was a bug, someone has to be the first to find it.
And you are completely off-topic now so please stop responding here and open a new thread.
This one is on OH 2.5.7. Yours is about openHABian.
Hello,
on my RPi4 with openhabian, since the update to version 2.5.7, I have about every 15 seconds two warning messages in openhab.log, which I cannot explain.
2020-07-28 10:34:43.219 [WARN ] [sysfs.internal.SysfsUsbSerialScanner] - Could not find the device path for /sys/class/tty/ttyACM0 in the sysfs: /sys/class/tty/ttyACM0
2020-07-28 10:34:43.227 [WARN ] [sysfs.internal.SysfsUsbSerialScanner] - Could not find the device path for /sys/class/tty/ttyUSB0 in the sysfs: /sys/class/tty/ttyUSB0
...
2020-07-28 10:34:58.259 [WARN ] [sysfs.internal.SysfsUsbSerialScanner] - Could not find the device path for /sys/class/tty/ttyACM0 in the sysfs: /sys/class/tty/ttyACM0
2020-07-28 10:34:58.265 [WARN ] [sysfs.internal.SysfsUsbSerialScanner] - Could not find the device path for /sys/class/tty/ttyUSB0 in the sysfs: /sys/class/tty/ttyUSB0
The two ports are used for Z-Wave and Enocean USB sticks, as far as I can tell, both work perfectly.
At first, I assumed that it was due to an incorrect configuration of EXTRA_JAVA_OPTS.
So I’ve made the following changes from
EXTRA_JAVA_OPTS="-Xms192m -Xmx320m"
to
EXTRA_JAVA_OPTS="-Xms192m -Xmx320m -Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyACM0"
Unfortunately, the warnings remain. Does anyone have an idea why this might be?
Whats the difference?
The update I first installed yesterday says 2.5.7-1
The image I installed yesterday says 2.5.7-1
Because I use openhabian, I´m not qualified to participate in this thread… Is that really what you´re saying?
So where does that mention your issue ? It does not. It is just a very generic warning that there may be more problems than usual.
Serious ? You want to tell us that after years of usage, you still don’t know the difference between openHAB and openHABian ? Your issue is on openHABian hence it does not belong here.
No, but -Dgnu.io... is deprecated. Remove it and restart OH to see if that makes a difference.
Hi @Kim_Andersen , would you please so kind and move your discussion with @mstormi to a private one? It’s annoying here to read your entitlement of a bug-free openHAB, which is maintained with blood, sweat and tears from everyone in their free time.
Thanks.
I already removed -Dgnu.io ... but the warnings remain. I don’t know if it’s relevant, I’m still using Java 8.
done
After installing 2.5.7 (over 2.5.6) a few days back, I had to downgrade to 2.5.6.
On 2.5.7, the CPU load for the java process maxed out for 15-20s every minute or so, blocking everything until the CPU was released again.
I tried enabling DEBUG logging for karaf,core and all my bindings, but nothing showed up in the logs as the CPU was hogged.
My system runs Ubuntu Server 18.04 LTS
openhab> list -s | grep -i binding
136 │ Active │ 80 │ 2.5.0 │ org.openhab.core.binding.xml
203 │ Active │ 80 │ 2.5.0.201907121940 │ org.openhab.binding.nanoleaf
239 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.astro
240 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.daikin
241 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.deconz
242 │ Active │ 80 │ 1.14.0 │ org.openhab.binding.expire
243 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.harmonyhub
244 │ Active │ 80 │ 1.14.0 │ org.openhab.binding.http
245 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.hue
246 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.kodi
247 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.mail
248 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.network
249 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.onkyo
250 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.samsungtv
251 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.shelly
252 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.squeezebox
253 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.systeminfo
254 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.tradfri
255 │ Active │ 80 │ 2.5.6 │ org.openhab.binding.zwave
openhab> logout
Connection to localhost closed.
omr@shs2:~$ java -version
java version "1.8.0_201"
Java(TM) SE Runtime Environment (build 1.8.0_201-b09)
Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
omr@shs2:~$ uname -a
Linux shs2 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
omr@shs2:~$
Downgrading to 2.5.6, the CPU load for the java process is a stable 8-12%
Can someone guide me in my issues after the upgrade? Details below. I am running OH2 on RPI3 with Buster. I kinda got stuck on 2.5.4-1 as anything above I upgrade to (today tried 2.5.7-1) I’m getting loads of errors with items which I guess are coming from binding issues. Rollback to 2.5.4-1 (and cleaning cache) helps to stabilize, get the log file clear and proper Basic UI look.
Error I’m getting:
2020-08-11 09:34:10.226 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'kamera_dol' 2020-08-11 09:34:10.259 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.261 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.264 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.267 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch 2020-08-11 09:34:10.269 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'kamera_dol' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
item is defined as:
Switch kamera_dol <camera> { http=">[ON:GET:http://192.168.1.27/web/cgi-bin/hi3510/ytdown.cgi?{Authorization=Basic xxxxxxxxxxx=}]" }
Then
same error for item introduced by PanasonicTV binding:
Switch BedroomTVPower "Power" { panasonictv="tv_sypialnia:POWER" }
and then with no errors in the log (no debug), there are lots of issues with items which are filled in via mqtt (for weather station, alarm etc) - values are not present but also icons problems. I tried to restart the instance couple of time, clean the cache, I didn’t try to restart the whole server yet so maybe I’m asking for help too early. On the other hand this must be something straightforward.
Leave the cache alone after an upgrade. Let it populate and do its job, do an “extra” restart without touching it, see what issues are left.
@rossko57 I obviously tried that in the first place (let it do its job and 2 restarts), then when it didn’t work, I tried to remove cache an so on. I tried this with 2.5.5, 2.5.6, and today 2.5.7. This isn’t a conincidence