Why is openhab server calling openhab.jfrog.io?

I have been playing with Pi Hole that is a server that reroutes add’s.

One of the (main) reasons why I installed it, is it gives me a view of what are all the different machines/programs in that are calling home (or other places)

To my surprise I saw that my openhab server did +300 calls to openhab.jfrog.io
and that in less then a few hours.

Maybe it has a reason why this happens. I can’t see it.
Will someone explain me why this is needed?

( I have openHAB 2.3.0 Build #1260 installed on a Pine64)

I can’t say why it is calling that frequently. But I believe jfrog is whether the add-ons are hosted.

why would an installed and configured server need to contact the place where add-ons are hosted?
(we are at 495 now, its the most contacted domain from my whole network… )

Unless you configured an offline installation, OH downloads add-ons on demand. And for the longest time offline installs didn’t work anyway.

Again, I can’t say why it is contacting it so frequently.

I assume the online installs are still done when there are changes done to the configuration.
I did no change on the configuration last night.
While I was asleep, we now have 1140 connections…

who can tell me why it’s so frequently?

You can always block it and see what breaks.

Same here.

Many many many connections to www.appbeat.io and openhab.jfrog.io

Is this because of myopenhab online connection for remote access (habdroid android app)?

I did a grep through userdata. The jfrog URL appears in

  • userdata/config/org/ops4j/pax/url/mvn.config
  • userdata/etc/org.ops4j.pax.url.mvn.cfg
  • userdata/etc/version.properties

The last one confirms that this has to do with the bindings.

online-repo : https://openhab.jfrog.io/openhab/online-repo-snapshot/2.3

I suspect that maven is configured to poll jfrog for changes since usually when it sees changes it can initiate a build to update your install. But OH doesn’t work like that. There won’t be any changes to that repo so the polling isn’t doing anything as far as I can tell. But I’m just guessing here.

@kai, is this expected behavior or something that is miss configured? If miss configured, is the openhab repo the correct place to create an issue?

From what I can tell from here all we would need to do is add an org.ops4j.pax.url.mvn.globalUpdatePolicy option to the mvn config or adding an update option to the jfrog URL in that config file:

https://openhab.jfrog.io/openhab/online-repo-snapshot/2.3@id=openhab@snapshots@update=never

Of course, this presumes that the default behavior is not desired. This is all far outside my area of expertise.

As for appbeat.io, @halloween, I suspect you have an add-on or some other program that is polling address. I cannot find that domain anywhere in my installs.

1 Like

how can i check which file or binding is causing this? My openhab is installed on debian.

1 Like

With netstat -tp you can see the processes with open connections. If you add -c it will update regularly.

Unfortunately it won’t help to identify a binding because it the connection is made by an addin the process name will be “java”.

I have searched on githup the different openHAB repos and did not find any reference to appbeat. Did you install any add-ons from Marketplace? Maybe somebody added calls to appbeat to collect information about the add-on usage.

https://www.appbeat.io/status/openHAB is the openHAB Infrastructure page. So this probably has to do with my myopenHAB.

It’s the myopenHAB cloud service that connects to appbeat but not every single installation of openHAB.

BTW: I also checked the source code of HABdroid and also no reference to appeat .

1 Like

That is it. I have an item to check myopenhab online status.

So only jfrog is to look at now.

Correct, openhab.jfrog.org hosts our snapshot online repository, while bintray.com hosts the one for releases (so if you use 2.2 you will see connections to bintray instead).

Note that you can configure whether the online repo should be used or not - this is done in the addons.cfg file (or alternatively in the Paper UI Configuration->System->Add-on Management). If this is disabled, I’d assume that no outgoing calls are made.

But i think, online repo is only called, when i do apt-get update inside linux? What is this from inside openhab?

Can i set up less frequent updates for this? One time in a hour instead of so many times?

That has nothing to do with apt. The online repo simply contains all add-ons of openHAB, see http://www.openhab.org/downloads.html: “This is a zipped version of openHAB runtime. It is configured to install any add-on from a remote repository.”

I think the confusion is if these assumptions are true:

  • once I install for example OH 2.x SNAPSHOT xxxx OH will only install add-ons of the same version and build number
  • this means the add-ons are not being updated or changed for that specific version
  • the only time OH should need to contact jfrog is when installing a new add-on

So the question/concern is why OH contacts jfrog over a hundred times per hour (at least for yves)? It isn’t learning anything new and nothing is changing. That ends up being a whole lot of hits to jfrog doing nothing.

Or is there something I’m missing or don’t know about that makes Maven or whatever is doing the polling to check so frequently?

These are good questions and I have to admit that I do not know a detailed answer either.
What openHAB is using here is a standard feature of Apache Karaf, which in turn uses OPS4J Pax URL.
So the best way to find an answer (as well as possibilities to reconfigure this behavior) would be at https://ops4j1.jira.com/wiki/spaces/paxurl/pages/3833866/Mvn+Protocol and http://karaf.apache.org/manual/latest/#_artifacts_repositories_and_urls. If anyone finds optimized settings, I’ll be more than happy to accept changes to those in openab-distro!

@yves, can you change the jfrog url in userdata/etc/org.ops4j.pax.url.mvn.cfg to match what I posted in post 9 above (with the @update=never appended to the end) and see if;

  1. the polling of jfrog stops
  2. you can still install new add-ons

If so, I think that would do the trick.