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:
Not mentioned.
Image either fixed or removed.
The images I´m using is whats beeing presented to the public, even new users are adviced to use these. In that particular situation its makes things even worse, when its has issues.
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).
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?
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.
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.
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.
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.
@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
There’s no “obviously” about it, we only know what you tell us.
The “missing Items” reports you show us invariably arise when the cache has been cleared, and stop happening when the cache has been allowed to settle and openHAB restarted. Some report two attempts needed at that, maybe it is configuration dependent.
It’s not quite impossible for some part of validation to have changed, so that an xxx.items file that worked under earlier versions now no longer loads. You would get a message about that in your openhab.log but you say there are no errors.
None of the problems you have shown us are directly to do with bindings. Let’s clear these Item related problems, and move on to the next.
Today I tried to upgrade again, then before I started OH2 again, I rebooted the server and when it came up it was already clean and no issues with items. Defintiely RPI reboot helped and I regret I didn’t try it before raising this issue but on the other hand it was never required before. Thanks to all who spent time and looked at my case and answered with ideas! This is very much appreciated. I will keep observing 2.7.1 now and see if any issues
I haven’t seen the same error message in the logs but I found my z-wave controller stopped working so all my devices aren’t initialized. Did you get it working again?
My Z-wave controller and my enocean Controller worked well. I have no problems, only the warning messages in the log.
And I have no idea where they came from.
