InfluxDB+Grafana persistence and graphing

I have 2 questions:

  • Did anyone test this on a windows machine?

  • Does Grafana also work with MySQL?

Thx & Regards
John

Hey @JohnnyX, sorry to be that guy but you would have been quicker googling this yourself :slight_smile:

first:

second:

thx got it running.
just one thing I found is, that with the newer version of influxdb the default retention policy is named autogen.

For openhab I needed to create a retention policy named default to get it working.

The generation speed to create png files is horrible slow on my ARM (Odroid U3). So the way to embed image charts is not interesting on such devices. I toked more then 16 seconds on a fast ARM device, RPi’s are much slower!

Hey @csowada, thanks for your input! I did not try on a raspberry pi yet but I hoped to make it work. Would be nice to be able to use “one for all” but yeah, we will see :wink:

For influxdb, they now produces official arm packages, so there is no need to build it yourself. For Pi, the article on aymerick’s blog deals with an old version of Grafana and things have changed a bit since then.

If you are on raspbian/jessie, it is relatively easy to build merely following the official build instructions. The only thing to be careful about is to get a PhantomJS for your pi and have it in your path, before the npm setup. On raspbian/wheezy, it is a bit more involved since Grafana requires a c++11 compliant g++. I wrote some explanation on how I proceed for wheezy and jessie.

For those not inclined in building the packages themself, you can have a look at the one I put on github which is for wheezy or jessie, tested by me on a raspberry pi 2 and reported to work on raspberry pi 3.

3 Likes

Hi,

I tried to set it up on a raspberry but I have a problem with the default RP as the current version of influxdb is v1.0.0. and in this version the RP created by default is named “autogen”

This makes imposible to persist data on OH. It shows an error
"error":"retention policy not found: default"

I tried to create a RP named “default” in influxdb, but it is not posible to create a RP with this name. Any other name is accepted.

> CREATE RETENTION POLICY default ON openhab_graf DURATION 72w REPLICATION 1 DEFAULT
ERR: error parsing query: found DEFAULT, expected identifier at line 1, char 25
Warning: It is possible this error is due to not setting a database.
Please set a database with the command "use <database>".

So, what is the solution?

I’m not sure about that problem and if it is of any meaning but your error is pretty clear. As the last line says, you just have to type use openhab_graf first.

I tried that, but still the error persists. Here you have an example with a diferent database name “openhab_db”

> use openhab_db
Using database openhab_db
> CREATE RETENTION POLICY default ON openhab_db DURATION 72w REPLICATION 1 DEFAULT
ERR: error parsing query: found DEFAULT, expected identifier at line 1, char 25
> 

Basically, “default” name as a RP can’t be used. Influxdb doesn’t accept it.

You can check the change request in github here:

Yes I know that thread. A good choice to rename it. The real question for me would be why you even need a retention policy and (because of xyz) why you insist to name it default…

I only insist in creating a “default” RD because I am geting the following error message:

2016-09-27 21:05:54.404 [ERROR] [org.influxdb.impl.BatchProcessor    ] - Batch could not be sent. Data will be lost
java.lang.RuntimeException: {"error":"retention policy not found: default"}

Mi understanding is that the data is not being persisted because “default” RD doesn’t exist.

Is my assumption correct?

For what I see in the following post, the same error is happening with Telegraf + InfluxDB and in their GitHub their solve it upgrading Telegraf. Aparently the latest version on Telegraf takes into account the change of “default” to “autogen”

In my opinion a change must be done in the InfluxDB persistance OH module to support InfluxDB v1.0.0.101. Is that correct?

I just realized that such change has been already done in the last version on InfluxDB 1.9

There is a new parameter called: retentionPolicy that you can add in InfluexDB service

So just add the following line to influx.db

retentionPolicy=autogen

Now I get it. I didn’t know that openHAB / the InfluxDB addon needs to concern itself with the RP.

A solution is out there though. According to this commit, there is an option to set the retention policy to use: Influxdb update influxdb java api, make retentionPolicy configurable … · openhab/openhab1-addons@fc3ca48 · GitHub
Thanks to @theo :wink:

1 Like

Ah you also found it. Thanks for pointing out that problem! I’ve updated the article.

With this great guide, I have nice graphs, however, I’m struggling getting the image in oh2 to work.

I have oh2 and influxdb+grafana running on a linux (gentoo) server named ‘xenon’.
I have setup a reverse proxy on this machine using the also great guide here; thread
(I don’t think this is part of the problem now, since I’m initially just running the grafana graphs directly here at home (xenon:8080/basicui/ etc ), but who knows - I’m out on deep water here.)

