Posts by Rasp-Berlin

  • SD Voll

    Quote from hyle

    /mnt/dietpi-backup

    ist wohl einen Datei, denn

    Quote from hyle

    sudo du -h -d 1 /mnt/dietpi-backup

    hatte er ja schon probiert, die letzte Zeile in letzten Bild.


    (Man kann Dateien verstecken, in dem man über das Verzeichnis, in dem diese Dateien liegen, etwas mountet. Die Partition bleibt dabei natürlich weiterhin damit belegt)

  • Zugriff auf meinen Raspberry über LTE

    Da vergibt der Mobilfunkanbieter wohl IPv4-Adressen, die nicht von außen erreicht werden können.

    Irgend welche aus dem CGN oder aus dem 10er Netz.


    Wie sieht es mit IPv6 auf dem LTE-Router aus? Bekommt dieser IPv6 und propagiert dieses in dein Wohnwagennetz?

    Dann könntest du über diese Adressen (Achtung, wenn der Router dafür keine Firewall hat, dann sind alle Geräte aus diesem Netz via IPv6 im Internet erreichbar, so du dir keine eigene FW 'hinstellst'. Und es gibt Leite, die solche Geräte suchen.)


    Du könntest also, besonders, wenn du zu Hause auch IPv6 hast, von dort auf die systeme in deinem Wohnwagennetz zugreifen (dDNS-Namen sind da auch für IPv6 hilfreich)

  • SD Voll

    nach dem zweiten Bild in #7 ist /var/swap gut gefüllt.

    Was liegt denn dort so alles rum? Eine Swap-Datei in dieser Größe?

  • Aufgabe in crontab wird nicht ausgeführt

    Quote from Jowi66

    30 * * * * pi influxd backup -portable -database solaranzeige /backup/Solar/Datenbank

    Und wie immer:


    Man packt solches in ein Skript, welches ausführbar ist und welches vorher getestet wurde.

    In dem Skript wird die Umgebung, in der es sauber ausgeführt werden kann (Pfad zu dem Programmen, benötigte Variablen und so weiter) gesetzt.

    Jetzt kann man nicht nur einmal dieses Skript ohne Crontab testen, man hat, wenn man dann nur dieses Skript in die crontab einträgt, auch die Sicherheit, das man in der Ausführungsumgebung nichts vergessen hatte.

    Außerdem schreibt man sowohl die Standardausgabe als auch die Fehlerausgabe des Crontab-Aufrufs in eine eigene Datei. (Dabei sollte man diese beiden Dateien bei jedem Aufruf überschreiben, um den Plattenplatz zu reduzieren. auf dem PI sollten diese Dateien in einer Ram-Disk liegen)

  • Smarte Strommessung mit Auslesung ohne App von außerhalb des Netzwerks

    Die meisten Smarten Steckdosen, die es gibt, laufen mit der Firmware der Firma Tuya. Dieser Geräte kann man nicht mehr ohne die Cloud betreiben, wenigstens für die Einrichtung der 'NonTuya' Umgebung muss man diese Steckdosen einmal mit der Tuya-Cloud verbinden.

    Diese Steckdosen sind also nicht wirklich nutzbar.


    Ansonsten gibt es die Shelly S oder Steckdosen, die mit der Firmware Tasmota geflascht sind.

    Bei den Tasmota-Geräten muss man aufpassen, dass die Steckdose wirklich den Strom messen kann, da es auch einfach Steckdosen mit Tasmota gibt, die eben den Strom nur Ein- und Ausschalten können


    es gibt z.B. eine Steckdose, die misst, von Dlock. Solche Steckdosen kosten zwischen 15.-- und 20.-- Euro das Stück.

    Damit man nicht jede einzeln abfragen muss, kann man zum Beispiel MQTT verwenden. Einige Systeme arbeiten auch mit anderen HAS-Systemen und Protokollen.

  • Influx - Bei Abfrage leere Werte ignorieren

    Quote from llutz

    Evtl mit fill (none)?

    Jepp ;)

    Code
    datum=`date +%Y-%m-%d`
