I think the issue would be running 2 different Java versions on the same machine. One of the OH instances can be run on a different web port to avoid conflict.
I think I read somewhere that OH2 works with Java 11.
Assuming Java version wouldnât be a problem, would my targeted setup work? What about the issue regarding port 8080?
People have got some parts of OH2 to work with Java 11 but I would not assume your favourite v2 or v1 addons work with it.
That port is configurable, I skirt that issue by using Docker and mapping one to 8081.
It can be done but itâll be a good bit of work. openHAB actually opens a bunch of ports beyond 8080 and youâll need to remap all of them to alternates to be able to run both instances at the same time.
Another gotcha is only one of the OH instances can access physical hardware devices (e.g. Zwave controller)at a time.
Given these, it might be easiest for you to stop your OH 2 instance while working on OH 3 and then turn off OH 3 when you are done and restart OH 2.
I am working on semantically creating Items in OH3 linked to my OH2 Items. I will then create OH3 Rules on them.
At some point I will âcut overâ Z-Wave from OH2 to OH3 and re-link the Items to the proper Things. This is similar to how I cut over from Home assistant to openHAB2.
@Lolodomo I found one issue today with the binding: If the remote openHab Server temporary loses its network connection then it does not recover. In my setup my Z-Wave devices run on a remote openHab Server and my main instance connects with the Remote openHAB Binding. After unplugging the network cable of the remote server for a couple of minutes and plugging it back in, there were no more state updates of the remote items on my main instance. However, I still could send commands successfully to the remote server (e.g. switch light on) and the lights were switched on. But, these state changes were not reflected back to the main instance (e.g. power meter values for the light did not change etc.). So the communication after a short loss of network conenction was no longer bidirectional.
Would it be possible to get it back working automatically?
open a Github issue. He responds quite promptly.
Received update does not seem to work. Could be an OH3 issue, or binding?
I have linked an item remotely from OH2 and have a rule:
rule "TestReceived"
when
Item MyRemoteOpenhab2Item received update
then
logInfo("TestRule", "Received update")
end
Changed will work:
rule "TestChanged"
when
Item MyRemoteOpenhab2Item changed
then
logInfo("TestRule", "Changed")
end
I was aware that it could happen if you restart your remote server and there was no availibility check during this period (check is run every 5 minutes by the binding). Your case is similar but I did not imagine that just disconnecting the network cable would have this impact. You can open an issue but I have no solution yet. It would be interesting to test your case to see if the behavior is different.
If your server is unavailable more than 5 minutes, the connection should be restored properly when reconnecting.
Well, this is going to be too complicated for me.
I decided to migrate my OH2 back from NUC (2.5.10) to Syno (2.5.2) and set up OH3 on NUC from scratch. Then I linked both instances with this binding.
Zwave remains on OH2 for now.
Now migration can startâŠ
Thanks a lot !!
@Seaside : works for me.
What action are you doing to trigger the update ? From OH2 ? From OH3 ? From your hardware device ?
Please show your OH2 logs to see the state changed and please show the corresponding TRACE logs of the remote openHAB binding in OH3.
@vossivossi : try this scenario:
1 disconnect your network cable from your remote server
2 wait few minutes until the server appears as OFFLINE in OH3
3 reconnect your cable
4 wait again few minutes until your server appears as ONLINE in OH3
5 normally now you should receive again updates through SSE.
Thank you for your quick reply. I tested exactly this prodecure tonight. After 9 minutes (after disconnecting the network cable) the remote OH-Server went offline. Then I reconnected the cable. After about 5 minutes later the items restarted to update again
However, this is not a really âbullet-proofâ implementation as it seems you need to have a blackout for at least 5-10 minutes, otherwise you are lost.
So why not rechecking every 30 seconds? It seems that the binding is actually able to recover by itself but it is âtoo blindâ to notice that when the period of time was too short?
Yes youâre right, it will take between 5 and 10 minutes.
Sending a request every 30 seconds if there was no traffic looks to me a little too much.
But I should check more often if there was traffic during the last 5 minutes, like for example every 30 seconds. Then the detection will occur between 5 min and 5 min and 30 s.
And going from 5 minutes timeframe to 3 minutes will look reasonable too.
But by the way there will still be some short disconnection not detected.
But why? I do not assume that a short âstill alive pingâ would cause that much traffic?
And on the other hand, even if the binding should not notice at first sight that the other server was down, it should definitely notice that no more updates are received from the remote server, so the âreinitialisationâ should also be tried in this case.
No because you can have a remote server alive but publishing more or less nothing. Not a common case but largely possible depending on what bindings are installed.
You can have a server working perfectly but which send nothing during several hours.
I will define a configuration setting for this timeframe (in minutes) so that everyone could decide what timeframe is appropriate to its remote server,
It does make sense to try at half that time if a failure is detected.