I have triple checked that I have anonymous enabled in grafana ini file.

I run all tests on my desktop.

If I go directly to the link from “Direct link rendered image” I get the image. In my case;

http://xenon:3000/render/dashboard-solo/db/nydashboard?from=now-24h&to=now&panelId=2&width=1000&height=500

But when I inser this into my sitemap accordingly;

Image refresh=60000 url="http://xenon:3000/render/dashboard-solo/db/nydashboard?from=now-24h&to=now&panelId=2&width=1000&height=500"

… I’m left with a broken image.
If I right click on the broken image link, and select “open in another tab” (Mozilla), I get;

HTTP ERROR 504
Problem accessing /proxy. Reason:
Gateway Timeout
(jetty)
Could it be that the image generation, which takes some time, takes too long time? I’m not sure
In the grafana log, I see;

t=2016-10-16T16:08:14+0200 lvl=info msg="PhantomRenderer::renderToPng url [http://localhost:3000/dashboard-solo/db/nydashboard?from=now-24h&to=now&panelId=2&width=1000&height=500]"

And finally, in oh2 log, I receive this line;

16:13:29.229 [WARN ] [thome.ui.internal.proxy.ProxyServlet] - Proxy servlet failed to stream content due to a timeout

Any suggestions welcome! :slight_smile:

Correct, if you’re running through openHAB’s 8080 port directly then then I doubt the reverse proxy server will be affecting your results.To completely eliminate this as a potential cause, you can simply disable nginx service (sudo service nginx stop) test what you’re doing and enable it again (sudo service nginx start).

Of course! Why did I not think about that! :slight_smile:

This made no difference though, so we can put that out the way.
However, I timed the time it takes for a graph to show when I put it directly into the browser, and it is somewhere around 7 seconds - very long time, considering this is on a core i7. Even if I do “now-1m” to “now”.
The timeout I get in oh is arriving in about 4 seconds…

I am more and more thinking this is the reason?

I can not speak for possible effects by the proxy but as @Benjy already stated, I can not think of one.

Are you sure this is done in a browser without authentication? Could it be a connection problem? Could you try the IP address instead of the “xenon” hostname. Please try opening the image on your OH2 machine: expecting a Linux system you could do this by downloading the image with wget http://...

Good luck!

I’ve just got this up and running and have encountered the same issue as you @vespaman

I don’t have a reverse proxy set up, but am running openHABian fwiw. I have triple checked my login settings match those set out in the guide, but still no image actually loads.

As a workaround (a better option @ThomDietrich?) i’ve set up a few html pages with iframes to the graphs. And not only does it work, it loads pretty quickly on my Pi3 and has some of the interactive elemnts of the original grafana graphs. Just put the html files and charts.css in the conf/html folder and it’ll all work fine. He say’s while crossing his fingers…

chartsDay.html (Also have chartsHour.html and chartsWeek.html)

<!DOCTYPE html>
<html>
<head>
        <meta http-equiv="Content-type" CONTENT="text/html; charset=utf-8">
        <link rel="stylesheet" type="text/css" href="charts.css" />
</head>

    <div class="container">
        <iframe src="http://192.168.1.20:3000/dashboard-solo/db/environment?from=now-1h&to=now&panelId=1"></iframe>
    </div>
  </br>
    <div class="container">
        <iframe src="http://192.168.1.20:3000/dashboard-solo/db/environment?from=now-1h&to=now&panelId=2"></iframe>
    </div>
</html>

charts.css

.container iframe {
  width: 100%;
  height: 400px;
}

.container {
  width: 98%;
  margin: 0 auto;
}

h2 {
  text-align: center;
}

Sitemap

Text item=Charts icon="calendar"{
    Switch item=weatherChartPeriod label="Chart Period" mappings=[0="Hour", 1="Day", 2="Week"]
    Webview url="/static/chartsHour.html" height=33 visibility=[weatherChartPeriod=="0"]
    Webview url="/static/chartsDay.html" height=33 visibility=[weatherChartPeriod=="1"]
    Webview url="/static/chartsWeek.html" height=33 visibility=[weatherChartPeriod=="2"]
} 
 //height varies based on number of graphs and dimensions of them. 

The height of the iframe is a bit weird and if you don’t want scroll bars then add a scrolling="no" attribute to the iframe. In Firefox the bars disappear when not being used anyway.

A solution for using this approach with the Android app is outlined by @Dries below.

6 Likes

OK, so with wget, I could not receive the file. Not on the same machine as oh, and not from any other machines either. (I get 404). Does this mean that authentication is anyway on?