@ticaki , @all,

Eure Tipps und Anregungen habe ich soweit umgesetzt, das Script habe ich noch ein bisschen erweitert um Zählerstände für Einspeisung und Eigenverbrauch.
Läuft soweit, vielen Dank für die Unterstützung.

Und jetzt die Auflösung für das erste Phänomen, wegen dem ich den Beitrag eingestellt hatte.

Ein typischer Anfängerfehler:

In den benutzerdefinierten Einstellungen des Datenpunkts war noch der Haken „Nur Änderungen aufzeichnen“ gesetzt. Ich hatte die Auswirkung dieses Hakens nicht auf dem Schirm. Ist mir ein bisschen peinlich, andererseits habe ich viel gelernt.

Insofern: Vielen Dank nochmal. Ihr seid ein klasse Forum.

Gruß

@kapitaen31 ,

ich habe mir beim letzten Update das exakt gleiche Problem eingefangen.
Sämtliche Browser, die ich auf meinem iPad ausprobiert habe, konnten mit Grafana nichts mehr anfangen. Nachdem ich auf die letzte 10er Version gegangen bin (v10.4.8) läuft es wieder.

Für die Nachwelt:
~ $ apt remove grafana
~ $ sudo apt install grafana=10.4.8
~ $ sudo apt-mark hold grafana
~ $ sudo systemctl restart grafana-server

Gruß

@Dieter_P ,

die chinesische KI hat sich heute mit der bahnbrechenden Information gemeldet, dass der DS18B20 selbst nicht über eine drahtlose Kommunikationsfunktion verfügt. 🤪
Man wolle sich aber mit dem Hersteller in Verbindung setzen.
Da ich nicht davon ausgehe, dass eine nochmalige detaillierte Schilderung des Problems an der Sachlage etwas ändert, habe ich inzwischen den Programmer für sage und schreibe 93 ct bei Ali Express bestellt. Sobald der eingetroffen ist, kommt auf das Modul Tasmota drauf und ich werde hier meine Erkenntnisse für die Nachwelt hinterlassen.

Bis dahin vielen Dank für Eure Unterstützung.

Gruß

@ACHIM-BAECKER ,

auch ich nutze Dein Script gerne und erfolgreich, um von der Cloud unabhängig zu sein.
Leider gibt es da noch den kleinen Schönheitsfehler, dass in dem Moment, wenn sich abends der Inverter mangels Energie abschaltet, die zuletzt gemeldete Leistung weiterhin ansteht. Der Inverter setzt die Leistung nicht als "Letzte Amtshandlung" vor dem schlafen gehen auf "0". Letztlich macht das den Kohl nicht fett, mich stört es aber, wenn nachts eine Leistung von 2 W - 5W angezeigt wird.

Daher habe ich mir erlaubt, Dein Script wie folgt zu modifizieren:

schedule('*/5 5-22 * * *', GetData); // zwischen 5-22Uhr alle 5min ausführen
 
// Anfang Original 
// function GetData(){
    // zyklisches abholen der Daten, falls Solaranlage online ist
//    var SolarIsOnline = getState(SolarOnlineVar).val;
//    if (SolarIsOnline) {
//        getWebsite();
//    }
//}
 // Ende Original

// Anfang Erweiterung, um "0" auszugeben, wenn der Inverter nicht erreichbar ist

