Pull Request für Merge des ahoy-all-in-one forks

[oberfritze]

Hallo Lukas,

auf Bitte/Vorschlag von stefant aus dem Discord Forum erstelle ich diesen Pullrequest zum Merge meiner Erweiterungen aus dem ahoy-all-in-one fork.
Wie im Discord Forum #dev-ahoy-esp8266 schon kurz skizziert: es geht darum, speziell für kleine Balkonkraftwerke ohne weitere Devices alle interessanten Infos rund um die eigene Anlage anzuzeigen.
Was ich bisher an Erweiterungen gemacht habe:

• Leistungskurve der Total AC Power über den Tag anzeigen (*)
• konfigurierbar mit Anzeige (*) der Leistungsdaten eines OBIS-fähigen Stromzählers via IR-Lesekopf
• konfigurierbar Anzeige des aktuellen Netzverbrauchs
• Spitzenleistung der Panels / des Inverters (Peekhold)
• eine Optimierung im Radioprotokoll
  (*): Die Diskussion im Discord Forum zu der verwendeten und hier auskommentierten Referenz auf die linzeninkompatible Highcharts Lib hast Du vielleicht mitbekommen. Stefant hatte angeboten, da ggf. was anderes zu verwenden.
  Alle diese Änderungen sind auf dem Stand Deines 0.6.9 Release passiert.

Danke nochmals für Deine sehr umfangreiche Arbeit von der ich in der alltäglichen Anwendung profitiere. Darüber hinaus haben mir Deine Sourcen Einblick in eine andere Programmierwelt gegeben und ich habe sicherlich schon einiges Neues dadurch gelernt.

Falls Fragen oder Kommentare sind: natürlich gerne.

tschau, oberfritze

[stefan123t]

This PR adds several things at once (natural coming from the ahoy-all-in-one fork 😀):

• several methods (cleanup_history, open_hist, has_pac_value, get_pac_average, get_cur_value, close_hist & handle_pac)
  in hmSystem.h to store history data on LittleFS in a csv file.
  How often does it write the csv file onto the LittleFS ?
  We were always a bit wary whether this may wear out the Flash too fast ?
  Better maybe to use an additional SD Card but limit it to once per day ?
  Would it be possible to store the data (Power AC & DC) in a round-robin-database or similar in memory ?
  There was a feature request to store the data in an online service, e.g. ThingSpeak
• /get_chartdata REST API endpoint to query csv data (using onGetChartData method)
  This could be used for the Highchart or any other Charting library.
  We have discussed to use either of Chart.js, Plotly oder Apache eCharts which are all under OpenSource licenses.
  There was a feature request for implementing it with Google charts
  We would need to provide a proof-of-concept in case we want to integrate that feature.
• AHOY_SML_OBIS_SUPPORT in SML_OBIS_Parser.cpp and SML_OBIS_Parser.h
  What license is this SML Parser allowing to attach the IR Sensor to UART0 or where was it derived from -> Tasmota ?
• several changes to the AHOY_MQTT_SUPPORT
• several Debug Statements (mostly in hmPayload.h and hmRadio.h) have been commented out
  using #ifdef undef instead of lowering the level from INFO to VERBOSE.

@lumapu It would probably be required to factor and test these changes out to merge them individually into the main trunk.

[oberfritze]

Answers to stefan123t comments:

Thank you for your comments! Please see my answers:

• I'm also worried about using the flash too much. Therefore both flash files /hist/ac_power/{day}{month}{year}.bin and /hist/grid_power/{day}{month}{year}.bin are deleted only once a day (by cleanup_history()/ sml_cleanup_history()). And every 10 min averaging interval additional 4 bytes are appended (!) to each files. So - haven't analysed LittleFS but my guess is this is an acceptable behaviour for a flash file system, especially because all intervals per day ((20 - 6) * 6 = 84 * 4 Bytes = 336 Bytes should fit into one single 512 Byte block of file system. And I guess, LittleFS as a flash file system will not use the same block again the next day but cares for a round robbin logic for itself.
• Yes, you have to find another charting lib than the one commented out. See comments in visualization.html.
• The sml obis parser consisting of the files SML_OBIS_Parser.cpp (actually a .c file) and SML_OBIS_Parser.h is a development of myself. It is not derived by Tasmota or any other project. The only exception is the content of the sml_test_telegram (not the testing code itself, which also is my own development). Of course the content of the sml_test_telegram stucture and content was changed but you can exchange the whole test data easily of course. The parser itself works on a stream, e.g. operates stateful iteratively and therefore needs small resources of RAM.
• Yes i introduced the define AHOY_MQTT_SUPPORT, but haven't changed the original MQTT code (I hope) in case of uncommenting AHOY_MQTT_SUPPORT. The reason for this is saving RAM, because this feature is not strictly needed by an all-in-one solution . But I guess the round about 3 kB RAM are still available due to reducing the number of reserved inverters (from 10 to 2) and you simple could uncomment AHOY_MQTT_SUPPORT.
• The reducement of radio comments: of course please feel free to do it your style. I did it my way to easily find my modifications of your original statements. But I had to reduce it a little bit to see my own stuff more easily. And also at the beginning of my modifications I experimented with a kind of logical critical section around a send/rcv radio cyle but felt, it wasn't necessary. For this testing I reduced your traces also.

[knickohr]

Ich kann das nur unterstützen, habe heute traumhafte Statistikwerte mit nur einer DTU an 12 Invertern bekommen mit der Testversion.