zwei Funkschalter können nicht mit einem Aktor...

Begonnen von oehi86, 06 Dezember 2021, 09:06:55

Vorheriges Thema - Nächstes Thema

oehi86

Guten Morgen,
also vorab schon mal eine kurze Entschuldigung: Ich habe keine Ahnung, wie ich das Problem besser beschreiben soll bzw. wonach ich suchen soll.
Wenn es bereits ein Thema etc. gibt, dann verlinkt es hier gern.

Nun zu meinem Problemchen:
Ich habe zum Beispiel zwei Funktaster und einen Aktor, der eine Lampe ein schaltet.
Schalte ich nun die Lampe an Taster1 an, kann ich sie an Taster2 nicht ausschalten. Da muss ich erst an Taster2 nochmals einschalten um dann ausschalten zu können.
Ich habe in der 99_myUtil über eine Funktion geregelt, welche Taste welchen Aktor schaltet. Aufgerufen wird die Funktion über ein notify.

Ich hoffe ich konnte das schon mal halbwegs erklären und bin für jeden Tipp dankbar.

DANKE und einen schönen Start in die Woche.
Philipp

Pfriemler

... na dann will ich mich mal erbarmen ...
Nein, reicht bei weitem nicht.

Du bist hier im Bereich Homematic, also sollte mindestens ein Gerät zu dieser Hardwarefamilie gehören.

Gib uns bitte mehr Infos:
a) welche Geräte
b) welche Taster
c) poste notifys und die Routine aus der myUtils hier (in Codetags). Dann können wir besser orakeln.

Fürs erste vermute ich: Du hast die Logik hinter Deinen Schaltvorgängen so gebaut, dass sie nur dieses (fehlerhafte) Schaltverhalten zulässt.
Wenn es sich ausnahmslos um Homematic handeln sollte, warum nicht eine Direktverknüpfung für alles?

"Ä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 ..."

martinp876

Ich mutmaßen einmal :
2 taster gepeert mit einem aktor. Das peering funktioniert, da der aktor auf beide reagiert.
Du kannst im aktor einstellen was er machen soll wenn der trigger eintrifft.
Was für dich passed scheint ist toggle.  Immer wenn ein trigger kommt wird gnadenlos umgeschaltet.
Das beschriebene Verhalten deutet auf toggletocnt . Der taster schickt einen trigger Immer mit einem zähler.  Dann schaltet der aktor bei geraden zählern ein und bei ungeraden aus. Oder umgekehrt. Jeder taster zählt selbst.
Du kannst testen ob dies zutrifft indem du 2 mal von taster 1 sendest .

Der mode ist Gold wert um mehrere Aktoren von einem taster aus zu toggle.
Du allerdings solltest das hier nicht nutzen.
Die Einstellung findest du in den Registern das aktors. Also nach getconfig die regtable ansehen und die action bei short prüfen

Pfriemler

Der TE meldet sich leider nicht mehr.

Martin, Deine Überlegungen hatte ich exakt auch, aber er schrieb nun mal:

Zitat von: oehi86 am 06 Dezember 2021, 09:06:55
Ich habe in der 99_myUtil über eine Funktion geregelt, welche Taste welchen Aktor schaltet. Aufgerufen wird die Funktion über ein notify.
somit habe ich ein peering gar nicht erst in Betracht gezogen...
"Ä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 ..."

martinp876


oehi86

Guten Morgen,
erst mal danke, dass ihr überhaupt geantwortet habt. Wenn ihr euch allerdings erbarmen müsst, finde ich es nicht in Ordnung, dann sollte ich vielleicht ein anderes Forum aufsuchen.
Schließlich ist man ja auch hier, wenn es nicht weiter geht und man Probleme hat. Wenn alles laufen würde und ich keine Fragen und Probleme hätte, müsste ich das hier nicht machen...nun ja, das nur als Anmerkung.

Also:
#Flur_wandtaster
sub
wandtaster($)
{
my ($taste) = @_;
{ fhem("set test01 ".$taste) };

if( $taste eq "fl_wandtaster_Btn_01 Short" ) {
fhem ("set FlurAmbiLight on");
}
elsif( $taste eq "fl_wandtaster_Btn_02 Short" ) {
fhem ("set FlurAmbiLight off");
}
elsif( $taste eq "fl_wandtaster_Btn_03 Short" ) {
fhem ("set AmbiLightSofa on");
}
elsif( $taste eq "fl_wandtaster_Btn_04 Short" ) {
fhem ("set AmbiLightSofa off");
}
elsif( $taste eq "fl_wandtaster_Btn_05 Short" ) {
fhem ("set StromLichtBett on");
}
elsif( $taste eq "fl_wandtaster_Btn_06 Short" ) {
fhem ("set StromLichtBett off");
}
}


