Geräte (zentral) durch Bewegungsmelder (oder ähnliches) steuern

[flummy1978]

Hallöchen,

ich hab mich bisher, durch Codeschnippsel und ähnliches an so viele Dinge wieder zurück erinnert, dass es immer besser klappt. Zusätzlich wurde mir auch damit natürlich entsprechend geholfen. Daher möchte ich mich revanchieren und mein (erstes KLEINES) Projekt vorstellen:

Steuerung von Geräten mit Hilfe eines Bewegungsmelders (Es kann auch Tür -Fensterkontakt sein, oder was auch immer)

Vorab hab ich eine Bitte an die Erfahrenen, diejenigen für die das vielleicht nichts ist: Es ist wie gesagt, meine erste eigene Funktion seit einiger Ewigkeit. Ich würde mich freuen, wenn ihr mir Tipps zur Code / Funktionsvereinfachung oder was auch immer geben könnt. Wenn es am Ende für Euch Schwachsinn ist sowas zu erstellen, ist auch diese Meinung willkommen - gefolgt von dem warum DANKE IM VORAUS DAFÜR

Beschreibung:
# Der Bewegungsmelder schaltet ein Device (in dem Fall das Licht in dem Raum) ein / aus, das im Bewegungsmelder geändert werden kann.
# (De)aktivierung der Auto Funktion in jedem Bewegungssensor möglich und nicht nur zentral für alle durch das Notify
# Schwellwert (in meinem Fall ein Lichtsensor) – kann aber auch alles andere an Nummerischen Werten sein
# Verzögerung nach Abfall des Bewegungsmelders
# Schnelle Anpassbarkeit an andere Devices
Einschränkungen:
# Ein / Aus ist der gleiche Befehl (in meinem Fall Tasmota Geräte die eh alle ein toggle Befehl verstehen). Außerdem schalte ich auch von anderen Orten die Geräte, daher ist hier das toggle (MEINER Meinung nach) am sinnvollsten. (Wäre aber bei Wunsch anpassbar, dann halt mit "ON_cmd" und "OFF_cmd")
# Aktuell wird nur beachtet wenn entsprechendes Reading ON oder OFF ist ( Großschreibung !)

Vorraussetzungen, Einträge, Ergänzungen:
1. Notify das auf entsprechende Events reagiert
2. Userattr im betreffenden Bewegungsmelder (Schalter, Taster, Dummy was auch immer)
3. Unterfunktion in myUtils einfügen

1.  Notify erstellen das auf das entsprechende Event reagieren soll. In meinem Fall ist das:

Code Auswählen Erweitern

PIR_.*move.*:occupancy.* { PIRAction($NAME) }

2. Notwendige Attribute (im Bewegunsmelder!) einsetzen und belegen:

Code Auswählen Erweitern

attr PIR_EG_FL_move_treppe userattr PIR:active,inactive PIR_limit PIR_control_dev PIR_control_cmd PIR_control_read PIR_ontime:0,30,60,90,120,150,180
PIR active
PIR_control_cmd toggle
PIR_control_dev Licht_EG_FL_decke_treppe
PIR_control_read POWER
PIR_limit 80
PIR_ontime 0

Erklärung:

PIR active ______________=> Aktiviert / Deaktiviert die automatische Schaltung
PIR_control_dev _________=> Zu Steuernder Devicename. Gerät auf das sich die Steuerung auswirken soll.
PIR_control_cmd _________=> Befehl zur Umschaltung (toggle)
PIR_control_read ________=> reading das auf ON OFF geprüft wird (GROßSCHREIBUNG !)
PIR_limit _______________=> Grenzwert hier Helligkeit (kann aber auch x-Beliebiger wert sein, der unterschritten sein muss)
PIR_ontime _____________=> Ausschaltverzögerung, nachdem der Bewegungsmelder nicht mehr belegt ist

3. in 99_myUtils einfügen:
Durch die Kommentare ist das meiste gut nachvollziehbar. Aber dennoch hier noch mal die Bitte der Tipps und Empfehlungen von oben...

Code Auswählen Erweitern

####################################
# Aktionen durch Bewegungsmelder   #
####################################

