Mein Forum
Registrieren
Neu hier?
Baukonstruktionen
Fertighaus
Fenster
Dämmung
Dichtheit
Passivhaus
Schimmel
Energieausweis
Heizung
Pellets
Erdwärme
Warmwasser
Stromsparen
Solaranlagen
Photovoltaik
Lüftungsanlagen
Energiespartipps
Berechnungen
|
|
||
|
@Becker kannst du mir die Formel der Verdichterspannung erklären, wie du da drauf kommst?? Weil Drehstrom?... |
||
|
||
|
var temp = (msg.payload[43141] *10) / ((msg.payload[43147] / 1000) * 1.732); P = √3 x U x I Spannung = Inverter Leistung / (Strom Inverter * 1,732) Der Wert  Bildquelle: https://www.elektrotechnik-fachwissen.de/bilder/wurzel3.gif wird als Verkettungsfaktor bezeichnet. Nachgemessen habe ich es nicht, kannst du ja mal machen 🤠 |
||
|
||
|
Habe mich jetzt ein bisschen mit Node-RED und Grafana gespielt und mir erlaubt Chrismo sein Dashboard mit Becker seinen Node-RED Flow nachzubauen. Habe aber auch Beckers Node-RED Flow ein bisschen abgeändert und zwar habe ich zusätzliche Daten in die InfluxDB schreiben lassen und auch die Variante wie in die InfluxDB geschrieben wird geändert. Becker hat für jede Quelle ein eigenes Measurement erstellt ich habe es jetzt so geändert dass alle Daten in das Measurement F1155 geschrieben werden und auch dementsprechend die Grafana Dashboards von Becker geändert. Aufbauen tut das ganze aber weiterhin auf Beckers Node-RED Flow, habe nichts gelöscht sondern nur nicht vorhandene Sachen deaktiviert im Node-RED. Aussehen tut das ganze jetzt so:  
|
||
|
||
|
kannst du mir das erklären? bzw. deine Datenbank zeigen. steh´ gerad auf´m Schlauch. So sieht das bei mir aus:  ich wollte nicht zu viele Werte permanent schreiben. |
||
|
||
|
Deine Datenbank ist so aufgebaut: Datenbankname: db Measurements: AT, Bezug, COP, Einspeisung,.... Unter AT AT [Außentemperatur] sind alle Daten von AT AT [Außentemperatur] und unter COP sind alle Daten von COP, usw... Bei mir ist die Datenbank so aufgebaut: Datenbankname: nibepi Measurements: F1155 F1155 hat mehrere Spalten wie AT AT [Außentemperatur], Bezug, COP, usw... In jeder Spalte werden die dazugehörigen Daten gespeichert   Erreichen kannst du das ganze so indem du in Node-RED for dem Wert den du in die InfluxDB schreibst den Spaltennamen angibst zB. AT: [Wert] So schaut es bei mir jetzt im Node-RED aus, rechts bei den Debugnachrichten kannst du sehen wie die Werte geschrieben werden.  Ich habe es mit einer Funktion gelöst die mir den Spaltennamen und Wert zusammenfügen.  Und so schaut die InfluxDB Konfig aus:  Von den Schreibzyklen habe ich nichts geändert nur die Datenbankstruktur. Wenn alles im gleichen Measurement ist gehen manche Sachen leichter im Grafana umzusetzen wenn ich das richtig verstanden habe. Ich hoffe ich konnte das jetzt irgendwie verständlich rüberbringen |
||
|
||
|
Ich habe es auch so wie Becker, also die inzelnen Register in mehreren Measurements. Aber es ist tatsächlich besser (Performance und tlw. auch bei den Queries), es so wie du zu machen und nur ein Measurement aber dafür mehrere Tags (Spalten) zu verwenden. Ich habe das erst spät rausgefunden und ändern werde ich das sicher nicht mehr Aber ich mache das jetzt bei allen neuen DBs so. |
||
|
||
|
@chrismo kann ich verstehen dass du es nicht mehr ändern willst, weil das würde so viel ich weiss kompletten Datenverlust bedeuten und ich denke du hast da sicher schon einiges gesammelt. Ich hoffe es macht dir nichts dass ich mir deine Optik vom Dashboard geklaut habe. Irgendwann muss ich mich noch damit beschäftigen wie man mittels MQTT kommuniziert damit ich die Steuerung auch über eine Visu einpflegen kann ...für Tipps bin ich natürlich sehr dankbar |
||
|
||
|
Kein Problem wegen des Dashboards. Im Gegenteil, freut mich, dass es nützlich war. Ist ja im Endeffekt der Sinn des Threads hier, dass man sich austauscht bzw. gegenseitig hilft. Die Daten kriegt man schon in eine neue Struktur. Aber der Gesamtaufwand ist schon recht hoch, weil ja auch die Logging-Skripte und die Visualisierung angepasst werden müssten. Solange da kein Leidensdruck wegen irgendwelcher Probleme besteht, greife ich das nicht an |
||
|
||
|
sehr interessant, ist das von der Leistung her besser ?  so sieht es bei mir aus. Wie sieht das bei dir aus? Wie rufst du dann die Werte in Grafana ab wenn alles in einem ist ?? msg2 = {}; wäre dann BF1 ? wozu hast du "number" genommen? Die Werte sind doch schon alle Nummern. Wusste nicht dass sowas möglich ist. Kenne mich halt 0 aus mit Influxdb. Wenn das deutlich performer ist, sollte man das umbauen. Weißt du zufällig was es mit dem Zeitcode auf sich hat z.B.: time value ---- ----- 1613084400000000000 28142.6 wie kommt man von "16130844" auf Datum + Zeit ? P.S. ich hab nur mal aus Spaß diese Funktion nachgebaut:  bei mir macht er keine "Number" aus dem String. Wäre das so der korrekte Ansatz? |
||
|
||
|
Wenn du mir sagst wie ich zu dieser Auswertung komme kann ich sie dir gerne zeigen 😊 Grafana ist ganz einfach du wählst oben die Measurement und bei Field das Tag.  Hat den Vorteil das du Queries im gleichen Measurement umsetzen kannst. Eins vorweg, ich kenne mich auch nicht wirklich aus 😉 ich habe überall die die gleich msg1 benützt Habe dafür immer eine extra Funktion erstellt. msg1 = {}; msg1.payload = {"AT": Number(msg.payload)} return msg1; ----- msg1 = {}; msg1.payload = {"BF1": Number(msg.payload)} return msg1; Mein Weg ist immer NibePi Wert > Funktion > InfluxDB wie du oben vielleicht am Bild von meinen Node-RED Flow erkennen kannst. Habe mit "number" gute Erfahrungen gemacht beim protokollieren von meinen KNX Daten deshalb benütze ich es jetzt sicherheitshalber. Ich habe leider keine Ahnung wie da Influx denkt, müssen wir aber eigentlich eh nicht wissen, wichtig ist dass es Grafana weiss 😄   Ich habe wie oben bereits beschrieben für jeden Wert eine eigene Funktion erstellt. Dein Problem ist aber glaub ich dass bei dir unten "return msg;" steht du musst aber die geänderte msg weitergeben, also zB. "return msg1;" |
||
|
||
|
einfach nur "htop" 🤠 meine Idee wäre es über ein "join" Node alle Werte als ein Objekt so wie du es machst in influxdb zu schreiben. Dann wären alle Werte auch immer zeitgleich da.  Ist die Frage ob man dazu ein "Measurement" für die 0,5Hz Werte des Log.set nimmt und ein "Measurement" für die restlichen Werte (etwa 60s Intervall). Bei mir wäre dann noch ein "Measurement" für die PV Daten nötig. Interessant wäre das allerdings nur, wenn es resourcenschonender ist, dazu bräuchte ich die Info aus htop bei dir. Wenn es gleich ist, lohnt es sich nicht, sehe in Grafana keinen großen Vorteil 🙄 edit hier mal ein kleiner Test:  |
||
|
||
|
das Problem ist das mein Setup anderst aufgebaut ist. Auf meinen Raspberry läuft nur Node-RED mit Nibe-Pi und MQTT, weil ich denke dass ich das für die später Kommunikation benötige. InfluxDB und Grafana läuft bei mir unter Proxmox auf einen eigenen Container. Habe da noch ein paar andere Node-RED Flows laufen die die in die InfluxDB schreiben. Fronius WR WR [Wechselrichter], KNX Daten und NibePi. Habe jetzt mal htop auf meinen Debian Container installiert, aber ich kann dir nicht sagen wie aussagekräftig das dann ist.  Ich habe im Augenblick noch garkein Log.set laufen, würde aber alles ins gleiche Measurement speichern. Ich habe es mir so angewöhnt dass ich immer eine Datenbank anlege für das System zB. KNX in der lege ich dann ein Measurement für jede Quelle an. zB. Wetterstation oder Temperaturen und dort kommt dann alles rein. In deinen Fall würde ich dann für PV ein eigenes Measurement anlegen, aber das muss jeder für sich selber entscheiden wie es für ihm passt. Da ich bei den Systemen ziemlicher Anfänger bin hätte ich nichtmal gewusst dass man das mit einen Join lösen kann, wenn das funktioniert ist das sicher die schönere Lösung, welche ich auch bevorzugen würde. Angeblich sind manche Berechnungen nur oder nur schwer möglich wenn die Daten nicht im gleichen Measurement sind. Aber frag mich was leichteres 😉 |
||
|
||
|
Das sind die Nanosekunden, die seit dem 1.1.1970 00:00 (UTC) vergangen sind Es ist üblich, dass Zeitangaben in Computersystemen diesen sog. Unix Timestamp verwenden, der die vergangenen Sekunden seit dem 1.1.1970 (UTC Zeitzone) zählt. Dafür gibt es in jeder Standardbiblliothek Umrechnungsfunktionen in andere Datumsformate. bzw. auch Online Konverter, wie z.B. diesen hier: www.epochconverter.com Die 1613084400000000000 entsprechen dem 12. Feb 00:00 Uhr (unsere Zeitzone) bzw. 11. Feb 23:00 in der Nacht (GMT). Man sieht hier auch den Vorteil dieser Darstellungsform: der Timestamp ist unabhängig von der Zeitzone, die man sonst immer mitspeichern müsste. Man kann auch Zeitstempel sehr einfach miteinander vergleichen, ebenfalls unabhängig von der Zeitzone. Stimmt, das braucht man selten. Aber ein Bsp. wo ich es gebraucht habe: für Skripte, die Monatsverbräuche ausrechnen, was Grafana bzw. genauer gesagt die Influx Queries leider nicht könnten. Bsp: wenn man VL VL [Vorlauf], RL Felder in einem Measurement gespeichert hat, kann man eine Query schreiben, die einem die Spreizung liefert: SELECT "vl" - "rl" FROM "nibe". Ähnlich könnte man sich direkt die Heizleistung ausrechnen. Hat man die Werte auf verschiedenen Measurements aufgeteilt, kann man das nicht direkt in Influx bzw. Grafana machen, sondern braucht irgendeine Applikation, die die Werte aus den verschiedenen Measurements liest, dann die Berechnung macht und ausgibt bzw. in eine neue Measurement speichert (ich mache so Sachen mit nodeRED).
|
||
|
||
|
Neues Graphana Update, multiple Y-Achsen: https://www.heise.de/news/Monitoring-Grafana-7-4-stellt-Zeitreihendaten-flexibler-dar-5051088.html |
||
|
||
|
Bei mir läuft leider noch das alte influx und grafana. Müsste irgendwie die alten db übernehmen und das edomi komplett auf die neue 2x version umstellen.. |
||
|
||
|
Nach dem Update ist vor dem Update 😈 |
||
|
||
|
Auf die Nanosekunden wäre ich nie im Leben gekommen 😘 Man kann sehr einfach die Spreizung in Grafana berechnen von verschiedenen Measurements:  Monatsverbräuche auch, bin derzeit aber erst bei Tageswerten, am 1.3. kann ich dann dies als MAZ berechnen:    Hier bilde ich aus dem Integral pro Tag die tägliche thermische & elektrische Energie und daraus wiederum die TAZ. Dann berechne ich aus den Werten vom integrierten WMZ (jeden Tag 0:00Uhr) ebenfalls die Wärmemenge Heizung+WW pro Tag:    Das kann ich dann mit dem Wert der Integralrechnung (also aus meiner Formel) vergleichen. Genauso die elektrische Energie vom S0 Zähler im Sunnyportal (durch SAE). Hierbei ist mir die letzten Jahre aufgefallen, dass der S0 Zähler im Sunnyportal immer weniger anzeigt als wenn ich ihn direkt ablese. In Grafana wiederum zeigt er mehr an - bin schon sehr gespannt auf den 1.3., ob das Integral über 1 Monat gleich dem abgelesenen Wert ist. ---------------------------------------------------------- Was sagst du denn zum Resourcenumgang ? Besser ein Measurement mit vielen Daten ? Bin echt am überlegen das zum 1.3. umzubauen oder nicht. Ein Measurement mit allen Daten in Spalten ist 👍 |
||
|
||
|
Besten Dank, da wäre ich auch nicht drauf gekommen. Jetzt hab ich wieder was dazugelernt. 😊 |
||
|
||
|
Ah, mit Transformationen geht das ja dann auch direkt in Grafana. Die habe ich noch nie verwendet, dürften dann aber zusätzliche Umwege über nodeRED und co für viele (alle?) meiner Berechnungen überflüssig machen. Du hast ja bei den Gruppierungen jetzt 1d drin. Sowas wie 1M (Month) gibt es aber nicht. Wie setzt du da die Filter für jedes Monat richtig? Also so, dass für die Berechnung der MAZ im Feber die TAZ von 1. bis 28. genommen werden, für die MAZ im März aber die TAZ von 1. bis 31.? Hier was zur "Performance Penalty", wenn man Daten auf mehrere Measurement aufteilt, direkt von InfluxDB Entwicklerin: https://community.influxdata.com/t/is-there-performance-penaly-for-having-multipe-measurements-instead-of-one-measurement-with-multiple-tags/9273 Sie empfiehlt einzelne Measurements zu vermeiden. Hier wird argumentiert, dass man genau die Daten in eine Messung zusammenfassen sollte, die "zusammen gehören", man also später auch gemeinsam für Berechnungen braucht: https://stackoverflow.com/questions/45368535/influxdb-single-or-multiple-measurement https://community.influxdata.com/t/what-is-the-criteria-to-use-multiple-fields-per-measurement/2174/4 Also Bsp. Nibe: alle Parameter, die man für die Berechnung der akt. Leistung benötigt. Umgekehrt, aber nicht z.B. die Verdichterfrequenz oder die Gradminuten... Finde ich aber zu kompliziert, weil man dann sicher Parameter hat, die man nicht eindeutig einem Measurement zuordnen kann und dann erst recht wieder das Problem hat, dass man Daten aus zwei Measurements kombinieren muss. |
||
|
||
|
Habe jetzt direkt Influxdb 2 gestartet kennt sich jemand mit "flux" aus, konkret wie man am Ende der Zahl die Einheit hinzufügt ich bin von der Fülle an Funktionen irgendwie erschlagen...  |
||
|
||
|
Angeblich geht auch 1M (1 Monat) und auch sogar 1 Jahr. Das werde ich dir am 1.3. sagen können, deshalb wollte ich solange die Datenbank in Frieden lassen. Aber ich denke am 1.3. werde ich umbauen auf sinnvolle "Measurements". Jetzt habe ich aber ein neues Problemchen zufällig entdeckt und zwar funktioniert die LOG.SET nicht richtig. 40008 40012 40013 40014 40015 40016 40072 43005 43136 43375 43437 43439 Die ersten drei, 40008, 40012, 40013 werden ignoriert, das wären VLT, RLT und WWoben. Ich habe mich nämlich gewundert, dass meine thermische Leistung nur 1x in der Minute berechnet wird, obwohl alle Werte in der LOG.SET sind. Habe es heute noch ein paar mal probiert, auch Modbus deaktiviert, aber die drei Werte übernimmt sie einfach nicht in die LOG.SET. Könntet ihr das mal ausprobieren ?? Habe dann auch noch mal eine minimal LOG.SET erstellt mit nur vier Werten: WT,KT-Pumpe, Hz und GM. Da hat sie mir nur KT-Pumpe übernommen. Ich verstehe es nicht. Wäre nett wenn ihr das mal bei euch überprüft. Edit: Problem gelöst, die ersten 3 Zeilen werden ignoriert. Habe aus Frust mal so eine LOG.SET gemacht:  40005 40006 40007 will ich gar nicht haben und genau so läuft es nun, ab 40008. |
Beitrag schreiben oder Werbung ausblenden?
Einloggen
Kostenlos registrieren [Mehr Infos]