Hue steuern per 99_myUtils.pm

Begonnen von Superposchi, 11 September 2021, 17:26:20

Vorheriges Thema - Nächstes Thema

Superposchi

ZitatEs ist zwecklos, mit dem TE diskutieren zu wollen...
Es ist nicht zwecklos mit mir zu diskutieren, es ist nur zwecklos mir seine Vorstellungen aufzwingen zu wollen.
Warum fällt es euch so schwer zu akzeptieren wenn ich andere Vorstellungen oder Strukturen habe? Ich muss meine eigenen Erfahrungen machen.
Vielleicht lande ich am Schluss bei eurer Schreibweise, vielleicht auch nicht. Aber im Augenblick ist es für mich einfach zu unübersichtlich.
Was ist daran so schwer zu akzeptieren? Warum wird gefühlt 20 Posts versucht mich von einer Schreibweise zu überzeugen, die ich im Augenblick für nicht übersichtlich und zu kompliziert halte?

ZitatBzgl. des "hübsch untereinander: Man kann das fhem("..."); _einmal_ "aufklappen" und dann alle Anweisungen hübsch untereinander schreiben - die Formatierung ist in myUtils nämlich weitestgehend egal, (was dir hier aber auch schon (von anderen) versucht wurde mitzuteilen)...
Das wäre eine weitere Alternative, schaue mir gerne an wie übersichtlich das für mich ist

Zitateine automatik mit sleep zu bauen ist selbst wenn man es richtig macht eine krücke. fehler bei erweiterungen oder änderungen am system sind vorprogrammiert.
Kann ich zum jetzigen Zeitpunkt nicht nachvollziehen, bitte erkläre warum du das meinst

Zitatfhem ist event basiert. das sollte man nutzen wenn man schon die in der hardware dafür vorgesehenen dinge wie gruppen nicht nutzen will. man kann mit sleep auch auf ein event warten. d.h. eine sache passiert wenn das even für den abschluss der sache davor kommt. egal wie lange es dauert. damit kann man sich code bauen der z.b. zufällige rampen in die schaltvorgänge baut und erst weiter machen wenn eine lampe wirklich aus ist. ohne das zeiten hard codiert sind.
Ich stehe noch völlig am Anfang was die MyUtils angeht und bin froh, dass ich sowas einfaches hinbekomme. Werde es im Laufe der Jahre sicherlich anpassen und verbessern, aber jetzt für den Moment muss ich sehen, dass ich es auch versteh.

Beta-User

Zitat von: Superposchi am 13 September 2021, 08:20:14
Warum fällt es euch so schwer zu akzeptieren wenn ich andere Vorstellungen oder Strukturen habe?
Andere Vorstellungen oder Strukturen sind an sich nicht das Problem. Es wird nur dann zwecklos, wenn du nicht akzeptierst, dass du damit gegen grundlegende Strukturprinzipien in FHEM oder der Hardware verstößt.

Zitat
Kann ich zum jetzigen Zeitpunkt nicht nachvollziehen, bitte erkläre warum du das meinst
Das verstößt
a) gegen grundlegende Prinzipen in FHEM. Danach sollte die Hauptschleife möglichst ungehindert durchlaufen. Ein "echtes sleep" würde FHEM komplett anhalten, es würden auch keine anderen Aktionen in der Zeit ausgeführt. FHEM-sleep ist daher (leider) dem Namen nach irreführend, eigentlich ist es eine Art "unbenanntes at" (es erzeugt einen InternalTimer, der den folgenden Befehl (!) später ausführt, wenn FHEM beim Durchlaufen der Hauptschleife feststellt, dass es Zeit ist).
(Das ist auch der Grund, warum man unnötige Events vermeiden sollte - die abzuarbeiten, kostet einfach unnötig Performance).
b) Allgemein ist "echtes sleep" (egal, auf welchem System) immer schlecht und nur zu erdulden, wenn man wirklich nicht erwarten kann oder darf, dass das betreffende System irgendwas in der Schlafenszeit macht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

"anwesenheits-simulation"

bedenke, dass die wahrscheinlichkeit gegen null geht, dass ein einbrecher genau in den 30 sekunden dein haus beobachtet, während deine "simulation" die lichter einschaltet.

je nachdem wann er bei dir vorbeischaut, ist sowieso alles an oder aus. dafür reicht dann auch eine structure, gruppe oder scene, falls der einbrecher überhaupt "allergisch" auf licht reagiert. 
um zu sehen, ob wirklich jemand da ist, ist doch klingeln das geeignete mittel.

in der regel sieht man bei wirklicher" anwesenheit auch spätestens nach dem ersten eingeschalteten licht sich bewegende schatten bevor das nächste licht im selben raum angeht.

viele kommen zb auch lieber mittags, da dann viele leute auf arbeit sind.

meiner meinung nach sind solche "ablauf-simulationen" unnötig und ggf sogar kontraproduktiv.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Superposchi

@Beta-User
Dazu kann ich nichts sagen weil ich mich mit der Matere nicht tief genug auskenne.
Ich kann nur sagen, dass ich ganz am Anfang in einem langen Lernprozess bin und für mich keine selbsterklärten Prinzipien existieren, solange der Code nicht gegen die Syntex verstößt und damit nicht mehr funktioniert. Wie gesagt, wer weiß was später ist, aber für den Anfang ist es für mich so einfach nachzuvollziehen und später auch mal wieder aufzugreifen.

@frank
Ich will dir nicht widersprechen, zitiere einfach mal den freundlichen Polizisten um der Ecke:
Diebe beobachten vor dem Einbruch ihre potenziellen Ziele über mehrere Tage und über längere Dauer. Darum vermeiden Sie gleiche oder wiederkehrende Abläufe. Vernehmungen von aufgegriffenen Einbrechern haben dargelegt, dass automatische Lichtschaltungen nicht mehr den Schutz bieten wie zu Beginn der Technik. Da die meisten Einbrüche jedoch in den Abend- oder Nachtstunden stattfinden, empfiehlt die Polizei sich keine festen Gewohnheiten anzueignen, statt dessen sich lieber wechselnde Abläufe und Zeiten anzugewöhnen.

Da wir bei uns im Kreis durchschnittlich 4-6 Einbrüche pro Monat haben gehe ich da lieber auf Nummer sicher und übertreibe es. Egal ob das Kontraproduktiv ist oder nicht.