sub PIRAction($){
my $dev = $_[0];
my $occupancy =ReadingsVal($dev, "occupancy", "false");
my $act_illu =ReadingsVal($dev, "illuminance", "100");
my $PIR=AttrVal($dev,'PIR',"inactive");
my $PIR_limit =AttrVal($dev,'PIR_limit',5);
my $PIR_control_dev =AttrVal($dev,'PIR_control_dev',undef);
my $PIR_control_cmd =AttrVal($dev,'PIR_control_cmd',undef);
my $PIR_control_read =AttrVal($dev,'PIR_control_read',undef);
my $onoff =ReadingsVal($PIR_control_dev, $PIR_control_read, 'OFF');
my $PIR_ontime =AttrVal($dev,'PIR_ontime',15);

# Abbrechen wenn PIR inaktiv ist
return undef if ($PIR eq "inactive");
# Abbrechen wenn notwendige Attribute nicht gesetzt sind
return undef if (!$PIR_control_dev);
return undef if (!$PIR_control_cmd);
return undef if (!$PIR_control_read);

# Kontrolle der übergebenen Variablen
#Log(1, "PIR_control_read:$PIR_control_read onoff:$onoff act_illu:$act_illu occupancy:$occupancy<br>dev:$dev PIR:$PIRPIR_limit:$PIR_limit<br>PIR_control_dev:$PIR_control_dev PIR_control_cmd:$PIR_control_cmd PIR_ontime:$PIR_ontime");

# Prüfen ob Gerät vorhanden # Bewegungsmelder an / aus # Helligkeitswert unterschritten
if  (defined($defs{$PIR_control_dev}) && ($occupancy eq "true") && ($act_illu < $PIR_limit))
{   
Log (1, "##### EIN ###### ");
# Prüfen ob Device NICHT ON ist (Großbuchstaben !!)
if ($onoff ne "ON")
{
Log (1, "### SCHALTEN ### ");
# Device steuern mit _control_cmd
fhem ("set $PIR_control_dev $PIR_control_cmd");
}
# Verzögerung löschen falls vorhanden
else { fhem ("cancel $PIR_control_dev quiet");}
}

elsif  (defined($defs{$PIR_control_dev}) && ($occupancy eq "false"))
{
Log (1, "##### AUS ##### ");
# Prüfen ob Device NICHT OFF ist (Großbuchstaben !!)
if ($onoff  ne "OFF")
{
Log (1, "### SCHALTEN ###");
# Verzögerung einsetzen # Device steuern mit _control_cmd
fhem ("sleep $PIR_ontime $PIR_control_dev; set $PIR_control_dev $PIR_control_cmd");
}
}
}

Log (1, "##### xxxxx ###### ")... Einträge können auskommentiert werden, dienen aber der Übersichtlichkeit wann entsprechende Geräte von der Automatik gesetzt wurden


Und nun seid ihr gefragt.

Falls es für Euch interessant ist würde ich mich über eine Rückmeldung freuen. Wenn nicht, auch dann würde ich mich freuen, wenn Ihr mir sagt, warum es unwichtig / unbrauchbar etc ist......

Viele Grüße
Andreas

[Beta-User]

Einschränkungen:
# Aktuell wird nur beachtet wenn entsprechendes Reading ON oder OFF ist ( Großschreibung !)

Vorraussetzungen, Einträge, Ergänzungen:
2. Userattr im betreffenden Bewegungsmelder (Schalter, Taster, Dummy was auch immer)

Hi, ich finde das ein ganz nettes Beispiel, wie man "sowas" generalisieren kann.

Hätte ein paar Anmerkungen:

1. zu ON/OFF
Einfach nach Großschreibung konvertieren:

Code Auswählen Erweitern

my $onoff =uc(ReadingsVal($PIR_control_dev, $PIR_control_read, 'OFF'));

2. zu den Attributen:
Gelegentlich ist es nicht optimal, die Infos in Attributen vorzuhalten, v.a., wenn man sie evtl. automatisiert ändern will  (rote Fragezeichen). Dasselbe kann man auch mit Readings erreichen (zu befüllen mit setreading).
Will man beides ermöglichen, wäre das eine Variante: suche erst im Attribut, wenn das undef ist, greife auf den Reading-Inhalt zu, gibt's den auch nicht, nimm den angegebenen default:

Code Auswählen Erweitern

my $PIR_limit =AttrVal($dev,'PIR_limit',ReadingsVal($dev,'PIR_limit',5));
Hat aber uU. den Nachteil, dass es nicht so transparent ist, wenn unterschiedliche Daten an zwei Stellen zu finden sind.

