HM-LC-Dim1TPBU-FM state immer chn:on phys:0 %

Begonnen von oelidoc, 01 Dezember 2013, 12:16:32

Vorheriges Thema - Nächstes Thema

frank

#15
ZitatWie verstecke ich denn die 2 für mich überflüssigen Kanäle?
wie du schon sagst: room hidden, oder sonst wo. löst aber natürlich nicht das problem.

ich glaube dem problem auf der spur zu sein. obwohl ich die 2 virtuellen channel noch nie benutzt habe, sind beide mit den beiden tastern gepeert. anscheinend sind demnach alle 3 channel auf gleiche weise gepeert und eingestellt. die virtuellen zusätzlich sogar noch inactiv gesetzt. vielleicht hilft also ein entpeeren der virtuellen channel.

gruss frank
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

frank

#16
ich habe jetzt mal reset gemacht und dann mit eq3-tool neu angelernt und konfiguriert. nur der untere taster (btn2) schaltet und dimmt den channel1 (realer aktor). die virtuellen channel haben jeweils die verknüpfungsregel inaktiv und zusätzlich sind die internen taster am virtuellen channel auf nicht aktiv gestellt. seltsamerweise natürlich ergibt ein anschliessendes getconfig in fhem, dass wieder beide taster mit allen drei channel gepeert sind. hm...

blöde frage: wie peere ich denn den btn2 mit channel1 über fhem?

update: die taster kann man natürlich nicht peeren. weder extern noch intern. sie sind also fest mit allen channels verbunden. also erscheinen korrekterweise auch in allen channels die peers. man kann ihr verhalten dann über die registereinstellungen der aktoren steuern. also alles ok mit den peers. meine erwartungshaltung war wohl deutlich daneben.  :( 

aber irgendwann gibt es in der asksin-library bestimmt eine dimmerklasse.  :)

gruss frank
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

martinp876

so - habe nachgebessert.

1) 3 virtuelle Kanäle
ist ein längeres Thema, muss man entsprechende Beschreibung suchen. Evtl in Wiki.
Fakt ist, dass man damit coole Sachen anstellen kann. Fakt ist auch, dass sich im Gegensatz zu anderen Schaltern der Wert des Lichts nicht so einfach au seinem Kanal ableiten lässt. Daher die separate Darstellung von Phys und "virt".
Wenn du nur den ersten Kanal nutzt (normalbetrieb) werden die beiden anderen wohl auf off stehen. Wenn du nun Kanal 1 einschaltest, die beidenanderen ignoriert werden wird also 1=on sein, die beiden anderen haben eine Differenz, Phys ist on (ist ja gleich für alle...) aber Chan ist 0(=off).

2) AckStatus
nach dem schalten - insbesondere wenn es (quasi) ohne rampe passiert, also sofort wirksam ist kommt in der ACK ein virtuell=100%, Physikalisch = 0%. Grund ist, dass der Aktor noch nicht geschaltet hat. Eine Statusmeldung kommt leider nicht mehr automatisch, wenn es schnell geht.

3) automatisches Nachfragen
hatte ich eingebaut - und wieder entfernt. Grund sind die BM, die sehr häufig einen trigger an den dimmer senden. Dies erzeugt zu viele messages.
Jetzt habe ich eingebaut, dass nach 5 sec nachgefragt wird, wenn ein Kommando abgesetzt wurde. Damit sind die BM aussen vor. Das sollte passen - hoffen ich.

Gruss Martin

j.mattke

Hallo Martin,

ich habe eben das update gemacht, anschließend getestet - war wie vorher. Dann habe ich den Schalter aus der fhem.cfg auskommentiert und die fhem.cfg abgespeichert.
Anschließend habe ich den Schalter neu angelernt, alle fehlenden Daten mittels save in die fhem.cfg schreiben lassen und nochmal getestet. War leider immer noch das gleiche Verhalten.
Beim Klicken auf das graue Lampensymbol erscheint "chn:on phys:0" und das Licht ist an, nach einem Klick auf statusRequest erscheint das gelbe Lampensymbol.
Beim Klicken auf das gelbe Lampensymbol erscheint dann "chn:off phys:100" und das Licht ist aus, nach statusRequest erscheint das graue Lampensymbol.