curl -G 'http://influx-system.local:8086/query?pretty=true' --data-urlencode "db=Solardaten" --data-urlencode "q=SELECT median(time), median(value) from apower where time >= '${datum}' GROUP BY time(1m) fill(none)" -H "Accept: application/csv"|gawk 'BEGIN { OFS=FS="," } { $3 = substr($3,1,10); print $3,$5; }' >  test.csv

    trennt die Nullen vom Unix-Timestamp ab, so dass man das zum Beispiel mit "date -d @${erste_Spalte}" in eine Datum/Zeit verwandeln kann.

  • Influx - Bei Abfrage leere Werte ignorieren

    Wie ich ja geschrieben habe, die Tools und Programme, die JSON in CSV verwandeln, kommen mit dem Datenaufbau von Influx wohl nicht zurecht.

    Der obere teil ist der Aufbau der JSON-Datei vom Influx, der untere der, mit dem die Tools zurecktkommen:

    Doch da es ja den Export-Parameter gibt, werde ich den wohl nehmen. Für das 'lange' Zeitformat werde ich mich, da ich das dann wohl mit PHP weiterverwurste, mit 'microtime()' anfreunden müssen ;)

  • Influx - Bei Abfrage leere Werte ignorieren

    Interessant, die Influx-Datenbank liefert, wenn man die Datenbank-Abfrage in eine Datei umleiten will, normalerweise eins JSON-Datei. Die kann man nicht ganz so einfach in eine CSV-Datei umwandeln, weil deren Aufbau anders ist.

    Wie man oben in dem Code der exportierten Datenbank sieht, gibt es einen Bereich, der die Zeilen beschreibt und dann die Bereiche, in denen einfach die Daten stehen, eben ohne den Namen des Feldes.

    und die Programme/Skripte, dei aus JSON CSV machen, mögen das nicht so.


    Doch es gibt einen Parameter für den Export der Datenbank-Abfrage in eine CSV-Datei:

    curl -G 'http://influx-system.local:8086/query?pretty=true' --data-urlencode "db=Solardaten" --data-urlencode "q=SELECT median(time), median(value) from apower where time >= '2022-09-20' GROUP BY time(1m)" -H "Accept: application/csv" --output test.csv

    -H "Accept: application/csv" ist das 'Zauberwort ;)

    Dann sieht das Ergebnis so aus:

    Leider funktioniert hier der Format-Befehl "precision 'rfc3339'" nicht, der die Zeitausgabe auf ein lesbares Datum umstellt, nicht.

    Das normale Zeitformat mit dem 'precision' sieht so aus:

  • Influx - Bei Abfrage leere Werte ignorieren

    Es heißt, das es im Influx keine Werte gibt, die 'null' seinen....

    Wenn ich die von dir angegeben Zeile aufrufe, bekomme ich keine Ausgabe, lasse ich das "and value != ''" weg, kommt wieder alles, aber eben auch die leeren Werte.

    Blöde Datenbank-Abfragesprache ;)


    Sehr lustig ist es, wenn ich das in die 'curl-Abfrage' packe, denn dann bekomme ich einige Werte, die ich aber nicht gebrauchen kann, den hier ist der Value '0', da die Werte von 00:00 Uhr bis 00:08 Uhr sind. Da scheint hier normalerweise keine Sonne ;) Also für meine Zweck nicht brauchbar.

  • Influx - Bei Abfrage leere Werte ignorieren

    Hallo,


    nachdem meine Influx-Datenbank von der Solaranlage schon gefüllt wird, wollte ich die Leistung, die diese Solaranlage liefert, ausrechnen und eine schöne Kurve malen, die auf meine Webseite soll.

    Dabei ist mir aufgefallen, dass einige Werte leer sind. Und das kann an natürlich schlecht darstellen.

    select median(time), median(value) from apower where time >= '2022-09-20' GROUP BY time(1m)

    liefert zum Beispiel:

    Code
    2022-09-20T14:43:00Z        292.4