[flummy1978]

Hallo Herr Tester,
(jemanden einfach nur User zu nennen, find ich doof  ),

zunächst einmal vielen Dank für Deine Rückmeldung. Freut mich, wenn jemand die Idee schon mal nicht als "grundsätzlich" doof abstempelt

Zu deinen Anmerkungen:
1. Super Idee. Danke dafür. Bin bei vielen Perl - Befehlen wirklich raus und alles was die trivialen IF übersteigt, echt aus der Übung. Dieser Tipp ist auf jeden Fall schon mal viel Wert und in Verbindung mit Anmerkung in 2. sorgt er sicher dafür, dass noch seltener Fehler (falsche Zustände) passieren können.

2. Die Idee mit den Readings hatte ich im ersten Moment auch. Im zweiten Moment musste ich lange nachdenken, wie ich das Reading steuern kann, ohne ein weiteres Device anzulegen, WENN ich eh schon einen state Zustand habe, der schon 2 Icons und einen Textteil beinhaltet. An dieser (Anfänger) Frage ist es dann (vorerst) gescheitert, weil:

Die meisten der bisherigen Einstellungen sind ja fest. Das Device ändert sich genauso selten, wie die Befehle es zu steuern. Daher wäre in meinem Fall ein Reading für (in)active und die Schwellwerte sinnvoll. Ich seh das schon kommen, die Ideen (ON / OFF Befehl zu trennen, anpassbare Werte als Readings statt Attribut usw) werden dafür sorgen, dass das Ding wachsen wird. ANDERERSEITS ist es so, dass man damit unheimlich viele Dinge machen kann, die nur 2,3 Befehle haben und automatisiert erfolgen sollen.

Ich glaube ich werde das je nach weiteren Rückmeldungen mehr oder weniger anpassen und zur Verfügung stellen......

Danke bis hierhin für Deine Meinung / Vorschläge.

Viele Grüße
Andreas

[Beta-User]

Hallo Andreas,
du darfst mich gerne mit Beta-User ansprechen , und getestet hatte ich erst mal noch nichts (nur ähnlichen Code "in der Mache").

2. Die Idee mit den Readings hatte ich im ersten Moment auch. Im zweiten Moment musste ich lange nachdenken, wie ich das Reading steuern kann, ohne ein weiteres Device anzulegen, WENN ich eh schon einen state Zustand habe, der schon 2 Icons und einen Textteil beinhaltet. An dieser (Anfänger) Frage ist es dann (vorerst) gescheitert, weil:

Das mit dem "Reading steuern" erschließt sich mir nicht, und auch nicht, was es mit "state" zu tun hat (oder STATE, das du vermutlich meinst). Das zusätzliche Reading muß nicht irgendwo separat angezeigt werden, sondern "darf" einfach da sein.

"Erzeugen" kannst du es mit setreading (hatte ich schon geschrieben), also z.B. so:

Code Auswählen Erweitern

setreading PIR_EG_FL_move_treppe PIR_limit 100
Danach ist es einfach da, kann auf demselben Weg geändert werden und ist auch in der Detailansicht zu sehen.
(Wenn es im STATE landen soll, nutzt du dazu stateFormat, aber das braucht man eher nicht, denke ich).

[flummy1978]

Hey nochmal,
(das mit dem Beta User, war eigentlich ehr Spaß  )

Das mit dem "Reading steuern" erschließt sich mir nicht, und auch nicht, was es mit "state" zu tun hat (oder STATE, das du vermutlich meinst). Das zusätzliche Reading muß nicht irgendwo separat angezeigt werden, sondern "darf" einfach da sein.
......
(Wenn es im STATE landen soll, nutzt du dazu stateFormat, aber das braucht man eher nicht, denke ich).

Ich glaube um das verständlich zu erklären (was in meinem wirren Kopf rumschwirrt *gg*) muss ich ein wenig die Randbedingungen erklären:

Hintergrund um das zu programmieren waren mehrere Räume in denen ich Bewegungsmelder habe, (die sich noch in der Testphase befinden) die dann unter bestimmten Umständen z.B. Anwesenheit (Hund könnte sie auch auslösen) Lichteinfall und Bewegung etwas steuern sollten - In diesem Fall, klar das Treppenlicht. Da ich eben vermeiden wollte für jeden Raum eine eigene Funktion, immer alle Variablen belegen müssen, oder für alles Dummys etc anlegen zu müssen, wollte ich vieles zentral erledigen.
Da manche "SuperTollDurchdachtenAutomatischen Funktionen" sich in den ungünstigsten Fällen als sch.... bewahrheiten (z.B.wenn Besuch da ist und alles nicht so läuft wie es soll), wollte ich eine schnelle Möglichkeit haben die besagten Auto-Funktionen zu deaktiveren, ohne das Gerät ansich deaktivieren zu müssen.
Dafür ist derzeit das Attribut - eigentlich wäre das Reading für active / inactive besser gedacht um eben genau das von Dir erwähnte Fragezeichen zu vermeiden, wenn man nur eine Funktion (de)aktiviert.
Da viele meiner STATE (die meinte ich tatsächlich) so oder ähnlich aussehen:

Code Auswählen Erweitern


attr PIR_EG_FL_move_garderobe stateFormat [$name:occupancy]
[$name:illuminance] lx

# oder
attr OG_SZ_SD_02Bett_LI stateFormat read1:[$name:POWER1]\
([$name:DS18B20_Temperature] °C)

# oder auch ganz wirr  ::) (ok das ist nur ein Readingsproxy)
attr read_OG_SZ_conditions stateFormat <table>\
<tr>\
<td style="width:80px;; font-weight:bold">\
Raum:\
</td>\
<td>\
[$name:Temperature]°C ([$name:Humidity]%)</td>\
</tr>\
<tr>\
<td style="width:80px;; font-weight:bold">\
Licht:\
</td>\
<td>[$name:Illuminance] lx</td>\
</tr>\
</table>



hatte ich im ersten Moment probleme diese um ein Reading zu erweitern, dass auch noch steuerbar werden sollte. Hier muss ich zugeben, dass ich schneller aufgegeben hatte als das normal der Fall wäre. Meine absolute Wunschvorstellung war das STATE

Code Auswählen Erweitern

[$name:occupancy]
[$name:illuminance] lx
das durch ein icon und den Lichtwert angezeigt wird um ein kleines X  und kleinen Haken zu ergänzen, das Anzeigt dass die entsprechende Lichtautomatik aktiviert ist (und hier auch ausschaltbar ist).

Grundsätzlich ist die Idee auch noch nicht ganz gestorben. Ich glaube ich werde mir für manche Dinge

Code Auswählen Erweitern

my $PIR_limit =AttrVal($dev,'PIR_limit',ReadingsVal($dev,'PIR_limit',5));
mal hinter die Ohren schreiben 

Ich hoffe ich konnte den Ursprung / Ansatz damit etwas besser erklären  ....

Viele Grüße
Andreas

[Beta-User]

Hey zurück .

Danke für die Erläuterungen.

Vielleicht noch ein paar Anmerkungen:

Es ist immer wieder spannend, welche unterschiedlichen Varianten (und Anlässe) es gibt, bestimmte Teile der Automatisierung "abschalten" zu können. Da gibt es vermutlich auch kein "richtig" oder "falsch", wichtig scheint mir vor allem zu sein, dass man dazu ein Kozept hat und das dann einigermaßen konsequent durchhält ("Wiederfinden macht Freude...").
Für solche "internen Marker" bieten sich entweder zentrale dummys an (state oder separate Readings darin), das auf (Ziel-) Device-Ebene zu regeln finde ich eher suboptimal.

Und (auch wenn es mein Vorschlag war)

Code Auswählen Erweitern

my $PIR_limit =AttrVal($dev,'PIR_limit',ReadingsVal($dev,'PIR_limit',5));finde ich auch nicht sooo das Gelbe vom Ei, weil im Zweifel intransparent, ich bevorzuge Readings für das Hin- und Herschalten und würde daher auch nur solche Abfragen.

Denkbar sind auch z.B. ReadingsVal-Verschachtelungen vom Einzel-Device her bis hin zu "alle" (wenn man nicht structure nutzt), also (beispielhaft) so:

Code Auswählen Erweitern

