/DG improvements for large datasets (introducing some new /D... commands)

[DE-cr]

addresses https://github.com/fredlcore/BSB-LAN/issues/539

[DE-cr]

FYI, @fredlcore:

• /DG now allows interactive a..b date range selection (default = most recent datalog day only)
• /DG does client side buffering of the data read from the server, and only fetches more data when the date range is extended beyond the last time data was read from the server
• Still no binary datalog file format, though, but adding that should require a minor adjustment to this code change here.
• Also still no rolling buffer. What was your use case for that?

[DE-cr]

My current working version has one more url command added (at the cost of +248 bytes for the bsb-lan binary): /DI gives you the datalog index file, in a human readable format, e.g.:

Date;DatalogPosition
2023-03-07;52
2023-03-08;283747

@fredlcore. would you consider this a useful addition for users or should I comment it out? (I'd like to keep the code in the sources, to possibly aid debugging later.)

[fredlcore]

I don't think it will be of use once the log file has been converted to a binary format. Since all entries will be of the same length and we know the log interval as well as the number of log parameters, we can calculate the required position. If any of this changes, it is easier to do a search from that point. Moreover, with a rolling log, maintaining an extra index file that would have to be rolling as well adds more complexity.

[DE-cr]

You won't be able to (easily) calculate the required position with people like me, who frequently change the number of parameters logged or the log interval, or stop and later re-start the logging - all w/o starting a new datalog file.

Also, using fixed length value fields limits datalog compression. An alternative solution could be to just use '\0' terminated strings of variable length.

Yes, maintaining a rolling index would add complexity - as does a rolling buffer.

[fredlcore]

These users will have to pay a penalty when the calculated result doesn't fit because then there will be an initial time spent for searching the correct entry backwards or forwards. This can be done in jumps because as you said, a few entries more won't hurt.

How further do you want to compress the datalog? Zero-terminated fields are fine, but will prevent row calculation.

And yes, a rolling buffer adds complexity, but that's why there's no need to add complexity twice.

[DE-cr]

Changes in this PR, as of now:

1. /DG initially loads the most recent n calendar days' data only (based on the current date)
2. n (c.f. above) is compile time configurable: #define DEFAULT_DAYS_TO_PLOT "3" in BSB_LAN_config.h
3. /DG then lets the user interactively select other date ranges available in datalog.txt
4. When the user reduces the date range, the data is not fetched from the server again - that's only done when the user extends the date range beyond the most recent data transfer from the server
5. /DG provides a link to download only the data currently displayed, in addition to the old link to download all of datalog.txt
6. /DG datalog transfer times are reduced by using a buffer of 4 KB instead of 1 KB (about 20 % speed increase on my esp32 w/o SD card and using wifi)
7. To quickly find dates in datalog.txt, a new file datalog.idx is used to keep track of the offsets in datalog.txt where a new calendar day starts
8. To allow transfer of a certain date range a...b from datalog.txt only, the new url command /Da,b is provided, where both a and b are dates given as year-month-day, e.g. /D2023-01-01,2023-01-31
9. To let /DG know what data range is available in the log (c.f. 3 above), the new url commands /DA (oldest date) and /DB (newest date) are provided (mnemonic: data range A...B)
10. A new url command /Dn can be used to download the most recent n calendar days' datalog.txt contents only, e.g. /D7 Note: with intermittent logging, these n days might not be consecutive calendar days, e.g. today's data, logging disabled before today, but data from a previous log session is still available in datalog.txt
11. A new url command /DI can be used by interested parties, to show what's in datalog.idx (c.f. 7 above)
12. To aid in debugging /DG's javascript code, #define NEWLINE "\n" can be set in html_strings.h
13. With dates running backwards in datalog.txt, /Da,b and therefore also /DG will only show data from after the most recent "date roll-over" (fredlcore in https://github.com/fredlcore/BSB-LAN/issues/539#issuecomment-1464876413: "older RVA controllers only provide day of week and time which I then convert to an arbitrary date. This will always roll over every seven days") Note: I have not tested this

P.s. I forgot to mention one more change in this PR: BSB-LAN_datalog-viewer.html in the scripts directory has also received controls for interactive date range selection, to speed up working with the plots, by limiting what is drawn from large datasets.

[DE-cr]

This PR now also includes change number 15: new url command /DKn, to keep only the n most recent days' data in datalog.txt (and *.idx).

Please note that I have decided to have /DKn output plain text, and not html with the bsb-lan header, for the following reasons:

• I wanted to avoid localization of the error messages I've used in /DKn. (With OTA updates, e.g. there's also no localization.)
• I consider this command to be "exotic" enough (just like OTA updates) to warrant this decision.
• If issued from a "cron job" (e.g. using wget) or something similar, the output is easier to parse.

Having someone test (or at least confirm) this PR's functionality on different hardware (Arduino, esp32 with SD card) before merging it to bsb-lan's main branch would be highly appreciated!

[fredlcore]

Agreed, I hope to find time to test this today or tomorrow on Olimex with SD card...

[fredlcore]

When compiling with Arduino IDE 2.0, I get the following error message:

/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino: In function 'const char* cleanupDatalog(unsigned int)':
/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino:4726:43: error: 'nDataBytes' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       int nBytesToDo = nDataBytes<bufSize ? nDataBytes : bufSize;
                        ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino:4700:11: error: 'dataOffset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       pos -= dataOffset;
       ~~~~^~~~~~~~~~~~~
cc1plus: some warnings being treated as errors

[DE-cr]

Make that "today and tomorrow", as your datalog would need to span mutiple calendar days. (...unless you look for "accelerated testing" in BSB_LAN.ino and try to figure out how to interpret the results with that enabled.)

[DE-cr]

When compiling with Arduino IDE 2.0, I get the following error message:

/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino: In function 'const char* cleanupDatalog(unsigned int)':
/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino:4726:43: error: 'nDataBytes' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       int nBytesToDo = nDataBytes<bufSize ? nDataBytes : bufSize;
                        ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~
/Users/frederik/Downloads/BSB-LAN-dg-d-improvements-for-large-datasets/BSB_LAN/BSB_LAN.ino:4700:11: error: 'dataOffset' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       pos -= dataOffset;
       ~~~~^~~~~~~~~~~~~
cc1plus: some warnings being treated as errors

That's a warning, and I'm pretty sure that the possibility of this "may" here is 0 %. I'll add two characters in the source code that should fix this, though.

[fredlcore]

Well, if the compiler treats these warnings as errors (as it states), it doesn't matter how low the probability is ;). Other warnings are also there which should be adressed eventually, but this one was a show-stopper.

[fredlcore]

Ok, I have it running now and it logs 3 values every 10 seconds. Looks great so far! Please let me know what kind of tests I should run and when and in which order.

[fredlcore]

Is the exclamation mark at the first date selector intentionally (as in showing that there are not yet three days worth of data)?

[fredlcore]

As for layout, I would put the two download texts right below each other, with "Angezeigte Daten" also left-aligned with "Daten vollständig herunterladen". Then the date selector in the next line can either be left-aligned with the graph or also with the two text lines above, whatever is easier.

[DE-cr]

As for layout, I would put the two download texts right below each other, with "Angezeigte Daten" also left-aligned with "Daten vollständig herunterladen". Then the date selector in the next line can either be left-aligned with the graph or also with the two text lines above, whatever is easier.

Done, but with the date selectors in the same line as the second link, to hint at the close relation between them.

[fredlcore]

I think the link between the text and the displayed data is evident because that's what the text says ;). The question is more whether people will then realize straightaway that these are also the controls to adjust the displayed data.

[DE-cr]

Since the platforms seem to mostly differ regarding SD handling, the most important test I can think of would be:

1. keeping the log running, wait until after midnight (according to your boiler)
2. the date controls in /DG should now become useful, so feel free to try them out :)
3. save the datalog (wget -qO- bsb-lan/D >saved.txt)
4. note the "free space on SD" (?) value given in /C
5. run /DK1, to keep only the (then) current day in the datalog
6. have another look at /D (or /DG) contents (did 5 work?)
7. ... and the free space on the SD card (has space been reclaimed?)

