That has nothing to do with M2.
Have a look here, Amazon is seemingly tinkering.
2 Likes
Okay, the Messages came up after upgrade to M2.
But many thanks for your information.
Did rule reloading stop working on 3.2M2? I havenāt investigated further but downgrading to 3.2M1 fixed the problem.
By rule reloading I mean when you make changes to a rule file (in my case jruby, but it applies to jython / dsl I too I guess), openhab didnāt seem to reload / re-execute it.
Hello, I updated 10min before to M3 and I see a strange behavior.
If I restart the system or the openHAB service - than all handlers are missing. If I stop the openHAB service and Clean-Cache and than start itās all fine. I am on openhabian latest stable.
I am the only one with this behavior???
I had something similar happen when I went to m2, have not seen it return and I have done a lot of restarts the past month. I think it only happened on the first restart directly after doing the m2 upgrade. Why it happened on the first reboot after its first startup, I have no idea, but it has not happened since.
@matt1 thanks for your hint.
yes, I saw this also in m2 but there it was only once. Now itās Everytime there. I will open an issue on GitHub. https://github.com/openhab/openhab-distro/issues/1321
@Kai if you or your team need more input to check this issue. Let me know.
Happy to report that Main UI (using Firefox) is much more stable in M3. Until (and including) M2 I had to refresh the screen very often (probably 25% when I changed page), and sometimes DSL rules were not properly saved. Now these two issues seem to be fixed.
after upgrade, cant reach the service:
The ports openHAB will bind its HTTP/HTTPS web server to.
OPENHAB_HTTP_PORT=1080
OPENHAB_HTTPS_PORT=10443
root@ccu3:/home/pi# service openhab status
ā openhab.service - openHAB instance, reachable at http://ccu3:8080
Loaded: loaded (/usr/lib/systemd/system/openhab.service; enabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/openhab.service.d
āāoverride.conf
Active: active (running) since Mon 2021-10-0
It seems to runā¦ strange but ok^^
I send out an email with the log file to kai regarding my loading issue. I still have the same behavior
Iāve seen this error on the most recent milestone M3:
- Administration/Settings
- Model - open location
- Create Equipment from Thing
- Select thingā¦
16.app.js:1
Uncaught (in promise) TypeError: Cannot read properties of undefined (reading 'localeCompare')
at 16.app.js:1
at Array.sort (<anonymous>)
at 16.app.js:1People, mind the community and posting rules please.
@Simon_B your issue is not related to the milestone so open your own thread please.
@milo You must not ping developers. Open your own thread and post there, and eventually open an issue on Github.
Thank you for your understanding (if you do).
Iām on 3.2.0.M3, macOS 10.15.7
Many times, when I unplug my z-wave USB stick from the server, openHAB exits with the below error:
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00000001101b0268, pid=29126, tid=112399
#
# JRE version: OpenJDK Runtime Environment Zulu11.50+19-CA (11.0.12+7) (build 11.0.12+7-LTS)
# Java VM: OpenJDK 64-Bit Server VM Zulu11.50+19-CA (11.0.12+7-LTS, mixed mode, tiered, compressed oops, g1 gc, bsd-amd64)
# Problematic frame:
# j org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(Lgnu/io/SerialPortEvent;)V+17
#
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /opt/openhab/userdata/hs_err_pid29126.log
Could not load hsdis-amd64.dylib; library not loadable; PrintAssembly is disabled
#
# If you would like to submit a bug report, please visit:
# http://www.azul.com/support/
This happened sometimes in M2, and now that M3 also prodcues this, I thought Iād share.
Is there someone around that can test WOL with network binding in 3.2 M3? For me it doesnāt work anymore and I see that there was a change in network binding:
IP- and MAC address are configured and same setup did work in M2. Do I need to change something in configuration?
This is my ECMA-Rule:
var Log = Java.type("org.openhab.core.model.script.actions.Log");
var ScriptExecution = Java.type("org.openhab.core.model.script.actions.ScriptExecution");
var ZonedDateTime = Java.type("java.time.ZonedDateTime");
var runme = function() {
var wolAction = actions.get("network","network:pingdevice:pc");
wolAction.sendWakeOnLanPacket();
Log.logInfo("WOL", "WOL Computer gesendet");
this.timer = undefined;
}
this.timer = ScriptExecution.createTimer(ZonedDateTime.now().plusSeconds(10), runme);
Thing is online and I have tried with IP and Hostname.
Thanks
Michael
Hi,
It also not working for me anymore.
Iām too at 3.2 M3
WOL is send from Fritzbox is working.
What is configured in there?
I think the linked change #11199 is messed up. If you have given an IP, it targets that for WoL. I think it should target MAC address for WoL - unless none is given, in that case use IP.
Hello I see a lot of āSSE event sinkā errors in the log since OH3
2021-10-12 21:11:26.494 [DEBUG] [est.sitemap.internal.SitemapResource] - Run clean SSE subscriptions job
2021-10-12 21:11:26.495 [DEBUG] [t.sitemap.SitemapSubscriptionService] - Release subscription 41a1a681-0ff1-4eb5-a2ec-061699f00927 as sitemap page is not set
2021-10-12 21:11:26.496 [DEBUG] [t.sitemap.SitemapSubscriptionService] - Removed subscription with id 41a1a681-0ff1-4eb5-a2ec-061699f00927 (1 active subscriptions)
2021-10-12 21:11:26.497 [DEBUG] [est.sitemap.internal.SitemapResource] - SSE connection for subscription 41a1a681-0ff1-4eb5-a2ec-061699f00927 has been released.
2021-10-12 21:11:26.494 [DEBUG] [.openhab.core.io.rest.SseBroadcaster] - Sending event to sink failed
java.lang.IllegalStateException: The sink has been already closed
at org.apache.cxf.jaxrs.sse.SseEventSinkImpl.close(SseEventSinkImpl.java:157) ~[bundleFile:3.4.3]
at org.openhab.core.io.rest.SseBroadcaster.close(SseBroadcaster.java:142) ~[?:?]
at org.openhab.core.io.rest.SseBroadcaster.lambda$2(SseBroadcaster.java:111) ~[?:?]
at java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986) ~[?:?]
at java.util.concurrent.CompletableFuture$UniExceptionally.tryFire(CompletableFuture.java:970) ~[?:?]
at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) ~[?:?]
at java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) ~[?:?]
at org.apache.cxf.jaxrs.sse.SseEventSinkImpl.dequeue(SseEventSinkImpl.java:256) ~[bundleFile:3.4.3]
at org.eclipse.jetty.server.handler.ContextHandler.handle(ContextHandler.java:1519) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.server.AsyncContextState$1.run(AsyncContextState.java:153) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:883) [bundleFile:9.4.43.v20210629]
at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:1034) [bundleFile:9.4.43.v20210629]
at java.lang.Thread.run(Thread.java:829) [?:?]
2021-10-12 21:11:26.499 [DEBUG] [.openhab.core.io.rest.SseBroadcaster] - SSE event sink is already closed
Such exceptions should actually be suppressed by this configuration.
Are you sure you have this latest log4j2.xml in your setup?
Actually the IP WoL is only being used, if an IP is given. If this is not the case the usual mac broadcast is used.
Yes. This makes it impossible to use the same Thing for ping and WoL where the device requires standard MAC based WoL.
If it used the MAC when the MAC is given, then it could be used either way.
I donāt think macAddress= has any other purpose in Thing config.
Yes, I have the same file in my system