my $PIR_limit =ReadingsVal($dev,'PIR_limit',ReadingsVal(AttrVal($dev,"room",undef),'PIR_limit',ReadingsVal("myGlobal_settingsdummy",'PIR_limit',5)));
(Also: Such im Device nach PIR_limit, wenn es da nicht ist, such nach einem Gerät mit dem Raumnamen und dem Inhalt des dortigen Readings PIR_limit, wenn es das nicht gibt, nimm den Wert aus dem Device namens myGlobal_settingsdummy, und erst wenn es das auch nicht gibt, liefere 5 zurück...

Wenn es darum geht, weitere schaltbare Elemente im DeviceOverview angezeigt zu bekommen, kann man entweder Multiline-stateFormat-Anweisungen verwenden (siehe Wiki zu stateFormat, iVm. entspr. devStateIcon-Anweisungen) oder gleich devStateIcon in der Perl-Variante verwenden (Beispiele sind in der file mqtt2.template in lib/AttrTemplate enthalten).
Ist aber für Fortgeschrittene und auch eine Übungssache .

[flummy1978]

Holla,

vielen Dank für Deine ausführliche Antwort. Muss da doch noch mal im einzelnen darauf eingehen, weil ich an mehreren Stellen (für mich) begeisternde Tipps erkenne:

....konsequent durchhält ("Wiederfinden macht Freude...").

Ich habe mittlerweile schon einges für / im / am Haus gebaut und gebastelt, wo ich mich im Nachhinein geärgert habe, dass ich das nicht "mal eben" deaktivieren, abschalten umgehen oder sonst was kann. Daher bau ich das jetzt bei viele Sachen ein die mit Fhem zu tun haben.

Für solche "internen Marker" bieten sich entweder zentrale dummys an (state oder separate Readings darin)

Ich weiss nicht warum, aber bisher hab ich mich immer geweigert 100 Dummys für 10 Aktoren zu bauen. Ich hab keinen blassen Schimmer warum... Was einzige was mir einfällt war vor allem in meiner Anfangszeit (vor wenigen Monaten), dass ich verschiedene Configs gesehen hab die für 1 Aktor 20 Dummys(oder andere devices) hatten. Der eine überwachte nur die Heizung, der andere Steuerte diese, der dritte wiederum steuerte die Heizung wenn Fenster auf waren, der vierte bei Licht der 5 wenn alles da war usw.  Da habe ich mir geschworen, dass meine Config (nach MÖGLICHKEIT) nicht so aussehen wird. In meinem Fall die "wichtigen" Einstellungen global über einen Dummy zu machen ist in der Tat wohl die aller Beste Idee. So kann ich globale Einstellungen darin verbauen, genauso wie die Möglichkeit es ein / aus zu schalten, ohne dafür jedes mal die Attribute der Devices zu ändern.

Denkbar sind auch z.B. ReadingsVal-Verschachtelungen vom Einzel-Device her bis hin zu "alle" (wenn man nicht structure nutzt), also (beispielhaft) so:

Vor allem DANKE für das Beispiel. Anhand diesem hab ich erst den Satz davor verstanden. Die Erklärung dazu hat das Ganze nochmal untermauert. Auch wenn es für Dich wahrscheinlich so aus dem Ärmel geschüttelt kommt, muss man sich die Zeit für sowas dennoch nehmen WOLLEN. Vielen dank dafür *thumbup*

...schaltbare Elemente im DeviceOverview...

Ich habe in der Tat schon mehrmals die Ansicht um mehrere Icons / Anzeigen etc erweitert. Die Beispiele aus Deinem Modul, helfen da natürlich nochmal für die nächsten Schritte, wenn ich mich an sowas wieder rantraue.
Ist schon genial grad denjenigen am Ohr zu haben, dessen Modul man grad zum erbrechen benutzt ( oder derjenige zumindest fleißg dabei mitgewirkt hat - hier bin ich nicht ganz sicher und will nichts falsches sagen ) Ich hab in den letzten Tagen viele Shelly, Sonoff und Zigbee Teile ins System mit eingebunden. Daher hatte ich da oft mit zu tun 

Mein ursprüngliches Anliegen (PIR und Helligkeit Anzeige wie gehabt PLUS kleinen Haken / N/A Symbol bei aktivität) habe ich hinbekommen  (screenshot). Wie gesagt ich wollte eigenlich ganz gerne aus dieser Oberfläche das Reading direkt beschreiben wollen, aber ich denke mal davon nehme ich dank der globalen Dummys abstand.

Vielen Dank und Grüße
Andreas

[DeeSPe]

Als kleine Leseempfehlung kann ich Dir noch den Wikieintrag zu meinem Modul HOMEMODE vorschlagen.
Ganz speziell das Attribut HomeCMDmotion, dort habe ich so etwas umgesetzt was Du vermutlich vor hast.
Ich habe generische Namen für meine Geräte verwendet, diese unterscheiden sich von Raum zu Raum nur durch ein Präfix (ku_,fl_,wz_,sz_....). Alle benötigten Geräte (Lampen) eines Raumes die über den BWM gesteuert werden sollen befinden sich in einer LightScene, die dann entsprechend aufgerufen wird.

Gruß
Dan

[Beta-User]

Danke für die positive Rückmeldung, auch zu "dem anderen Zeug" (das meiste davon hat Rudi gemacht und dabei ziemlich spontan und sehr auf Zuruf/Verdacht - für mich damals noch - irre Sachen eingebaut, die scheinbar viele Leute sehr hilfreich finden ).

Was dummy's angeht, sehe ich auch oft Dinge und Verkettungen, bei denen ich mich frage, was das soll. Insgesamt arbeite ich nach wie vor gerne mit so wenig Devices wie möglich und versuche wenn, dann Infos auch zusammenzufassen und an einem Ort zu verwalten. "Echte Modus-Dummys" habe ich auch wenige (Heizperiode an, ist grade Ferien (der ist aber auch eher historisch, das kann calendar+script zur Erstellung aktueller holiday-Dateien besser)). Ansonsten arbeite ich lieber mit internen Abhängigkeiten (also zB. ist ein WeekdayTimer nur aktiv, wenn ein bestimmter THRESHOLD nicht aktiv ist - beide wirken auf den selben Aktor, der aber im Winter andere Dinge tut als im Sommer...).

Diese Grundhaltung habe ich eigentlich immer noch, aber mit gewissen Durchbrechungen. Beispiel:
Für AutoShuttersControl "brauchte" ich plötzlich ein paar Bewohner, wollte aber nicht direkt in die RESIDENTS-Geschichte eintauchen (das war mir zu kompliziert, um das so neben bei auch noch korrekt einzurichten). Daher gibt es jetzt eben eine Reihe dummy-Devices und structures, die auszugsweise so aussehen:

Code Auswählen Erweitern

define rr_Kind1 dummy
attr rr_Kind1 userattr HT_Devices children children_map structexclude
attr rr_Kind1 HT_Devices Thermostat_Bad_OG_Clima,Thermostat_Kind1_Clima
attr rr_Kind1 event-on-change-reading .*
attr rr_Kind1 group Persons
attr rr_Kind1 icon user_unknown
attr rr_Kind1 readingList state smartphone smartphone_MAC T_msgPeerId T_status T_last
attr rr_Kind1 room Steuerung->Presence
attr rr_Kind1 setList state:home,gotosleep,awoken,absent,asleep smartphone:absent,present smartphone_MAC T_msgPeerId T_status:absent,present T_last
attr rr_Kind1 userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }

Da gibt es dann z.B. ein "FritzBox-notify", das auf WLAN-An- und Abmeldungen reagiert, und über das Reading" "smartphone_MAC" den "richtigen" dummy findet und dessen "smartphone" auf absent oder present stellt (die Zuordnung würde ich heute über getKeyValue machen und auf das erste Reading verzichten).
Da alle relevanten Readings an einem Device hängen, kann ich so relativ leicht Routinen bauen, um den Bewohnerstatus oder sonstige für diesen Bewohner relevante Infos auszulesen, z.B. welche Heizkörper abgesenkt werden sollen, wenn der Bewohner länger weg ist (ein notify, das nach 12h die HK auf manual+18° stellt, wenn nicht zwischendurch wieder anwesend).

Aber grundsätzlich finde ich auch, dass mehr Devices nicht unbedingt zur Übersichtlichkeit beitragen und man daher sparsam damit umgehen sollte (und lieber mehr Zeit auf das Design der Logik verwenden, damit man möglichst gar nichts/sehr wenig manuell schalten muß).


@DeeSPe:
Danke für den ergänzenden Hinweis auf HOMEMODE und das Thema Namensschema.

Sowas kann hilfreich sein, ich selbst habe damals versäumt, zu viel Zeit darauf zu verwenden (vermutlich weil ich noch nicht tief genug in der Materie war). Heute finde ich mein sprechenden Namen nach wie vor ok, muss dann aber das Problem mit dem "Raum" anders lösen. Meine Hardware ist - soweit raumspezifisch - in der Regel nur in einem Raum zu finden, daher funktioniert das wie in dem Code oben. Wer mehr hat, muß ggf. vorab (oder nachträglich für den undef-Fall) das room-Attribut auslesen und dann den ersten Eintrag nutzen (was wieder bedeutet, dass man uU. nicht einfach so in FHEMWEB klicken kann...).

