Problem mit einem PIR rule für ein Tasmota device mit pulsetime

[Boris099]

Pi4, noch auf 2.5

Was für die Experten.
Ich krieg das nicht sauber auf die Reihe wer kann mir hier etwas auf die Sprünge helfen?

Folgende Situation:
Ein Sonoff Basic mit Tasmota schaltet einen Eltako Stromstossrelais. Also Taster-Schaltung. Damit das funktioniert verwende ich pulsetime 5.
Soweit so gut. Nun habe ich in diesem Flur auch einen ZWave Bewegungsmelder, der diesen Sonoff schaltet.
Das ist aber irgendwie nicht ganz so einfach, denn der Sonoff weiß ja gar nicht in welchem Modus die Lampe gerade ist ...
und so schaltet der BW munter an und dann wieder aus, aber leider ist das nicht so wie gedacht.

Wer hat da eine Idee oder hat das evtl. sogar schon gelöst?

Noch ne andere kleine Sache: Diese Zeitbeschränkung, die ich auskommentiert habe, funktioniert wenn aktiviert nicht.
Was ist denn damit nicht in Ordnung?

Code: Alles auswählen

// Globale Variablen
var Timer DieleUG_Timer = null      	// Timer für autoamtische Abschaltung Licht UG Diele PIR 

// Globale Konstanten
val Integer DieleUG_TimeOut = 600       // Timeout (hier z.B. 10 Minuten oder 600 Sek Vorgabe) unten verwendet

rule "ZPIR_DieleUGMotion changed"
when
    Item zwave_device_6c898019_node7_alarm_motion received update ON  				//ZPIR7 DieleUG
then
//    if (now.getMinuteOfDay >= (8 * 60 + 01) && now.getMinuteOfDay <= (23 * 60 + 59)) {   	//zwischen 8.01h und 23.59h
		DieleUG_Timer?.cancel                                    			//Timer abbrechen, unten Neustart
			K_Diele.sendCommand(ON)

		DieleUG_Timer = createTimer(now.plusSeconds(DieleUG_TimeOut), [|		//DieleUG Licht Timer Start
//		if(K_Diele.state != OFF) 
			K_Diele.sendCommand(ON)
		])
//    }
end

[udo1toni]

Ich will ja nicht nörgeln, aber: Warum machst Du das überhaupt so? Mach bitte das Eltako weg und papp da stattdessen einen Shelly1 hin.
Der Shelly hat hat einen Eingang, der als Tastereingang konfiguriert werden kann.
Der Shelly lässt sich als Treppenlicht parametrieren (also wegen Ausschaltzeit usw.) und lässt sich selbstverständlich über openHAB mit dem PIR koppeln.
openHAB sendet dann nur einen ON-Befehl zum Shelly.
Nebenbei bekommt openHAB auch noch eine aktive Rückmeldung über den Status des Lichts.

Den Eltako mit einem Sonoff anzusteuern, ist hingegen Rumgepfusche, mindestens müsstest Du dann noch einen Sensor verbauen, der den aktuellen Schaltzustand anzeigt.

Protipp: Du kannst den Shelly auch so konfigurieren, dass Tastereingang und Relaisausgang voneinander unabhängig sind. Dann kannst Du über den Umweg openHAB auch Dinge realisieren wie: Langes Drücken -> Licht aus. Eimnal kurz drücken -> Licht für 60 Sekunden an, zweimal kurz drücken -> Licht für 120 Sekunden an, dreimal kurz drücken -> Licht für 10 Minuten an. Oder auch eine Warnung, 20 Sekunden vor Abschalten wechselt der Zustand von ON nach OFF und wieder zurück. Der Phantasie sind da kaum Grenzen gesetzt.

[Boris099]

