![]() you don't care about the trigger channels of this remote thing and you don't want the binding to create them locally,.Setting the buildTriggerChannels parameter to false is for the main following advanced usages : Please note that if your remote server is an openHAB v3 server, you will need to define a valid token on your bridge thing to have your things correctly initialized. If set to true, a trigger channel will be automatically created and linked to each trigger channel from the remote thing. The thing UID in the remote openHAB server. The thing thing has the following configuration parameters: Parameter Number of last minutes to take into account to determine whether the remote server is alive. Minutes between checking the remote server accessibility. The token to use when the remote openHAB server is setup to require authorization to run its REST API. The subpath of the REST API on the remote openHAB server. Set to true if you want to use HTTPS even without a valid SSL certificate provided by your remote server. The HTTP port to use to communicate with the remote openHAB server. Set to true if you want to use HTTPS to communicate with the remote openHAB server. The host name or IP address of the remote openHAB server. The server thing has the following configuration parameters: Parameter The binding has no configuration options, all configuration is done at Thing level. Once a bridge thing representing a remote openHAB server is created, all things from this remote server will be discovered when you scan for new things. So if your remote server has one IPv4 address and one IPv6 address, you will discover two things in the inbox. You will find in the inbox one discovery thing per remote server interface. # DiscoveryĪll openHAB servers in the local network are automatically discovered (through mDNS) by the binding. There is two supported things : the server bridge thing representing a remote openHAB server and the thing thing representing a thing from the remote openHAB server. The Remote openHAB binding installed on the openHAB v3 server will then allow to use the openHAB v1 bindings through communication with the openHAB v2 server.Ī third usage is for users that would like to keep unchanged an existing openHAB v2 server but would like to use the new UI from openHAB v3 they can simply setup a new openHAB v3 server with the Remote openHAB binding linked to their openHAB v2 server. They can keep an openHAB v2 server to run their old openHAB v1 bindings and setup a new openHAB v3 server for everything else. One use of this binding is to distribute your home automation system on multiple openHAB servers.Īnother use is for users to interact with older versions of openHAB that may support old openHAB v1 bindings that were not migrated to openHAB v2 or openHAB v3. Through this mapping, in your rules (local server), you can take actions based upon status updates or status changes generated by remote things and you can take actions based upon trigger events generated by the trigger channels defined in the remote thing. It can map any remote thing to a local thing. It transfers any item command from the local server to the remote server. The binding on the local server listens to any item state updates on the remote server and updates accordingly the linked channel on the local server. ![]() The Remote openHAB binding allows to communicate with remote openHAB servers.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |