Dimmer per DOIF in 3 Stati schalten

Begonnen von TommiH, 16 Oktober 2017, 17:35:00

Vorheriges Thema - Nächstes Thema

TommiH

Noch eine Frage:
Wenn ich mit dem ersten Taster eines 6-er Tasters den DeckenlichtDimmer zwischen 3 verschiedenen Stati hin und herschalten möchte, dann hätte ich nun gedacht, dass es so in etwa gehen müsste, aber das klappt nicht. Liege ich da völlig daneben oder ist der Weg der richtige?


define dimmi
DOIF (.*SI_PB6_Btn_01.trigger:.Short.* and [SI_DeckenlichtDi:level] = 80) (set SI_DeckenlichtDi 15)
DOELSEIF ([SI_DeckenlichtDi:level] = 30) (set SI_DeckenlichtDi 80)
DOELSEIF ([SI_DeckenlichtDi:level] = 15) (set SI_DeckenlichtDi 30)
DOELSE (set SI_DeckenlichtDi 15)


LG
Tommi

TommiH

Zitat von: Pfriemler am 16 Oktober 2017, 16:54:54
Prinzipiell bitte: Für eine neue Frage einen neuen Thread!

Ich sage mal: Wenn Du den Button als Bedingung siehst und die aktuellen Level lieber als Abfrage?
Sonst entstehen lustige Nebeneffekte  ;D ...
Außerdem: was soll das .* vor der Bedingung? und im DOIF gehören Eventabfragen doch auch immer in [ ]?

define dimmi
DOIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] = 80) (set SI_DeckenlichtDi 15)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] = 30) (set SI_DeckenlichtDi 80)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] = 15) (set SI_DeckenlichtDi 30)
DOELSE (set SI_DeckenlichtDi 15)


TommiH

Hallo Pfriemler, (habe den Thread mal getrennt)

das funktioniert leider nicht. Es wird im EventMonitor nur

2017-10-16 17:42:51 CUL_HM SI_PB6_Btn_01 trigger: Short_103
2017-10-16 17:42:51 CUL_HM SI_PB6_Btn_01 triggerTo_48754D: Short_103
2017-10-16 17:42:51 CUL_HM SI_PB6_Btn_01 trigger_cnt: 103


angezeigt, aber es passiert nichts - also es geht kein Licht an.

?SI_DeckenlichtDi:level] = 80
Das ist richtig? level ist ja ein Reading von dem Dimmer, aber auch pct oder state, alle stehen auf 80, wenn ich 80 setze. Ist es da egal welches Reading man heranzieht?

Wobei der Fehler in den Readings kommt:
> condition c01: Can't modify non-lvalue subroutine call in scalar assignment, line 1, at EOF

Was auch immer mir die erste Zeile beim Ende des Files sagen möchte.

LG
Tommi


Pfriemler

Ach damned ... ersetze mal alle "=" in den Abfragen durch "==" ...
Du kannst auch pct nehmen, meines Wissens ist das alles egal. state wechselt bei 100 auf on. Level und pct sind eigentlich immer gleich. Dachte ich.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

TommiH

Ah, Abfrage == und Zuweisung =
ok. Yep, damit geht es prima - zumindest nachdem ich das alte notify rausgenommen habe, was bei einem Short -Druck auf den linken oberen Taster direkt auf 80% dimmt - hab mich schon gewundert, warum es sich komisch verhalten hat.

Jetzt muss ich nur noch rausbekommen, wie man den verflixten Dimmer (wie es bei FS20 ging) langsam runterdimmen kann (soweit das mit LEDs geht) und dann bin ich fast mit dem zweiten Kinderzimmer durch ;)
Irgendwie erstaunlich wie rasch sich Kinder an 'Papa, wieso geht das _langsame_ Lichtausmachen nicht mehr' - (Szenario: Kind drückt auf den AUS-Knopf und das Licht dimmt in 30 Sekunden auf 0 runter - da das Kind ja noch quer durchs Zimmer, ins Hochbett klettern und sich mit Kuscheltieren und Decke versorgen muss ;) )