Es bleibt also dabei: alles nicht so einfach, und wenn man vorher wüßte (oder auch nur ahnen könnte), was man hinterher evtl. mal gelernt hat, wäre manches einfacher .

@Andreas:
Viel Freude jedenfalls beim weiteren Lernen.

[flummy1978]

Bäääähhh ich hatte eine soooooo lange und ausführliche Antwort und kein Plan warum das weg ist 

Also nochmal in (kürzerer) neuer Fassung:

@DeeSPee: Das Modul liegt schon auf der Leseliste. Ich bin grad dabei dank der Unifi Geräte ein ziemlich genaues presence reading zu erhalten und kann dadurch dieses zuverlässig in die Steuerung mit einsetzen. Da ich gesehen hab dass bei dem Homemode Modul eben viele Sachen schon direkt abgenommen werden, werde ich sie mir denke ich mal in Ruhe anschauen und umsetzen.

Ich habe generische Namen für meine Geräte verwendet, diese unterscheiden sich von Raum zu Raum nur durch ein Präfix (ku_,fl_,wz_,sz_....).

Entgegen meiner ursprünglichen Vorhaben (zuerst war es Klartext, später wilde abkürzungen mit Punkten) habe ich mir jetzt eine Liste erstellt, die ich dank einer Excel Liste relativ gleich halten kann und mir bei Bedarf entsprechende Devices raussuchen kann. Wenn ich in die einzelnen Spalten von links nach rechts
PIR    EG    FL    move    treppe (xxx xxxx xxxx xxx)
eingebe, wird daraus in der Excel ein PIR_EG_FL_move_treppe inkl Link auf das entpsrechende Device in Fhem, so dass ich das immerwieder aktuell halten kann und es mir auch nicht schwer fällt entsprechende Geräte anzulegen und wieder zu finden.

Das führt dazu, dass man bsw mit einem Befehlt alá "set Licht_.* on" dafür sorgt, dass der Stromzähler als Ventilator funktioniert, aber dann kann mit "set Rollo_.* closed" auch dafür sorgen, dass man einen Grund für die Partybeleuchtung hat OHNE jedes Gerät / Raum / Geschoss einzeln kontrollieren zu müssen. Ich habe bereits in einigen Bereichen einen großen Vorteil darin gefunden, weil man natürlich mit Abends "set Licht_EG_.* off" dafür sorgen kann, dass das Licht im EG komplett ausgemacht wird, wenn bestimmte Vorraussetzungen zutreffen 

@Beta-User:
Auch hier finde ich es immerwieder interessant (und auch gut) wenn erfahrene Benutzer (Programmierer) sich die Mühe machen auf sowas wie hier auch etwas detailierter einzugehen. Warum Du etwas so gemacht hast und es jetzt anders machen würdest, bringt mir persönlich deutlich mehr als eine Vorgabe wie ich etwas programmieren soll (auch wenn ich zugeben muss, dass ich gern zu den Copy&Paste Programmierern gehöre (doofe Angewohnheit).

Ich fühl mich jetzt nochmal mehr bestätigt, darin jetzt am Anfang einen vergleichbar großen Aufwand zu betreiben, (z.B. die oben beschriebene Namensgebung, oder auch dieses "Möchtegernmodul" dass einfache kleinigkeiten übernimmt) die einzeln Dinge zu realisieren wären. Ich bin mir aber ich mir sicher bin dass ich es in Zukunft noch deutlich öfter benutzen werde und dann dankbar bin über die "Ordnung und zentralisierbarkeit von vielen Geräten.
Wenn nicht? Tja dann hab ich wohl mal wieder ein wenig programmieren gelernt und mich an meine jüngeren Jahre erinnert 

Viele Güße
Andreas