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.
1 Like
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,
2 Likes
It does make sense to try at half that time if a failure is detected.
Will this work with OH 1.8? This looks like the way I can start with OH 3.
Thanks
Not likely but your v1 bindings will likely work with OH 2.5 & permit you to bridge to OH3.
While this may be true in some cases I still see a bigger problem in a logic that assumes that every “silent” remote server is healthy. And especially the use case of short network interruptions happens very often in real life situations (e.g. short WLAN interruption, if it is a WAN connection a small interruption of internet access or VPN, a short power failure because of a fuse etc.). And in all these comman cases the binding would not recover by itself but falling in a stealth mode without publishing any item updates.
That sounds a good idea to me 
I am not sure at all that a short network interruption leads systematically to a problem in the current version. To be checked by myself with your scenario consisting in disconeccting the network cable just a short time.
Maybe the connection is lost if the remote server tries to publish something while the network is no more available?
That might indeed be possible. In my case this was definetely the case as the remote server is running about 60 ZWAVE devices and provides 183 items which are subscribed by the main instance. According to my persistence data there are about 550 updates per hour on average , which means one update every 7 seconds .
No, OH 1.8 doesn’t support the REST API necessary to make the binding work. But you can use the MQTT Event Bus tutorial approach on the OH 3 side and the MQTT EventBus configuration of the MQTTv1.x binding on the OH 1.8 side too achieve the same thing, with just a bit more work.
1 Like
PR to let you setup the remote server accessibility check (two new advanced settings):
2 Likes
Thank You, More than you know appreciate your work!!!
The change with the new settings is merged.
But there is not yet any snapshot including the last changes.
2 Likes
All recent changes are included in snapshot 2061.
4 Likes
Hi,
I tried to use the Remote Opnehab Binding in OH3-M5. After connecting to my OH2 instance I was able to autodiscover all my remote things, for example:
[INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'remoteopenhab:thing:openhab2:rfxcom_rfy_usb0_buero' to inbox.
But my remote things doesn’t have any channels:
This thing has no channels. Either the thing type doesn't define channels, or they may be detected and appear later. (Message in the channels tab in main ui)
Any ideas, what could be wrong?
The server bridge should have channels, each representing an OH2 Item. You can then link them to OH3 Items.
@Bruce_Osborne: Thank you for the hint, there they are. I expected them on the thing page, my fault.
Now everything works well. Great binding!
1 Like
I tried the Thing way too & thought I hit a bug. All the developer would say is I misunderstood the purpose of that part