mycontroller-v1-legacy icon indicating copy to clipboard operation
mycontroller-v1-legacy copied to clipboard

Published 20 hours ago • verified publisher icon mycontroller-org

Slow graphs

Open seant100 opened this issue 7 years ago • 26 comments

All graph displays are very slow. The longer the period selected the slower it is. 5 mins is fairly quick, then incrementally gets slower and slower as you increase time period. I downloaded and installed latest snapshot release as on 17 Aug 2017 and problem persists. It may be related to this : https://github.com/mycontroller-org/mycontroller/issues/359 However that issue seems like it was fixed many months ago

seant100 avatar Aug 20 '17 10:08 seant100

@seant100

  • What is the hardware are you using?
  • MyController version?
  • database type? default? changed any settings?
  • snapshot of data retention settings.

jkandasa avatar Aug 21 '17 05:08 jkandasa

@jkandasa

  • C.H.I.P - with only MyController and node-red installed and running on it
  • MyController version is latest snapshot as of 17 Aug 2017. Screenshot of Status/About attached.
  • Using MyController standard database - no settings changed
  • Screenshot of data retention settings attached - these should be default settings as I have not changed anything.

image

image

seant100 avatar Aug 21 '17 06:08 seant100

@jkandasa I now installed the same 17 Aug snapshot version on a raspberry pi 3 model b and still have the same issue

seant100 avatar Sep 03 '17 13:09 seant100

My graphs are quite responsive (2-3 seconds).

@seant100 Can you tell us something about the graph? If it is a binary graph it might be related to the retention technique.

All graphs should get aggregated and as such have a reduced number of total datapoints (except binary graph).

cimba007 avatar Nov 02 '17 20:11 cimba007

@cimba007 @jkandasa All graphs are slow ... Dashboard, sensor details etc. The greater the time period the slower it is ... The issue happens both on page load and when changing the time period in the dropdown selection or the min/max button for the graph.

Examples of what I mean by slow : Last 5 minutes: Graph appears after about 5 seconds Last 10 minutes : Graph appears after about 10 seconds Last 6 hour : Graph appears after about 20 seconds Last 12 hours : Graph appears after about 45 seconds
Last 1 Day : Gave up after 5 minutes - freezes mycontroller web interface completely for maybe 30 minutes or more.

In the logs it shows these errors :

[Thu Nov 02 23:37:56 SAST 2017] Unexpected problem running servlet: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
[Thu Nov 02 23:37:56 SAST 2017] IO error: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe (Write failed) in processing a request from /192.168.1.20:8443 / sun.security.ssl.SSLSocketImpl
2017-11-02 23:37:58,615 WARN [Thread-6] [org.mycontroller.standalone.rule.McRuleEngine:184] Scheduled Rule exuection skipped. Engine not available for more than 4000 ms
[Thu Nov 02 23:37:59 SAST 2017] Unexpected problem running servlet
org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:167)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328)
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282)
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054)
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Broken pipe (Write failed)
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
	at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
	at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:886)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:857)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at java.io.OutputStream.write(OutputStream.java:75)
	at Acme.Serve.Serve$ServeOutputStream.flush(Serve.java:4891)
	at Acme.Serve.Serve$ServeOutputStream.close(Serve.java:4923)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.close(HttpServletResponseWrapper.java:58)
	at org.jboss.resteasy.util.CommitHeaderOutputStream.close(CommitHeaderOutputStream.java:87)
	at org.jboss.resteasy.util.DelegatingOutputStream.close(DelegatingOutputStream.java:60)
	at com.fasterxml.jackson.core.json.UTF8JsonGenerator.close(UTF8JsonGenerator.java:1060)
	at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:209)
	at org.mycontroller.standalone.api.jaxrs.mixins.McJacksonJson2Provider.writeTo(McJacksonJson2Provider.java:120)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
	at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
	at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
	at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
	... 12 more

[Thu Nov 02 23:37:59 SAST 2017] Unexpected problem running servlet: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
[Thu Nov 02 23:37:59 SAST 2017] IO error: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe (Write failed) in processing a request from /192.168.1.20:8443 / sun.security.ssl.SSLSocketImpl
[Thu Nov 02 23:38:03 SAST 2017] Unexpected problem running servlet
org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
	at org.jboss.resteasy.core.SynchronousDispatcher.writeException(SynchronousDispatcher.java:167)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:471)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:415)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:202)
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328)
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282)
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054)
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402)
	at java.lang.Thread.run(Thread.java:748)
Caused by: java.net.SocketException: Broken pipe (Write failed)
	at java.net.SocketOutputStream.socketWrite0(Native Method)
	at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:111)
	at java.net.SocketOutputStream.write(SocketOutputStream.java:155)
	at sun.security.ssl.OutputRecord.writeBuffer(OutputRecord.java:431)
	at sun.security.ssl.OutputRecord.write(OutputRecord.java:417)
	at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:886)
	at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:857)
	at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123)
	at java.io.OutputStream.write(OutputStream.java:75)
	at Acme.Serve.Serve$ServeOutputStream.flush(Serve.java:4891)
	at Acme.Serve.Serve$ServeOutputStream.close(Serve.java:4923)
	at org.jboss.resteasy.plugins.server.servlet.HttpServletResponseWrapper$DeferredOutputStream.close(HttpServletResponseWrapper.java:58)
	at org.jboss.resteasy.util.CommitHeaderOutputStream.close(CommitHeaderOutputStream.java:87)
	at org.jboss.resteasy.util.DelegatingOutputStream.close(DelegatingOutputStream.java:60)
	at com.fasterxml.jackson.core.json.UTF8JsonGenerator.close(UTF8JsonGenerator.java:1060)
	at org.jboss.resteasy.plugins.providers.jackson.ResteasyJackson2Provider.writeTo(ResteasyJackson2Provider.java:209)
	at org.mycontroller.standalone.api.jaxrs.mixins.McJacksonJson2Provider.writeTo(McJacksonJson2Provider.java:120)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.writeTo(AbstractWriterInterceptorContext.java:131)
	at org.jboss.resteasy.core.interception.ServerWriterInterceptorContext.writeTo(ServerWriterInterceptorContext.java:60)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:120)
	at org.jboss.resteasy.plugins.interceptors.encoding.GZIPEncodingInterceptor.aroundWriteTo(GZIPEncodingInterceptor.java:100)
	at org.jboss.resteasy.core.interception.AbstractWriterInterceptorContext.proceed(AbstractWriterInterceptorContext.java:124)
	at org.jboss.resteasy.core.ServerResponseWriter.writeNomapResponse(ServerResponseWriter.java:98)
	at org.jboss.resteasy.core.SynchronousDispatcher.writeResponse(SynchronousDispatcher.java:466)
	... 12 more

[Thu Nov 02 23:38:03 SAST 2017] Unexpected problem running servlet: org.jboss.resteasy.spi.UnhandledException: RESTEASY003770: Response is committed, can't handle exception
[Thu Nov 02 23:38:03 SAST 2017] IO error: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Broken pipe (Write failed) in processing a request from /192.168.1.20:8443 / sun.security.ssl.SSLSocketImpl

seant100 avatar Nov 02 '17 21:11 seant100

@seant100

I am no pro but my assumption is that the C.H.I.P. has only one single-core with 1ghz. As opposed to that I use an raspberry pi 2 with a Quadcore (4x 1ghz) and sometimes get more 2 cores fully loaded.

Could you try to check the idle system-load with "top" from the linux console?

Just for reference I got 5-25% on java. In addition to that the load-avg is interesting (top right corner at "top"). Mine reads 0,09 0,17 0,30 which all indicates very low cpu-load (1,0 = 1 full core 2,0 = 2 full core).

In addition to that the output of "free -h" would be interesting or a screenshot of the "top" output.

As the database is stored on the disk reading "migh" be a speed-bottleneck but I can't say that for sure.

An example of my "top":

image

Can you check if it makes an impact if you temporary stop the nodered service?