[DE-cr]

FYI, this is the current layout:

[fredlcore]

Ok, will do. What I can confirm now already is that data transfer is up here as well, above 300kB/s, sometimes falling to 150kB/s, but that maybe because BSB-LAN has other things to do at that very moment, that will become more clear when the log is larger...

[DE-cr]

Ok, will do. What I can confirm now already is that data transfer is up here as well, above 300kB/s, sometimes falling to 150kB/s, but that maybe because BSB-LAN has other things to do at that very moment, that will become more clear when the log is larger...

With this PR, that's for /Da,b (date range, which /DG uses) only.

https://github.com/fredlcore/BSB-LAN/pull/554 would take care of /D and /Dn, in the same way as /Da,b does.

https://github.com/fredlcore/BSB-LAN/pull/556 would add further gains for esp32 platforms.

[fredlcore]

Hm, but why do I have an increase in speed with /D then?

[DE-cr]

No idea. I only touched /D in https://github.com/fredlcore/BSB-LAN/pull/554

[DE-cr]

Agreed, I hope to find time to test this today or tomorrow on Olimex with SD card...

Arduino (totally different library to access SD cards), and a wired connection (not wifi, for transfer speed numbers in /DG before/after this PR) would be the most interesting to me.

[fredlcore]

I can test on Arduino later, but in both cases I'm using LAN connection, transfer speed on Olimex EVB/LAN is around 340 kB/s.

[fredlcore]

Ok, tests are done and all works fine: Space of around 900k has been reclaimed and graph still displays fine. Transfer speed is still around 350 kB/s for a 1.5MB large datalog.txt. Great job!

[DE-cr]

Thanks for the tests on both Olimex+SD and Arduino (?), using wired network connections!

[fredlcore]

Those were only tests with Olimex/LAN. Here are first impressions from Arduino: Download speeds are in the range of 150kB/s, so the greater speed of the ESP32 seems to pay off (as did the greater speed of the Due compared to the Mega). After moving the SD card from the Olimex to the Due (and keeping the log file), I get quite a strange output:

I'm not sure if this has to do with the date rollover (now there are entries from 2005 coming from the heater's wrong date and time after the previous entries were from 2023), but that was just one entry. In any case, I'll delete the log and see if the error persists...

[fredlcore]

I have noe deleted the log and logged parameters 6225 and 6226 (which are device family and variant, so they are fixed, but on that test controller, I don't have any changing values), and the result is a log file like this:

Milliseconds;Date;Parameter;Description;Value;Unit
4050939;15.08.2005 12:24:41;6225;Gerätefamilie;54;
4051226;15.08.2005 12:24:41;6226;Gerätevariante;3;
4125226;15.08.2005 12:25:55;6225;Gerätefamilie;54;
4125530;15.08.2005 12:25:55;6226;Gerätevariante;3;
4199501;15.08.2005 12:27:09;6225;Gerätefamilie;54;
4199753;15.08.2005 12:27:09;6226;Gerätevariante;3;
4273632;15.08.2005 12:28:23;6225;Gerätefamilie;54;
4273871;15.08.2005 12:28:23;6226;Gerätevariante;3;

But the graph is empty. No legend, no graph, no data displayed.

Since this should not be platform-dependend, could you just take this log and see if/how it displays on your setup?

[DE-cr]

The datalog looks okay to me, and when I put it into a file and use BSB-LAN_datalog-viewer.html from the scripts directory to plot it, it's also displayed correctly.

The reason why there's nothing in /DG is that your Arduino's date is way off from your browser's. Your preference was to initially set b=today in the a-b date range in /DG. You would have to use the date controls to go back all the way to 2005-08-15 to see something in /DG. My own preference was to initially set b to the most recent date available in the log when calling /DG, but you convinced me that your choice would be better, to let the user see right away that something is wrong - in your case, that's your Arduino's (or the boiler's) date.

[DE-cr]

After moving the SD card from the Olimex to the Due (and keeping the log file), I get quite a strange output:

I'd say that's worse than sharing a toothbrush with your friends. I know you like analogies. ;oP

I am checking endianness, so it shouldn't be that. Maybe the Arduino uses a different file system / structure or something like that?

[DE-cr]

Thanks for also taking the time to test this on Arduino! The /DKn functionality would be the area where surprises would surprise me the least. ;)

[fredlcore]

You would have to use the date controls to go back all the way to 2005-08-15 to see something in /DG.

And what great wisdom of yours makes you think I didn't do that?

Maybe the Arduino uses a different file system / structure or something like that?

No, because /D produces perfectly fine data (as quoted above).

The /DKn functionality would be the area where surprises would surprise me the least. ;)

That I can obviously only check tomorrow.

[fredlcore]

Another anomaly in the now freshly generated log file downloaded with /D:

5386594;15.08.2005 12:46:56;6225;Gerätefamilie;54;
5386839;15.08.2005 12:46:56;6226;Gerätevariante;3;
5460706;15.08.2005 12:48:10;6225;G005 13:11:40;6226;Gerätevariante;3;
6944648;15.08.2005 13:12:54;6225;Gerätefamilie;54;
6944904;15.08.2005 13:12:55;6226;Gerätevariante;3;

[DE-cr]

Another anomaly in the now freshly generated log file downloaded with /D:

5386594;15.08.2005 12:46:56;6225;Gerätefamilie;54;
5386839;15.08.2005 12:46:56;6226;Gerätevariante;3;
5460706;15.08.2005 12:48:10;6225;G005 13:11:40;6226;Gerätevariante;3;
6944648;15.08.2005 13:12:54;6225;Gerätefamilie;54;
6944904;15.08.2005 13:12:55;6226;Gerätevariante;3;

Is that /D proper, and without https://github.com/fredlcore/BSB-LAN/pull/554 also being applied? In that case, I have no explanation. Imo it should behave the same as with the current master branch of https://github.com/fredlcore/BSB-LAN

I'm still wondering whether the file systems used by Olimex and Arduino could be incompatible (block sizes / allocations, ...).

[DE-cr]

No, because /D produces perfectly fine data (as quoted above).

Could you please check the output of /D2005-08-15,2005-08-15 (which is what /DG uses)? It should be the same as /D.

I don't really expect anything interesting with /DI, but it just might also help here. It should currently contain the following on your system:

Date;DatalogPosition
2005-08-15;52

[DE-cr]

...and both /DA and /DB should return 2005-08-15

[DE-cr]

Sorry that I don't have an Arduino w/ EtherlanShield (we don't even have wired LAN in our house) and SD card reader, to test this myself.

[fredlcore]

That is /D proper downloaded from this branch yesterday or so, no other modifications. And I don't know why this should have anything to do with the file system. The SD card was formatted on the computer, so the question how Olimex or Arduino deal with low-level file system matters (if they do at all) should not arise.

[fredlcore]

Could you please check the output of /D2005-08-15,2005-08-15 (which is what /DG uses)? It should be the same as /D.

No, it's not (117 vs. 286 lines):

frederik@MBP-FH ~ % diff D D2005-08-15,2005-08-15 
40,79c40
< 5460706;15.08.2005 12:48:10;6225;Gerätefamilie;54;
< 5460973;15.08.2005 12:48:11;6226;Gerätevariante;3;
< 5534880;15.08.2005 12:49:24;6225;Gerätefamilie;54;
< 5535139;15.08.2005 12:49:25;6226;Gerätevariante;3;
< 5609130;15.08.2005 12:50:38;6225;Gerätefamilie;54;
< 5609397;15.08.2005 12:50:38;6226;Gerätevariante;3;
< 5683280;15.08.2005 12:51:52;6225;Gerätefamilie;54;
< 5683513;15.08.2005 12:51:53;6226;Gerätevariante;3;
< 5757460;15.08.2005 12:53:07;6225;Gerätefamilie;54;
< 5757748;15.08.2005 12:53:07;6226;Gerätevariante;3;
< 5831640;15.08.2005 12:54:21;6225;Gerätefamilie;54;
< 5831907;15.08.2005 12:54:21;6226;Gerätevariante;3;
< 5905813;15.08.2005 12:55:35;6225;Gerätefamilie;54;
< 5906070;15.08.2005 12:55:36;6226;Gerätevariante;3;
< 5979980;15.08.2005 12:56:50;6225;Gerätefamilie;54;
< 5980254;15.08.2005 12:56:50;6226;Gerätevariante;3;
< 6054228;15.08.2005 12:58:04;6225;Gerätefamilie;54;
< 6054505;15.08.2005 12:58:04;6226;Gerätevariante;3;
< 6128399;15.08.2005 12:59:18;6225;Gerätefamilie;54;
< 6128650;15.08.2005 12:59:18;6226;Gerätevariante;3;
< 6202532;15.08.2005 13:00:32;6225;Gerätefamilie;54;
< 6202773;15.08.2005 13:00:32;6226;Gerätevariante;3;
< 6276749;15.08.2005 13:01:46;6225;Gerätefamilie;54;
< 6277001;15.08.2005 13:01:46;6226;Gerätevariante;3;
< 6350963;15.08.2005 13:03:00;6225;Gerätefamilie;54;
< 6351217;15.08.2005 13:03:00;6226;Gerätevariante;3;
< 6425221;15.08.2005 13:04:14;6225;Gerätefamilie;54;
< 6425488;15.08.2005 13:04:15;6226;Gerätevariante;3;
< 6499358;15.08.2005 13:05:29;6225;Gerätefamilie;54;
< 6499600;15.08.2005 13:05:29;6226;Gerätevariante;3;
< 6573598;15.08.2005 13:06:43;6225;Gerätefamilie;54;
< 6573878;15.08.2005 13:06:43;6226;Gerätevariante;3;
< 6647832;15.08.2005 13:07:57;6225;Gerätefamilie;54;
< 6648114;15.08.2005 13:07:58;6226;Gerätevariante;3;
< 6722042;15.08.2005 13:09:11;6225;Gerätefamilie;54;
< 6722318;15.08.2005 13:09:12;6226;Gerätevariante;3;
< 6796240;15.08.2005 13:10:26;6225;Gerätefamilie;54;
< 6796486;15.08.2005 13:10:26;6226;Gerätevariante;3;
< 6870438;15.08.2005 13:11:40;6225;Gerätefamilie;54;
< 6870723;15.08.2005 13:11:40;6226;Gerätevariante;3;
---
> 5460706;15.08.2005 12:48:10;6225;G005 13:11:40;6226;Gerätevariante;3;
117,156c78
< 8281163;15.08.2005 13:35:10;6226;Gerätevariante;3;
< 8355118;15.08.2005 13:36:24;6225;Gerätefamilie;54;
< 8355355;15.08.2005 13:36:24;6226;Gerätevariante;3;
< 8429244;15.08.2005 13:37:38;6225;Gerätefamilie;54;
< 8429547;15.08.2005 13:37:39;6226;Gerätevariante;3;
< 8503421;15.08.2005 13:38:52;6225;Gerätefamilie;54;
< 8503701;15.08.2005 13:38:53;6226;Gerätevariante;3;
< 8577574;15.08.2005 13:40:07;6225;Gerätefamilie;54;
< 8577854;15.08.2005 13:40:08;6226;Gerätevariante;3;
< 8651767;15.08.2005 13:41:22;6225;Gerätefamilie;54;
< 8652067;15.08.2005 13:41:22;6226;Gerätevariante;3;
< 8726021;15.08.2005 13:42:36;6225;Gerätefamilie;54;
< 8726305;15.08.2005 13:42:36;6226;Gerätevariante;3;
< 8800225;15.08.2005 13:43:50;6225;Gerätefamilie;54;
< 8800478;15.08.2005 13:43:50;6226;Gerätevariante;3;
< 8874457;15.08.2005 13:45:04;6225;Gerätefamilie;54;
< 8874713;15.08.2005 13:45:04;6226;Gerätevariante;3;
< 8948622;15.08.2005 13:46:18;6225;Gerätefamilie;54;
< 8948868;15.08.2005 13:46:18;6226;Gerätevariante;3;
< 9022833;15.08.2005 13:47:32;6225;Gerätefamilie;54;
< 9023107;15.08.2005 13:47:32;6226;Gerätevariante;3;
< 9097046;15.08.2005 13:48:46;6225;Gerätefamilie;54;
< 9097312;15.08.2005 13:48:47;6226;Gerätevariante;3;
< 9171198;15.08.2005 13:50:01;6225;Gerätefamilie;54;
< 9171427;15.08.2005 13:50:01;6226;Gerätevariante;3;
< 9245425;15.08.2005 13:51:15;6225;Gerätefamilie;54;
< 9245669;15.08.2005 13:51:16;6226;Gerätevariante;3;
< 9319567;15.08.2005 13:52:29;6225;Gerätefamilie;54;
< 9319801;15.08.2005 13:52:30;6226;Gerätevariante;3;
< 9393766;15.08.2005 13:53:44;6225;Gerätefamilie;54;
< 9394027;15.08.2005 13:53:44;6226;Gerätevariante;3;
< 9467898;15.08.2005 13:54:58;6225;Gerätefamilie;54;
< 9468180;15.08.2005 13:54:58;6226;Gerätevariante;3;
< 9542124;15.08.2005 13:56:12;6225;Gerätefamilie;54;
< 9542375;15.08.2005 13:56:12;6226;Gerätevariante;3;
< 9616317;15.08.2005 13:57:26;6225;Gerätefamilie;54;
< 9616599;15.08.2005 13:57:26;6226;Gerätevariante;3;
< 9690573;15.08.2005 13:58:40;6225;Gerätefamilie;54;
< 9690817;15.08.2005 13:58:41;6226;Gerätevariante;3;
< 9764803;15.08.2005 13:59:55;6225;Gerätefamilie;54;
---
> 8281163;15.08.2005 13:35:10;6226;Gerätevariante;25;Gerätefamilie;54;
194,205c116
< 11174966;15.08.2005 14:23:24;6225;Gerätefamilie;54;
< 11175221;15.08.2005 14:23:24;6226;Gerätevariante;3;
< 11249119;15.08.2005 14:24:39;6225;Gerätefamilie;54;
< 11249385;15.08.2005 14:24:40;6226;Gerätevariante;3;
< 11323320;15.08.2005 14:25:54;6225;Gerätefamilie;54;
< 11323562;15.08.2005 14:25:54;6226;Gerätevariante;3;
< 11397491;15.08.2005 14:27:08;6225;Gerätefamilie;54;
< 11397758;15.08.2005 14:27:08;6226;Gerätevariante;3;
< 11471692;15.08.2005 14:28:22;6225;Gerätefamilie;54;
< 11471973;15.08.2005 14:28:22;6226;Gerätevariante;3;
< 11545917;15.08.2005 14:29:36;6225;Gerätefamilie;54;
< 11546198;15.08.2005 14:29:36;6226;Gerätevariante;3;
---
> 11174966;15.08.2005 14:23:24;6225;
\ No newline at end of file

