[SOLVED] Openhab android app sends commands after delay of 10-20 seconds

  • Platform information:
    • Hardware: Raspberry Pi 3B+
    • OS: Raspbian Lite
    • openHAB version: openHAB 2.5.0 Build #1619(in a docker container)
  • Issue of the topic: When I change the state of a sonoff switch running tasmota firmware through the app(while connecting through remote url), it takes around 15-20s to change the state of the switch. Is that some known bug in the app or am I missing something.
    However if I directly open the myopenhab.org in a web browser, it works instantly from there and also through the local url on the andoid app it again works instantly.

##Note: When connected through remote url in the app, If I turn on or off the switch, then press back button in the app, the switches change state as soon as back button is pressed.

Welcome to the openHAB Community :heart:

Okay, so if you switch the sonoff via the webUI of tasmota, the openHAB BasicUI (I guess) takes 15-20s to switch the state.
Yes I know this behavior, I had this myself. But since I switched to MQTT 2.X and config everything via PaperUI I never had this problem again.

It would be interesting to know which version of the MQTT Binding you are using.
If you did PaperUI config or manual text config.

Why would Paper UI or manual text configuration make a difference? I am just starting my newbie experience.

That my friend is a topic that got discussed so many times in the community :slight_smile: Just check the forum.

Generally spoken, PaperUI config is easier to use and you can’t make so much mistakes.
Just a quick example:

Textual / Manual MQTT

you will need to create the bridge thing in text, the thing in text, the item in text.
It’s like coding a single missing “,” or “</>” can change the whole behavior if you do not follow the manual.


Install Binding via Click.
Add MQTT Broker via Click.
Add MQTT Thing via Click.
Add Channels via Click.
Done. Working

THIS IS VERY VERY simplified! If you wish to know more about the differences pros/cons study the community forum and/or the docs.
google search

There are pros and cons. PaperUI comes into its own when there is an element of self-discovery about external devices/services. And as said, in places it guides you into predetermined sensible value selection.

When you are manually configuring though, I find it difficult to review a bunch of related Things; there’s no means to base a new thing on a previous thing (copy/paste/edit), it is not easy to share configs in a text based forum, etc. and I prefer to use xxx.things files.


I personally have been referring the text configuration wherever possible but I use HABmin for zwave discovery & config and for some discovery of things like weather & systemInfo.
Like I guessed, it depends very much on the particular binding requirements.

There’s no easy means. When I converted over to MQTT 2 I created one Generic Thing in PaperUI, stopped OH, then copied/pasted/edited that entry in JSONDB to create all the other MQTT Things/Channels I needed. It worked pretty well.

This has indeed been argued over quite a bit. Probably about a thousand posts have been made over it.

I’ll provide a bit of a tl;dr here for why it makes a difference. I am not reopening the discussion about how/whether to change this in openHAB 3. I’m just explaining how it works now and why.

It all started with openHAB 1.x. In this version of openHAB everything had to be configured with text files. The text config files are all a custom syntax based on Xtext (including the Rules DSL which is sort of a sibling of Xbase). So all the text config files you see are essentially hold overs from openHAB 1.x. Because everything was in text files, and one of the problems with these file formats is there is no file writer, automatic discovery was impossible. Every Item had to be configured with binding specific information, some of which had to come from watching log files for magic numbers and api keys and the like.

openHAB 2.0 was a near complete rewrite of the openHAB core. It introduced a pretty extensive REST API, moved to Karaf, internal storage for configuration (JSONDB), web based UIs for configuration, and the concepts of Things, Channels, and Links. Most of these changes including the JSONDB and new concepts were introduced to allow for automatic discovery of devices. But these changes and the rewrite involved a whole new way for bindings to work meaning that all the old OH 1.x bindings were no longer compatible with OH 2.

To address this problem an OH 1.x compatibility layer was created which is kind of a mini version of the openHAB 1.x core running on top of OH 2. This means that OH 2 has two minds, the old OH 1.x mind and the new OH 2.x mind. When dealing with OH 1.x bindings and addons we are dealing with the OH 1.x mind. Everything else uses the OH 2.x mind. This is why beyond installation, you can’t do anything in PaperUI (REST API) with 1.x bindings.

I’m not sure if the text config parser is part of the compatibility layer (I don’t think it is) but it is a similar hold over from OH 1.x. The loading of configs from the text files is a wholly separate subsystem of OH from the JSONDB. Thus there are two sources of truth in OH 2 that both feed into the internal memory of a running OH instance. It’s currently configured such that the text configs override JSONDB but there are still conflicts that can occur. But the main point is all the stuff you do in PaperUI is stored, loaded, and processed completely separately from anything done in text based configs. This is why it makes a difference.

Also, in addition to the fact that there is no writer for the text based config files, apparently the Xtext libraries that are used to parse them tend to be slow, especially for parsing Rules on an RPi. But reading and parsing JSON is super fast. So the more that is in JSONDB the faster loading and restarting.

But, it shouldn’t make a difference at runtime as Elias mentions so I don’t know specifically what that references. But the MQTT 2.x binding is a complete rewrite from scratch of the MQTT 1.x binding so there might be some bug or other in the 1.x binding that doesn’t exist in the 2.x binding.

