Interesting, the build went fine, all three packages were uploaded to the repo before the metadata was calculated, will have a look when I can.
1 Like
The 2.4.0~M7-1 versions of the openhab2-addons and openhab2-addons-legacy packages are now available.
1 Like
You have some generic problem with your linux box (Synology?). open up a new thread and we can troubleshoot there to avoid spamming this thread plz.
Hey,
right now testing the M7 and all in all it works like a charm. There is just one error message, which I dont know where it comes from. Not sure if its an issue with the M7? Maybe it`s helpful posting it here 
.
2018-12-04 16:12:43.848 [INFO ] [control.internal.WebSocketConnection] - Web Socket error {}
org.eclipse.jetty.io.EofException: null
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:286) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.ssl.SslConnection$DecryptedEndPoint.flush(SslConnection.java:1005) ~[75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.WriteFlusher.flush(WriteFlusher.java:429) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.WriteFlusher.write(WriteFlusher.java:323) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.AbstractEndPoint.write(AbstractEndPoint.java:380) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.FrameFlusher.flush(FrameFlusher.java:218) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.FrameFlusher.process(FrameFlusher.java:157) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.util.IteratingCallback.processing(IteratingCallback.java:241) [87:org.eclipse.jetty.util:9.4.11.v20180605]
at org.eclipse.jetty.util.IteratingCallback.iterate(IteratingCallback.java:224) [87:org.eclipse.jetty.util:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.FrameFlusher.enqueue(FrameFlusher.java:90) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.outgoingFrame(AbstractWebSocketConnection.java:495) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.client.io.WebSocketClientConnection.outgoingFrame(WebSocketClientConnection.java:72) [91:org.eclipse.jetty.websocket.client:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.WebSocketSession.close(WebSocketSession.java:223) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.WebSocketSession.close(WebSocketSession.java:202) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onConnectionStateChange(AbstractWebSocketConnection.java:353) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.IOState.notifyStateListeners(IOState.java:184) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.IOState.onReadFailure(IOState.java:498) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.readParse(AbstractWebSocketConnection.java:547) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.websocket.common.io.AbstractWebSocketConnection.onFillable(AbstractWebSocketConnection.java:391) [92:org.eclipse.jetty.websocket.common:9.4.11.v20180605]
at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:281) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.ssl.SslConnection.onFillable(SslConnection.java:291) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.ssl.SslConnection$3.succeeded(SslConnection.java:151) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:102) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:118) [75:org.eclipse.jetty.io:9.4.11.v20180605]
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:762) [87:org.eclipse.jetty.util:9.4.11.v20180605]
at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:680) [87:org.eclipse.jetty.util:9.4.11.v20180605]
at java.lang.Thread.run(Thread.java:748) [?:?]
Caused by: java.io.IOException: Broken pipe
at sun.nio.ch.FileDispatcherImpl.write0(Native Method) ~[?:?]
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) ~[?:?]
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) ~[?:?]
at sun.nio.ch.IOUtil.write(IOUtil.java:51) ~[?:?]
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) ~[?:?]
at org.eclipse.jetty.io.ChannelEndPoint.flush(ChannelEndPoint.java:264) ~[?:?]
... 27 more
2018-12-04 16:12:43.885 [INFO ] [control.internal.WebSocketConnection] - Web Socket close 1006. Reason: WebSocket Read EOF
It doesn’t appear to be a general issue.
Can you think of any context?
when does it happen? e.g. when you connect a browser to a OH2 UI? when you connect a mobile app?
How often does it happen?
Which bindings do you have installed? (that are using websockets?)
Looks like some https connection is failing.
Open up a new thread with all this info.
As stated in this issue I’m having some issues with the charts, can anybody confirm that?
M6 or M7?
Thanks, got that wrong in the github issue. I’m having the issues in M7, fixed it in the issue.
You’re already one step further, right now I would just like someone to check and confirm or not confirm the issue. I have installed the update on the day it came out and heard about that today the first time, so it might stay unnoticed for quite a while. If someone says that he/she doesn’t have the issue on the build I will do a complete bug report with all the details and do some investigations myself to see what might be going on here, if someone else has the issue aswell it’s most likely an issue in the code. If you have a group using rrd4j for persistence a simple check would be to use the URL I wrote in the github issue, insert the groups name and see how that looks like.
@Kim_Andersen have meet following tricky problem with M7 release. Problem have not seen with earlier versions.
IHC Binding doesn’t get all channelLinked “events” from OH/SmartHome core during OH full start, but if binding is restarted after OH start, the binding get all channelLinked events.
Most of the bindings are not interested by the channelLinked events, but IHC binding is.
IHC binding have couple of static channels (introduced by the thing defination)
and rest of the channels are generated on the fly (there can be hundreds of channels at the end).
It seems that only those static channels receive the channelLinked events on startup, but not others.
During openHAB start:
2018-12-04 20:40:29.043 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerUptime
2018-12-04 20:40:29.043 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerState
2018-12-04 20:40:29.047 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerTime
After binding restart:
2018-12-04 20:41:32.718 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerState
2018-12-04 20:41:32.742 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:temperature6145300
2018-12-04 20:41:32.737 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerTime
2018-12-04 20:41:32.756 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:controllerUptime
2018-12-04 20:41:32.773 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:temperature11011604
2018-12-04 20:41:32.780 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:output13957725
2018-12-04 20:41:32.780 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - channelLinked: ihc:controller:elko:output6512219
I can’t reproduce this problem on my development environment (Macbook pro). So this problem might be related to timing as Kim is testing this in Raspberry Pi.
@Kai have there been recently any changes on OH/SmartHome core which could have impact to thing channelLinked events?
To folow up on Pauli´s msg…
I run Rpi 3B+ with apt-get openhabian hasslefree.
I started off with a clean openhab 2.3 install, upgraded to #1445 and then #1447, and latest the Milestone M7.
I think the problem Pauli speak of could have been represented in #1447 and maybe even #1445. I just didnt pay enough attention due to some testing where I used the disable/enable button alot. (I can try downgrade and test if necessary??).
The IHC binding is the only extra binding installed, since my main purpose with this test setup was to test the new IHC binding only.
I can reproduce the problem even by restarting openhab, (I dont have to reboot).
The issue with the charts is that it defaults to mapdb for some reason, even though it doesn’t make sense at all as the mapdb doesn’t store historical values. This solution was provided by someone in the github issue.
Then please explain why this wasn’t an issue until now, it was working since I started with version 2, it never used mapdb for that.
No one with any suggestions to the above problem??
If the binding expects this, I would consider it a bug in the binding. The channelLinked() method is only meant for dynamic updates during runtime. It is absolutely ok that it is never called for channels, which are already linked at startup while the handler isn’t yet initialised.
Ok, then I have misunderstand the channelLinked method use.
Kai fixed it: correct swagger response type definition by kaikreuzer · Pull Request #6638 · eclipse-archived/smarthome · GitHub ! 
PR was merged 4 hours ago
We wait now for the new OH 2.4.0 Snapshot that will include the new ESH build
Maybe another Milestone #8 before 2.4.0 Stable also? 
1 Like
There’s quite a lot that got fixed, not putting out another Milestone is kinda risky. Also I still consider the changed behaviour of the chart an issue, mapdb has been my default forever and now it’s starting to cause issues and it’s documented absolutely nowhere that this might break during an upgrade (so maybe someone should start writing documentation instead of complaining that people don’t read documentation, pun intended).
If you’re telling people to read the documentation you should make sure the documentation people should read is there.
As long as you make sure in future that the documentation exists before you tell people to read it I’m fine with that. It’s a jerk move to say people haven’t read the documentation when there is no documentation at all about that particular topic.
So in conclusion: There should be at least some kind of note that the chart now respects the default persistence service (even if it doesn’t make sense at all), otherwise this probably won’t be the last message about this issue (and pointing to the documentation is not an appropriate reaction because it’s not documented anywhere).