Hallo,
ich habe jetzt schon das Forum rauf und runter gesucht, aber leider verstehe ich immer noch nicht, warum mein UP Dimmer beim Einschalten statt state: on immer chn:on phys:0% anzeigt. Erst ein status request und anschließendes refreshen der Seite ergibt die bekannte leuchtende Glühbirne. Beim Ausschalten wird problemlos state off angezeigt.
Hier mal ein list
Internals:
DEF 1AA69C01
EVENTS 87
NAME Dimmer_Kueche
NR 309
STATE chn:on phys:0 %
TYPE CUL_HM
chanNo 01
device Licht_Kueche
Readings:
2013-12-01 11:58:07 CommandAccepted yes
2013-11-30 23:07:02 R-fuseDelay 1 s
2013-11-30 23:07:02 R-logicCombination or
2013-11-30 23:07:02 R-ovrTempLvl 80 C
2013-11-30 23:07:02 R-powerUpAction off
2013-11-30 23:07:02 R-redLvl 40 %
2013-11-30 23:07:02 R-redTempLvl 75 C
2013-11-30 23:07:02 R-statusInfoMinDly 2 s
2013-11-30 23:07:02 R-statusInfoRandom 1 s
2013-11-30 23:07:02 R-transmitTryMax 6
2013-12-01 11:58:07 deviceMsg on (to CUL)
2013-12-01 11:58:07 dim stop:on
2013-12-01 11:58:07 level 100 %
2013-12-01 11:58:07 overheat off
2013-12-01 11:58:07 overload off
2013-12-01 11:58:07 pct 100
2013-11-30 23:36:17 phyLevel 0 %
2013-12-01 11:58:07 reduced off
2013-12-01 11:58:07 state chn:on phys:0 %
2013-12-01 11:58:07 timedOn off
Helper:
peerIDsRaw ,00000000
Role:
chn 1
Shadowreg:
Vdim:
idPhy 1AA69C01
idV2 1AA69C02
idV3 1AA69C03
Attributes:
autoReadReg 4_reqStatus
expert 1
model HM-LC-Dim1TPBU-FM
peerIDs 00000000,
room Kueche
webCmd toggle:on:off:up:down:statusRequest/code]
Vielen Dank im voraus
oelidoc
Hallo oelidoc,
fhem setzt die readings nach neustart gemäss dem "statefile". Dies wird beim runterfahren gespeichert... den präzisen mode habe ich nicht untersucht.
Mit "autoReadReg 4_reqStatus" sollte nach Einschalten automatisch ein statusRequest abgesetzt werden (wenn du es nich tin HMInfo komplett ausgeschaltet hast). Das kommt ein paar sekunden nach hochfahren.
=> wie startet du? restart, rereadCfg,...
=>wird der statusRequest abgesetzt? hast du ein paar Sekunden gewartet? was sagen die "prot..." variablen nach dem starten?
Gruss Martin
Hallo,
ich hoffe ich habe dich richtig verstanden. Das Problem besteht immer - im laufenden Betrieb von FHEM - nicht nur nach einem restart oder rereadcfg. Nach jedem Anschalten des device (egal ob per Taster oder per Funk) bleibt der state bei chn:on phys:0%.
Die "prot..."-Variablen sind glaub ich o.k.
hier das list des device
CUL_MSGCNT 23
CUL_RAWMSG A0EA6A0101AA69CF1080401000000002B
CUL_RSSI -52.5
CUL_TIME 2013-12-01 11:57:35
DEF 1AA69C
EVENTS 23
IODev CUL
LASTInputDev CUL
MSGCNT 23
NAME Licht_Kueche
NR 306
STATE CMDs_done
TYPE CUL_HM
channel_01 Dimmer_Kueche
channel_02 Dimmer_Kueche02
channel_03 Dimmer_Kueche03
lastMsg No:B9 - t:02 s:1AA69C d:F10804 0101C800336C
protLastRcv 2013-12-01 13:48:55
protSnd 163 last_at:2013-12-01 13:48:55
protState CMDs_done
rssi_CUL avg:-51.33 min:-52 max:-50 lst:-51 cnt:92
rssi_at_CUL avg:-51.87 min:-53.5 max:-50.5 lst:-51 cnt:137
Readings:
2013-12-01 11:57:31 PairedTo 0xF10804
2013-12-01 11:57:31 R-intKeyVisib invisib
2013-12-01 11:57:31 R-pairCentral 0xF10804
2013-12-01 11:57:31 RegL_00: 02:01 0A:F1 0B:08 0C:04 15:FF 16:00 00:00
2013-11-24 22:09:01 phyLevel 0 %
2013-12-01 13:48:55 state CMDs_done
Helper:
mId 0068
rxType 1
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf
qReqStat 00
Role:
dev 1
Rssi:
Cul:
avg -51.3369565217391
cnt 92
lst -51
max -50
min -52
At_cul:
avg -51.8795620437956
cnt 137
lst -51
max -50.5
min -53.5
Shadowreg:
Vdim:
idPhy 1AA69C
idV2 1AA69C
idV3 1AA69C01
Attributes:
autoReadReg 4_reqStatus
expert 2_full
firmware 2.2
model HM-LC-Dim1TPBU-FM
peerIDs
room Kueche
serialNr JEQ0203084
subType dimmer
webCmd getConfig
Gruß
oelidoc
Hallo oelidoc,
du hast einen dimmer, dessen physikalischer Kanal durch die 3 virtuellen Kanäle gesteuert wird (Kanal 2 und 3 werden meist nicht genutzt).
Da Kanal 1 aufgesetzt ist (Dimmer_Kueche) sollte das Device keine Daten über das "licht" beinhalten. Das Reading phyLevel ist auch schon eine Woche alt - kommt sicher aus einer Zeit vor dem Update.
Die Infos über das Licht sind also in Dimmer_Kueche,Dimmer_Kueche02,Dimmer_Kueche03 enthalten.
In jedem findest du
level = level dieses Kanals
pct = level dieses Kanals (für den slider, ohne Einheit)
phyLevel = realer Level des Lichts, das was der dimmer aus den 3 virtuellen Kanälen macht.
Der aktuelle Zustand sollte automatisch gelesen werden - mit einer Verzögerung von ~2sec (um die dim-rampe abzuwarten).
=> wenn du ein "list Dimmer_Kueche" machst - ist dann der Wert nach 5sec korrekt? Dann liegt es am web-update.
bei mir wird es automatisch geschrieben - und bis auf "state" upgedated.
Gruss Martin
Hallo Martin,
das war`s:
ZitatDa Kanal 1 aufgesetzt ist (Dimmer_Kueche) sollte das Device keine Daten über das "licht" beinhalten. Das Reading phyLevel ist auch schon eine Woche alt - kommt sicher aus einer Zeit vor dem Update.
Nach einem clear readings des device funktioniert jetzt alles wie gewünscht ;)
Meinst du mit web-update automatisch schreiben
define WEB FHEMWEB 8083 global
attr WEB longpoll 1
?
Nochmals Dankeschön!
Gruß
oelidoc
longpoll ist nicht gesetzt, einen update bekomme ich trotzdem.
der default von longPoll ist "on" - wird demnach bei mir daran liegen.
Ok, alles klar, longpoll war bei mir zwar gesetzt, aber auf 0 :-\
Gruß
oelidoc
Hallo,
ich habe das hier beschrieben Problem in der Web-Oberfläche sowohl in der Standard-Raumansicht, als auch im Floorplan. Die Dimmer bleiben beim Einschalten im state "chn:on phys:0" und beim Ausschalten im state "chn:off phys:100" - erst wenn jeweils statusRequest aufgerufen wird, verschwindet der Schriftzug und das Symbol (Glühlampe) erscheint. Das gleiche Verhalten tritt bei Betätigung von 'toggle' bzw. 'on' und 'off' auf. Bei 'up' und 'down' (x-faches Klicken) funktioniert der Wechsel, wenn auch mit Verzögerung.
Ein "clear readings" brachte bei mir leider nix und longpoll ist bei mir auf 1 gesetzt (habe es auch mit '...longpoll on' versucht). Alle anderen Schalter / Steckdosen schalten auch einwandfrei bzw, deren Anzeigestatus auf der Web-Oberfläche wechselt auch korrekt.
Meine Systemdaten:
Release : 5.5
Branch : DEVELOPMENT
OS : linux
Arch : x86_64-linux-gnu-thread-multi
Perl : v5.18.2
Vielen Dank,
Gruß
HaMuBot
Wie steht autoreadreg ?
Ein statusreq sollte ggf. Automatisch gesendet werden, wenn du es nicht abschaltest.
Welche version hast du ? 5.5 ist quasi alles. Schon einen update gemacht ?
Alle Geräte haben bei mir "autoReadReg 4_reqStatus".
Bei Eingabe von fheminfo zeigt mir die Ausgabe nur Version 5.5 an. Wie kann ich das genauer ausgeben lassen?
Ein Update habe ich vorhin erst gemacht. Gleiches Ergebnis. Wie gesagt, alle anderen Schalter funktionieren einwandfrei.
Lediglich die Dimmer haben diese Statusausgaben. Und das "up 100" und "down 100" funktioniert bei den Dimmern.
ZitatLediglich die Dimmer haben diese Statusausgaben.
kann ich bestätigen mit autoreadreg=5_missing. ebenfalls wurde das hier beschrieben http://forum.fhem.de/index.php/topic,27975.0.html (http://forum.fhem.de/index.php/topic,27975.0.html). ich dachte das wäre ein neues feature. :)
gruss frank
Hallo Frank,
vielen Dank, das hilft mir zumindest momentan erstmal weiter. Ist halt nur die Frage, ob es möglich wäre, die State-Ausgabe wieder auf "on" - "Prozentangabe" - "off" zu ändern. Ich hoffe es, denn früher hat das mal so funktioniert. :-)
Gruß
HaMuBot
die Version bekommst du genau mit "version"
der status nach nach Channel und Physical getrennt ist ein Feature- Wenn beide übereinstimmen bekommst du nur einen wert.
dach Ende des Dimmens sollte dies wieder stimmen.
Zu beachten ist, dass der TBU seine physikalische Helligkeit aus 3 virtuellen dimmern errechnet. Meist nutzen die Leute nur den virtuellen Kanal 1. wenn du also diesen auf 50% setzt, die beiden anderen aber nicht genutzt werden erhältst du
Ch1: 50
Ch2: off/phys:50
Ch3: off/phys:50
das ist ein feature. wenn du die beiden zusätzlichen Kanäle nicht nutzt, verstecke sie.
Bei Kanal 1 sollte alles automatisc gehen - so bei mir jedenfalls - autoReadReg 5 :) (4 reicht hier auch)
Hallo Martin,
Ausgabe version:
# $Id: fhem.pl 6777 2014-10-18 05:25:57Z rudolfkoenig $
# $Id: 10_CUL_HM.pm 6747 2014-10-12 05:36:33Z martinp876 $
# $Id: 01_FHEMWEB.pm 6611 2014-09-24 07:48:32Z rudolfkoenig $
Wenn ich auf das graue Lampensymbol (LS=off) klicke, erscheint folgendes in der Zeile:
LS_Dimm_Schlafzimmer_Sw chn:on phys:0 toggle on off up down statusRequest
Würde die Staus-Ausgabe auf "on" gehen, würde die gelbe Glühlampe angezeigt werden (anstelle von "chn:on phys:0") und man könnte anschließend mit der Maus auch wieder ausschalten. Dies ist hier leider nicht mehr möglich - es sei denn, man verwendet den workaround mit dem stateFormat.
Wie gesagt, ich meine hier nicht das dimmen, sondern die Verwendung des Dimmers als normalen Schalter.
Wenn ich in obigem Zustand "statusRequest" aufrufe, wird die entsprechende Glühlampe wieder angezeigt, aber eben nur dann oder wenn ich die fhem.cfg abspeichere, wonach eine automatische Neuinitialisierung erfolgt.
Wie mir scheint, wird bei mir also am Ende kein statusRequest automatisch ausgeführt, denn der Channel wird hier schon als "on" angzeigt, das Licht ist an, aber der phys. Kanal steht auf 0?
Die Einstellung autoReadReg 4_reqStatus oder autoReadReg 5_reqStatus hat in diesem Fall auch bei mir jeweils das gleiche Resultat - es ändert sich nichts.
In der Tat benutze auch ich nur den virtuellen Channel 1 (..._Sw).
Ich hoffe, ich habe mich einigermassen verständlich ausgedrückt.
Hast du eine Idee, woran das noch liegen kann?
Hallo Martin,
ich glaube, ich bin jetzt dainter gekommen, was du gemeint hast.
Wenn ich den Kanal _Sw einschalte, müssen auch die Kanäle _Sw1_V_01 und _Sw1_V_02 "on" sein, damit im state des Kanals _Sw "on" angezeigt wird. Richtig?
So scheint es jedenfalls zu funktionieren. Ich verstehe allerdings noch nicht, warum das so sein soll, bzw. wofür man das nutzen kann.
Wie verstecke ich denn die 2 für mich überflüssigen Kanäle? Einfach in der fhem.cfg auskommentieren reicht nicht. Verwendung von room hidden reicht ebenfalls nicht. Könntest du mir da bitte noch mal einen Tip geben?
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
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
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
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.
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
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?
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
Dann schlage ich vor, dass wir diesen Thread damit schließen.