I am on M6, and no issues with z-wave.
My only issues are with broadcomm binding, which is still 3rd-party, and for whom M6 had some breaking changes. But z-wave seems pretty stable
2 Likes
Same thing here 
No issues at all
1 Like
Hello,
I can confirm the hue issue in M6 release. I get an unuseable system after upgrading. If I remove the hue things it becomes normal again, but after including only one hue thing, logfile will be spammed with hue events and CPU consumption is 100% an memory is increasing over 5GB.
I am using openhab with docker and I also started a test with new conf, addon and userdata folder, but got the same behavior after only installing hue binding and including one hue thing. After removing the one hue thing the cpu consumption stays at 100 percent but log spamming stopped.
First I will switch back to M5 release and will still watch this forum for new informations about this topic.
Yes I know. But since I only use that binding for cosmetic purposes the need to update is somewhere at the bottom of my TODO-list.
For openHABian Xms/Xmx defaults are 250/350 which is fine for a 1GB ARM system and on x86 or ARM boxes with more mem probably not more harmful than the defaults.
Actually, on this recent install on a Pi 3B+ the OPTS is blank. I inslled Java using openHABian, used apt to install Milestone 5 and then used openHABian to set the defaults. I specifically wanted Milestone 5 because I was testing the upgrade from 5 to 6.
EXTRA_JAVA_OPTS=""
Made a quick dirty fix for the Broadlink binding for M6: Broadlink binding for RMx, A1, SPx and MP. Any interest?
I’ve seen Java go to 100% and stay there, too.
First I’ve seen a number of
2019-12-08 14:40:19.398 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@ffb7f8' takes more than 5000ms.
until I restarted.
Now this time (and only this time) I got
2019-12-08 14:39:33.351 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.OutOfMemoryError: Java heap space
2019-12-08 14:39:33.373 [DEBUG] [nal.provider.AbstractCallbackServlet] - Post message received from OwnTracks tracker: {"_type":"location","acc":16,"alt":0,"batt":78,"conn":"w","lat":XX.XXX,"lon":XX.XXX,"t":"p","tid":"XX","tst":1575812344,"vac":0,"vel":0}
and quickly after that
2019-12-08 14:40:09.039 [WARN ] [WaveSerialHandler$ZWaveReceiveThread] - Exception during ZWave thread.
java.lang.IllegalStateException: Queue full
at java.util.AbstractQueue.add(AbstractQueue.java:98) ~[?:1.8.0_222]
at java.util.concurrent.ArrayBlockingQueue.add(ArrayBlockingQueue.java:312) ~[?:1.8.0_222]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.processReceiveMessage(ZWaveTransactionManager.java:417) ~[bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveController.incomingPacket(ZWaveController.java:1072) ~[bundleFile:?]
at org.openhab.binding.zwave.handler.ZWaveControllerHandler.incomingMessage(ZWaveControllerHandler.java:411) ~[bundleFile:?]
at org.openhab.binding.zwave.handler.ZWaveSerialHandler$ZWaveReceiveThread.run(ZWaveSerialHandler.java:331) [bundleFile:?]
2019-12-08 14:40:19.398 [WARN ] [me.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.events.internal.EventBridge@ffb7f8' takes more than 5000ms.
So the prime candidate I believe is the gpstracker binding (pinging @gbicskei), the following ZWave error (pinging @chris) may or may not be a followup problem.
Will raise -Xmx java limit but I would think that should not be the cause as I believe the whole JVM should crash if that limit is hit, shouldn’t it? Which it does not. Memory usage also was pretty constant i.e. no visible leak.
I’ve also been thinking of a relationship to VScode because I’ve only been seeing this since I recently started to use that, but I haven’t been able to verify or falsify yet. At least it does not touch the dir or files which would cause that 100% due to a recompile of many rules or items.
I’m not keen to discuss issues here where it’s mixed up with so many other issues. If there’s a problem, please create a thread and I’m happy to look at it.
However the thread full error is an effect, not the cause.
2 Likes
MQTT Link Number item - items missing
I configured a number type channel for a generic MQTT thing using paper ui
When I add a link to this channel, I expect all number type items of my things to be listed. But the list is empty and I have only the choice to create a new item.
This works perfectly OK in 2.4 stable
Background
-
My sandbox setup is on openhabian buster with mostly just 2 enocean devices (NodonPir and Nodon Plug).
-
I want to publish LUX values of my automatically discovered Nodon PIR via MQTT
-
Linking On/Off items to ON/Off Channel Types works as expected
Hi, me again… I have now rebuilt a new machine from scratch and when I restore my openhab backup from the other machine, I get the same java error as on the old machine:-(
Conclusion is then I guess that there is something in my config that is not “right” even if M4 is happy about it…
2019-12-08 17:25:16.658 [ERROR] [org.openhab.core.ephemeris ] - bundle org.openhab.core.ephemeris:2.5.0.M6 (143)[org.openhab.ephemeris(146)] : The activate method has thrown an exception
java.lang.IllegalArgumentException: No enum constant java.time.DayOfWeek.( "MONDAY"
at java.lang.Enum.valueOf(Enum.java:238) ~[?:1.8.0_222]
at java.time.DayOfWeek.valueOf(DayOfWeek.java:109) ~[?:1.8.0_222]
at
[snip... snip... snip - several times the same error related to this ephemeris module.... snip... snip]
2019-12-08 17:25:17.681 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://192.168.101.18:8080
2019-12-08 17:25:17.683 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://192.168.101.18:8443
2019-12-08 17:25:18.267 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
And then it is stuck here and not moving any more…
Anyone would have an idea as to what can be the cause and how to debug it?
If not, I guess that instead of restoring a backup I’ll have to rebuild the new machine step by step (exactly what I was tryingt to avoid)…
Thanks in advance,
Please start a new thread for your issue then. I expect this thread to be locked after 2.5rc1 is released later today.
With so many issues in Milestone 6, is it wise of Kai to release 2.5 on 15th December? Sounds like it needs far more work 
1 Like
Release Candidate 1 has been released. There is a new thread for critical issues. Other issues will not be addressed at this time.
Just for documentation:
M6 replaced my java entry in /etc/default/openhab2:
EXTRA_JAVA_OPTS=“-Xms400m -Xmx650m“
with
EXTRA_JAVA_OPTS="-Xms250m -Xmx350m"
Which leads to a Java heap space issue
Do you mean openHABian? I do not think openHAB itself sets the heap space. In fact it did not set it on my Pi 3B+.
What OS & Java versions?
You’re right - it was more likely by openhabian.
Java:
openjdk version “1.8.0_152”
OpenJDK Runtime Environment (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 1.8.0_152-b76)
OpenJDK Client VM (Zulu Embedded 8.25.0.76-linux-aarch32hf) (build 25.152-b76, mixed mode, Evaluation)
Release = Raspbian GNU/Linux 8 (jessie)
Kernel = Linux 4.9.35-v7+
Platform = Raspberry Pi 3 Model B Rev 1.2
What version did you move from? On my test Pi I installed Milestone 6 & then move to 6 and my JAVA_OPTS is blank. I installed M5 using apt-get and then applied the openHABian system tweaks.
Opened an issue on github about the hue log file flooting
First fix for me is to remove hue motion sensor and dimmer switch things out of openHab configuration because I am not using them at the moment for any rules or actions.
1 Like