[fredlcore]

/DI:

Date;DatalogPosition
2005-08-15;52

[fredlcore]

...and both /DA and /DB should return 2005-08-15

Yes.

[DE-cr]

Looks to me as if Arduino doesn't like the 4 KB buffer - which is used for /Da,b (and therefore also /DG) only in this branch. /D and /Dn would need https://github.com/fredlcore/BSB-LAN/pull/554 for 4 KB buffering. Without that, they use bigBuff, not malloc'ed memory.

[fredlcore]

The abovementioned anomaly must be caused by the way the data is transferred to the browser (buffer issues?) because it occurs erratically. I've had one, two or no mangled lines of data.

[DE-cr]

I'll #ifdef my way around it for Arduino, then, hang on...

[fredlcore]

Correction: The anomaly appears when downloading /D2005-08-15,2005-08-15. It does not occur when downloading /D. Since it's the same in both cases(?), it shouldn't be a file system or storage issue.

[DE-cr]

Please give it another try with the most recent version of this PR here. If that works, I'll also apply https://github.com/fredlcore/BSB-LAN/pull/542/commits/4c5f7a7864f267fe776fb3e3465895f9b8182e6a to https://github.com/fredlcore/BSB-LAN/pull/554.

[fredlcore]

Output anomaly is fixed with this fix, thanks! Empty display however remains...

[fredlcore]

Could it be that these parameters 6225 and 6226 don't have a unit? But then it would probably fail on your test environment as well...

[fredlcore]

Found it: I have to change the end date first to set it to 2005 and then the start date. This seems to be a JavaScript problem, because I can see in the network analysis in Firefox that the script only does a new request when changing the start date, not the end date. So if I change the start date first to 2005, it'll do a request from 2005 to 2023. But it won't do another one when changing the end date to 2005. So I have to set the dates the other way round.

This still did not explain why there isn't at least a legend showing (because the drawn dots would probably be too smal to appear in that long timeframe. The cause for this is that the data returned for this long timeframe is only consisting of the CSV header. No data. No idea why.

But as I said, changing the end date first and then the start date will lead to a proper request and displayed data and legend.