Remote openHAB Binding

Add-ons Bindings
1

Here a new binding available in OH3 official distribution.

The Remote openHAB binding allows to communicate with remote openHAB servers. The communication is bidirectional. 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. It transfers any item command from the local server to the remote server. It can map any remote thing to a local thing. 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.

One use of this binding is to distribute your home automation system on multiple openHAB servers.

Another 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. They can keep an openHAB v2 server to run their old openHAB v1 bindings and setup a new openHAB v3 server for everything else. 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.

A 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.

16 Likes
2

All features are now included in OH3 snapshots.

3

@Lolodomo Could this be used also as 4th alternative, first 3 are (1) openhab2 cloud (2)reverse proxy (3) vpn, to access your openhab2 installation remotely?

4

Another usage would be to migrate from OH2 to OH3 more gradually. You could gradually build the Items rules and UI in OH3 and move the back end bindings such as Zwave after all the infrastructure is in place.

5

This is my current usage. I am migrating from OH2 to OH3 step by step. All my rules are now migrated to OH3 and most of the bindings I am using. I still have 3 bindings still running on OH2, including Z-Wave binding.

6

Not exactly because the remote openHAB binding does not give you a full access to your remote server. It does not replace Paper UI for example.

1 Like
7

I installed the binding in a fresh install of OH3 M3, and created a bridge item for my main OH2.5.9 instance. The binding discovered all of my things as expected but unfortunately created all of the channels under the bridge item itself. The rest of the items have blank channels page. I imagine this isnā€™t the intended design?

Both versions of OH run as Docker containers.

8

Yes, this is exactly what is intented. Remote items are mapped to channels on the bridge thing.

You probably mean the rest of thingsā€¦
Yes, only channels of type trigger are created on these other things.

Extact of the documentation:

Channels are built dynamically and automatically by the binding.

On the ā€œserverā€ thing, a channel is created automatically for each item defined in the remote server. Only basic groups (with no state) from the remote server are ignored. The channel ID of the created channel corresponds to the name of the item on the remote server. For example, if your remote item is named MyDate, the channel UID of the channel created by the binding will be remoteopenhab:server:xxx:MyDate.

On the ā€œthingā€ thing, if the buildTriggerChannels parameter is set to true, a channel is created automatically for each trigger channel defined in the remote thing. For example, if your remote thing provides a trigger channel with this UID astro:sun:local:night#event, the channel UID of the channel created by the binding will be remoteopenhab:thing:xxx:astro_sun_local_night_event.

1 Like
9

Thanks for the reply. That makes sense. I was thrown off by all the trigger things. I donā€™t plan on using them so Iā€™ll hide them for clarity.

Thanks for your work on this binding! Iā€™m planning on a gradual cut over to openHAB 3 and this binding makes it far simpler.

10

Thank you for making this binding. It means I can migrate to OH3 slowly and learn along the way. I have one issue I hope you can help with.
The binding is installed on OH3 M3 and I have all the items from my OH2.5.10 connected over the bridge.
Some of the items do not update.
This is the OH2 log:

2020-11-26 12:08:02.542 [vent.ItemStateChangedEvent] - ValveStudyTRV changed from 86 to 98
2020-11-26 12:08:02.621 [vent.ItemStateChangedEvent] - TemperatureStudyTRV changed from 26.5 Ā°C to 25 Ā°C
2020-11-26 12:08:09.455 [vent.ItemStateChangedEvent] - RoomStatSignal changed from 26 to 24
2020-11-26 12:08:55.413 [vent.ItemStateChangedEvent] - TemperatureKitchen changed from 22.0 Ā°C to 21.9 Ā°C
2020-11-26 12:09:08.265 [vent.ItemStateChangedEvent] - TemperatureT15 changed from 22.17 Ā°C to 21.88 Ā°C
2020-11-26 12:09:23.539 [vent.ItemStateChangedEvent] - ShowerSignal changed from 70 to 72

and this is the OH3 log:

2020-11-26 12:08:02.548 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'RemoteopenHABServer_ItemValveStudyTRV' changed from 86 to 98
2020-11-26 12:08:02.636 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'RemoteopenHABServer_ItemTemperatureStudyTRV' changed from 26.5 Ā°C to 25 Ā°C
2020-11-26 12:08:09.460 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'RemoteopenHABServer_ItemRoomStatSignal' changed from 26 to 24
2020-11-26 12:09:08.277 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'RemoteopenHABServer_ItemTemperatureT15' changed from 22.17 Ā°C to 21.88 Ā°C
2020-11-26 12:09:23.544 [INFO ] [marthome.event.ItemStateChangedEvent] - Item 'RemoteopenHABServer_ItemShowerSignal' changed from 70 to 72

Notice that the TemperatureKitchen is missing from OH3

On my OH2 setup, TemperatureKitchen is defined as a Number:Temperature, and it is updated by a REST API PUT
I have other items, but just defined as Number, also updated the same way with a PUT, and they work OK i.e. the OH3 item is updated.

I have also tried using a POST, but that doesnā€™t propagate to OH3 either.
Do you have any ideas?

11

Post the OH2 Item definition for the missing Item. Perhaps there is a clue hidden there.

12

Which REST API exactly ? The items API I imagine ?

image
image1186Ɨ718 83.5 KB

You have one to send a command (POST) and one to update an item state (PUT).
By the way, this is not the problem as your item state is changed on your remote server.
Can you please enable DEBUG logs in the binding and see what is logged when you update the remote item state. If you see nothing special, please enable the TRACE logs and show them to me.

1 Like
13

Yes, please, that could help too.

14

With the logs, the idea is first to be sure that the binding is receiving an event for your remote item state change, and then to understand why it is not handled correctly by the binding.

1 Like
15 
Number:Temperature TemperatureKitchen "Kitchen Temperature [%.1f %unit%]" <Temperature> (gKitchen, gHistory)

But I have many other items defined the same way.

The items are updated by a Python script (using requests.put() ) but I have also tried using the openHAB REST UI, and, as you say the remote server is updated correctly.

Iā€™ve enabled debug, and get:

2020-11-26 19:38:08.821 [DEBUG] [l.handler.RemoteopenhabBridgeHandler] - Unexpected value type Decimal for item TemperatureKitchen

This happens for all the items updated by my Python script (about 11 items)
Hereā€™s that code:

def updateOpenhab(item: str, value: str) -> None:
    url = f"http://127.0.0.1:{OPENHAB_PORT}/rest/items/{item}/state"
    headers = {"Content-Type": "text/plain"}
    requests.put(url, headers=headers, data=value)

and hereā€™s the karaf item form OH2:

openhab> items list TemperatureKitchen
TemperatureKitchen (Type=NumberItem, State=22.9 Ā°C, Label=Kitchen Temperature, Category=Temperature, Groups=[gKitchen, gHistory])

I guess Iā€™m doing something wrong at the OH2 side, although itā€™s been working fine for years. Can you suggest where else to look?

16

The explanation is that the expected state is a Quantity type when the item is a number with dimension. And the received state is of type DecimalType in your case. This is probably due to the way you provide the state with your script.
If I accept Decimal type, I will not know what unit to consider for this value.

1 Like
17

Is this binding essentially like the MQTT bus in OH2.4? Itā€™s a great idea.

18

Yes, more or less I believe but with something easier to setup.
And the idea is coming from @Kai I just implemented it :wink:

2 Likes
19

Of course, you can define your item type as Number rather than Number:Temperature and your problem should be solved.

1 Like
20

Yes, not using Quantity types at all would solve lots of problems, but whereā€™s the fun in that :wink:
So Iā€™ve (sort of) figured out whatā€™s going on.
If you define an item in OH2 as Number:Temperature and using the openHAB REST UI, do a items PUT using say ā€˜20.1ā€™ as the value, then the Remote openHAB binding (on OH3) flags a ā€˜Unexpected value type Decimalā€¦ā€™
However if you use ā€˜20.1 Ā°Cā€™ as the value then it doesnā€™t.
But OH2 does not complain about being sent ā€˜20.1ā€™ and a subsequent GET on the item returns 20.1 Ā°C i.e. it has converted it to a Number:Temperature to store into the item, but what gets published (on the Event Bus?) is just a Number, which the Remote openHAB binding picks up.
Iā€™m not sure what to conclude about this, but thereā€™s some inconsistency somewhere.
This is not really a problem for me, as Iā€™m just using it as a playground for OH3, but hopefully it makes others aware.