Ja das ist mir bewusst, nur habe ich beim Schaltschrank 0 WLAN. Ich hatte einen Shelly1 in der Verteilerdose über den Taster, und hatte den Taster auf SW des Shellys, und O als Stromstoß für den Eltako.
Das verrückte ist daß ich genau 2mal schalten bzw. Tasten kann, unser Shelly stürzt ab. Im Shelly Forum schon Rum diskutiert, aber keine Lösung.
Es sieht so aus als wenn beim Tasten irgendwie die Spannung wegbricht.
Egal, also habe den dummen Basic genommen und der tut problemlos den Stromstoss auslösen und stürzt nicht ab, jedoch tut der PIR halt dauernd hin und her schalten.
Ich hatte in einem neuen Beitrag auch gefragt, ob ich im rule evtl. den PIR ausbremsen kann, also z.b. während der Timer läuft, ignoriere weitere Signal vom PIR, oder so

[udo1toni]

Nein, das wird so nicht funktionieren. Das ist - wie gesagt - Rumgemurkse.

Eine Möglichkeit wäre, den Shelly außerhalb des Schaltschranks in ein Kunststoffgehäuse einzubauen. Das ist natürlich nicht besonders schön und fällt auch in die Kategorie Rumgemurkse. Man könnte auch versuchen, die WLAN Antenne des Shelly nach außen zu verlängern, immer noch Gebastel, aber (zmindest aus meiner Sicht) vertretbar.

Hast Du den Shelly auch fest an Phase und Masse angeschlossen? Was ich mir noch vorstellen kann, ist eine Störung durch den Eltako. Der Shelly selbst ist eigentlich ziemlich robust.

Wenn Du den Shelly übrig hast, kannst Du ihn als Sensor missbrauchen. Der Schalteingang kommt auf die Leitung, an der die Leuchten angeschlossen sind, Voraussetzung ist natürlich, dass die Leuchten mit der gleichen Phase gespeist sind wie der Shelly (der braucht so oder so dauerhaft Strom).
Dann bekommst Du eine Rückmeldung über den Schaltzustand des Eltako und kannst das in einer Rule auswerten. Ist aber schon etwas von hinten durch die Brust ins Auge.

[Boris099]

Ich komme nicht so einfach an die Leitung zu den Lampen, das sind mehrere Spots in einer Zwischendecke, ich weiß aber nicht wo der "Zirkus" beginnt

Deshalb wäre mir im Augenblick der simple Weg im rule am liebsten. Gibt es die Möglichkeit die Meldungen des PIR, während der Timer läuft, zu ignorieren? Die rule die ich habe funktioniert ja schon rudimentär.

[udo1toni]

Du kannst einen Timer nutzen, der gestartet wird, wenn das Licht geschaltet wird. Dann prüfst Du nur, ob der Timer läuft, wenn das der Fall ist, ist das Licht an. Aber Du wirst mit absoluter Sicherheit feststellen, dass eine solche Rule zuverlässig nicht richtig funktioniert. openHAB kann letztlich nur vermuten, ob das Licht an oder aus ist, das ist echt Müll.

[Boris099]

Wie mach ich das, das ich die Meldung des PIR ignoriere, solange der Timer läuft? Kann ich mir in Cousine nicht vorstellen?
Ich könnte alternativ in diesem Zwave PIR die ON-Time auf 10 Minuten setzen dann meldet er erst nach der gesetzten Zeit wieder, aber diese Zwave Dinger sind mir suspect, das ist einfach komisches Zeugs

[udo1toni]

Ausgehend von Deiner Rule oben:

Code: Alles auswählen

// Globale Variablen
var Timer DieleUG_Timer = null      	// Timer für autoamtische Abschaltung Licht UG Diele PIR 

// Globale Konstanten
val Integer DieleUG_TimeOut = 600       // Timeout (hier z.B. 10 Minuten oder 600 Sek Vorgabe) unten verwendet

rule "ZPIR_DieleUGMotion changed"
when
    Item zwave_device_6c898019_node7_alarm_motion received update ON  				//ZPIR7 DieleUG
then
    if(now.getMinuteOfDay > 8 * 60) {   	//zwischen 8:01 Uhr und 24:00 Uhr
        if(DieleUG_Timer === null) {
            K_Diele.sendCommand(ON)
            DieleUG_Timer = createTimer(now.plusSeconds(DieleUG_TimeOut), [|		//DieleUG Licht Timer Start
                K_Diele.sendCommand(ON)
                DieleUG_Timer = null
            ])
        }
    }