Taster 1 (fl_wandtaster): HM-PB-6-WM55
Taster 2 (sz_LichtBettFB): HM-RC-4-2
Taster 3 (wz_Fernbedienung): HM-RC-12-B
Aktor: größtenteils z. B. FlurAmbiLight, HM-LC-SW1-PL2
1 x sz_AmbiLight: HM-LC-SW1PBU-FM
1 x D-Link WLAN-Steckdose

1 Beispiel-Notify:
wz_Fernbedienung:wz_Fernbedienung_Btn_.* { fhem (wz_fb(Value('wz_Fernbedienung')));}

Ich habe bewusst auf Peering etc. verzichtet um evtl. schnell und unkompliziert, neue Geräte hinzuzufügen oder zu ändern.

Ich hoffe ich konnte ein paar Infos liefern.

Beta-User

#6
...meine Güte...

Würdest du Unbedingt vor dem ersten Post lesen beachten, bräuchten wir uns nicht über atmosphärisches unterhalten, und würden sofort erkennen, dass hier martinp876 mit seinem (leider nur auf 95% der Fälle passenden) Dauertipp, event-on-change-reading auf ".*" zu stellen, eben manchmal daneben liegt.

Zeigst du mal ein list von einem der "Taster", damit wir meine Hypothese bestätigt bekommen...?

(PS: Es hängt dazu noch uU. davon ab, welche CUL_HM-version du im Einsatz hast...!)
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

Pfriemler

#7
Dass innerhalb von 2 Tagen niemand auf eine Anfrage antwortet, ist für dieses Forum eher ungewöhnlich. Ich selbst komme mal mehrmals am Tag, mal auch eine Woche nicht hier vorbei. Mein flapsiger Spruch war auch eine Mutmaßung bzgl. des Verhaltens anderer: Die gebotenen Erstinformationen waren einfach mal viel zu dürftig, um überhaupt irgendwas raten zu können. Sehr viele andere Foristen hier strafen solche Anfragen regelmäßig mit Missachtung, und das darf man ihnen nicht vorhalten, es ist ihre Freizeit und sie dürfen entscheiden was sie machen und was nicht.
Du hast fast eine Woche gebraucht, um die nötigen Informationen zu liefern. Beschwere Dich dann bitte nie wieder, wenn Dir nicht in Stunden geholfen wird.
Sorry, das musste mal sein. Und jetzt zur Sache.

Ich bin nicht überzeugt, dass ein event-on-change-reading.* an dieser Stelle falsch ist. Das reading "trigger" etwa ändert sich bei jedem Tastendruck oder längerem Tastenhalten ("Short_xx" bzw "Long_xx"). Da muss man dann natürlich auch auf das richtige Reading triggern, Beispiel von mir:
2021-12-16 12:32:58 CUL_HM FB4V2 FB4V2_Btn_04 Short
2021-12-16 12:32:58 CUL_HM FB4V2_Btn_04 Short 1_1 (to 4BattAkt)
2021-12-16 12:32:58 CUL_HM FB4V2_Btn_04 trigger: Short_1
2021-12-16 12:32:58 CUL_HM FB4V2_Btn_04 triggerTo_4BattAkt: Short_1

Du nimmst das erste Event.
Das erscheint bei mir genau dann, wenn ich abwechselnd kurz (short) und lang (long) drücke - dank event-on-change-reading.*
Trigger auf das zweite, hier im Beispiel "FB4V2_Btn_04:trigger: Short_1". Wenn ich den notify-Assistenten im Event-Monitor bemühe, spuckt der mir dafür ein "FB4V2_Btn_03:trigger:.Short_5"  als Regex aus.
Wenn man das auf FB4V2_Btn_..:trigger:.Short_.*" ändert, springt es auf alle Short-Presses meiner Fernbedienung an. Und zwar genau ein Mal je Tastendruck.
Wenn Dir nicht klar ist, was . und * genau in der Regex bedeuten, solltest Du eine kleine Extralektion einlegen.

Warum die Sub jetzt nicht funktioniert, habe ich auf die Kürze nicht herausbekommen.

Last but not least: Diese einfachen Zuordnungen schreien nachgerade danach, mit einer einfachen Direktverknüpfung gelöst zu werden. Die ist genauso schnell gemacht wie die Sub geschrieben, überdauert jeden Crash und Serverausfall und funktioniert zudem auch noch wesentlich latenzärmer als jedes notify. Ich weiß, das ist nicht die Problemlösung die Du hier hören wolltest, aber es ist eine.



