I asked because I do not have the necessary knowledge.
If my proposal is merged, there will be now an enhanced description of the thing displayed in MainUI (for the users who are not reading the binding manual - I added a sentence in bold in the documentation too).
I just hope the description is enough clear now.
Good idea, that would have saved me at least 4 hours 
1 Like
Can this binding work through openhabcloud?
Yes, this is now possible to communicate with a remote server through an openHAB Cloud instance like myopenhab.org.
1 Like
Another interesting feature I recently implemented is the proper detection of a remote server proper shutdown.
So if your remote server is properly restarted, the main server will detect it and reconnect properly when the remote server is available again. This use case is now 100℅ reliable.
5 Likes
I did have some problems initially with losing the “thing” on the main server and had to relink the items from the remote openhab instance. I do not recall if it was due to a shutdown -r or a systemctl stop openhab on the remote instance. Because of this I have limited my use to a few remote server items. Does this feature you implemented solve both types of remote server actions? In what version is this feature implemented? I am on 3.0.1 right now.
Also before I ran across this post, I disabled the “accessibility” and “alive” flags (set to 0) thinking that would help. I haven’t had to either shutdown the remote (Rpi3) or stop openhab, so I don’t know if that helped. Any thoughts on that?
Bob
1 Like
The binding itself does absolutely not touch the links between local channels and local items. I doubt it exists any binding doing that, this is the domain of MainUI (or previously PaperUI) as this is OH administration.
The channels on the binding bridge thing are dynamic. As soon as an item is created/suppressed on the remote server, a channel is created/suppressed on the main server thing.
So when your remote server is properly shutdown, all channels are removed from the local thing. When it restarts, the channels are created again. Obviously, you don’t need to relink the channels to local items as these links are kept by the OH server.
I am not sure to understand exactly your problem but it looks like it is not related to the binding itself.
3.0.1 only provide critical fix, mainly for the core framework.
If you want to use the binding features implemented since end of December 2020, you have to install 3.1 M1 version.
Setting the accessibility setting to 0 is I believe a bad idea, it disables the check that your remote server is alive or not.
Setting the alive setting to 0 is a … choice but probably not the best choice. It will ignore if events were received through SSE when this is time to check if the remote server is alive. Even if an event was received recently, it will use the REST API to check if the remote server is reachable. Setting it to 0 breaks nothing but is useless when your remote server is triggering events frequently.
Thanks for responding.
I probably did not use the correct terminology. I have no problems or issues between the local channels and local items.
I probably need to upgrade to 3.1 M1 before commenting further, since what I tried to explain is probably fixed.
Thanks for the feedback on the “alive” and “accessibility”
Bob
Sorry if I did not understand your problem.
Just as a complement, the NTP binding is the good example of a binding triggering an event every minute. In this case, I would not set the “alive” setting to 0.
@Lolodomo Thank you for this great binding!
From time to time it happens to me, that some items don’t get updated <=> have different states in the OH3 with the remote openHAB binding.
My setup:
- Raspberry Pi with OH2 (data collector)
- Docker Container on my HomeServer with OH3 (UI and Rule-Logic)
I collect data like rollershutter end-position with the data collector. In the real world the rollershutter reached end position. In paper UI on the data collector Raspberry Pi it is shown correctly as 1 in the respective Number Item. But in the OH3 the item not always shows the same state.
Possible Solution??
Is it possible to define a refresh value on the item to force a refresh?
What I think is, that the SSE-connection got lost or some overload happened on the network layer…
Hi there,
I hope someone can help me with setting up the remote binding.
I want to get some items from my live OH2.5 system into my OH3 test system.
When copying remoteopenhab.things - which contains:
Bridge remoteopenhab:server:oh2 "OH2 server @Raspi3b" [ host="192.168.178.31", port=8080, useHttps=false, trustedCertificate=false ] {
}
into things folder, I’m getting this error:
Thing 'remoteopenhab:server:oh2' changed from UNKNOWN to OFFLINE (COMMUNICATION_ERROR): Failed to get the list of remote items using the items REST API: java.util.concurrent.TimeoutException
What do I need to provide in order to get it working?
Hello,
I’m trying to get this binding up and running. But somewhere, I’m missing a part.
My ‘Remote openHAB server’ is online on my second server B.
I’m trying to connect an KNX module to the remote server. But this part won’t come online? Any idea what I’m doing wrong?
Screenshot on server A, for the original thing:
Screenshot on server B, for the linked thing:
Maybe some info about the servers:
Server A: openHAB 3.1, IP: 10.10.10.11
Server B: openHAB 3.3, IP: 10.99.0.11
Servers are virtual, and on the same site, just a different VLAN, with a firewall in between.
ps Problem in this setup is that KNX is mixed through the whole building, and I would like to have different OH instances where people can’t control something in the other environment. Or better said, they can’t open other sitemaps…
Here is a part of the binding documentation :
Please note that if your remote server is an openHAB v3 server, in order for all of your things to be properly initialized, you will need to define on your bridge thing a valid API token in the parameter token and also define the parameter authenticateAnyway to true in case you are using an unsecured connection (HTTP). This API token can be created on your remote server using Main UI.
I have 3 remote servers and since moving to 3.1 or higher, I have not been able to get them to authenticate using the API token. Even before 3.1, I was constantly having them drop out and I would get, bad API errors. The only way I can get them to talk now it to turn on Authenticate Anyway. It is less secure, but it is inside my network and it is flawless.
This binding is brilliant. I’ve just set up a secondary openhab instance connected to my main instance. The secondary one will be used for showing openhab and letting kids play with blockly automation by working with a limited set of actual devices/sensors without disrupting the rest of the system.
Extract from the documentation: Set it to true in case you want to pass authentication information even when the communicate with the remote openHAB server is not secured (only HTTP).
So I just guess you are not using HTTPS.
If you set up your thing to use HTTPS, this should not be necessary to set authenticateAnyway to true.
This may seem like an odd question:
Is there a way for this binding to work in the opposite direction? an OH2 listening and running rules on items from an OH3 system. I know and already have my OH3 use items from an OH2 system.
There is no version of this binding available in OH2.5. It was introduced with OH3.0.
I created my items with a second channel and a follow-profile - so if I you move a binding to OH3 you can still reflect the item state back to OH2.
Example:
Number VAC_Ap_statusBat "Battery Level [%1.0f%%]" <battery> { channel="miio:vacuum:8cxxxxxxxx:status#battery", channel="remoteopenhab:server:192_168_100_3:VAC_Ap_statusBat" [profile="system:follow"] }