I try to connect to OH 2 from OH 3 with Remote Openhab Server binding. It stays at “unknown” for over a day. I have tried restarting both Thing, OH and computer. OH 3 on windows 10, OH 2 on Win 7.
I believe the server is more useful than the thing. When I tried using the thing and opened a GitHub Issue I was told I misunderstood the purpose of the thing in remoteopenhab.
EDIT I just looked at the documentation and we need @Lolodomo to help clarify, I think.
That issue needs to be fixed first then. I think it takes a few minutes for the binding to discover the server channels once online.
What do the logs say? Is the IP address of the server correct and reachable from OH3? In the advanced configuration you can also specify the OH2 port used.
Im not so good on log files
IP adress should be correct, and in my first post “/rest” from that IP is shown. I guess thats correct data there?
Log files:
2020-12-28 16:20:45.930 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘remoteopenhab:server:94557b3211’ changed from UNINITIALIZED (DISABLED) to INITIALIZING
2020-12-28 16:20:45.999 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing ‘remoteopenhab:server:94557b3211’ changed from INITIALIZING to UNKNOWN
2020-12-28 16:20:46.084 [WARN ] [mmon.WrappedScheduledExecutorService] - Scheduled runnable ended with an exception:
java.lang.IllegalArgumentException: Duplicate channels remoteopenhab:server:94557b3211:MoonFull
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:128) ~[?:?]
at org.openhab.core.thing.binding.builder.ThingBuilder.withChannels(ThingBuilder.java:86) ~[?:?]
at org.openhab.core.thing.binding.builder.BridgeBuilder.withChannels(BridgeBuilder.java:74) ~[?:?]
at org.openhab.core.thing.binding.builder.BridgeBuilder.withChannels(BridgeBuilder.java:1) ~[?:?]
at org.openhab.binding.remoteopenhab.internal.handler.RemoteopenhabBridgeHandler.createChannels(RemoteopenhabBridgeHandler.java:260) ~[?:?]
at org.openhab.binding.remoteopenhab.internal.handler.RemoteopenhabBridgeHandler.checkConnection(RemoteopenhabBridgeHandler.java:336) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) ~[?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
I was not aware that is was possible to have several items with the same name !
As this is something of course to be avoided (makes no sense), the workaround is easy, just delete any duplicated item in your remote server.
Now, yes, the remote openHAB binding should be more robust and not fail in this unusual case. So something has to be fixed, like considering only the first item with a certain name and then ignore the other items with the same name. But this will be low in my priorities. You can open an issue in Git to not forget it.