@Kai Can you please upload net.java.dev.jna/jna/5.14.0 to JFrog?
Upgrading from 4.1 to 4.2M1 I have two problems…
Validation in Rules (no context to infer the closure’s argument types)
2024-03-04 16:20:38.395 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model '24g.rules', using it anyway:
There is no context to infer the closure's argument types from. Consider typing the arguments or put the closures into a typed context.
JS Unavailable
2024-03-04 16:20:39.186 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model '24g.items'
2024-03-04 16:20:58.167 [WARN ] [s.internal.SingleValueTransformation] - couldn't transform response because transformationService of type 'JS' is unavailable
EDIT from Googling a bit, I hypothesise that issue 1) is probably caused by the .rules file being loaded before the .items file, and issue 2) is probably caused by the .items file being loaded before the JavaScript transform is loaded. i.e. it looks very much to be some kind of start up timing issue. (Note: it all works perfectly in v4.1 … to which I have in the meantime reverted…)
It seems that Issue #16360 in 4.2.0.M1 fixed my problems with rrd4j (issue #16354). My problem with rrd4j has been very annoying because querying data has been extremely slow, in worst cases it has taken ~20s. Now my 3Y old data are plotted almost immediately. What a huge improvement this is. Many thanks for this great update.
1 Like
happy to hear this, one further PR has not yet been merged and should improve it even more:
This will allow to read batches of bytes and not byte by byte.
Can you please merge also the last updates of the Tapo binding, lots of people are waiting on it:
At the end of Openhab 4.2 M1 chagelog…
There is written:
amazonechocontrol Bug Fixes [16152](https://gith...
but github link is not valid.
What exatly is fixed? Is fixed the last voice command? or i still need to install the 3rd party addon?
All seems OK in a QNAP X64 (non-docker environment):
- QTS 5.1.5.2679
- Zulu JDK 17.0.8
- openHAB 4.2.0.M1
Now that HTTP Binding supports national characters I’ve removed SmartHome/J HTTP Binding and all seems Ok.
Thanks devs.
I cannot change the settings of a channel of a thing (Astro binding). Instead of the save-button there is a lock and when I click it an error-message is displayed saying it’s not possible to change a channel of thing that’s defined in a things-file.
But the thing is UI-defined and so are the items.
openHAB 4.2.0.M1
are you sure no .things file exists? you can have two definitions of the same name, file and Ui defined it’s coincidence then which one is loaded first, and the other one is suppressed. Only possible status change is on next startup.
no, not for this thing.
And I created a new thing via UI to double-check.
See the lock in the screenshot. It’s really definitely a UI-created thing.
This was my mistake. Channel edit: Fix regression causing editable channels to be locked by jimtng · Pull Request #2455 · openhab/openhab-webui · GitHub
3 Likes
I have two problems with the current: 4.2 Milestone
The KNX binding:
2024-03-05 20:54:00.128 [ERROR] [Xnet/IP Tunneling 192.168.10.15:3671] - send disconnect failed
java.net.SocketException: Socket closed
at sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:222) ~[?:?]
at java.net.DatagramSocket.send(DatagramSocket.java:669) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.send(ConnectionBase.java:294) ~[?:?]
at tuwien.auto.calimero.knxnetip.ClientConnection.send(ClientConnection.java:240) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.close(ConnectionBase.java:472) ~[?:?]
at tuwien.auto.calimero.knxnetip.ConnectionBase.close(ConnectionBase.java:325) ~[?:?]
at tuwien.auto.calimero.link.AbstractLink.close(AbstractLink.java:364) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.doSend(KNXNetworkLinkIP.java:530) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.onSend(KNXNetworkLinkIP.java:503) ~[?:?]
at tuwien.auto.calimero.link.AbstractLink.send(AbstractLink.java:397) ~[?:?]
at tuwien.auto.calimero.link.KNXNetworkLinkIP.sendRequestWait(KNXNetworkLinkIP.java:480) ~[?:?]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.send(ProcessCommunicatorImpl.java:494) ~[?:?]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.readFromGroup(ProcessCommunicatorImpl.java:464) ~[?:?]
at tuwien.auto.calimero.process.ProcessCommunicatorImpl.read(ProcessCommunicatorImpl.java:386) ~[?:?]
at org.openhab.binding.knx.internal.client.AbstractKNXClient.readNextQueuedDatapoint(AbstractKNXClient.java:367) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.nio.channels.ClosedChannelException
at sun.nio.ch.DatagramChannelImpl.ensureOpen(DatagramChannelImpl.java:267) ~[?:?]
at sun.nio.ch.DatagramChannelImpl.blockingSend(DatagramChannelImpl.java:850) ~[?:?]
at sun.nio.ch.DatagramSocketAdaptor.send(DatagramSocketAdaptor.java:218) ~[?:?]
... 20 more
and
And the TR64 binding
2024-03-05 20:54:05.747 [WARN ] [ng.tr064.internal.soap.SOAPConnector] - Failed to get Tr064ChannelConfig{channelType=missedCalls, getAction=GetCallList, dataType='string, parameter='1'}: java.util.concurrent.TimeoutException: Total timeout 5000 ms elapsed
I tried to restart openHAB several times, but this did not solve the issue.
For the time beeing I downgraded to 4.1.1-1, to avoid massiv WAP problems ;). This version seems seems to work fine (as it did before)
Today I did some more testing and it seems, that the problems above where not caused by the milestone release but by the jrubyscripting addon causing a high CPU load. Not sure why, I just installed it to do some testing and have no Ruby scripts yet.
With the milestone build a noticed an error loading one of my Python scrips:
2024-03-06 16:56:20.622 [ERROR] [ipt.internal.ScriptEngineManagerImpl] - Error during evaluation of script '/etc/openhab/automation/jsr223/python/personal/network_rules.py':
java.util.ConcurrentModificationException: java.util.ConcurrentModificationException in /etc/openhab/automation/jsr223/python/personal/network_rules.py at line number 1
Line number 1 of this script is just an import:
from core.rules import rule
The script was loaded fine after resaving it.
1 Like
Can you verify/confirm this issue? I haven’t noticed such issue, but in M2 the jruby version was upgraded from 9.4.5.0 to 9.4.6.0.
Does this happen every time you restarted openhab?
Id did some more testing:
-
openHAB 4.1.1. without jRuby. The CPU load of the openHAB process varies between 5%-11%, mostly around 10%
-
Still with openHAB 4.1.1. I installed jRuby. The CPU load increases a bit, but not much, 8%-15%, mostly around 11-12%
-
I installed the M2. The CPU load is at 100% for all four cores, after some time openHAB restarts (not sure why)
-
I waited another 30min after the restart The CPU load of the openHAB process varies a lot, between 5% and 90%, most of the time it is around 38%
No, this is not reproducible, but I noticed some more of these errors in the various restarts, caused by different files.
For the time being I will revert to 4.1.1
I don’t think this was caused by the jruby addon, especially if you don’t even have any rules written in jruby.
When I first tested M2 I removed the jruby addon and the problem got better, but this might be a coincidence.
I will do some further testing, but I am not sure when I will have time for that.