Ankündigung

Einklappen
Keine Ankündigung bisher.

Neues Database Plugin

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Sipple
    antwortet
    So etwas fürchte ich eben auch, drum habe ich es auch noch nicht ausprobiert.

    Einen Kommentar schreiben:


  • bmx
    antwortet
    Ich habe das noch nicht ausprobiert. Ich weiß nicht, ob die Zuordnung der Datenbank ID zu den Namen der Items auch gleichbleibt...

    Einen Kommentar schreiben:


  • Sipple
    antwortet
    Moin

    Wenn man zwei ansich identische SHNG Installationen hat, davon eine, die schon einige Zeit läuft und eine neue, kann man einen smarthome.db file einfach von der alten auf die neue kopieren oder geht das schief?

    Gruß, Martin

    Einen Kommentar schreiben:


  • henfri
    antwortet
    Hallo,

    Zitat von firefox Beitrag anzeigen
    fair enough.
    Danke.
    Im Dockerfile habe ich pymysql hinzugefügt:


    Gruß,
    Hendrik

    Einen Kommentar schreiben:


  • wvhn
    antwortet
    Hi Thomas,

    am besten schaust Du Dir im Admin-Interface das Webinterface des Plugins an und dort die historischen Daten für das Item. Grundsätzlich steht der letzte in die db geschriebene Wert ja immer mit Duration "none" drin, bis der nächste Wert geschrieben wird. D.h wenn es nicht regnet, müsste dieser Wert im Beobachtungszeitraum konstant bleiben und somit zur Anzahl "1" führen. Deshalb denke ich, dass es richtig ist, die 1 immer zu subtrahieren.

    Aus der Doku des Plugins kommt zudem folgende Info:
    • count: for the amount of values not “0” (more examples: count>10, count<10, count=10)
    • countall: for the amount of values (without checking any condition)
    Möglicherweise ist das nicht relevant, wenn Dein Sensor keine Impulse (0-1-0 Übergänge) in die db schreibt, sondern die aufaddierte Anzahl an Impulsen.

    Gruß
    Wolfram

    Einen Kommentar schreiben:


  • Maxthomas2001
    antwortet
    Hallo,
    folgendes Problem:
    Ich habe einen Regenmesser, der als Impulszähler funktioniert. Bei einem Niederschlag von 0,2 mm wird der Zählimpuls um 1 erhöht.
    Wenn ich also wissen möchte, wieviel es in der letzten Stunde / Tag etc. geregnet hat, lasse ich die die Anzahl der Zählimpulse in diesem Zeitraum mit 0.2 multipliziert ausgeben. Dazu verwende ich die Funktion
    Code:
    sh.Wetter.Regen.Impulse.db('countall', '60i') * 0.2
    Komischerweise ist die Anzahl der Impulse, die die Funktion liefert, um 1 zu hoch.
    Oder es wird sogar die Anzahl 1 zurückgeliefert, obwohl in den letzten 60 Minuten gar kein Eintrag in die Datenbank erfolgte.

    Habe ich hier einen Denkfehler bezüglich der Verwendung von countall?
    Dann würde ich als einfache Lösung einfach noch die Anzahl -1 nehmen.
    Oder liegt hier ein Fehler im Plugin vor?

    Grüße
    Thomas

    Einen Kommentar schreiben:


  • firefox
    antwortet
    fair enough.
    Danke.

    Einen Kommentar schreiben:


  • Msinn
    antwortet
    In der aktuellen Version von SmartHomeNG werden Requirements automatisch installiert, wenn das Plugin eine requirements.txt hat.

    Beim Database Plugin ist der Treiber für MySQL (pymysql) nicht in den Requirements, weil MySQL nicht die Standard Datenbank ist. Normalerweise wird SQLite3 genutzt, was auch out of the Box funktioniert. Für den Großteil der Nutzer ist pymysql kein Requirement, das ca. 80% bis 90% SQLite3 nutzen. Ich nutze übrigens auch einfach SQLite3 und habe selbst mit größeren Datenbanken (ca. 6 GByte) eine gute Performance.

    Die Installation der benötigten Komponenten zur Nutzung von MySQL oder anderen Datenbanken wie z.b. PostgreSQL gehr weit über den Standard Scope hinaus. Wer sich für eine optionale Datenbank entscheidet, muss auch alle benötigten Software Teile installieren.

    Wenn wir pymysql mit installieren würden, würde sicher jemand kommen und sagen "MySQL funktioniert nicht, die Datenbank Software wurde nicht mit installiert"

    Im develop Branch haben wir eine requirements-mysql.txt zum Plugin dazugelegt. Die wird aber nicht automatisch installiert. Wer MySQL nutzt, muss das schon selbst dazu installieren.

    Einen Kommentar schreiben:


  • firefox
    antwortet
    Hallo zusammen,

    ich nutze SmarthomeNG zwischenzeitlich mit dem Dockerimage. Im Dockerimage wird das Modul pymysql nicht mitinstalliert, weshalb ich jetzt immer einen Fehler beim database plugin bekomme. Mir ist beim telegram plugin aufgefallen, dass es wohl eine Möglichkeit gibt, dass das Plugin beim laden automatisch fehlende Python Module nachinstalliert (Requirements.txt)

    Lässt sich das beim database Plugin auch einbauen oder gehört das eher ins Dockerfile?

    Danke und Grüße
    Thomas

    Einen Kommentar schreiben:


  • Maxthomas2001
    antwortet
    Hallo.
    Ich habe folgendes Problem:
    Ich möchte zu einem gespeicherten Wert in der Datenbank den dazugehörigen Zeitpunkt auslesen.
    Konkret: Ich möchte die tiefste Temperatur des Tages, Jahres, ... Anzeigen lassen und dazu, wann diese Temperatur gespeichert wurde.
    Ist das möglich? Würde mich über einen kleinen Denkanstöße freuen .

    Grüße, Thomas

    Einen Kommentar schreiben:


  • aschwith
    antwortet
    Klingt gut, da mache ich gerne mit.

    Einen Kommentar schreiben:


  • wvhn
    antwortet
    aschwith , ich fürchte, die Abfragen in die Zukunft haben wir mit dem letzten Update des plugins abgeschossen.
    Ich hatte den Wunsch der Community aufgegriffen, Plots für einen ganzen Tag (0 - 24.00 Uhr) zur Verfügung zu stellen. Highcharts kann gut mit Zeiten in der Zukunft umgehen, aber die Datenbank hat mir bei den Tests mit normalen series ne Menge Datenmüll geliefert. Daraufhin hatte ich Msinn gebeten, die Rückgabe von Werten auf "now" zu begrenzen.

    Vorschlag: sobald die negativen durations verlässlich abgestellt sind, kümmern wir uns um dieses Thema. Ich hab da schon eine Idee

    EDIT: ich fände es besser, None durations zu vermeiden, z.B. indem diese beim init des Plugins geprüft und mit "now" aufgefüllt werden.
    Zuletzt geändert von wvhn; 01.07.2020, 20:43.

    Einen Kommentar schreiben:


  • aschwith
    antwortet
    wvhn zu Deinem anderen Thema für series mit Start und Endzeitpunkt in der Zukunft: Diese Option für Abfragen in der Zukunft hatten wir hier in der Community mal vor einigen Jahren mit eingebaut. Usecase war unter anderem die Möglichkeit, z.B. Vorhersagen für z.B. Bewässerungssysteme zu berechnen, in die Datenbank zu schreiben und dann plotten zu können. Alles für Zeitpunkte mit Start und Endzeitpunkten in der Zukunft.

    VG

    Einen Kommentar schreiben:


  • aschwith
    antwortet
    Hallo wvhn ,

    Du hast recht. Mir waren die Differenzen bei Onkelandy im Milisekundenbereich nicht aufgefallen. Es kann sich wirklich um zwei Ursachen handeln. Bei mir tritt das Problem momentan allerdings nicht auf, deshalb kann ich nicht weiter Debuggen.
    Dein zweiter Aspekt ist auch korrekt: Es ist normal, dass der aktuelle Wert in der Datenbank mit Duration=None gehalten wird. In der Tat läuft hier manchmal was schief, so dass diese Werte in der Datenbank verbleiben. Solange der Messwert 0 ist fällt das häufig nicht auf. Ist diese Wert aber ungleich Null, fällt das z.B. beim Aufintegrieren durch völlig überhöhte Werte auf.
    Ich nutze z.B. das 'integrate' feature des database plugins, um Momentanleistungen in der DB zu Verbrächen aufzuintegrieren. Der SQL Code dazu findet sich im database plugin, Zeile 705:

    Code:
    'integrate': 'MIN(time), SUM(val_num * duration)',
    Dort schlagen die Durations=None leider als echte Werte zu. Kennt jemand einen Weg, diese None Durations im SQL Format bei der Summenbildung auszuschließen?

    Einen Kommentar schreiben:


  • wvhn
    antwortet
    Ich denke, wir haben hier zwei Probleme (gehabt ? ):
    • die Beobachtung von Onkelandy zeigt negative durations im Bereich weniger 100 Miikrosekunden. Wenn man sich ansieht, an wie vielen Stellen in shNG und SV aktuelle Zeitstempel mit einer Funktion ähnlich
      Code:
      	timestamp = new Date(now)
      generiert werden und dann unterschiedliche Rechenzeiten in den jeweiligen Modulen annehmen, dann müssen zwangsläufig solche Differenzen auftreten. Abhilfe wäre aus meiner Sicht möglich mit einer Rundung auf volle Sekunden - oder meinetwegen 100 ms.
    • das zweite Problem mit wesentlich größeren negativen durations und den durations mit Wert "None" ist ja gerade in Bearbeitung. Die von aschwith gezeigten Abweichungen scheinen mir zu groß, um "nur" aus der Wiederherstellung der Attribute zu stammen.
      Dazu ein Ansatz: grundsätzlich steht der aktuelle Wert jedes items immer mit duration=None in der Datenbank, bis der nächste Wert herein kommt und die duration berechnet werden kann. IMHO muss nochmal geprüft werden, inwiefern nach Abstürzen, Neustarts oder Timeouts wirklich sicher gestellt wird, dass durations nachgetragen werden (lieber falsche als gar keine).
    Wenn wir mit dem Thema durch sind, müssen wir uns nochmal die Werte ansehen, die künstlich hinten an die series angehängt werden. Siehe diesen Beitrag und (viele) fortfolgende.

    Einen Kommentar schreiben:

Lädt...
X