cimba007 avatar Nov 02 '17 22:11 cimba007

In addition could you check this custom widget?

https://github.com/mycontroller-org/mycontroller/issues/253#issuecomment-242796728

It can give us some insights on message-processing performance and the queue of messages.

cimba007 avatar Nov 02 '17 23:11 cimba007

@cimba007

As per previous comment I moved from CHIP to Raspberry Pi Model B. Here is screenshot showing both top and free -h

Screenshot without accessing via web interface (i.e. no graphs loading etc)

pi-mycontroller-top-and-free

Screenshot with accessing web interface on sensor page showing graph set to show "Last 1 day"

pi-mycontroller-top-and-free-graphs

Message Stats Widget pi-messages-stats

seant100 avatar Nov 02 '17 23:11 seant100

Looks pretty normal to me. Normal CPU load and plenty of free ram. Only thing I don't understand is the high # of messages in the queue. From my understanding this should be always zero or close to zero.

I got some of the SSL errors too but only just after startup of mycontroller server.

image

Could you try to change "logback.xml":

  <logger level="TRACE" name="org.mycontroller.standalone.metrics" />
  <logger level="TRACE" name="org.mycontroller.standalone.metrics.jobs" />

This should give you something like this in the logfile:

2017-11-03 09:16:05,089 DEBUG [Quartz_Scheduler_Worker-4] [org.mycontroller.standalone.metrics.engines.McMetricsAggregationBase:56] Running aggregation and data removal for this time range[from:1509696822859, to:1509696882859, sourceType:0, resultType:1], SQL query: Insert:[INSERT INTO metrics_double_type_device (sensorVariableId, min, max, avg, samples, timestamp, aggregationType) SELECT sensorVariableId, MIN(min) AS min, MAX(max) AS max, SUM(avg*samples)/SUM(samples) AS avg, SUM(samples) AS samples, 1509696882859 AS timestamp, 1 AS aggregationType FROM metrics_double_type_device WHERE aggregationType=0 AND timestamp > 1509696822859 AND timestamp <= 1509696882859 GROUP BY sensorVariableId ], Deletion:[DELETE FROM metrics_double_type_device WHERE aggregationType=0 AND timestamp <= 1509696882859 ]
2017-11-03 09:16:05,517 DEBUG [Quartz_Scheduler_Worker-4] [org.mycontroller.standalone.metrics.engines.McMetricsAggregationBase:66] Query execution result. Count[insert:6, delete:46], **time taken:426 ms**
2017-11-03 09:16:05,546 DEBUG [Quartz_Scheduler_Worker-4] [org.mycontroller.standalone.metrics.engines.McMetricsAggregationBase:56] Running aggregation and data removal for this time range[from:1509696822859, to:1509696882859, sourceType:0, resultType:1], SQL query: Insert:[INSERT INTO metrics_battery_usage (nodeId, min, max, avg, samples, timestamp, aggregationType) SELECT nodeId, MIN(min) AS min, MAX(max) AS max, SUM(avg*samples)/SUM(samples) AS avg, SUM(samples) AS samples, 1509696882859 AS timestamp, 1 AS aggregationType FROM metrics_battery_usage WHERE aggregationType=0 AND timestamp > 1509696822859 AND timestamp <= 1509696882859 GROUP BY nodeId ], Deletion:[DELETE FROM metrics_battery_usage WHERE aggregationType=0 AND timestamp <= 1509696882859 ]
2017-11-03 09:16:05,715 DEBUG [Quartz_Scheduler_Worker-4] [org.mycontroller.standalone.metrics.engines.McMetricsAggregationBase:66] Query execution result. Count[insert:2, delete:12], **time taken:167 ms**

2017-11-03 09:17:06,489 DEBUG [Quartz_Scheduler_Worker-5] [org.mycontroller.standalone.metrics.jobs.MetricsAggregationJob:45] Sql Query[DELETE FROM metrics_binary_type_device WHERE timestamp > 1509092165789 AND timestamp <= 1509092226483 ], Deletion count:0, **Time taken:5 ms**
2017-11-03 09:17:06,544 DEBUG [Quartz_Scheduler_Worker-5] [org.mycontroller.standalone.metrics.jobs.MetricsAggregationJob:45] Sql Query[DELETE FROM metrics_gps_type_device WHERE timestamp > 1507104965789 AND timestamp <= 1507105026483 ], Deletion count:0, **Time taken:2 ms**