Im schlimmsten Fall müsste ja sowas wie DIM100% - wait 3 - DIM90% - wait 3 - DIM80% - wait 3 - usw. klappen. Mal etwas ausprobieren. Zu Dimmern habe ich erstaunlicher Weise recht wenig Infos gefunden, nichtmal in der Aktor-Hilfe steht, ob man auch runterdimmen kann...

LG
Tommi


Pfriemler

ZitatJetzt muss ich nur noch rausbekommen, wie man den verflixten Dimmer (wie es bei FS20 ging) langsam runterdimmen kann (soweit das mit LEDs geht)
Nichts leichter als das  :) - wenn die LED mitspielen.
Mit dem Btn_01 erreichst Du ja nun das Durchtoggeln durch drei Helligkeitszustände. Das geht mit einem direkten Peering nicht.
Für das Ausschalten kannst Du aber das Peering nutzen, z.B. mit der Taste Btn_02. Dann kannst Du mit shRampOffTime für den betreffenden peer die Rampenzeit von default 0.5 s auf die gewünschten 30s ändern.

Hast Du nicht gepeert und möchtest das über FHEM regeln, dann schicke doch ein set <dimmerchannel> pct 0 30. Die optionalen Paramter ontime (hier 0=unbenutzt) und ramptime (30) geben die Laufzeit der Rampe an. Anderenfalls schaltet der Dimmer ja hart.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

TommiH

Hallo Pfriemler,

irgendwie hakt das DOIF noch etwas. Ich habe es folgendermaßen angepasst:
   

([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] == 96) (set SI_DeckenlichtDi 18)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] == 36) (set SI_DeckenlichtDi 96)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] == 18) (set SI_DeckenlichtDi 36)
DOELSE (set SI_DeckenlichtDi 18)


Aber, das klappt nur manchmal - und ich verstehe überhaupt nicht wieso. Wenn ich den Wert per set an der Eingabezeile erst auf 18 setze, dann kann ich zwischen den 3 Stati durchwechseln.
Wenn ich das nicht mache, dann kommt in der EventAnzeige nur ein


2017-10-18 16:28:20 CUL_HM SI_PB6_Btn_01 trigger: Short_229
2017-10-18 16:28:20 CUL_HM SI_PB6_Btn_01 triggerTo_48754D: Short_229
2017-10-18 16:28:20 CUL_HM SI_PB6_Btn_01 trigger_cnt: 229


und nichts passiert - manchmal aber klappt es schon, warum keine Ahnung.
Sollte das DOIF nicht immer zum Ergebnis 18 kommen, also dem DOELSE, wenn kein Wert 18,96 oder 36 vorgegeben ist? Ich verstehe nicht, wo da das Problem liegen könnte.

Tommi

Pfriemler

#7
hast Du Attribut "do always" gesetzt? Sonst wird jeder Zweig nur einmal ausgeführt, und wenn die letzte Aktion das Setzen auf 18 war weil nichts anderes zutraf, wird bei einer zwischenzeitlichen Änderung des Levels (auch auf 0) nichts passieren.
Das Verständnis, dass ein DOIF seinen Zustand normalerweise nur wechselt und keinen Zweig, auch bei wiederholtem Zutreffen, wiederholt, ist der mit Abstand häufigste Anfängerfehler, der auch bei mir schon zu temporär flacher Stirnfläche führt  ;D
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

Beta-User

Versuch mal den letzten Zweig als DOELSEIF mit Button-Ereignis, aber ohne Statusabfrage.
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

TommiH

Pfriemler,

das wars, die Variante von Beta-User habe ich mal ungefähr in der Form

DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] == 0) (set SI_DeckenlichtDi 18)

versucht, weil ich irgendwie dachte, das DOELSE würde das Problem haben - aber auch damit ging es natürlich nicht.