end

Nur wenn die Timer-Variable null ist, wird der Schaltbefehl gesendet und anschließend der Timer angelegt. Im Timer wird ebenfalls der Befehl gesendet und die Timer-Variable wieder auf null gesetzt.
getMinuteOfDay steht unter openHAB3 nicht mehr zur Verfügung (nur so für den Hinterkopf...)

Wenn sichergestellt ist, dass openHAB jeden Schaltvorgang des Eltako mitbekommt, könntest Du Dir ein Hilfsitem basteln, welches Du bei jedem Schaltvorgang toggelst. Dieses kannst Du dann ebenfalls nutzen, um den Zustand abzufragen. Aber (siehe oben) Du musst Dir im Klaren darüber sein, dass früher oder später der Moment eintritt, wo das Hilfsitem einen falschen Zustand signalisiert, dann musst Du händisch eingreifen (es ist also sinnvoll, dieses Hilfsitem über die UI erreichbar zu haben, damit Du es händisch synchronisieren kannst).

[Boris099]

Na das ist doch was Schönes, wenn man es sieht, sieht es so einfach aus

Also dann gibt es auch keinen Timer-Reset, geht halt erst nach dem abgelaufenen Timer wieder, akzeptabel!
Das mit dem Abschalten geht zum einen im Notfall über den vorhandenen Taster, oder mit dem Basic in der Sitemap.

Es drängt sich mir jedoch noch eine Frage auf: Wie kann ich mit diesem Timer in den neuen Tag hineinreichen,
also nicht 24h sondern 01h nächster Tag? (habe diesbezüglich auch einen separaten Thread geöffnet)
und ich bin noch auf 2.5.12 kann ich diese Zeit-Regel unter OH3 belassen?

Vielen Dank

[udo1toni]

Unter openHAB3 gibt es kein getMinuteOfDay mehr. Es gibt verschiedene Möglichkeiten, damit umzugehen. Du kannst die Differenz zum Tagesbeginn berechnen lassen, aber das erscheint vergleichsweise kompliziert.

Code: Alles auswählen

ZoneId z = ZoneId.of( "America/Montreal" ) ;
ZonedDateTime zdt = ZonedDateTime.now( z ) ;
long minutesIntoTheDay = ChronoUnit.MINUTES.between( 
    zdt.toLocalDate().atStartOfDay( z ) ,
    zdt 
);

(Der Code ist noch nicht an die Rules DSL angepasst)
Da erscheint es einfacher, Stunde und Minute getrennt zu vergleichen:

Code: Alles auswählen

if(now.getHour > 7) // 8:00:00 Uhr bis 24:00:00 Uhr

Für den Zeitraum von 0:00:00 Uhr bis 1:30:00 Uhr (wenn das die Wunschzeit ist)

Code: Alles auswählen

if(now.getHour < 1 || (now.getHour == 1 && now.getMinute < 30)) // 0:00:00 Uhr bis 1:29:59 Uhr

Man muss unterscheiden, ob die Stunde noch nicht erreicht ist, oder die Stunde erreicht, aber die Minute noch nicht erreicht ist.

Es gibt noch eine weitere, recht schlanke Lösung für das Problem, die führt über ein Hilfsitem:

Code: Alles auswählen

rule "Tag an"
when
    Time cron "0 0 8 * * ?" // um 8:00:00 Uhr
then
    TagItem.postUpdate(ON)
end

rule "Tag aus"
when
    Time cron "0 30 1 * * ?" // um 8:00:00 Uhr
then
    TagItem.postUpdate(OFF)
end

Das (Switch-)Item TagItem wird einfach zu den besagten Grenzzeiten umgeschaltet. In der Rule muss dann ledglich geprüft werden, welchen Status das Item gerade hat. Nachteil: Beim Neustart des Systems muss der Sollzustand des Items manuell hergestellt werden (es sei denn, der Neustart erfolgt rechtzeiig, dass kurz nach dem Neustart eine der beiden Rules das Item automatisch schaltet).