2022-09-20T14:44:00Z        287.4
2022-09-20T14:45:00Z
2022-09-20T14:46:00Z        293
2022-09-20T14:47:00Z        301.3
2022-09-20T14:48:00Z        287.45

    Der Wert in der Spalte "Value", der zu "2022-09-20T14:45:00Z" ausgegeben wird, sollte also ignoriert werden. Doch wie bekommt man das bei der Kommandozeilenversion für die Influx-Datenbank hin?


    Wenn ich die Datenbank von einem anderen System abfrage, bekomme ich für diese Fälle in der JSON-Datei den Inhalt 'null', das also zu filtern, bevor es dort landet, wäre nicht ganz unpraktisch.

    Abfrage:

    curl -G 'http://influx-system.local:8086/query?pretty=true' --data-urlencode "db=Solardaten" --data-urlencode "q=SELECT median(time), median(value) from apower where time >= '2022-09-20' GROUP BY time(1m)" --output test.txt


    -----

    Das es keine Abfragemöglichkeit auf der Kommandozeile nach 'today' gibt ist ..... nicht so schön.

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    also, das Skript mault nicht mehr ;)

    Nur 'apower' muss dann noch vorzeichenfrei werden.

    Und in der Datenbank ist jetzt auch etwas zu finden:

    Schön ;)

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    Quote from keepfear

    Dann gib mal die ip vom Pi in der Influx Adresse an.


    Das

    Code
    Connected with result code 0

    bedeutet das der Client im Script mit dem Broker Verbunden ist.

    Das ist mir auch klar, deshalb vermute ich, das der Teil des Skriptes, der die Daten aus dem MQTT abholen soll, nicht richtig definiert ist.


    Hier noch einmal die Definition aus dem Skript:

    Und hier die Daten, als JSON, wie der MQTT sie darstellt:

    --------------

    Ich habe einen Fehler gefunden. Im Skript wird MQTT_TOPC gesetzt, doch dieses Topic gibt es nicht. Nachdem ich das auf

    MQTT_TOPIC = "shelly_BKW/status/switch:0/#"

    gesetzt habe, bekam ich:

    Der Fehler liegt in diesem Bereich:


    Das Skript kann mit dem Index "ENERGY" wohl nichts anfangen. Hmmm.

    [Die Payload, also das, was das Skript aus dem MQTT geholt hat, wird beim Fehler mit ausgegeben, weil im Skript 'print(paylod)' steht]

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    Quote from Bernd666

    Das/Der MQTT hat die Daten? Das ist sicher?

    Ja, das hatte ich doch schon im ersten Beitrag geschrieben:


    Quote from Bernd666

    Wir reden nun ausschliesslich von der Verbindung MQTT -> influxdb?

    ebenfalls richtig.


    Quote from Hofei

    Solltest du/ihr mit MQTT jetzt auf keinen grünen Zweig kommen, warum auch immer,

    will ich nur mal erwähnt haben, dass Shelly eine API bietet mit der man auch sehr einfach die Daten direkt Abholen kann.

    https://shelly-api-docs.shelly…en1/#shelly1-1pm-settings

    Interessante Seite, doch die Shelly Pro-Modelle habe ich da nicht gefunden, bis auf den Shelly4Pro, doch ich habe einen Shelly Pro 1PM. Hierbei weiß ich nicht wie viele Befehle aus dem Shelly 1 PM-System übernommen werden können. (Die Pros sind für die Hutschiene)

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    MQTT läuft auf einem Devuan-System, Influx und das Phyton-Script auf dem PI


    Wenn ich auf dem PI ein Verbidnungstest-Skript starten, wird diese Verbindung im MQTT-Log angezeigt.

    https://github.com/eclipse/paho.mqtt.python/issues/369

    (Mit meinen Daten angepasst ;)

    Das funktioniert also. Wieso kommen die Daten vom "Shelly Pro 1PM" nicht 'an'?

    Hier stehe ich und weiß im Moment nicht weiter.


    Wie man am Log-Auszug in #19 sieht, steht die Verbindung. Meine Vermutung ist jetzt nur noch, das das Skript auf eine Art abfragt, die der MQTT so nicht beantworten kann.


    In dem Skript hatte ich noch eine andere Änderung gemacht, und zwar habe ich den Benutzernamen und da sPasswort für die Datenbank herausgenommen, doch das hatte am Ergebnis nichts geändert.

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    Quote from Bernd666

    Man kann im Journal des OS sehen was in etwa passiert.

    Der MQTT ist nicht der PI, ich habe nur diese Daten angepasst :)

    Bei diesem landet im Log vom Mosquitto das folgende (anstelle vom 'localhost' unten stand die IP des Influx-Servers)


    Quote from keepfear

    Was hast du jetzt geändert?

    Anstelle der IP im ersten Post den Eintrag 'localhost', obwohl dei beiden System auf unterschiedlichen #Debian'-Computern laufen. Der mit de Mosquitto ist ein Devuan mit SysVinit ;)

  • MQTT => Influx => Grafana der Solardaten (nach Influx gehts nicht)

    Quote from keepfear

    das Dictionary mittels print() ausgeben um zu sehen ob da was eingeschrieben wird

    Er kommt nur bis zur

    Code
    def on_connect(client, userdata, flags, rc):
    """ The callback for when the client receives a CONNACK response from the server."""
    print('Connected with result code ' + str(rc))
    client.subscribe(MQTT_TOPIC)

    bis ich es abbreche.