Kategorie: Allgemein

Messungen in einer InfluxDB löschen

Manchmal gibt es Messungen in einer InfluxDB, die zerstören das schöne Bild – verursacht durch Messfehler, Programmierfehler oder Schnittstellenproblemen. Bei mir sind das manchmal fehlerhafte 0-Werte.

Leider gestaltet sich das Löschen von einzelnen Messungen aus einer InfluxDB nicht so einfach, wie der ein oder andere es vielleicht von anderen Datenbanken gewohnt ist, da die Zeit das einzig zugelassene Identifikationsmerkmal einer DELETE Operation ist.

Update 02.10.2022: Inzwischen unterstützt der ioBroker InfluxDB Adapter das Löschen von Messwerten. Dazu einfach den Datensatz auswählen und das Löschicon betätigen.

Hier meine Vorgehensweise (unter Windows):

  1. Über die Software InfluxDB Studio (nur für Windows) mit der Datenbank verbinden.
  2. Über folgenden Befehl und das Anpassen der Zeit (und der Datenbank) die zu löschenden Werte identifizieren.
    SELECT * FROM „coronavirus-statistics.0.Germany.cases“ WHERE time > now() – 5d – 19h AND time < now() – 5d – 17h

    Dabei steht „5d“ für fünf Tage, „19h“ für 19 Stunden, und so weiter.
  3. Werden bei dem SELECT nur noch die Messungen angezeigt, welche gelöscht werden sollen, das “ SELECT * “ durch “ DELETE “ ersetzen und den Befehl ausführen.
  4. Fertig.

Ich übernehme keine Garantie für ungewollte Datenverluste.

delete measurment influxdb

Schnelles Smartphone UI

Ich mag ioBroker, ich mag Node-RED – aber ein User Interface, welches innerhalb von drei Sekunden auf dem Smartphone zur Verfügung steht, ist weder mit vis noch mit Node-RED UI / Dashboad möglich. Vielleicht liegt es am eingesetzten Raspberry PI und eine Monster-Hardware würde es schneller ermöglichen – so ist die Ladezeit je nach Verbindungsqualität (WLAN, VPN) jedoch belastend – gerade für den schnellen Blick auf die Haustechnik (z.B. Solarthermie) oder die Straßenbahn-Abfahrtszeiten.

Einzige Lösung kann eine native App fürs Smartphone sein, dachte ich mir. Doch weder für vis noch für Node-RED UI gibt es entsprechende perfomante Ansätze. Also musste eine weitere Lösung her. Erste Tests mit MQTT Dashboard-Apps waren verheißungsvoll, doch offenbarten sie dann Probleme. Denn bei MQTT muss die App weitgehend online sein, um die aktuellen Werte empfangen zu können. Frisst Akku und Leistung auf Seiten des Smartphones. Ein Abrufen der Werte nach einer längeren Offline-Phase ist nicht ohne weiteres möglich.

Covergestaltung

Dann stolperte ich über die App IOT Dashboard, welche mich gerade sehr begeistert. Die App von Ciprian Savastre ermöglicht es, via REST im JSON-Format Daten abzurufen, und auch Befehle zu senden. Ein paar Nodes in Node-RED ermöglichen sowohl die Auslieferung der Daten an die App, als auch das Empfangen von Befehlen aus der App.

  • Ja, die App ist funktionell noch ausbaufähig. Der Entwickler ist aber nett und ansprechbar für Bugs und Ideen.
  • Ja, es ist nur eine Ergänzung zu einem ausgefeilten UI via vis oder Node-RED Dashboard.
  • Ja, man muss auf dem Smartphone einigen Konfigurationsaufwand betreiben.

Dafür hat man aber in atemberaubender Geschwindigkeit den aktuellen Stand des Smart-Homes auf dem Schirm.

Und so sieht es gerade bei mir aus:

Aktuell benutze ich noch keine Steuerungsfunktionen, sondern nur das reine Auslesen von Werten. Daher sieht es im Node-RED auch bisher sehr einfach aus.

