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.
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
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.
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
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.
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?
Post the OH2 Item definition for the missing Item. Perhaps there is a clue hidden there.
Which REST API exactly ? The items API I imagine ?
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
Yes, please, that could help too.
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
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?
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
Is this binding essentially like the MQTT bus in OH2.4? It’s a great idea.
Yes, more or less I believe but with something easier to setup.
And the idea is coming from @Kai I just implemented it 
2 Likes
Of course, you can define your item type as Number rather than Number:Temperature and your problem should be solved.
1 Like
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.
How does it know 20.1 C or 20.1 F? Both are reasonably common temperatures to be encountered.
Sorry, I don’t know. Locale perhaps?
1 Like