If you don't mind you could zip your whole mycontroller folder and upload it somewhere. Would be interesting to see if the problem persists on other machines too (or when no new input data is collected).

cimba007 avatar Nov 03 '17 11:11 cimba007

@cimba007

I've zipped up the mycontroller folder - I removed all backups to reduce the size. You can download from here :http://sites.za.org/myc/myc.zip Its a 44MB file.

Thanks for the help

seant100 avatar Nov 03 '17 13:11 seant100

@cimba007 Please let me know once you have the file so I can remove it from the server. Thanks

seant100 avatar Nov 03 '17 13:11 seant100

Got it, will try it out

Update 1: First feedback .. yeah .. it is slow af :D

Update 2: My first assumption is that it might be related to binary data values see https://github.com/mycontroller-org/mycontroller/issues/407

Update 3: Nope .. not related to binary data .. even after purging binary data it seems slow, sometimes even the sensor page does not load properly

Update 4: Might have found the culprit .. @jkandasa There are no indizes on the METRICS_DOUBLE_TYPE_DEVICE table at all

After adding some:

image

I can at least get the graphs to load within 2-3 seconds (didn't work at all before in created the indices)

cimba007 avatar Nov 03 '17 14:11 cimba007

@seant100

  • Do a backup of your current database
  • Update to latest snapshot from here (https://forum.mycontroller.org/topic/58/download-snapshot-build)
  • Replace your database with this: https://mega.nz/#!21gHWTob!fBx2XyLn8pJDb7fNam1BO1QC_yvB4ea5ylhNzdG69cU

I will remove the db when I come back from cinema if you got it by then

cimba007 avatar Nov 03 '17 15:11 cimba007

@cimba007 Thanks. Will try it out now. I have downloaded the db so you can remove it now

seant100 avatar Nov 03 '17 15:11 seant100

ok, link removed

cimba007 avatar Nov 03 '17 15:11 cimba007

@cimba007 Setup and running latest snapshot with db you provided in link. So far working great! Graphs are super fast now. And for the first time ever I can actually view a whole day of data. Even 1 year works very fast now. Thanks a million. What was the issue?

seant100 avatar Nov 03 '17 15:11 seant100

I hope I can explain the issue in an easy way.

A database is organized as follows:

  • A database contains multiple so called tables (something like excel sheets)
  • Each table contains multiple columns (like timestamp, sensorid, value ...)

If the table grows and contains more and more rows it becomes more difficulty for the programm to find the "right" ones. In the worst case the database software has to check every row if it is the right one (for example only the rows whos timestamp is within the last day).

To help the database find the rows faster you can use so called "indexes" .. They are like an "Index" to find the rows faster. A index is always related to one (or more) columns and takes additional space. The index can only be used if you ask the database for the exact combination of columns.

For example an index is usless if it is created for the sensor-id but the query is asking for the "most recent values" and does a filter on the timestamp. It is even useless if you create an index for the timestamp and query for values for a special sensor-id within a time range.

As all data with floating values is stored in one table for mycontroller it might take longer to find the right values.

One way is to "compress" the data. This is called grouping. For example for values older then 1 week you are no longer interested in the raw-data which might consist of new values every few minutes. It is more resonable to store only one value representing one whole hour. This is something that mycontroller already does.

To further improve the performance indices should be used.

To make a long story short .. your database seems to contain soo many values that it became very slow. In your database I manually added an index to make it faster.

@jkandasa only has to create these indices upon creating the database the first time (or when updating to a newer version). This step should increase the performance overall for all users of mycontroller who got many datapoints from their sensors.

cimba007 avatar Nov 03 '17 19:11 cimba007

@cimba007 I do know what an index is. Just I am not familiar with the type of database used by mycontroller and no idea what admin tools are available for it.
And yes - it would be ideal if this can be part of the next database update / migration script. Otherwise i assume i might have to add the index manually again if I update mycontroller. Thanks again for the fix. Its working perfectly now

seant100 avatar Nov 03 '17 20:11 seant100

@seant100 With the default settings mycontroller uses a h2-database which is some kind of java flat database. I don't know too much of the details but is seems to work like a sql-database.

Just copy the mycontroller.mv.db from the raspberry pi to your desktop.

  • https://mvnrepository.com/artifact/com.h2database/h2/1.4.196
  • Run "java -jar h2-1.4.196.jar"

This opens a small builtin webserver ..

image

Password is mycontroller

The jdbc url has to point to the database file (without file ending):

jdbc:h2:D:\Users\Marc\Downloads\h2-2017-06-10\mycontroller

The rest is pretty much straight forward:

image

Here are some commands I used to add indices:

ALTER TABLE METRICS_BINARY_TYPE_DEVICE DROP INDEX IDXNAME;
CREATE INDEX IDXNAME ON METRICS_BINARY_TYPE_DEVICE(TIMESTAMP);
DELETE FROM metrics_binary_type_device WHERE timestamp < 1505952000000;

cimba007 avatar Nov 03 '17 20:11 cimba007

@seant100 @cimba007 Thank you for the great support on this issue! :+1:

@cimba007 These are all the index's should be covered?

ALTER TABLE METRICS_BINARY_TYPE_DEVICE DROP INDEX IDXNAME;
CREATE INDEX IDXNAME ON METRICS_BINARY_TYPE_DEVICE(TIMESTAMP);
DELETE FROM metrics_binary_type_device WHERE timestamp < 1505952000000;

jkandasa avatar Nov 04 '17 10:11 jkandasa

@cimba007 For what reason are you issuing the 3rd sql statement - to delete metrics before a certain date? Also would it not be beneficial to add an index on 2 fields - the sensorvariableid and the timestamp

seant100 avatar Nov 04 '17 11:11 seant100

These commands are just an EXAMPLE of what you can do with the h2-1.4.196.jar "console".

@jkandasa I would suggest adding the following two indices for the METRICS_DOUBLE_TYPE_DEVICE table.

Index 1:

CREATE INDEX IDXNAME ON METRICS_DOUBLE_TYPE_DEVICE(SENSORVARIABLEID,TIMESTAMP);

This should speed up all querys with charts.

Index 2:

CREATE INDEX IDXNAME2 ON METRICS_DOUBLE_TYPE_DEVICE(aggregationType,TIMESTAMP);

This should speed up aggregation jobs with querys like this:

Deletion:[DELETE FROM metrics_double_type_device WHERE aggregationType=0 AND timestamp <= 1509750102859

cimba007 avatar Nov 04 '17 11:11 cimba007

@seant100 The 3rd query was just a test to manually purge binary metrics. I did this to do a quick check if a reduced number of values would impact the query speed.

cimba007 avatar Nov 04 '17 11:11 cimba007

@jkandasa Could you be so kind and add the index in an "fix" so this issue could be closed for now?

cimba007 avatar Nov 15 '17 16:11 cimba007

@cimba007 Can you tell me if this is fixed in the snapshot downloaded today? Not sure about the METRICS_BINARY_TYPE_DEVICE. Screenshot of the db structure below: myc-snapshot-2018-05-11

ragflyer avatar May 11 '18 08:05 ragflyer

I'm encountering poor graph performance on 1.2.0.Final (Database schema revision: 1.04.01 - 2017 Oct 25 on PostgreSQL) too, it takes about 8 seconds on average to update a graph with 10 variables (last hour) but the requested update interval was 1 second. What is weird is that there are so few values in the finally sent graph too, I should be seeing one reading per sensor per second but there's like 8 individual points in total on the graph (it hasn't even collected data for even 10 minutes and is clearly struggling).

Avamander avatar May 21 '18 15:05 Avamander