Add simple DataLogger and support for SD cards. #2125
Conversation
|
Hi, dein Posting ist total an mir vorbeigegangen. Morgen sollte mein Reader ankommen und dann werde ich mich gleich mal versuchen. Der Reader ist von AZ-Delivery. Mal sehen ob ich den angeschlossen bekomme da meine openDTU auf einer Platine verbaut ist. |
|
Leider habe ich es bis jetzt noch nicht hinbekommen etwas auf die SD zu schreiben. DataLogger: 1723215469;0.00;0.00;0.00 Nachtrag: Etwas wird auf die SD geschrieben mehr aber nicht. |
|
@Juergen2453 please check the size of your SD Card. I recall that Jomjol AI on the edge requires 4/8GB SDCards to work. I actually bought a couple of 8GB SD cards as the 32GB SanDisk I had from RasPi around would not work. See here espressif/arduino-esp32#7707 with hints regarding the SPI settings of the SD library, tracing the IO using a Logic Shrimp, some suggestions to the 3.3V vs 5V SDCard modules too and a link to troubleshooting several issues with mounting 32GB SanDisk modules in ESP-IDF. Or here for the same I assume the FAT filesystem table may be to big for the tiny uC/ESP32 or the filesystems “Blocksize” for appending to the same block. Can you check with a smaller SDCard ? This issue has one proposal regarding append fails in the stackexchange sub post https://forum.arduino.cc/t/esp32-sd-writes-but-doesnt-append/697112 You may also verify the “/api/datalogger/config” REST endpoint for your current config, but the Debug Logging is already quite explicit. Thanks for the concise report. |
|
Ich habe extra eine 4 GB SDCards genommen. Den Header schreibt er ja, also pin_mapping alles richtig. Ich habe allerdings noch keinen Funkmodul für den Wechselrichter angeschlossen Ausgabe: /api/datalogger/config |
|
@Juergen2453 Schau Dir nochmal meine Updates oben an. Evtl liegt es auch am VSPI Setting wie in dem Kommentar von P-R-O-C-H-Y in espressif/arduino-esp32#6372 Das wird auch im ersten Link/Issue angesprochen. SPIClass spi = SPIClass(VSPI);Die drei true Werte sollten die Ausgabe der Spalten aktivieren, sonst schreibt er jeweils eine Wenn er jedoch keine Werte vom WR bzw. NRF/CMT Modul bekommt weiss ich nicht ob/was er loggt, aber er scheint ja einen Timestamp und Werte schreiben zu wollen: |
|
Funkmodul ist angeschlossen, er könnte auch die Werte abspeichern. DataLogger: 1723274070;171.40;236.00;2207.78 Ich würde ja gerne selber bauen, dann könnte ich auch Wie kann ich das Clonen oder muss ich die Änderungen mit der Hand einpflegen? |
|
@Juergen2453 tut mir leid ich habe mich mit git noch nicht soweit angefreundet dass ich das schon wüsste. Ich glaube Du musst den feature branch auschecken, ggf mit der Commit Id ? |
|
@Juergen2453 an welchen Pins hast du den Kartenleser angeschlossen? Kannst du mal bitte deine pin_mapping.json Einträge zeigen. |
|
@jblond4711 zum Testen habe ich einen ganz normalen ESP32-D0WD-V3 mit 38-Pin genommen. In der pin_mapping habe ich nur das nötigste drin. Ich habe die vorkompilierte Builds zum Testen genommen. |
|
@jblond4711 schau mal hier espressif/arduino-esp32#7707 (comment) hat eismeraldo sogar je nach ESP32 board unterschiedliche SPI verwendet: Analog zu seinen Versuchen mit unterschiedlichen SPIs sollten wir mE auch noch daa Append an die Datei testen. Ich vermute dass er prinzipiell schreiben kann, aber beim Seek für den Append oder beim Lesen des letzten Blocks evtl ein Problem hat. Der Testaufbau mit Logic Analyzer ist mE auch sehr hilfreich bei der Fehlersuche. void setup() {
pinMode(PIN_NUM_SD_ACTIVITY, OUTPUT);
pinMode(PIN_STEP_NR_1, OUTPUT);
pinMode(PIN_STEP_NR_2, OUTPUT);
pinMode(PIN_STEP_NR_4, OUTPUT);
clearStep();
// SPI depending on Board type
#if defined(BOARD_DOIT_DEFINED_DEFAULT_GPIO) || defined(BOARD_ESP32_S3_DEFINED_GPIO)
showStep(0, "Init SPI");
SPIClass* spiSpecial = NULL;
#if defined(BOARD_DOIT_DEFINED_DEFAULT_GPIO)
spiSpecial = new SPIClass(HSPI);
#endif
#if defined(BOARD_ESP32_S3_DEFINED_GPIO)
spiSpecial = new SPIClass(FSPI);
#endif
spiSpecial->begin(PIN_NUM_CLK, PIN_NUM_MISO, PIN_NUM_MOSI, PIN_NUM_CS);
#endif
#if defined(BOARD_DOIT_DEFINED_DEFAULT_GPIO) || defined(BOARD_ESP32_S3_DEFINED_GPIO)
showStep(1, "SD.begin");
if (!SD.begin(PIN_NUM_CS, spiSpecial)) {
#else
showStep(1, "SD.begin");
if (!SD.begin()) {
#endif
clearStep();
log_e("Initialization failed!");
return;
}
log_i("*** Initialization ok.");
writeToSD("/test.txt", "123ABCabc1122");
readFromSD("/test.txt");
} |
|
@Juergen2453 an welche Pins hast du den Cardreader angeschlossen? Vermutlich werde ich dann mal einen fliegenden Aufbau machen. Bis jetzt habe ich immer eine Platine verwendet wo ein nrf24 und cmt2300a schon drauf sind aber irgendwas passt da nicht da der Reader immer richtig heiß wird. @stefan123t soweit bin ich leider noch lange nicht da ich erstmal mit dem Hardware Aufbau klarkommen muss. Jetzt muss ich erstmal sehen wo ich eine Pinbelegung zum Anschließen herbekomme. |
|
@jblond4711 hier sind die Settings die @Juergen2453 verwendet hat: "sd": { Laut dem Datenblatt hier sind 15,12,13,14 HSPI und 5,18,19,23 VSPI, das sollte man dann auch entsprechend berücksichtigen.
|
|
So ich habe gerade die Daten in die neueste openDTU eingepflegt (ging schneller als ich dachte) @jblond4711 "Laut dem Datenblatt hier sind 15,12,13,14 HSPI und 5,18,19,23 VSPI, das sollte man dann auch entsprechend berücksichtigen." Aber jetzt kann ich ein bisschen suchen ausprobieren. |
|
|
@Juergen2453 wenn er die Datei anlegt bzw den Header schreibt, schmeisst er dann auch schon Fehler ? Und ja die Zuordnung von VSPI vs HSPI solltest Du bei Deinen Versuchen einhalten. Ggf auch noch das SPIClass* spiSpecial = NULL;
spiSpecial = new SPIClass(HSPI);
spiSpecial->begin(pin.sd_clk, pin.sd_miso, pin.sd_mosi, pin.sd_cs);
//SPI.begin(pin.sd_clk, pin.sd_miso, pin.sd_mosi, pin.sd_cs); |
|
Die Datei legt er ohne Fehler an. Sollte ich mal berücksichtigen. "SPIClass* spiSpecial = NULL; Leider habe ich jetzt keine Zeit mehr, darum schönes Wochenende noch. |
|
Erstmal Danke für die Hilfe. Dann mache ich mich jetzt mal an die fliegende Verdrahtung. Kann man Pins eigentlich auch doppelt verwenden oder gibt es dann Konflikte? |
|
Alles fliegend verdrahtet aber wieder Fehlschlag. Die DTU startet aber sd Card wird nicht erkannt. In der Systeminfo steht bei SD alles auf 0kB. |
|
@jblond4711 hat Dein SD Card Reader +3.3V oder 5V ? Da scheint es Unterschiede zu geben, ggf muss man Vorwiderstände zwischen bauen siehe die o.a. Issues und deren Spin-offs. |
|
@stefan123t ist der gleiche den Juergen2453 verwendet. Ich steige da echt nicht mehr durch. Um den Kartenleser zu testen habe ich ihn mal nur allein an den esp32 angeschlossen an die Pins 18, 5, 19, 23 und die pin_Mapping angepasst aber nichts immer noch 0kB und im der Konsole auch keine Anzeige. |
|
Kleiner Fortschritt, ich habe jetzt mal nur den Reader allein an den esp32 angeschlossen mit 5 Volt und die Pins 12, 27,26, 14 wie bei Juergen2454. |
|
Jetzt weiß ich auch nicht mehr weiter. Nachdem ich jetzt von der fliegenden Verdrahtung zur Platine gewechselt bin klappt nichts mehr. |
|
@stefan123t So bauen kann ich jetzt. Ich hatte mich nur gewundert das ich keine Einstellungen am "Datenlogger" machen konnte. @jblond4711 hast du gebaut oder die fertigen builds genommen? |
|
@jblond4711 du hast ja CMT und SD an den gleichen PINs. Ich glaube nicht das das geht. |
|
CMT und SD könnte evtl. sogar gehen wenn man definitiv einen anderen CS verwendet, dh MISO, MOSI und CLK kann man sich teilen. Wo es aktuell mW Probleme gibt ist beim gemeinsamen Verwenden des selben SPI mit dem NRF, weil das die RF24 Bibliothek nicht anbietet. Aber wenn man nicht NRF und CMT braucht bietet es sich an HSPI und VSPI getrennt zu verwenden. |
|
Es läuft (update alle 15Sek.), 22:18:50.880 > DataLogger: 1723407530;0.00;0.00;0.00
|
|
@Juergen2453 gratuliere und danke fürs Testen und debuggen! Kannst Du noch Deine aktuelle Verbindungen (CMT und SD Card Reader) und die Pin Mappng / SD Card Einstellungen hier dokumentieren ? Hast Du den Source Code jetzt noch anpassen müssen bzw die SPIClass wie vorgeschlagen verwendet oder ging es jetzt auch ohne diesen extra Klimmzug ? |
|
Die Anschlüsse und die pin_mapping habe ich für die SD geändert. pin_mapping: |
|
Hallo @Juergen2453, vielen Dank fürs Testen! Ich konnte bereits erfolgreich den NRF24 mit einer SD-Karte, sowie ein CMT-Modul mit einer SD-Karte anbinden. Ich verwende jedoch auch einen ESP32 S3, welche mehr SPI-Busse enthält. Wie @stefan123t schon sagte, hängt es mit VSPI und HSPI zusammen. Ich hatte außerdem auch Probleme mit deinem Card-Reader (https://www.az-delivery.de/products/copy-of-spi-reader-micro-speicherkartenmodul-fur-arduino). Liegt daran, dass das Modul nicht zuverlässig mit 3,3V läuft. Schau dir die Bewertungen ab: https://www.amazon.de/product-reviews/B077MCQS9P?filterByStar=one_star&pageNumber=1 Der ESP32 unterstützt die direkte Verbindung mit einer SD-Karte. Ich habe tatsächlich zum Testen direkt Kabel an eine "Micro-SD zu SD Adapter" angelötet. Alternativ kannst du auch SD-Modul ohne Spannungswandler und co. benutzen z.B.: https://www.amazon.de/DAOKAI-Micro-SD-Kartenmodul-SD-Schreiber-Arduino-Dupont-Kabel/dp/B09YYG6BT3/ Hier noch mein Pin-Mapping, aber wie gesagt mit für einen ESP32 S3: |
|
@marvincarstensen Zitat: ist leider schade. Da ja alles im Prinzip lauft werde ich es mal auf einem ESP32-S3 umbauen. Das mit dem PR besprochen: #2068 habe ich auch ausprobiert, lief ohne Probleme. Danke nochmal. |
|
Jetzt habe ich auch mal direkt Kabel an einen SDCard Adapter gelötet und was soll ich sagen jetzt wird die Micro SD erkannt. |
|
Gerade gebaut für ESP32- generic_esp32. |
|
Danke für die Firmware. |
|
Hi, kann denn wirklich niemand was zu den gespeicherten Daten und deren Auswertung etwas sagen? Hat sich schon jemand die Arbeit einer Excel Tabelle gemacht und würde sie teilen? Bitte lasst das Projekt nicht einschlafen. Leider funktioniert bei mir das andere Projekt mit der Auswertung nicht. |
|
Wahrscheinlich liegt es daran, dass das kaum jemand macht. Die meisten holen sich die Daten in ihre Smarthome-Software, wie Homeassistant oder IObroker und lassen sich das ganze schön grafisch mit bunten Bilder anzeigen. |
|
Hallo @jblond4711, die Werte korrespondieren mit den drei "Hauptwerten" auf dem Live-Daten im OpenDTU-UI: |
|
Hi, @marvincarstensen, |
man könnte einen einfaches Dateimanagement einprogrammieren. die .csv Datei vom ESP herunterladen (wie es bei der config und den pinmapping bereits geht). jeden Tag eine neue .csv erstellen lassen. ggf. .csv Datein, die älter sind als x Tage löschen.
der Tageswert wird als einzelner Wert vom WR ausgegeben und startet jeden Tag bei 0. theoretisch reicht es also, den Wert nach Sonnenuntergang zu nehmen. du könntest auch den Maximalwert aus einer Liste an Werten nehmen (in Excel mit max(Bereich)) oder, wenn du es vom totalyield herleiten willst, den max()-min() Wert nehmen. aber wie @Omega13x schrieb, die meisten Leute machen das alles wahrscheinlich im Smarthome. mit einer Datenbank und einem passenden Frontend. bspw. influxdb und grafana. oder auch dem Volkszähler, oder homeassistent oder oder oder... |
|
Alternativ kannst Du auch den Fork von @RaBa64 verwenden. Wenn ich den Code und das Bild auf der Readme Seite richtig deute sollte damit auch ein SD Card Leser unterstützt werden? https://github.com/RaBa64/OpenDTU-Database/releases ich muss aber zugeben ich habe es noch nicht geschafft die Artefakte bei mir auf dem OpenDTU-Fusion v2.0 zum Laufen zu bekommen. Keine Ahnung woran es liegt. |
Wäre es nicht sinnvoll, sowas wie einen Datenlogger bzw. so eine Ansicht wie bei @RaBa64 direkt hier in OpenDTU zu integrieren? |
|
@sbernhard dafür sind die beiden PRs #935 und dieser #2125. Es muss aber sichergestellt sein dass es den Flash Speicher des ESP32 nicht über Gebühr belastet (flash wear leveling) und dass das Feature auch hier im Upstream Projekt gewollt ist oder es ein Tasmota-ähnliches Build system gibt, bei dem man bestimmte Optionen mit builden kann. |
Ich denke, es wäre besser eine SD Card Slot über den ESP32 anzusteuern und dort die Daten zu speichern. Da kann man sicherlich reichlich an Daten halten und wenn die SD Card voll oder kaputt ist, funktioniert die OpenDTU immer noch - die gespeicherten Werte sind halt weg. Ob man eine SD Card nutzt oder nicht kann man live feststellen und dann diese Funktion über ein Setting aktivieren.
Wenn die Funktion ordentlich programmiert ist und abschaltbar ist, spricht doch nix dagegen sowas hinzufügen? Diese Zersplitterung, wie auch openDTU on Battery find ich persönlich nicht gut weil dadurch nicht gemeinsam an einer Softwarekonstrukt gearbeitet und verbessert wird. Zu viel Know How ist verteilt und langfristig sind die Projekte gar nicht mehr kompatibel - man arbeitet schlimmstenfall dann vielleicht eher gegeneinander als miteinander. |
Kann ich so nicht nachvollziehen. Im Gegenteil, onBattery ist eine sinnvolle Erweiterung, die eben zusätzliche Funktionen wie die Batterie und das power Meter mitbringt. Es gibt viele PRs hier im „upstream“, die von onBattery initiiert wurden. Von bugfixes über Umstrukturierungen im Code bis zu neuen Funktionen. Nichts mit gegeneinander arbeiten oder nicht mehr kompatibel sein. Der Nachteil von onBattery ist bspw dass weniger inverter gleichzeitig abgefragt werden können oder dass OTA bei esps mit nur 4Mb nicht mehr geht. Das sind halt Einschränkungen, die aufgrund der Größe des Codes durch zusätzliche Funktionen kommen. Von daher ist es auch durchaus legitim beide firmwares zu pflegen |
Aber, wäre es nicht besser alles in einem Projekt zu haben und dann via Optionen beim Bau zu unterscheiden? Eine gemeinsame Code Basis und dann ggf verschiedene Binaries wenn notwendig. Bestenfalls nur via Setting unterscheiden. Dadurch spart man sich zusätzlichen Pflegeaufwand wie einen PR in mehreren Projekten öffnen und hat trotzdem die Vielfalt unterschiedlicher Binaries für unterschiedliche Einsatzzwecke. |
This PR contains a simple DataLogger that can be used to record historical production data to a CSV file. I think this would be a nice addition for people who don't have a fancy smart home setup with MQTT, Grafana, etc.
To make it easy to access the recorded data (CSV file), I also added support for an SD card through an SPI bus. The MemoryInfo view has been updated to show the SD card capacity:
The configuration of the DataLogger can be done in its own configuration view:
Currently, only the following data will be exported, including a timestamp:
If this PR is considered for merging, I would invest more time to also export individual inverter data (yield, power, voltage, frequency, etc.). What do you think?
Here are some precompiled builds to test:
generic_esp32.zip
generic_esp32c3.zip
generic_esp32s3.zip
generic.zip
opendtufusionv2.zip