Außenlicht über Bew. Melder mit/ohne Dummy

Begonnen von blitzcom, 30 März 2017, 14:31:16

Vorheriges Thema - Nächstes Thema

blitzcom

Hallo zusammen,
ich hab da einen Knoten und kriege den aufgrund meiner Nichtkenntnisse auch nicht gelöst.

Derzeit habe ich einen PIRA der einen Kanal eines 4-Kanal Switch mit on-for schaltet. An dem Kanal hängt ein LED Strahler. Klappt soweit prima:

define Terasse_Bewegung_an notify Bewegung_Terasse.* { if(!isday()) { fhem("set Terassenlicht on-for-timer 60") } }

Gleichzeitig kann ich den Strahler aber auch mit einer Fernbedienung ein/aus schalten. Klappt auch prima.

So, jetzt sitzen wir im Sommer dort mal für ein Lagerfeuer und ich will vermeiden das der Strahler angeht. Und zusätzlich will ich vermeiden, dass ich den Strahler per Fernbedienung einschalte, der Bewegungsmelder dann aber ein on-for sendet wenn ich ihn auslöse, das würde dann bedeuten, dass der Strahler plötzlich ausgeht.

Hab ich das so halbwegs erklären können und kann mir jemand mit einen Beispiel helfen?

mfg
Mike

Beta-User

Lösungen gibt es sicher mehrere, aber folgender Versuch (untested, bitte genaues coding nach commandref checken!):

- eine sequence anlegen mit triggerpartial auf 1xFB-OFF bzw. 2xFB-OFF
- ein notify für FB ON oder triggerpartial2 (2xFB-OFF), das Dein "Terasse_Bewegung_an" disabled (das kannst Du ja zur Sicherheit per at um 4:00 Uhr wieder anschalten)
- ein notify auf triggerpartial1 (1xFB OFF), das Dein Terasse_Bewegung_an wieder einschaltet (disable 0; die Lampe geht/bleibt ja durch die FB automatisch aus, oder)

Da ich HM nutze und von daher nicht weiß, ob man hier das follow-on-for-timer nutzen sollte: Das ist bekannt?

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

Mit Deinen Lagerfeuerbedingungen habe ich ein Problem.

Soll bei "Lagerfeuer an" geschaltet werden?
Zitatdass der Strahler plötzlich ausgeht.

Oder soll bei "Lagerfeuer an" das Licht nicht angehen?
Dann überlege Dir welcher Zustand  "Lagerfeuer an" ist und frage das im notify mit ab.  if(!isday() AND Lagerfeuer == an)  -> das ist kein Code.
Ggf. brauchst Du fürs Lagerfeuer einen Dummy, da musst du aber überlegen wie Du den schaltest.

Wie Beta-User schreibt ist disable auch eine Lösung, hängt aber davon ab ob Du Feuer und Lich haben willst und verlangt einen Schalter/Sensor.
Auch funktionierende Lösungen kann man hinterfragen.

Beta-User

#3
Hatte das so verstanden, dass der Strahler die Romantik stört und daher der Bewegungsmelder deaktiviert werden soll und die Lampe dauerhaft aus bleibt. Dieses Deaktivieren macht das erste der neuen vorgeschlagenen notifys, nämlich bei doppeltem Tastendruck auf die Fernbedienung (oder alternativ bei "normalem" Anschalten), natürlich kann man auch weitere Auslösebedingungen definieren wie das Schalten eines on/off-Dummys.

Es braucht dann eben noch das andere notify, mit dem die normale BW-Melderfunktion wieder eingeschaltet wird (hier: bei einfachem "Aus", die alternative Auslösung per Dummy ist natürlich ebenso möglich).

Da hier als Eingabemethode die FB bereits genannt war, wäre es naheliegend, genau darüber auch die entsprechende Automatik-Ein/Aus-Schaltung vorzunehmen. Finde ich (halbwegs) intuitiv und man braucht kein Handy oä.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

DeeSPe

