perl im notify

[Beta-User]

- Generalisierung grundsätzlich immer wo es geht In meinem besonderen Falle macht es aber wenig Sinn
- die nicht lineare Funktion ist schon auf meinem Schirm, da muss aber noch ein Qualifier mit rein, der die Kurve bestimmt (LED vs. alter "Birne" vs. Dimmkurven in der Hardware)
- meine Tradfri FB möchte ich für die Long Klicks (Presses und Released) für die Sonos Steuerung benutzen - Ist aber mit den Latenzen ziemlich doof als Mensch dann zu bedienen

Durchaus verständlich, es war eher als "Bitte, denke mal drüber nach, dazu einen Wiki-Artikel zu verfassen " (und bei der Gelegenheit gleich noch einen generalisierten Code für Utils.pm bereitzustellen!) von mir an dich zu verstehen .

Dass man für die nichtlineare Variante ein oder sogar zwei Parameter braucht, ist klar (hatte ich "optional" geschrieben oder nicht?!?), und für linear ohne Parameterangabe kennen wir jetzt ja alle "//" (ich btw. schon länger ).

Was die FB angeht: Latenzen sind ein sch... Thema, und für Lautstärke ist es ganz besonders dusselig. Für das sind einfach Input-Devices besser, bei denen man (ungefähr) abschätzen kann, was passiert; grade für sowas (dto. Rolläden und Lamellenposition) finde ich die Milight-Hub-Lösung eigentlich ganz elegant, da hat man wenigstens auf der Fernbedienung selbst einen Anhaltspunkt für "wo wer wie was"...

(Witzchen am Rande: Erst war der Speicher auf meinem ESP8266 (Wemos-Clon) defekt, neulich hatte ich WLAN-Trouble, weil mein DD-WRT-Router irgendwie in den Wald gelaufen ist; danach waren sowohl ein Tasmota-Device im AP-Mode wie der neue ESP8266 offline, auf dem das "Sidoh-Gateway" läuft (das lief vorher gefühlt > 18 Monate ohne irgendeinen Mucks zu lassen!). )

[herrmannj]

- die nicht lineare Funktion ist schon auf meinem Schirm, da muss aber noch ein Qualifier mit rein, der die Kurve bestimmt (LED vs. alter "Birne" vs. Dimmkurven in der Hardware)

dat is easy.

Werte zuerst auf den Bereich 0..1 (float). Danach $raus = $rein ** $x ($rein hoch $x)* ($x idR so bei 1.3). Danach $raus ans Gerät anpassen, also *255 für 0..255 oder *100 für 0..100

* 1= linear, 1.3 am Anfang langsamer dann schneller

[RichardCZ]

Generalisierung ist zwar zu begrüßen, aber auch da gibt es dann irgendwo eine Linie zum "Zuviel des Guten".

Ich war auch früher auf dem "as generic as possible" Trip, aber da ist man dann auch schnell in Overengineering-City. (Codebeispiele verfügbar)
Also wie üblich eine feine Balance finden ... oder Pareto.

[Beta-User]

Generalisierung ist zwar zu begrüßen, aber auch da gibt es dann irgendwo eine Linie zum "Zuviel des Guten".

Ich bin da in weiten Teilen bei dir und würde jetzt z.B. auch nicht vorschlagen, das dahingehend zu erweitern, dass man an die Funktion nur das Device und das Event übergibt, aus dem dann ermittelt wird, welches das Zieldevice ist und wie weit die Dimmschritte zu sein haben...
(Ich habe solche Konstruktionen, aber wenige!)

Aber einen generalisierten Dimmer-Code bereitzustellen (bzw. zwei: einen für immer, wenn eine Taste gedrückt wird, einen für "ab Tastendruck" und "bis Taste loslassen"), finde ich eigentlich nicht "overengineered", zumal, wenn der 3. Parameter optional ist... Sondern eben genauso einen "Dienst am user" wie devStateIcon in Color.pm.
(Hmm, bei genauer Betrachtung: "eigentlich" müßte man noch automatisiert ermitteln, ob das Zieldevice in der Lage ist, den Dimmvorgang selbstständig .. *duck und weg*)

Braucht "man" ständig bzw. in ganz vielen Installationen, und die Leute suchen sich einen Wolf, wenn sie sowas z.B. für einen ZWave-Taster finden wollen...

Just my2ct.

[Wuppi68]

Braucht "man" ständig bzw. in ganz vielen Installationen, und die Leute suchen sich einen Wolf, wenn sie sowas z.B. für einen ZWave-Taster finden wollen...

Just my2ct.

wäre es nicht cool, dieses in die setextensions.pm zu packen und dort die Funktionen dim(Up|Down)(Start|Stop) mit den Parametern Speed, ValueRange und dimCurve zu verankern?
dasselbe natürlich dann auch direkt dem den beiden Settern dim(Up|Down)

[Beta-User]

wäre es nicht cool, dieses in die setutils zu packen und dort die Funktionen dim(Up|Down)(Start|Stop) mit den Parametern Speed, ValueRange und dimCurve zu verankern?
dasselbe natürlich dann auch direkt dem den beiden Settern dim(Up|Down)

Falls sich die Frage an mich richtet:
Ich bin da leidenschaftslos, was das wohin und unter welchem Namen angeht. Es macht nur m.E. wenig Sinn, das "jedem user" zur Übernahme in myUtils zu empfehlen, das ist wirklich Standardfunktionalität.... M.E. braucht man "das Perl" auch nicht vor dem user zu verstecken. Wir sollten den usern eher beibringen, wie man "sinnvoll" mit dem Werkzeugkasten umgeht, und dazu gehört eben auch der eine oder andere direkte Perl-Befehl, meine Meinung dazu ist ja auch an anderer Stelle etwas ausführlicher wiederzufinden.

Um es etwas drastisch zu formulieren: Wen das "Perl-Gedöns" wirklich stört, ist bei FHEM falsch (bzw. er sollte seine Haltung überdenken).

just my2ct.

[RichardCZ]

Um es etwas drastisch zu formulieren: Wen das "Perl-Gedöns" wirklich stört, ist bei FHEM falsch (bzw. er sollte seine Haltung überdenken).

Tja - das ist z.B. ein Rad, das OpenHAB neu erfindet. Eine eigene Scripting Language. Da schaue ich auch genüsslich zu.