Buy Shiba Inu Token

Einrichtung der openHAB Umgebung und allgemeine Konfigurationsthemen.

Moderatoren: seppy, udo1toni

Antworten
Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der gespeicherten (persistenten) Daten

Beitrag von udo1toni »

Nein, das geht nicht. Du kannst aber durchaus eine Abfrage erstellen, welche die Rohdaten entsprechend abbildet. Die Abfage speicherst Du direkt in der Datenbank.

Was die Wochentage betrifft, so ist Sonntag bis Samstag üblich, wobei Sonntag auch gerne mal 0 ist. Aber wie gesagt, da Du die Daten ohnehin üpber Abfrage so listen kannst, kannst Du den Wochentag so gestalten, wie Du das willst.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der persistenten Daten / Automatisierung Lichtsteuerung

Beitrag von udo1toni »

Die Frage ist, willst Du das einmalig berechnen? Dann wäre der einfachste weg über eine entsprechende SQL-Abfrage. Willst Du, dass die Daten immer wieder aktualisiert werden? Dann wäre es sinnvoll, dies in openHAB direkt vorzunehmen.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der persistenten Daten / Automatisierung Lichtsteuerung

Beitrag von udo1toni »

Ich habe jetzt noch nicht intensiv darüber nachgedacht, aber ein erster Versuch sähe ungefähr so aus:

Je Werktag ein Satz Number(!) Items für das erste ON des Bewegungsmelders und das letzte OFF (oder evtl. das letzte ON?) des Bewegungsmelders. Diese Items für mehrere Wochen. Eine Gruppe, in der all diese Items zusammengefasst sind. Die Itemnamen folgen einem Schema: Time_[1-5]_[0-9]_O[N|FF] Beispielnamen: Time_3_5_OFF (Mittwoch vor 5 Wochen, letztes OFF-Ereignis)
Number hält dann die Anzahl Sekunden seit Mitternacht (Datumsrechnerei ist für die Aufgabe eher hinderlich)

Jeweils um 0 Uhr werden alle Items des passenden Wochentags ins vorhergehende Item verlagert. Das "jüngste" Item wird auf NULL gesetzt.
Für die Schaltzeiten wird der Mittelwert der letzten 9 Wochen gebildet, evtl. mit einer Gewichtung, so dass die jüngsten Zeiten mehr Gewicht haben.

Wenn der Bewegungsmelder anspricht, prüft die Rule, ob eine NULL im Item steht und schreibt in diesem Fall die Uhrzeit ins Item (Minimum). Für das Maximum wird jedes Mal der Zeitpunkt notiert. Eventuell ist es sinnvoll, hier noch Grenzwerte zu definieren, außerhalb derer die Werte nicht geschrieben werden (je nachdem, wie gut die Melder arbeiten, kann es ja mal einen Fehlalarm geben).
Eingeschaltet wird bei Erkennung der ersten Bewegung, falls vor dem errechneten Zeitfenster, geht das Licht wieder aus, ansonsten bleibt es bis zum errechneten Ende eingeschaltet.

Code: Alles auswählen

var Integer iMin = 0
var Integer iMax = 0
var Timer tLightOff = null

rule "transfer data"
when
    Time cron "0 0 0 ? * MON-FRI" //Montag bis Freitag, 00:00:00 Uhr
then
    val dOW = now.getDayOfWeek.toString
    gTime.members.filter[i|i.name.split("_").get(1) == dOW].sortBy[ -name ].forEach[j|   // für jedes j aus allen Items der Gruppe, die dem Wochentag entsprechen (absteigend sortiert)
        val jPlatz = Integer::parseInt(j.name.split("_").get(2))                         // Bestimme den Platz als Integer
        val jSwitch = j.name.split("_").get(3)                                             // bestimme die Richtung
        if(jPlatz > 0) {                                                                 // falls noch nicht 0
            val jVorgaenger = gTime.members.filter[i | i.name.split("_").get(1) == dOW
                                                    && i.name.split("_").get(2) == (jPlatz - 1).toString 
                                                    && i.name.split("_").get(3) == jSwitch].head             // Bestimme das Vorgänger Item
            j.postUpdate(jVorgaenger.state)                                                                    // und übernimm den Wert
        } else
            j.postUpdate(NULL)                                                                                // ansonsten nimm NULL als Wert0
    ]
    // Durchschnitt berechnen (ohne Gewichtung)
    val gMin  = gTime.members.filter[i|i.name.split("_").get(1) == dOW  && i.state instanceof Number && i.name.split("_").get(3) == "ON"]
    val gMax  = gTime.members.filter[i|i.name.split("_").get(1) == dOW  && i.state instanceof Number && i.name.split("_").get(3) == "OFF"]
    var sMin = 0
    var sMax = 0
    gMin.forEach[i|sMin = sMin + i.state as Number ]
    gMax.forEach[i|sMax = sMax + i.state as Number ]
    iMin = (sMin / gMin.size).intValue
    iMax = (sMax / gMax.size).intValue
    // Timer für aus
    tLightOff?.cancel
    tLightOff = createTimer(now.plusSeconds(iMax),[|
        if(Bewegungsmelder.state != ON)
            light.sendCommand(OFF)
    ])
end

rule "set data"
when
    Bewegungsmelder changed
then
    val iTime = now.getSecond+now.getMinute*60+now.getHour*60*60
    val iiTems = gTime.members.filter[i|i.name.split("_").get(1) == now.getDayOfWeek.toString && i.name.split("_").get(2) == "0"]
    iiTems.forEach[j|
        if(j.name.split("_").get(3) == "ON" && j.state == NULL && newState == ON)
            j.postUpdate(iTime)
        if(j.name.split("_").get(3) == "OFF" && newState == OFF)
            j.postUpdate(iTime)
    ]
    if(newState == ON)
        light.sendCommand(ON)
    if(newState == OFF && (iTime < iMin || iTime > iMax))
        light.sendCommand(OFF)
end
Code ungetestet und vermutlich voller Fehler ;)
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der persistenten Daten / Automatisierung Lichtsteuerung

Beitrag von udo1toni »

Nein, das ist eine reinrassige DSL Rule. Die speicherst Du in einer Datei unterhalb /etc/openhab/rules/, der Dateiname muss auf .rules enden.


Gesendet von iPad mit Tapatalk
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der persistenten Daten / Automatisierung Lichtsteuerung

Beitrag von udo1toni »

Nein, eine Datenbank brauchst Du dazu nicht.
Man könnte etwas ähnliches auch mit Persistence erreichen, aber der Weg geht immer über zwei Items, welche pro Tag Minimum und Maximum festhalten und dann manuell persistieren (z.B. indem der Wert dann um 23:59:59 per Time cron Strategy geschrieben wird. Diese Daten kann man dann entsprechend auslesen, aber auch nur einzeln, was einen ziemlichen Aufwand bedeuten wird. Ich gehe davon aus, dass passender Code auch nicht kürzer werden wird.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Benutzeravatar
udo1toni
Beiträge: 13864
Registriert: 11. Apr 2018 18:05
Answers: 222
Wohnort: Darmstadt

Re: Automatische Formatierung der persistenten Daten / Automatisierung Lichtsteuerung

Beitrag von udo1toni »

Ja, die dürfte in der UI nicht auftauchen.
openHAB4.1.2 stable in einem Debian-Container (bookworm) (Proxmox 8.1.5, LXC), mit openHABian eingerichtet

Antworten