Wertigkeit von Befehlen vergeben

Begonnen von tfriedrich85, 29 Januar 2018, 18:07:00

Vorheriges Thema - Nächstes Thema

tfriedrich85

Hallo zusammen,

ich habe folgende Frage:

Ausgangslage:

Sämtliche Lampen werden über Bewegungsmelder gesteuert und gehen automatisch an/aus
Je nach Tageszeit in verschiedenen Helligkeiten
In jedem Raum gibt es einen Taster für manuelle Befehle

Situation:
Ich möchte spät Abends z.B. einen Koffer packen und brauche dafür 100% Helligkeit

Wenn ich jetzt den angesprochenen Taster betätige und dem Tastendruck zuweise das er das Licht in dem Raum in voller Helligkeit anzuschalten funktioniert das nur solange, bis ich das nächste mal vom Bewegungsmelder erfasst werde. Weil er dann Fhem mitteilt "es ist nach 24 mach das Licht nur noch 20% an" - Kann ich solche Ausnahmen elegant umsetzen?

Ich will also sagen manuelle Befehle haben eine höhere Wertigkeit als automatisierte Befehle.

Ich stelle mir das so vor, das Fhem sich den neuen Helligkeitswert dann speichert und beispielsweise für 1 Stunde behält. Kennt jemand dafür eine charmante Lösung?

fischit

Ich glaube erstmal, dass mehrere Beiträge zu einem Thema nicht nötig sind.

Denn auch hier ist die Antwort DOF, notify etc.

FranzB94

Hi tfriedrich85,
Zitat von: tfriedrich85 am 29 Januar 2018, 18:07:00
Situation:
Ich möchte spät Abends z.B. einen Koffer packen 

...dann Fhem mitteilt "es ist nach 24 mach das Licht nur noch 20% an" - Kann ich solche Ausnahmen elegant umsetzen?


Ob FHEM mit einer solchen Logik klarkommt ist zu bezweifeln.

Gruß Franz

fischit

#3
Zitat von: FranzB94 am 29 Januar 2018, 19:22:25
Ob FHEM mit einer solchen Logik klarkommt ist zu bezweifeln.

Hi,

wieso denn nicht?
Ausgangssituation: Licht geht nur an wenn über den BWM Bewegung erkannt wird und wahrscheinlich nach X Minuten wieder an.

Man kann doch grob sowas machen:
WENN Lichtschalter "ein" DANN Bewegungsmelder "aus" und Licht an.
Wenn Lichtschalter "aus" DANN Bewegungsmelder "ein" und Licht aus.

Oder das ganze mit On/off-for-time oder mit einem dann erzeugten AT, das gewisse Dinge macht.

Ich kenne nicht die eingesetzte Hardware aber grundsätzlich ginge sowas schon.
Ich finde vorallem FHEM eigentlich perfekt dafür  8) Darum geht es doch bei Automatisierung.

Edit: oder ich verstehe die Ironie nicht  :o

igami

Ich habe mir mal ein cmdalias gebaut um Prioritäten mit zu vergeben. Die gehen dabei von 0 an. Nur wenn der neue Befehl eine gleiche oder höhere Priorität hat wird er ausgeführt.

Für die Raw definition:

defmod priorityset cmdalias priorityset .+\s+(reset|\d+)(\s+.+)? AS {\
  my ($name, $priority, $cmd) = split(/[\s]+/, $EVENT, 3);;\
  \
  return unless(IsDevice($name) && $priority);;\
  \
  if($priority eq "reset"){\
    fhem("set $name $cmd") if($cmd);;\
    fhem("setreading $name priorityset 0");;\
  }\
  else{\
    return unless($cmd);;\
    \
    fhem("set $name $cmd;; setreading $name priorityset $priority;;") \
      if(int($priority) >= ReadingsNum($name, "priorityset", 0));; \
  }\
}
attr priorityset group priorityset
attr priorityset icon control_return
attr priorityset room helper


Beispiel:

priorityset test 3 on      => test geht an, priority steht auf 3
priorityset test 1 off     => nichts passiert
priorityset test reset off => test geht aus, priority geht auf 0

