Solaranzeige friert immer wieder ein :o(

[solarfanenrico]

..
Moin Enrico,

wusste, es gibt einen Haken..
Wie ich Daten an eine Remote DB sende, check ich, aber nicht wie ich die Temperatur des Pi da "raus" bekomme

EDIT..ich hab die zweite _math einfach an einen WR angehängt, der an dem entfernten Pi eingelesen wird..wörx!

moin Andreas,
ich dachte mir bereits daß es Nachfragen geben muß.
Es gibt mindestens zwei Wege. Besser und leichter für mich ist, wenn ich mehr Einzelheiten weiß.
Raspi-A hast Du alles im Griff? RapsTEmp in der InfluxDB, Dashboard, solaranzeige.log?
Wie ist der Stand am Raspi-B?
Enrico

[andreas_n]

Hi Enrico,

alsoooo, der Keller Raspi liest die beiden Growatt ein und da hab ich deine Zeilen in eine growatt_math.php eingebaut.
In der DB tauchen die Werte des KELLER Raspis auf, in Grafana sichtbar, die tackert dann der Keller Raspi nach oben zum One (entfernte DB)

Analog dazu wird der SMA WR vom Raspi ONE, der neben mir steht, eingelesen. Und da hab ich die growatt_math reinkopiert und als sma_wr_math.php umbenannt.Damit wird die Temp des One eingelesen...ich hab dann beide PI Werte in das eh schon vorhandene ELWA Temp Dashboard mit rein, das geht einwandfrei.

Wichtig war, die Temp des Raspis mit einer vor Ort laufenden Abfrage zu verknüpfen...gibt sicher elegantere Möglichkeiten, aber Hauptsache es geht

[solarfanenrico]

..
Wichtig war, die Temp des Raspis mit einer vor Ort laufenden Abfrage zu verknüpfen...gibt sicher elegantere Möglichkeiten, aber Hauptsache es geht

Moin Andreas,
jede Lösung ist besser als keine.
Reinkopieren, umbenennen ist die einfachste.

Ich habe zwei verschiedene Wege. Mein Serverraspi hat ja keinen solaranzeige.de also auch keine _math.php.
Also lese ich den direkt aus, entferne Überflüssiges und speichere in einer MariaDB. Zusätzlich frage ich den Garagenraspi aus der InfluxDB ab, und speichere dort mit.
Die Zweite Variante, daß ich den Wert aus dem Serverraspi als Variable in mein Growatt_math.php einbinde und in die InfluxDB speichere.

Enrico

[gudwih]

sooo, heute Nacht war es wieder soweit - ist eingefroren

Hat sich wohl um 00:17 erhängt, ich hab das dann um 07:33 bemerkt und den Stecker gezogen (war nicht mehr ansprechbar)

Was mich wundert ist, dass die Einträge beim Absturzzeitpunkt zeitlich durcheinander sind.
erst 00:25:xx un ddann 00:17:xx.
Und einen Fehler der vor dem Absturz noch nicht da war

Code: Alles auswählen

06.08. 07:33:39 >-Rasperry Temperatur: 53 °C
06.08. 07:33:39  -MQTT Daten zum [ localhost ] senden.
06.08. 07:33:39    -Curl Fehler[2]! Daten nicht zur lokalen InfluxDB solaranzeige gesendet! Curl ErrNo. 7
06.08. 07:33:39    -InfluxDB Fehler -> nochmal versuchen.
06.08. 07:33:39    -Curl Fehler[2]! Daten nicht zur lokalen InfluxDB solaranzeige gesendet! Curl ErrNo. 7
06.08. 07:33:39    -InfluxDB Fehler -> nochmal versuchen.
06.08. 07:33:39 MQT-MQTT Daten zum Broker gesendet: localhost Port: 1883
06.08. 07:33:49    -Auslesen des Gerätes beendet.
06.08. 07:33:49    -Goodwe_wr_math.php durchlaufen.
06.08. 07:33:49  -Array
(

Ich habe mal das komplette log auf meinen server gelegt und würde mich freuen wenn ihr mal draufschauen könntet. Nicht wundern wenn die Zeilen mit password und seriennummer fehlen, das ist Absicht.

Hier der Link

Nachtrag:
Ich habe jetzt influx manuell gestartet, das geht zumindest soweit wieder.

[solarfanenrico]

Hallo,
ich vermute die Ursache des curl-Fehlers in der Netzwerkverbindung zum Goodwe.
Wird da zum Auslesen durch solaranzeige und Schreiben in die InfluxDB ein Passwort verwendet bzw. unbedingt benötigt?
Enrico

[gudwih]

CURL Fehler ist weg, ich habe die Influx manuell gestartet, aber warum der heute Nacht wieder eingefroren ist !?
Kann das abschmieren an der Größe des Log Files liegen ?
Die letzten drei Tage wurde immer um 0:00 Uhr ein gezipptes log erstellt 600-800k.
Heute Nacht ist das Solaranzeige.log ungezippt mit 20MB stehen geblieben, also nicht gezippt worden.
Die Frage ist, was ist Ursache und was ist Wirkung ?

[solarfanenrico]

Hallo gudwith,
ich nutze die log-files eigentlich nur, um zu sehen ob irgendwelche Fehler vorhanden sind.
Deshalb lasse ich die über eine user.wartung.php in der täglichen Wartungsroutine automatisch löschen. Die ist dadurch bei mir nie größer als 1MB.

Vergangene Fehler interessieren eigentlich auch überhaupt nicht, sondern immer nur der

erste Eintrag für die Suche nach dem aktuellen Fehler, und

der letzte Eintrag, die Ursache der Störung.

Diese Sichtweise hilft mir zur schnellen Entscheidung.

Enrico

[gudwih]

Hallo Enrico,
das wäre für mich auch perfekt.
Habe keinen Plan von PHP , hier ein Versuch:

So würden nur jeweils Sonntags alle Daten älter einen Tag gelöscht werden, korrekt?

Code: Alles auswählen

if (date("N") == 7 and $Tage > 1) {  // Jeden Sonntag im Monat

Würde das so dann jeden Tag klappen?

Code: Alles auswählen

if ($Tage > 1) {  // Jeden Tag

[gudwih]

Wieder eingefroren, an der Log Größe kanns also nicht liegen.
Aber auch hier wieder die seltsame Lücke, bei der es einen "Zeitsprung in die Vergangenheit gibt"
von 15:48:53, dann 15:38:09

[solarfanenrico]

Hallo gutwith,
ist doch irgendwo eine unnötige Passwortabfrage.
Bei mir z.B. auf meinem Serverraspi ist ein MariaDB(MysqlDB) dort kommt man ohne Passwort normal gar nicht rein.

Ich habe dort den user solaranzeige angelegt und dem nur die Abfragen gestattet.

In Grafana brauchte ich dann auch keine zusätzlichen Angaben machen, und bekomme die Antworten sofort.

Enrico