Das mit dem 'do always' hatte ich irgendwann mal gelesen aber überhaupt nicht mehr auf dem Schirm gehabt - nun habe ich mal alle möglichen Varianten durchprobiert, selbst 'shutdown reload' und jedesmal hat es geklappt ;) - dankeschön!

Zu der Probiererei noch eine kurze Zusatzfrage, die Commandozeile oben in fhem ist ja ganz nett, aber zum ausprobieren wäre eine echte Commandshell mit History evtl. sogar Syntaxergänzung oder mehr Übersicht (der letzten eingegebenen Befehle) nicht schlecht - gibt es da eine Art addon?

Tommi

(Stirnfläche ist langsam wieder normal runzelig ;) - ich dachte schon ich würde gar nichts mehr verstehen - das DOIF selber dachte ich verstanden zu haben...)

Beta-User

Schön, das es jetzt geht, aber zur Klarstellung:
Zitat von: Beta-User am 18 Oktober 2017, 16:56:07
aber ohne Statusabfrage.
wäre wohl etwas weniger "ungefähr" das rausgekommen (vermutlich besser dann ohne "do always"):
DOELSEIF ([SI_PB6_Btn_01:"Short"]) (set SI_DeckenlichtDi 18)

Was passiert eigentlich, wenn jemand einen anderen Wert einstellt als die, auf die genau geprüft wird - über ein set im FHEMWEB oder so?

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

Pfriemler

Da "[SI_PB6_Btn_01:"Short"]" das bisher einzige triggernde Ereignis im ganzen DOIF ist, dürfte ein DOELSEIF ohne weitere als die triggernde Bedingung und ein DOELSE funktional identisch sein. Entscheidend ist aus meiner Sicht das "do always", was diesen letzten wiederholt möglich macht.
ZitatWas passiert eigentlich, wenn jemand einen anderen Wert einstellt als die, auf die genau geprüft wird - über ein set im FHEMWEB oder so?
Jeder Knopfdruck bei einem anderen als den Werten sollte auf 18 dimmen. Gefällt mir auch noch nicht. Ich würde da eher Vergleichsoperatoren einbauen.
([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] >= 96) (set SI_DeckenlichtDi 18)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] >= 36) (set SI_DeckenlichtDi 96)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] >= 18) (set SI_DeckenlichtDi 36)
DOELSE (set SI_DeckenlichtDi 18)

So springt es bei Knopfdruck immer auf die nächsthöhere Stufe als der aktuelle Wert, außer Rücksprung natürlich.

Strenggenommen ist die erste Bedingung sogar überflüsssig, oder?
([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] >= 36) (set SI_DeckenlichtDi 96)
DOELSEIF ([SI_PB6_Btn_01:"Short"] and [?SI_DeckenlichtDi:level] >= 18) (set SI_DeckenlichtDi 36)
DOELSE (set SI_DeckenlichtDi 18)


nun habe ich mal alle möglichen Varianten durchprobiert, selbst 'shutdown reload' und jedesmal hat es geklappt
Nach jeder Redefinition und jedem shutdown/restart ohne "do always" sonst nur genau einmal.
"Änd're nie in fhem.cfg, denn das tut hier allen weh!" *** Wheezy@Raspi(3), HMWLAN+HMUART, CUL868(SlowRF) für FHT+KS+FS20, miniCUL433, Rademacher DuoFern *** "... kaum macht man es richtig, funktioniert es ..."

TommiH

Hai Pfriemler,

stimmt, da nur die 3 Werte existieren können und jeder erste Druck auf die kleinste Stufe (kleiner als 18 springen die LEDs noch nicht an) dimmen soll, müsste es auch mit den 3 Zeilen klappen. Ziel war ein definiertes Springen zum kleinsten Wert (und zwar immer), wenn man den Taster quasi das erste Mal drückt.
Daher passt es schon mit den ==-Werten. Alles bestens.

Tommi