Ein normales set nimmt darauf natürlich keine Rücksicht. Momentan habe ich das auch nicht aktiv im Einsatz, mir fehlte noch die Zeit zum implementieren. Aber ich würde mich freuen, wenn es was für dich ist und du es testen kannst :)
Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

CoolTux

Eine einfache Umsetzung wäre mit FILTER zu arbeiten. Ausgehend davon das dein Schalter immer 100% macht kannst du die 100% beim set Befehl vom BWM abfragen und nicht schalten wenn 100%
Sollte allerdings in der Dämmerung für den BWM set 100% eingestellt sein solltest Du 99% nehmen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

tfriedrich85

Hallo zusammen,

die Diskussion geht in die richtige Richtung ich hab auch schon über so eine Nummern Prio-Vergabe nachgedacht. Ich schau mir igami's Code mal an momentan ist mir da noch nicht alles klar...

@CoolTux: Dazu muss ich mir mal anschauen wie das mit den Filtern läuft.

Vielen Dank für die Hinweise!

CoolTux

set Schalter1:FILTER=level!=100 level 20
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

igami

Pi3 mit fhem.cfg + DbLog/logProxy
Komm vorbei zum FHEM Treffen im Kreis Gütersloh! Das nächste Mal im April 2020.

MAINTAINER: archetype, LuftdatenInfo, monitoring, msgDialog, Nmap, powerMap
ToDo: AVScene, FluxLED

Reinerlein

Hallo tfriedrich85,

versuch doch einfach alle Bedingungen in ein DOIF zu verpacken:

([Schalter] == 0 and [PIR:motionHold] eq "on" and [20:00-22:00]) (
  ## Bewegung frühabends Licht an
) DOELSEIF ([Schalter] == 0 and [PIR:motionHold] eq "on" and [22:00-0:00]) (
  ## Bewegung spätabends Licht an
) DOELSEIF ([Schalter] == 0 and [PIR:motionHold] eq "on" and [0:00-6:00]) (
  ## Bewegung nachts Licht an
) DOELSEIF ([Schalter] == 0 and [PIR:motionHold] eq "on") (
  ## Bewegung sonst Licht an
) DOELSEIF ([Schalter] == 1) (
  ## Schalter Licht an
) DOELSE (
  ## Alles aus
)

An dem DOIF muss noch das Attribut "checkall" auf "all" gesetzt sein.
Bedenke beim Erweitern der Else-Fälle, dass die Reihenfolge wichtig ist. Die speziellste Bedingung zuerst, da von oben nach unten geprüft wird, und der erste passende Zustand gesetzt wird...

Das Reading "motionHold" an meinen PIRs ist ein userReading, welches nach einer Bewegung für 1,5 Minuten auf "on" steht, und dann auf "off" wechselt.

Das macht es mir viel einfacher solche DOIFs wie oben zu schreiben, da ich sonst mit dem wait-Attribut arbeiten müsste, und das geht im obigen Kontextbeispiel nicht (ich bräuchte ein wait, welches festlegt, wielange ich in einem Zustand mindestens bleibe, und nicht wie lange ein Wechsel in einen neuen Zustand verzögert wird, also sozusagen ein "leavewait")...

Hier mal das userReading am PIR-Device:

motionHold:motion..on.* {
  CommandDefMod(undef, $name."_MotionHoldTimer at +00:01:30 setreading $name motionHold off");
  return 'on';
}


Vielleicht ist das für dich ja auch eine Idee...

Grüße
Reinerlein

willib

Noch eine Idee:
Wenn du mit notify und watchdog arbeitest kannst du ans ende des notify set deinnotify inactive anhängen. damit wird das notify nach einmaliger Ausführung inaktiv. Den set activ Befehl packst du in deinen watchdog, der dann das notify wieder aktiviert und das Licht ausschaltet nachdem keine Bewegung mehr erkannt wurde. Somit kannst du, solange du dich im Raum aufhälst das Licht manuell schalten wie du willst und nach Verlassen des Raums läuft deine gewohnte Automatik wieder.
So mache ich das mit meiner Musik auf dem Gästeklo ;) Funktioniert gut.
FHEM in Debian 10 LXC unter Proxmox auf NUC, Homematic, Hue, Intertechno, Jeelink, RFXTRX, Harmony Hub, VU+ Uno 4K, Sonos, AMAD