Bei mir werden die Lichter in allen Räumen durch BWMs gesteuert.
Nach einem definierten Timeout, nach Schliessen der BWMs, werden dann die Lichter wieder ausgeschaltet.
Für jeden Raum gibt es bei mir einen AutoLight dummy. Nur wenn dieser auch eingeschaltet ist, wird das Licht automatisch eingeschaltet.
Die Lichtautomatik kann ich ganz easy per Siri an- und ausschalten.

Gruß
Dan
MAINTAINER: 22_HOMEMODE, 98_Hyperion, 98_FileLogConvert, 98_serviced

Als kleine Unterstützung für meine Programmierungen könnt ihr mir gerne einen Kaffee spendieren: https://buymeacoff.ee/DeeSPe

Beta-User

#5
Ergänzung noch im Hinblick auf Dan's Szenario:

Wenn ein Dummy eingesetzt wird, würde ich das notify nicht deaktivieren, sondern den Zustand des Dummys im BWM-Notify prüfen.
Die sequence würde ich dann so nutzen, dass statt des (de-)aktivierens des notify dann der Zustand des Dummys geändert wird...

EDIT:
Alternativ könnte man die Info, ob die Automatik jetzt an oder aus ist auch als userattr bei dem BWM-notify ablegen, aber da bin ich erst am experimentieren, wie das geht und wo es Sinn macht. Da die Variable ja nur genau hier Verwendung finden dürfte, wäre das uU. eleganter, da in der Detailansicht des notify direkt zu sehen. Macht wohl wenig Sinn, da ein unnötiger Zwischenschritt erfolgt. Besser dürfte es sein, direkt einen entsprechenden webCmd anzulegen, der das BWM-notify enabled/disabled. Kann aber sein, dass andere Frontends wie FHEMWEB damit Probleme hätten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

Ich würde auch sagen, solange Feuer ist, ist Romantik und deshalb kein Licht.
Für mich ist das hier aber nicht klar formuliert.

Für mich ist auch das setzen eines Status der im notify abgefragt wird eine gute Idee. Das mit dem userreading ist doch die schönste Lösung. Ein per Fernbedienung (notify), aus per Fernbedienung oder at.
Auch funktionierende Lösungen kann man hinterfragen.

Beta-User

Zitat von: rabehd am 30 März 2017, 15:29:16
...Das mit dem userreading ist doch die schönste Lösung.
Achtung! Der Begriff ist belegt (siehe commandref) und vermutlich meinst Du das nicht im dem dort definierten technischen Sinn, oder?
Bin auch reingefallen und denke, userattr ist die richtige Begrifflichkeit (lerne aber immer wieder was neues. Wenn es jemand für korrekturbedürftig hält, bitte her damit!). Und mit einer entsprechenden webCmd-Definition sollte sich auch ein "echtes" reading (wie disabled 0/1) ändern lassen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

rabehd

Ich meine das Attribut ("att")  "userReadings" zum Device.
::)
Auch funktionierende Lösungen kann man hinterfragen.

blitzcom

Guten Morgen zusammen.

Ich denke, die Lösung einen Dummy zu schalten könnte das sein.
Und vielleicht ist das mit dem Lagerfeuer als Beispiel auch eher irreführend. Möglicherweise ist der Hinweis auf triggerpartial oder auch sequenz der richtige Weg.

Bei einfachen Tastendruck auf FB "Terassenlicht ein" = Kanal 1 ein (Licht an)
Bei einfachen Tastendruck auf FB "Terrassenlicht aus" = Kanal 1 aus (Licht aus)
bei dreifachen  Tastendruck auf FB "Terassenlicht ein" = BWM aus (Funktion Bewegungsmelder außer Betrieb)
bei dreifachen  Tastendruck auf FB "Terassenlicht aus" = BWM ein (Funktion Bewegungsmelder in Betrieb)

Im besten Fall quittiert das FHEM mit einem dreimaligen Blinken des Terassenlicht´s. Also quasi wie bei einem Auto, dass die Türen zu sind oder so.

Finde ich recht spannend und ich glaube, dass die Grundlage hier vielleicht auch an anderen Stellen sehr gute Verwendung finden könnte.

mfg
Mike


Beta-User

