Send switch refresh via Remote openHAB item doesn't work

Setup, Configuration and Use Migration
1

I am running OH 2.5 and OH 3.3 with the Remote openHAB binding and I am switching over to OH 3.3 step by step. As of the current icloud-binding-problem, I disabled it on OH 2.5 and installed the fixed version on OH 3.3. But my setup is based on the basic UI from OH 2.5… So what I did is to create items on OH 3.3 for all the icloud channels. Additionally, I linked the those items against the old items in OH 2.5 with profile=follow.

So at the moment, I get all updates from the binding in OH 3.3 reflected to my items in OH 2.5 => works great!

But now comes the other way round. In OH 2.5 my setup looks like:

# sitemap
Switch item=iPhone_Refresh  mappings=[ REFRESH='Refresh now' ]

# old item configuration in OH 2.5
Switch iPhone_Refresh  "Force iPhone Refresh"  (giCloud)  { channel="icloud:device:xxx:location", autoupdate="false" }

So basically - when I click on REFRESH in the sitemap, the switch send REFRESH to the icloud-location-channel. This worked before in OH 2.5 and it works in OH 3.3. But it seems, REFRESH doesn’t work via the remote binding.

The allowed values of a switch are:
OnOffType: ON OFF
RefreshType: REFRESH

ON/OFF works perfectly but REFRESH doesn’t work…

Any idea what I do wrong here?

2

Note that I am very surprised it is possible to send a REFRESH command using this sitemap syntax…

I took a look to the remote openHAB binding to see what I implemented for the REFRESH command. You expect that the REFRESH command to be sent to the remote server and your expectation looks reasonable to me. Unfortunately, this is not the choice I did when I implemented this binding few years ago. The REFRESH command is caught by the main server and the item state (main server) is then updated with the last item state from the remote server. The REFRESH command is handled on the main server, rather than being sent to the remote server.

Today, I agree with you that the REFRESH command should rather be handled like any other command and so should just be sent to the remote server. I will probably prepare a fix.

2 Likes
3

Hi @Lolodomo - thanks for investigating. Actually I got the syntax for the sitemap from the original binding documentation! Currently I am “abusing” the openhab-remote binding to work in the opposite direction. Most of my rules/scripts etc. are still on OH 2.5 but as bindings are not fixed / updated for 2.5 anymore, I install them on OH 3.3 and update the items in OH 2.5.

For example: In OH 3.3 I define the item like this:

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"] }

This works fine! The only difference is that OH 2.5 receives the updates as a “sendcommand” instead as a “postupdate” - but this just means some more event.log-entries which doesn’t bother me

4

I submitted a change regarding the handling of the REFRESH command. The REFRESH command is now transmitted to the remote server.
You can try with the jar provided in the PR.

1 Like
5

Change has been merged. Will be included in next snapshot.

1 Like
6

I use a service openHAB instance that only provides the items, but no rules. Most local and cloud devices, e.g. harmony hub or Netatmo, are served from this instance.

Two further instances of openHAB, a productive and a development instance, are accessing the service instance via the remote openHAB binding.

The advantage of this approach is that I can use the newest bindings in the service instance, without the need to upgrade the productive instance. And in the development instance I can decide to upgrade whenever I want in order to adapt the rules.

The remote openHAB binding is therefore essential. In addition, when the development instance changes a serviced item, the item is also changed in the production instance.

So I have the following problem.

If an item file containing remote items is saved in the development instance, a REFRESH command is send to the service instance. This is ok for switch or number items, but it is not good for string items.

In my case the currentActivity of a harmony hub is stored in a string item in the service instance. If a REFRESH command is sent from the development instance, the string item associated with currentActivity channel becomes REFRESH. The harmony hub bindung raises a warning that REFRESH is not a valid activity, but does not change the currentActivity back.
Even if one say that the harmony hub binding should restore the current activity in such cases, the behavior to send a REFRESH on a string item in order to refresh its value is wrong in many cases.

Therefore I would propose not to send REFRESH on string items. Ideally it can be configured.