Wenn es nicht möglich sein sollte, das frühere Verhalten wieder zu erreichen, dann kann man sich ja auch mit der Lösung aus dem Link, den Frank genannt hatte behelfen:

attr <Dimmer>_Sw stateFormat {if(ReadingsVal($name,"level",0)==0) {"off"} elsif (ReadingsVal($name,"level",0)==100) {"on"} else {ReadingsVal($name,"level",0)}}

Allerdings müssen Neueinsteiger nach dem Anlernen ihres ersten Dimmers erstmal herausfinden, wie das get, es sei denn, man könnte diesen Eintrag beim Anlernen automatisch mit eintragen lassen.

Vielen Dank für deine Mühe.

frank

Zitatich habe eben das update gemacht, anschließend getestet
ein update mit der update-funktion ist erst ab morgens 8 uhr möglich. vorher über svn.

gruss frank
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

j.mattke

#20
Zitatein update mit der update-funktion ist erst ab morgens 8 uhr möglich. vorher über svn.

okay, das wusste ich noch nicht.

Habe eben erneut ein update durchgeführt und getestet: Es funktioniert, wenn auch leider mit 5 Sekunden Verzögerung.

@martinp876: Nochmals danke.
Ich werde wohl die Variante mit dem stateFormat bevorzugen, da diese sofort reagiert. Aber dass der andere Weg auch wieder geht, ist gut zu wissen.

@frank: Auch dir danke ich für die schnellen Hinweise.

Ergänzung: Habe gerade unter elv.de (Suchbegriffe: "Virtuelle HomeMatic-Aktorkanäle") Infos über die virtuellen Kanäle und ihre Anwendungsmöglichkeiten entdeckt. Kurz und knapp: Die virtuellen Kanäle können mit anderen Geräten (z.B. Bewegungsmelder) gepeert werden (Direktverknüpfung) und die virtuellen Kanäle lassen sich zudem untereinander logisch verknüpfen. Sehr interessante Möglichkeiten.

@martinp876: Was ich immer noch nicht verstehe, wenn die virtuellen Kanäle auf "R-logicCombination  inactive" stehen, sollten sie doch garnicht genutzt werden und der Schalter sollte wie bisher funktionieren. Wäre es denn möglich, diese Register abzufragen und nur dann, wenn sie aktiv sind, den verknüpften "state" auszugeben oder ist das zu aufwendig oder gar unmöglich? Oder lag das jetzt ausschließlich daran, dass du den statusRequest wegen der Bewegungsmelder herausgenommen hattest?

martinp876

Die 5sec sind eine wartezeit falls eine info noch automatisch kommt. Das koennte der fall sein, wenn der dimmer in einer langsamen rampe faehrt.
Die register abfragen ist weder schwer noch komliziert. Bisher ist aber keine aktion oder verhalten auf den inhalt von revisgwrn basierend. Moechte ich prinzipiell vermeiden. Register liegen nicht immer vor. Viele haben deutliche probleme mit dem einfachen handling. An ein geordnetes speichern und nachladen mag ich nicht denken. Daher der einfache weg.


Peeren kannst du jeden der virtuellen kanaele mit mehreren peers. Das besondere sind die uueberlagerungsfunktionen. Du kannst einen timer in fhem einrichten, der tagsueber kanal 2 hochschaltet, nachts runter. kanal1 ist der bm.  Beide werden multipliziert. Tags ist die reaktion auf den bm also heller als nachts.
Oder du kombinierst xor mit der klingel - 1sec. Dann blinkt das licht wenn ,jemand an der tuer ist

j.mattke

Dann schlage ich vor, dass wir diesen Thread damit schließen.