function GetData(){
    // zyklisches abholen der Daten, falls Solaranlage online ist
    var SolarIsOnline = getState(SolarOnlineVar).val;
    if (SolarIsOnline) {
        getWebsite();
    }
    else {
      	setState("0_userdata.0.Solar.webdata_now_p", 0);
   }

Die "setState" Anweisung setzt die Leistung auf "0", wenn der Inverter nicht erreichbar ist.

Es gibt sicher elegantere Lösungen um das zu realisieren, aber für mich funktioniert es.

Gruß

Hallo zusammen,

ich kann Vollzug melden. Mit diesen Einstellungen:

Kommt dann so etwas heraus:

Hier nochmal separat der komplette Template String (Menu: Configure Other):
{"NAME":"DS18B20","GPIO":[1,1,1312,1,1,1,1,1,1,1,1,1,1,1],"FLAG":0,"BASE":18}

Und die Ausgabe auf der Konsole:
15:51:53.290 MQT: tele/tasmota_6F4C36/SENSOR = {"Time":"2024-07-22T15:51:53","DS18B20":{"Id":"3C01B556A05B","Temperature":30.2},"TempUnit":"C"}

Die 5V für die Versorgung des Moduls habe ich temporär von dem Programmer genommen. Später kommt da eine gescheite Versorgung dran.

Der entscheidende Punkt war der GPIO2 wie in dem Beitrag von ralla66 beschrieben. Leider hatte ich den Beitrag in seinem Link (noch) nicht gefunden. Keine Ahnung, wo ich vorher Richtung GPIO0 abgebogen bin...

Ich hatte zwar alle GPIOs durchprobiert, muss aber jetzt sagen, es ist nicht zielführend, mehrere Pins blind gleichzeitig zu konfigurieren und darauf zu hoffen, dass der richtige schon dabei sein wird. Bei mir hat es halt nicht funktioniert.

Vielen Dank an alle, die hier so geduldig geholfen haben, insbesondere @ralla66 und @Dieter_P , mit deren Unterstützung ich es letztlich hinbekommen habe.

Wie schon weiter vorne angekündigt, werde ich das Ganze mal für die Nachwelt kompakt zusammenfassen, damit der nächste, der sich dieses Modul zulegt es ein wenig leichter hat.
(Und als Feedback für die Leute, die hier in diesem Forum ihr Wissen anderen täglich kostenlos zur Verfügung stellen.)

Beste Grüße und einen schönen Abend noch

@haus-automatisierung und @paul53 ,

vielen Dank Euch beiden. Super Forum

Beste Grüße

@thomas-braun

habe ich doch gemacht, steht im Thread oben:

…
…
…
sudo chown -R influxdb:influxdb /var/lib/influxdb
sudo chmod -R 755 /var/lib/influxdb/
iobroker fix

Damit ist doch der ursprüngliche Zustand wiederhergestellt.
Bisher übrigens keine Probleme, nur um Telegraf muss ich mich noch kümmern. (Load, Disk, Network etc.).

Gruß

@thomas-braun ,

danke. Das war es.
Meine Schritte, um die influx 1.8 DB auf ein neues System zu übertragen habe ich hier dokumentiert:
https://forum.iobroker.net/topic/77362/keine-grafana-dashboards-nach-systemwechsel?_=1729892070152

Gruß

@thomas-braun ,

danke fürs drüber schauen. Kritik ist immer willkommen.

chmod 777 ist immer falsch. Insbesondere rekursiv über ein Verzeichnis gekübelt.

Ack. Deshalb auch nur temporär, da ich als nicht Guru nicht sofort eine Alternative zur Hand hatte. Verständlicherweise wollte ich keine allzu große Lücken in meinen Measurements haben.
Wie hättest Du das denn gelöst? Ich lerne gerne dazu.

Gruß

Hallo zusammen,
es hat sich herausgestellt, dass das Übertragen der Datenbank mittels BackitUp nicht erfolgreich war.
Da verlässliche und aktuelle Infos über das Backup und Restore der Influx DB zwar vorhanden, aber schwierig aufzufinden waren, habe ich meine Erkenntnisse mal für die Nachwelt zusammengeschrieben. Vielleicht hilft es ja jemandem und möglicherweise schaut auch ein Admin mal drüber.
Ich habe ich mich letztlich entschieden, Backup und Restore der Influx 1.8 DB auf einem anderen System mit Influx Bordmitteln durchzuführen.

Ausgangslage:
Altes System: Raspberry 4 mit 8 GB RAM
Neues System: Futro S720 mit 4 GB RAM

Beide Systeme sind im gleichen Netzwerk und mittels BackitUp auch auf dem gleichen Stand (Adapter, Scripte, Grafana etc.). Die relevante Datenbank in meinem Fall heißt sinnigerweise „iobroker“.

Auf dem alten System (Influx muss laufen):

influxd backup -db iobroker /Backup/influx/
sudo scp /opt/iobroker/backups/* USER@ZIEL_IP:/opt/iobroker/backups/

Auf dem neuen System (Influxdb muss gestoppt sein):
Zusätzlich habe ich noch die Instanzen Javascript und History angehalten. Ob das zwingend nötig ist, kann ich nicht sagen. Auf dem neuen System war aber bereits durch die vorherigen Versuche eine Datenbank mit gleichem Namen angelegt.

systemctl stop iobroker
sudo chmod -R 777 /var/lib/influxdb/
influxd restore -db iobroker -datadir /var/lib/influxdb/data/ -metadir /var/lib/influxdb/meta/ /Backup/influx/
sudo chown -R influxdb:influxdb /var/lib/influxdb
sudo chmod -R 755 /var/lib/influxdb/
iobroker fix
systemctl restart iobroker

Ohne (2) hatte ich ein "Permission denied". Um nicht lange zu suchen habe ich das temporär mittels chmod gelöst. Geht bestimmt auch anders.

Im Anschluss wurde das alte System heruntergefahren und dem neuen System auf der Fritz Box die alte Adresse zugewiesen. Das erspart einem, auf allen Systemen / Objekten die MQTT Adresse anzupassen.
Letztlich noch einen Reboot des Futro durchgeführt, um die neu zugewiesene „alte“ IP Adresse zu übernehmen und siehe da: Die Messwerte und Daten kommen rein. Grafana liefert Daten und alles ist gut.
Gefühlt ist der Futro etwas gemütlicher unterwegs als der Raspberry, das kann ich aber eher akzeptieren als die angeflanschte USB Platte an dem Raspberry. Außerdem ist meine HA bereits nahe am geplanten Endausbau, es kommt also voraussichtlich nicht mehr viel hinzu, daher sollte das passen.
Es sind nur an drei Datenreihen (Zählerstände von Shellys und Hichi IR Lesekopf) Probleme aufgetreten. Die wenigen falschen Werte habe ich direkt in den Datenreihen gelöscht bzw. korrigiert.
Der Raspberry bleibt erst einmal eine Weile in der Schublade, bis ich sicher bin, dass sich mein neues Setup bewährt.

Gruß

@Thomas-Braun ,

bis dahin kein Fehler, aber dann:

@futro:/usr/share/keyrings$ echo '393e8779c89ac8d958f81f942f9ad7fb82a25e133faddaf92e15b16e6ac9ce4c influxdata-archive_compat.key' | sha256sum -c && cat influxdata-archive_compat.key | gpg --dearmor | sudo tee /usr/share/keyrings/influxdata-archive_compat.gpg > /dev/null
sha256sum: influxdata-archive_compat.key: No such file or directory
influxdata-archive_compat.key: FAILED open or read
sha256sum: WARNING: 1 listed file could not be read

Der Inhalt des Ordners:

l@futro:/usr/share/keyrings$ ls
influxdata-archive_compat.gpg       ubuntu-pro-cis.gpg
ubuntu-archive-keyring.gpg          ubuntu-pro-esm-apps.gpg
ubuntu-archive-removed-keys.gpg     ubuntu-pro-esm-infra.gpg
ubuntu-cloudimage-keyring.gpg       ubuntu-pro-fips.gpg
ubuntu-cloudimage-removed-keys.gpg  ubuntu-pro-fips-preview.gpg
ubuntu-master-keyring.gpg           ubuntu-pro-realtime-kernel.gpg
ubuntu-pro-anbox-cloud.gpg          ubuntu-pro-ros.gpg
ubuntu-pro-cc-eal.gpg

Hallo zusammen,

beim Versuch, meine Influx 1 DB von meinem Raspberry auf einen Futro zu übertragen komme ich auch nicht so richtig voran und bin auf diesen Beitrag gestoßen. Da ich einen ähnlichen Fehler bei mir vermutet habe, bin ich der Anleitung von @Thomas-Braun in diesem Beitrag gefolgt, bekomme aber bei der Neuinstallation die folgende Meldung.
/usr/bin/influx und
/var/cache/apt/archives/influxdb_1.8.10-1_amd64.deb
wurden bereits gelöscht.

@futro:/usr/bin$ sudo apt-get update && sudo apt-get install influxdb
OK:1 http://de.archive.ubuntu.com/ubuntu noble InRelease
OK:2 http://de.archive.ubuntu.com/ubuntu noble-updates InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu noble-backports InRelease
OK:4 http://security.ubuntu.com/ubuntu noble-security InRelease
OK:5 https://apt.grafana.com stable InRelease
OK:6 https://repos.influxdata.com/debian stable InRelease
OK:7 https://deb.nodesource.com/node_20.x nodistro InRelease
Fehl:6 https://repos.influxdata.com/debian stable InRelease
  Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D8FF8E1F7DF8B07E
Paketlisten werden gelesen… Fertig
W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Depot wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: https://repos.influxdata.com/debian stable InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D8FF8E1F7DF8B07E
W: Fehlschlag beim Holen von https://repos.influxdata.com/debian/dists/stable/InRelease Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D8FF8E1F7DF8B07E
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
  influxdb
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
Es müssen noch 0 B von 54,4 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 153 MB Plattenplatz zusätzlich benutzt.
(Lese Datenbank ... 146163 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../influxdb_1.8.10-1_amd64.deb ...
Entpacken von influxdb (1.8.10-1) ...
dpkg: Fehler beim Bearbeiten des Archivs /var/cache/apt/archives/influxdb_1.8.10-1_amd64.deb (--unpack):
 Versuch, »/usr/bin/influx« zu überschreiben, welches auch in Paket influxdb-client 1.6.7~rc0-2ubuntu0.24.04.1 ist
dpkg-deb: Fehler: »einfügen«-Unterprozess wurde durch Signal (Broken pipe) getötet
Failed to disable unit: Unit file influxdb.service does not exist.
Fehler traten auf beim Bearbeiten von:
 /var/cache/apt/archives/influxdb_1.8.10-1_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Hat jemand eine Idee dazu?

Danke und Gruß

Hallo zusammen,

da mir mein Raspberry Pi 4 mit der angeflanschten USB SSD nicht wirklich gut gefiel, habe ich meine Installation via BackitUp auf eine Fujitsu Futro S720 mit Debian GNU/Linux 12 (bookworm) übertragen. Das hat erstaunlich gut geklappt bis auf das Übertragen der Grafana Dashboards. Die kommen auf dem neuen System nicht an, obwohl der BackitUp Restore eines erfolgreich auf dem Raspberry erzeugten Backups keinen Fehler zeigt.

Auf dem Futro ist die Installation identisch mit der auf dem alten Pi, alle Objekte sind da, die Verbindung zur influx DB klappt, alle Adapter wurden per Restore neu installiert und die Instanzen sind auch alle grün. Die Grafana Version auf beiden Systemen ist 10.4.8 wegen dieses Problems: https://forum.iobroker.net/topic/75401/problem-nach-grafana-update-auf-v11/16?_=1728485212268

Der Raspberry läuft momentan noch produktiv mit seiner angestammten IP, der Futro hat eine andere IP, bekommt also keine aktuellen MQTT Daten und die Scripte sind gestoppt. Es geht erst einmal darum, warum die Dashboards mit den historischen Grafen nicht angezeigt werden.

Interessant ist noch folgendes:

Wenn ich auf dem Futro in Grafana die Verbindung zur lokalen Datenbank teste erhalte ich dieses:

Stelle ich auf dem Futro mal testweise die Verbindung zur Raspberry Datenbank ein, erhalte ich das:

Das ist das gleiche Ergebnis, dass ich auch auf dem produktiven Pi bekomme. Es sind wohl nicht alle Measurements übertragen worden.

Hat jemand eine Idee dazu?

Danke und Gruß

@kapitaen31 ,

ich habe mir beim letzten Update das exakt gleiche Problem eingefangen.
Sämtliche Browser, die ich auf meinem iPad ausprobiert habe, konnten mit Grafana nichts mehr anfangen. Nachdem ich auf die letzte 10er Version gegangen bin (v10.4.8) läuft es wieder.

Für die Nachwelt:
~ $ apt remove grafana
~ $ sudo apt install grafana=10.4.8
~ $ sudo apt-mark hold grafana
~ $ sudo systemctl restart grafana-server

Gruß

@thomas-braun und @simatec ,

vielen Dank Euch beiden und einen schönen Abend.

Gruß

@simatec ,

das hatte ich so verstanden. Sorry.
Vielen Dank, die Benachrichtigung läuft jetzt wie geschmiert.
Bei meinen Update gestern wurde auch Grafana aktualisiert. Daher muss ich wohl den Key erneut generieren. Das Grafana Backup läuft deshalb gerade noch nicht. Das gehört aber nicht hierher und wird morgen angegangen.

@thomas-braun ,

vielen Dank für den Hinweis. Ist erledigt.
Wie oft / in welchem Rhythmus sollte denn das System aktualisiert werden?

Gruß