Moin,
ich habe vor einigen Tagen FHEM auf meinem Raspberry Pi installiert, dies funktioniert sehr gut soweit.
Meinen ersten Aktor (HM-LC-Sw2PBU-FM) habe ich heute erhalten und zusammen mit dem Homematic Raspberry Modul auch diesen sehr schnell einrichten können.
Nun zu meinem Problem:
In der Standardeinstellung toggelt ein Tastendruck nach oben/nach unten jeweils einen Ausgangskanal. In meinem speziellen Anwendungsfall möchte ich den zweiten Kanal nur zeitgesteuert über FHEM steuern und ein direktes Schalten am Taster verbieten.
Das verbieten klappt auch, ein Tastendruck nach oben toggelt weiterhin meinen ersten Kanal, ein Druck nach unten tut nun nichts mehr.
Nun würde ich gerne bei einem Druck nach unten den ersten Kanal ebenfalls toggeln oder ausschalten. Hierfür habe ich in meinem ersten Kanal peerBulk mit self02 verwendet. Nun taucht in den Readings (expert 1_allReg ist an) auch der komplette Registersatz für self02 auf. Ich nahm an, dass wenn ich jetzt die Einstellungen gleich denen von self01 setze, Kanal 1 über den Taster nach oben und nach unten getoggelt werden müsste.
Leider ist das nicht der Fall :/ jetzt frage ich mich ob ich was falsch gemacht, oder vielleicht etwas vergessen habe. Oder ist das ganze eine (mutwillige) Beschränkung in der Firmware des Aktors?
Vielen Dank im Voraus für Eure Antworten :)
Du musst den self01 mit beiden Aktoren peeren. Allerdings: das habe ich nie versucht. Keine Ahnung ob es klappt.
Aber: was bringt es?Ein interner button sendet keine Trigger. Du wirst es in der zentrale also nicht sehen.
Es gibt für manche Aktoren eine Eigenbau fw welche so etwas mach. Nicht aber eq3 orginal
Moin,
es geht mir nicht darum, dass der Trigger in der Zentrale ankommt, sondern dass ich ohne Verzögerung den Verbraucher an Kanal 1 umschalten kann wenn der Taster in die Richtung gedrückt wird, die eigentlich dem anderen Kanal zugeordnet ist. Ansonsten habe ich eine tote Taste.
Besten Dank für Deine Antwort :)
Probiere dies:
Set aktorchan01 peerBulk <hmid>02
Damit peerst du Taster 02 mit Channel 01.
Mache ein getconfig um zu prüfen, dass es funktioniert hat.
Hallo,
das was du beschrieben hast, würde ich auch gern umsetzen. Kanal 1 mit internen Tasten betätigen - oben Ein, unten AUS. Den zweiten Aktor nur von Fhem bedient. Hattest du eine Lösung gefunden?
Per default peert eq3 den taster 1 mit Aktor1 und den taster 2 mit aktor2.
Ich haben noch nie die internen Peerings geändert. Ich würde keines der peerings entfernen - nur das fehlende addieren:
set <aktor-channel1> peerbulk <hmid02>
himid02 ist die HMId des Device mit 02 am Ende : HMId des Device ist 35F38A dann setze 35F38A02
ein getconfig falls die Register noch nicht da sind. Du solltest am Kanal 1 sehen, dass self01 und self02 gepeert sind.
Hat das bei Euch geklappt?
Ich versuche ebenfalls self01 und self02 intern mit dem selben Aktor zu peeren, um einen toggel auf beiden Kanälen zu realisieren.
Per peerbulk klappt das auch, und wird in den Registern angezeigt. Nur funktionieren tut es nicht, sprich die Kanäle werden nicht zusammen geschaltet.
Die internen Tasten arbeiten immer nur auf den vorgesehenen Aktor. Es ist nicht möglich, ein internes Relais durch Drücken von oben und unten gezielt ein- und auszuschalten.
Zumindest kenne ich das von anderen Geräten so.
Default toggelt ja unten das eine und oben das andere Relais..
Was genau hattest Du vor? Sollten immer beide Relais schalten?
Genau, es sollen beide Relais schalten, egal ob oben oder unten gedrückt per toggle.
Oder beide Relais oben an unten aus.
So was sollte doch intern am Device per Register möglich sein. Oder ist die FW wirklich so limitiert?
1. beide schalten, egal ob oben oder unten: geht nicht.
2. beide schalten, oben an, unten aus: geht nicht (schrieb ich schon)
Ich erinnere mich, sowas an meinem Doppelschalter (wie im Betreff) schon probiert zu haben. Man kann allenfalls die Peers sogar eintragen und sie werden auch angezeigt, aber es schaltet nicht. Die Firmware ist da wirklich limitiert. Leider.
Auch beim Vierfach-Hutschienenaktor ist es nicht möglich, die self01...self04 anderen als den üblichen Kanälen zuzuweisen.
Gegenfrage: Wenn beide Relais schalten sollen, warum nimmst Du nicht einen HM-LC-Sw1PBU-FM? Oder kommt es wirklich darauf an, dass die angeschlossenen Geräte in stromlosen Zustand voneinander getrennt sind? Denn bei diesem Aktor kannst Du das "toggle-egal-wo" problemlos einstellen. Oben an/unten aus ist ja dort default.
Oder benötigst Du die lokale Bedienung nur als Backup und willst aus FHEM sonst getrennt schalten?
Wenn es bspw. darum ginge, den Aktor gezielt (ohne Sicht auf das Ergebnis) ein- oder auszuschalten, so ließe sich das mit unterschiedlichen Reaktionen auf lange und kurze Tastendrücke realisieren. Habe ich bei meinen Terrassenlicht/steckdosen so gemacht: sind die Rolläden unten, sehe ich da nix mehr. Kurz toggelt, lang schaltet immer aus. Kann man beliebig machen.
Ich würde den Schalter gerne wie jeden anderen Schalter bedienen können. Ich kann mich nicht an das toggeln oben/unten getrennt für beide Kanäle gewöhnen. Die Bedienung am Gerät sollte auf jeden Fall wie ein normaler Schalter oben/unten an/aus funktionieren.
An den HM-LC-Sw1PBU-FM habe ich gedacht, da ich aber zwei getrennte Lampen habe, wollte ich es mit dem HM-LC-Sw2PBU-FM lösen. (Außerdem fast gleicher Preis für 2 Kanäle und geringer Verbrauch)
Das die FW so limitiert ist hätte ich nicht gedacht. Ist jetzt schon mein zweites HM Device was nicht wirklich durchdacht ist - ziemlich schwach was EQ3 da fabriziert.
Gibt es den eine Möglichkeit das ganze per FHEM zu realisieren. z.B. per notify, wenn eine Lampe an, dann die andere auch anschalten und umgekehrt?
Das geht per Notify wirklich, aber Du wirst Verzögerungen haben, bis zu 5 Sekunden.
Und eine Haptik "wie jeder Schalter" bekommst du mit einer Wippe mit Mittelstellung eh nicht.
Bis zu 5 Sek. Verzögerung - OK, dass ist keine Lösung!
Haptik ist egal, solange es oben/unten an/aus geht.
Dann muss ich wohl doch das Device wechseln.
Die Verzögerung resultiert aus a) leicht verzögerte Meldung des Schaltzustandes an die Zentrale b) notify und c) Reaktion des anderen Schaltkanals. Das kann auch in 1-2 Sekunden passieren, wenn FHEM gerade nicht beschäftigt ist. 5 Sekunden sind eher die Obergrenze, 2 Sekunden die Regel. Nach meiner Erfahrung.
Also bei mir sind es 3 Sek. Verzögerung.
Ist mir etwas zu träge. Außerdem bekomme ich es nicht hin beide Schalter zu toggeln. Ich lande dann immer in einer Endlosschleife.
Hier mal mein notify (nur für einen Schalter).
define toggleBathroomLights notify (br_Light_Sw_01:.*|br_Light_Sw_02:.*)\
{\
if ($NAME eq "br_Light_Sw_02" & $EVENT eq "on") { \
fhem("set br_Light_Sw_01 on");;\
} elsif ($NAME eq "br_Light_Sw_02" & $EVENT eq "off") {\
fhem("set br_Light_Sw_01 off");;\
} \
}
Gegen die Dauerschleife ist ein wenig Hirnschmalz und ein paar mehr Abfragen nötig ...
Hi,
Meinst du sowas?
defmod nty_Aktor1 notify Aktor[2,3]:on|off set Aktor1:FILTER=STATE!=$EVENT $EVENT
Wenn Aktor 2 oder Aktor 3 geschaltet werden, schaltet Aktor 1 immer mit
Gruß Otto
So ähnlich. Wir hatten das schon mal... find's nicht.
Versuch (nach Ottos Idee):
define toggleBathroomLights notify br_Light_Sw_[01|02]:on|off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT
edit: funktioniert so nicht, siehe ein paar Beiträge weiter unten.
Vorausgesetzt, es gibt nicht mehr als zwei "br_Light_Sw_0x" (mit x=1 oder 2)
Klartext: Wenn einer der beiden Schalter auf on oder off geschaltet wird, dann setze alle Geräte, die mit "br_Light_Sw_0" beginnen und deren Status NICHT dem des Schaltzustandes entsprechen, auf den Schaltzustand.
Das funktioniert, allerdings nur über Webcommands. An der Schaltern selbst klappt das nicht. Nur wenn self02 (br_Light_Sw_02) gedrückt wird, geht br_Light_Sw_01 mit an. Alles andere wird ignoriert. Noch komischer, nach ca. 1 Min. schaltet sich alles wieder aus.
Mit der Regex [01|02] oder [01,02] kommt fhem auch nicht klar, sprich notify reagiert nicht.
Ich habe das so angepasst:
define toggleBathroomLights notify br_Light_Sw_0.*:on|off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT
Was ich nicht ganz verstehe ist der Code: FILTER=STATE!=$EVENT $EVENT
Was passiert hier genau?
Die Anpassung ist ok und sollte auch klappen. Das mit Minute verstehe ich nicht. Hm.
FILTER= definiert einen Filter, den die ausgewählten (...*) Geräte erfüllen müssrn
STATE!= bedeutet deren Status ungleich ist zu ...
$EVENT ist das auslösende Event.
Gesetzt, das Event ist "on", also einer der beiden Schalter wurde (irgendwie) eingeschaltet. Das löst das notify aus, welches nun alle Schalter, die in das Regex passen und nicht auf "on" stehen, auf on setzt. So ähnlich schrieb ich das ja schon.
Jetzt wäre spannend zu erfahren wo der Denkfehler liegt.
Am Kanal 2 ist nich zufällig eine automatische Abschaltung nach einer Minute definiert?
In Ergänzung noch zum nachlesen von devspec (https://commandref.fhem.de/commandref_DE.html#devspec)
Für die Stunden rings ums Fest. :D
Schöne Feiertage
Otto
Nein, ein Timer ist nicht definiert.
Mein Perl Code funktioniert ja auch ohne das die Lampen wieder ausgehen. Es scheint eher an den FHEM Befehlen zu liegen.
hm ... mir kommen da gerade ein paar Ideen, ich glaube ich muss da erst was ausprobieren...
edit: ich denke, mit den Regex kann das so nicht stimmen. Also die Langfassung.
mit Dummys funktioniert das schonmal:
defmod toggleBathroomLights notify br_Light_Sw_0.*:on|br_Light_Sw_0.*:off set br_Light_Sw_0.*:FILTER=STATE!=$EVENT $EVENT
parktisch ohne Verzögerung.
Jetzt grabble ich nochmal einen Aktor heraus und checke das...
edit2: funktioniert hier auch an einem HM-LC-Sw2-FM. Beim Schalten über Webinterface knapp 1 Sekunde, beim Schalter am Gerät 3-4 Sekunden Verzögerung.
Aber stabil, beidseits, völlig egal wo geschalter wird - der geschalteten Kanal folgt der andere brav nach. So wie das soll.
edit3: Und wenn man die richtigen Klammern verwendet, klappt es mit den Alternativen sowohl im Trigger als auch im set:
defmod toggleBathroomLights notify br_Light_Sw_0(1|2):(on|off) set br_Light_Sw_0(1|2):FILTER=STATE!=$EVENT $EVENT
Diese Variante hat den Vorteil, dass man hier die zu überwachenden und die (evtl.) zu schaltenden Aktoren wirklich sauber einzeln deklarieren kann.
Das sieht gut aus. :)
Funktioniert auch direkt am Schalter.
Ich würde sagen das ist ein Eintrag im Wiki wert.
Vielen Dank
P.S.
Mit einem set des Attributs "R-statusInfoMinDly" auf "0.5" für beide Aktoren, ist auch die Verzögerung etwas kürzer. Bei mir zwischen 1-2 Sek. am Gerät.
Zitat von: sherwood am 23 Dezember 2018, 15:46:49
Mit einem set des Attributs "R-statusInfoMinDly" auf "0.5" für beide Aktoren, ist auch die Verzögerung etwas kürzer. Bei mir zwischen 1-2 Sek. am Gerät.
Richtig, denn das beschleunigt die Rückmeldung des lokal betätigten Aktors um 1,5 Sekunden (default ist 2s).
R-statusInfoRandom kann man auch noch verkürzen, dann wird die Verzögerung zudem etwas stabiler.
edit: Ich habe im Beitrag zwei darüber noch die "Kurzfassung" mit korrekten Alternativen (Variante1|Variante2) eingepflegt, die ebenfalls hervorragend funktioniert.
Man muss nur die richtigen Klammern nehmen ...