Die Steuerung realisiere ich bisher über Node-RED UI / Dashboard – einige häufig genutzte Funktionen werde ich aber sicher auch in der App IOT Dashboard abbilden – außer es läuft mir etwas besseres über den Weg.

Gedanken zur KWL

Kontrollierte Wohnraumlüftungen (kurz KWL) sind eine feine Sache. Man stelle sich vor, man müsste tagsüber mehrmals lüften … Klar: sie ist keine Klimaanlage. Und doch sollte man nicht nur beim Thema „wärmen“, bzw. Wärme erhalten im Winter (was sie über die Wärmerückgewinnung ja macht) ein paar Dinge beachten.

Standort

Wer die Gelegenheit hat, den Standort des KWL Geräts zu bestimmen, tue dies weise. So sollten sie klar innerhalb der thermischen Hülle des Hauses stehen – für die entsprechende Effizienz im Winter. Erfahrungen zeigen aber auch: der Heizraum ist meist nicht der geeignete Ort für das Gerät – gerade in einer Kombination mit Solarthermie. Die steht im Sommer schließlich fast unbegrenzt zur Verfügung und hebt die Temperatur im Heizraum (wo in der Standardausführung meist auch der Warmwasser-Speicher steht) auf unschöne Höhen. Jegliche Kaltluft, die möglicherweise in der Nacht die KWL dank Bypass ohne Wärmerückgewinnung passieren könnte, wird so stark durch die Heizraumtemperatur beeinflusst, dass nicht mal eine minimale Abkühlung der Räume über die KWL stattfindet. Also: vielleicht gibt es einen Wäscheraum oder einen Kellerraum – sofern man über einen solchen verfügt – in dem die KWL besser aufgehoben ist.

Funktionen / Abhilfe

Eine wichtige Funktion für ein angenehmes Raumklima ist der schon erwähnte Sommer-Bypass. Er leistet – wenn nicht von der Raumtemperatur beeinflusst – einen Beitrag für ein angenehmes kühles Raumklima im Sommer, indem er die Wärmerückgewinnung umgeht. Interessant und wichtig – auch für alle, die das gleiche Dilemma der Interaktion zwischen Solarthermie und Lüftung haben – ist der Fensterlüftungsmodus. Bei ihm wird die Zuluft komplett abgeschaltet, sodass die KWL nur absaugt und das Zuströmen kalter Luft (in der Nacht) durch die Fenster unterstützt.

Beispiel: Pluggit

Bei meinem Lüftungsgerät von Pluggit Avent P310 lässt sich der Fensterlüftungsmodus über die Modbus Schnittstelle aktivieren:

modbus.0.holdingRegisters.40169_prmRamIdxUnitMode

Manuel = 4 / Wochenprogramm = 8 / Start Sommer = 2048 / Ende Sommer = 2048

Leider ist es ein Toggle – sprich man sendet sowohl zum Einschalten, als auch zum Ausschalten „2048“.

Hallo Welt!

Ich baue mir mein eigenes SmartHome. Da ich dies nicht während eines Neubaus, sondern in einer (unserer) Bestandsimmobilie tue, sind die meisten Lösungen auf Funkbasis.

Ich versuche beim Bau einigen Grundsätzen zu folgen:

  • kein Smartphone Zwang – alle wichtigen Funktionen wie Licht und Rollläden müssen auch über die normalen Schalter bedienbar sein.
  • keine Insellösung – das Festlegen auf einen einzelnen Hersteller schränkt nur unnötig ein und verteuert es.
  • my home is my castle – das SmartHome läuft bei mir zuhause – nicht in der Cloud.
  • Open Source – soweit es geht. Bei der Firmware (gerade von Zigbee-Geräten) stößt man hier natürlich an seine Grenzen.
  • kein „Alexa“, kein „Hey Google“ – Daten fallen in einem SmartHome wahre Unmengen an. Doch die bleiben bei mir.
  • es hat auch Grenzen: zumindest sage ich das jetzt noch.

Ich bin in dem Bereich kein Profi. Vor gut einem Jahr habe ich mit ioBroker und NodeRED angefangen. Trotzdem gibt es vielleicht die ein oder andere Erkenntnis, die ich hier teilen kann.