"Ä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

#8
Zitat von: Pfriemler am 16 Dezember 2021, 12:48:41
Das reading "trigger" etwa ändert sich bei jedem Tastendruck oder längerem Tastenhalten ("Short_xx" bzw "Long_xx").
Korrekt. Er hört aber nicht auf "trigger" in den Kanälen, sondern auf das (verkappte "state"-Event im) Hauptdevice:
wz_Fernbedienung:wz_Fernbedienung_Btn_.* { fhem (wz_fb(Value('wz_Fernbedienung')));}
Tastet er jetzt an verschiedenen Hauptdevices, passiert eben hin und wieder gar nichts. Aber wir sind wieder am Spekulieren...

(Zu allem anderen, angefangen von "Value" (edit: und dem Generalisieren mit "$NAME"), mag ich schon gar nix schreiben, und "Unverbesserliche" daran zu erinnern, dass es Quatsch ist, Dinge nicht auf der Hardware zu erledigen, wenn die das kann, bringt erfahrungsgemäß gar nichts (ist aber ggf. hilfreich für "stille Mitleser", daher auch von mir zur Klarstellung: Ja klar, mach es mit peering, wo es geht!))
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

Pfriemler

#9
Jein. Ich interpretiere: Es wurde nur eine SUB gezeigt (die "Wandtaster"), das genannte Notify gehört aber zur "wz_Fernbedienung" und ruft die Sub "wz_fb" auf. Wenn das Wandtaster-Notify analog gestrickt ist ("fl_wandtaster:fl_wandtaster_Btn_.*"), müsste es eigentlich brauchbare Strings für die SUB bringen.
Das ist in der genannten Form zwar immerhin eindeutig im Sinne eines einmaligen Aufrufs (hauptdevice:channelevent) - aber eben bei gesetzter eocr.* nur bei unterschiedlichen Tastendrücken... ich wollte ja nur demonstrieren, dass man mit dem richtigen Event auch bei eocr.* immer zum Ziel kommt.
Direktes peering würde hier tatsächlich etwas mehr Arbeit erfordern, sehe ich gerade: die Buttons wären erst mal funktioniell vertauscht (1=off, 2=on). Lässt sich aber korrigieren. Oder man lebt damit.

edit: gerade erst gefunden, war mir neu: peerChan besitzt die Option "reverse" - funktioniert wie "dual", nur werden die beiden Buttons andersherum funktionalisiert (1=on, 2=off).
Das wäre es doch hier ...
"Ä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

...so hatte ich auch gemutmaßt...

Vielleicht nochmal eine Anmerkung zur Gesamtkonstruktion:
Meiner Ansicht nach (die muss man nicht teilen) fährt man mittelfristig am besten, wenn man Code in myUtils-Files möglichst "Device-los" schreibt - was hier in mehrfacher Hinsicht anders gelöst wurde...

Daher hätte ich in dem Fall eher einen längeren Perl-Ausführungsteil direkt im notify geschrieben, damit die Zuordung direkt in FHEMWEB erkennbar bleibt. Ein Beispiel (auch mit state-Events, allerdings HUEDevice) wäre in https://forum.fhem.de/index.php/topic,123886.msg1184606.html#msg1184606 zu finden. In dem Thread ist weiter oben auch eine generalisierte Lösung von martinp876 zu finden, die das auch auf eine interessante Weise löst.

Wenn man aber unbedingt in myUtils gehen will, sollte man m.E. dafür wenigstens eine einzige sub verwenden, und der dann $NAME und $EVENT übergeben. Sinnvollerweise benennt man dann aber seine Taster so, dass die Regex einfach gehalten werden kann, die das NOTIFYDEV ermittelt...

PS: das richtet sich eher an fortgeschrittene Mitleser...
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

oehi86

Guten Abend,
sorry, dass ich für Unruhe gesorgt habe. Ich wollte niemals jemanden angreifen etc und bin froh, dass es das Forum hier gibt.
Also, zum technischen:

Erstmal danke für Eure Beiträge. Ich werde morgen mal testen, die Devices direkt zu peeren. Sie sind ja alle in fhem enthalten.
Ich glaube, so wie ich es jetzt gemacht habe, ist es zwar machbar und funktioniert ja auch in gewisser Weise...Aber es ist halt nicht perfekt.

Ich werde berichten und das hoffentlich zeitnah und nicht erst wieder eine Woche später  8)  ::)