...das hat mir jetzt keine Ruhe gelassen, habe daher mal ausgetestet, wie das mit dem (de)aktivieren und einem entsprechenden Symbol ohne Dummy ginge. Wichtig sind hier die Attribute.

Ergebnis für Interessierte:
define Automatik_Terrassentuer_Jalousie notify Jalousie_Mitte:leve.*|Terrassentuer_EZ:ope.* IF ( [Jalousie_Mitte:level] < 55) and [Terrassentuer_EZ:state] eq "open") (set Jalousie_Mitte 60)
attr Automatik_Terrassentuer_Jalousie devStateIcon active:fts_shutter_automatic@green:inactive inactive:fts_shutter_automatic@red:active
attr Automatik_Terrassentuer_Jalousie eventMap active:active inactive:inactive
attr Automatik_Terrassentuer_Jalousie group Türen und Fenster
attr Automatik_Terrassentuer_Jalousie icon fts_shutter_automatic
attr Automatik_Terrassentuer_Jalousie room Esszimmer
attr Automatik_Terrassentuer_Jalousie webCmd active:inactive


Ob es diese komische eventMap bräuchte, kann ich nicht genau sagen, hat jedenfalls übergangsweise ohne leider nicht funktioniert. Auf die webCmd könnte man wohl auch verzichten (es sollte die dritte Angabe beim devStateIcon reichen).

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Thyraz

Ich habe bei mir in FHEM einen Dummy namens "Variables" welcher unter anderem auch regelt ob diverese Automatiken aktiv sind oder nicht.
Meine DOIFs fürs Licht sind dann so ausgelegt, dass das Licht über Bewegung nur eingeschaltet wird wenn die jeweilige Automatik an ist.
Für das Ein- / Ausschalten der Automatiken hab ich Buttons in TabletUI.
Kann natürlich aber auch über die Fernbedienung passieren.

Zusätzlich Schalten die DOIFs das Licht nur aus, wenn es über die Automatik (Bewegung) angeschaltet wurde
und seither kein manueller Eingriff mehr passiert ist (Lichtschalter, FTUI, FHEMWEB, oder in deinem Fall Fernbedienung).

DEF fürs Doif (Aus dem Kopf und ungetestet):

## Bewegung erkannt und Lampe aus -> Einschalten und Zeitpunkt merken
([MotionSensor01:"motion: 1"] and [?Lampe:pct] eq 0 and [?Variables:MotionsSensor01_enabled] eq 1)
  (
    set Lampe pct 100,
    setreading Lampe motionTimestamp triggered ## Reading steht immer auf "triggered", es geht nur um das Aktualisieren des Timestamps vom Reading
  )
 
## Erneute Bewegung -> Nichts tun (Dient nur zum Abbrechen der wait-verzögerten Abschaltung im nächsten DOELSEIF Abschnitt
DOELSEIF (([MotionSensor:"reportedState: aktiv"]) and ([?Lampe:dimmerVal] != 0) and [?Variables:MotionsSensor01_enabled] eq 1)

## Ende der Bewegungserkennung und Lampe ist noch an
DOELSEIF ([MotionSensor01:"motion: 0"] and [?Lampe:pct] ne 0 and [?Variables:MotionsSensor01_enabled] eq 1)
  ## Zeitpunkt des Einschaltens durch Motion und aktueller Timestamp des dim-Readings der Lampe praktisch zeitgleich?
  ## -> Scheinbar seither kein manueller Eingriff (z.B. durch Lichtschalter, oder durch FHEM Webinterface, FTUI, etc.)
  (
    IF (ReadingsAge("Lampe","motionTimestamp",999999) - ReadingsAge("Lampe","dim",0)) < 2)
      (set Lampe pct 0) ## Abschaltung 5 Minuten verzögert über wait Attribut
  )

Zusätzlich:

attr do always
attr wait 0;0;300
Fhem und MariaDB auf NUC6i5SYH in Proxmox Container (Ubuntu)
Zwave, Conbee II, Hue, Harmony, Solo4k, LaMetric, Echo, Sonos, Roborock S5, Nuki, Prusa Mini, Doorbird, ...