For completeness, just to reiterate the controversies involved with this stuff. (I do not list these for discussion here, just for information. Everything that can be said has already been said).

  • OH 3 may drop support for 1.x addons.
  • OH 3 will completely replace PaperUI with a new unified web based UI. Some of the studies/prototypes for this UI have included the ability to copy/paste/edit Things and Items in the browser.
  • OH 3 will address the problem caused by there being two sources of truth in the config files.
  • I would not be surprised if OH 3 moves to some more standard format for text based configuration. YAML has been discussed. Perhaps it would be written so multiple formats can be supported. But this means there will be support for text based configs. Importantly, there will be a migration path between text based configs and REST API created configs. But likely the text based configs will be imported and loaded into the internal JSONDB (or what ever may replace that) and the internal DB will become the single source of truth
  • Rules DSL will be replaced with the Next Gen Rules Engine (i.e. JSR223/PaperUI Experimental Rules) as the default. No one is talking about dropping Rules DSL completely, but it will no longer be the default.

All of the above have been proposed and discussed at length largely to address the problems with the current text configs. But ultimately what happens and what doesn’t will depend on what the developers work on and manage to complete. An important feature that I push at all times is that there is a way to transition into all of these changes.


Sorry for not making it more clear to understand. The problem i am facing is this
I give command to turn on the switch from the openhab android app interface which is connected through the remote url, the actual switch turns on after 15-20 seconds so maybe the app does not send the commands instantly through the remote url.
However, if in the above scenario, whenever I press back button on my mobile phone just after issuing the turn on command, then the actual switch turns on right at the instant when the back button is pressed

Using the same openhab app through the local url works instantly and also using web browser based myopenhab.org account to turn on the switch works intantly.
The delay only occurs when using the android app and connecting through remote url.
Evaluating all these scenarios, I can say that there seems to be some problem with the app or the openhab build i am currently using as it is not sending data or command as soon as button is pressed.
As a workaround, I have to press the back button everytime i need to turn on or off the switches.

Thank you for the OH history lesson & explanation.
Is the testing Rules UI ready for everyday use? As a User I see warnings indicating it may not be ready for "prime time? I think another posing indicated loading text based rules can slow down startup.

Just want to take a moment to appreciate what you people have been doing out there for the community. It must take a lot of time and effort to keep things going and that too for no selfish interest. Thanks a lot to you people. Great job

1 Like

I’d do the following, just to clear everything out.

  1. Are you using the latest snapshot? If not you should try it on the latest just in case there is a problem that has already been fixed. Try it with the beta version of the app as well (it’s in the play store).

  2. Clear the Cache

  3. Restart the phone

If it still persists then file an issue on the openhab-android repo.

There are a few deal killer bugs still in the PaperUI implementation that makes it really hard to recommend, though they are slowing being worked down. The problems are with the UI though, not the Rules themselves. The UI is also missing some important Rule triggers like System started and a comprehensive cron trigger. I believe the underlying JSON supports it, it’s just a problem with PaperUI, which no one really knows how to work on anymore so fixes and new features are hard to come by (this is why it’s being replaced).

If you want to go for something more future proof than Rules DSL, the JSR223 Rules are totally ready for prime time. With the helper libraries writing Rules in Jython or JavaScript is basically as easy to learn and do as Rules DSL. These rules get executed using the same engine as the PaperUI Rules and should you choose to move to the UI created Rules at some point it shouldn’t be too difficult.

It’s mainly Rules DSL Rules that are a problem (i.e. .rules files). Text based JSR223 Rules load up really fast.

1 Like

I guess I need to look at other rule options when I get time. I assume Jython is similar to Python?

It’s Python 2.7 (I think) that can run on the Java Virtual Machine. When we are able to move OH off of Java 8 and onto something newer, a whole world of languages will open up to us through Graal VM.

If you prefer Python 3, @Spaceman_Spiff has written HABApp. Lots of users use NodeRed for rules as well. There are many options.

1 Like

Considering Python 2 becomes totally unsupported in January, I may look at HABApp & Pyhon 3.

Im running nginx with user name and password, passing port 70 to port 80 internally.
I open port 70 on my router to the RPI ip address, and i use a chrome home shortcut on my phone to connect to my openhab remotely.
This way im actually not running through the cloud. So if and when the cloud is down. i can still control everything from anywhere

This way is also about 3 -4 times faster than running the android app and connecting through the cloud.
I keep the android app connected through the cloud for notifications and that is it.
My sonoff items have a delay of approx 200ms to 500ms. Nothing more than that, no matter where i am.

Okay thanks I ll try updating to the latest snapshot today.

Yes I know that is something which can be used ofcourse. But I do not have a dedicated IP address at home as my ISP would charge some 4-6 dolars more per month for just an IP address, so the cloud solution seems to be the only option.
I have tried the cloud before, with openhab 2.4 release and it worked fantastic. The problem only occured after I shifted to snapshots.
However I think this problem may be with the build I am using(couple of weeks old). So I hope this would not be there in the latest snapshot build.

Ugrading to the latest snapshot removed the issue. Thanks

1 Like