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.
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.
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.
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?
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.
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?
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.
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.
Yes, not using Quantity types at all would solve lots of problems, but where’s the fun in that
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.