Hallo,
mir ist aufgefallen, das bei mir der CH1 des Dimmers immer bei chn:on phys:75 stehen bleibt, und nicht wie früher bei 75, mit der Folge das im Webfrontend der Slider nicht mehr aktualisiert wird.
Zu konfiguration: CH2 und 3 werden nicht genutzt und stehen auf off.
Die peers von CH1 sind limitiert auf 75% z.B. R-self02-shOnLevel 75
So das beim einschalten maximal 75% sind. Wenn ich über die Peers einschalte, dann geht er auch tatsächlich auf 75 so das auch der Slider den richtigen Wert anzeigt.
Aber wenn ich im Frontend die LAmpe klicke oder set licht_EG_Wohnzimmer_CH1 on mache, dann bleibt es bei hn:on phys:75 stehen.
Was muss ich tun, das die Slider im Webfrontend wieder laufen bzw. am ende der Status von CH1 wieder 75 anzeigt?
Grüße
ZitatWas muss ich tun, das die Slider im Webfrontend wieder laufen bzw. am ende der Status von CH1 wieder 75 anzeigt?
versuche es mit einem virtuellen button (zb von einer vccu), den du ebenfalls mit dem dimmer peerst. den nutzt du dann zum schalten über fhem.
Hallo Frank,
gut gemeint, aber das kann ja nicht die Lösung sein. Die Standard Funktionalität sollte ja auch ohne irgendwelche zusätzlichen virtuellen Buttons funktionieren. Ich will ja auch nicht zusätzlich neben dem Slider noch einen weiteren Button installieren.
Ich habe auch noch einen HM-LC-DIM1T-FM der hat wohl keine Virtuellen kanäle. Da funktioniert noch alles wie es soll.
Ich verstehe auch nicht warum der HM-LC-Dim1TPBU-FM überhaupt bei einem set on auf 75% geht. Müsste er nicht auf 100% gehen? Die 75% sind ja nur bei den Peers eingestellt.
Außerdem ist mir noch ein Reading aufgefallen das auch relativ neu ist:
levelMissed desired:100
Hat das was damit zu tun?
ZitatIch verstehe auch nicht warum der HM-LC-Dim1TPBU-FM überhaupt bei einem set on auf 75% geht. Müsste er nicht auf 100% gehen? Die 75% sind ja nur bei den Peers eingestellt.
genau, on=100%.
ZitatlevelMissed desired:100
hat meiner nicht. der zeigt auch die gelbe lampe bei on an.
ich schätze, dass dein fhem keinen neuen status bekommt und deshalb das reading ausgibt. sind die rssi ok? was sagt hminfo configcheck/protoevents
Also ich hab jetzt noch mal die Config neu geladen. Jetzt steht da wo im Webfrontent die Lampe steht CMDs Done :( und dort wo der slider normalerweise ist steht nur noch pct.
Keine Ahnung was da los ist.
Bei hm rrsi taucht der garnicht auf, aber empfangsprobleme hab ich ja nicht, das läuft ja alles,auch das getConfig lief sauber durch.
Proto Events:
licht_EG_Esstisch : - | - | - | - # - | - | - | -
Edit:
Ok, in dem Raum war das DEvie, welches die Ganze zeit den Slider hatte. Jetzt geht das nur noch mit dem Channel 1. Aber da hab ich immer noch das Problem, das wenn ich den Channel auf On setze, geht das licht zwar an aber die channels sagen:
CH1: chn:on phys:0
CH2: chn:?? phys:0
CH3: chn:?? phys:0
wir haben 3 virtuelle Kanäle und einen realen.
wir haben nur 3 entities.
der Status jeder entity wird entsprechend dargestellt - und mit dem Realen - also Physikalischen verglichen.
Nach dem setzen des Chan1 auf on erhalten wir einen Unterschied bei allen kanälen: 1 "will" on, ist aber noch off. nach kurzer Zeit sollte Phys auf "on" sein (je nach Rampe) und alles ist gut.
Die beiden virtuellen Kanäle... da ist der Status nicht gelesen. Solltet du einmal nachholen. AutoReadReg ist dein Freund.
diese werden einen Unterschied anzeigen. Sie sind voraussichtlich off, das Licht aber an.
Ob dies korrekt ist, musst du entscheiden. FHEM rechnet nichts aus.
Sollte es dich nerven, setzen die beiden virtuellen Kanäle auf ignore. Und dannsetze in den Status des Chan1 den Wert des physikalischen Readings.
CH1: chn:on phys:0
CH2: chn:?? phys:0
CH3: chn:?? phys:0
Hi,
das hat mir zumindest schon mal ein bisschen weiter geholfen. Allerdings hatte ich autoReadReg extra ausgeschaltet, wegen zu viel Funkverkehr und Overload, insbesondere nach eine fhem shutdown Rerstart.
attr stateFormat phyLevel funktioniert aber nicht wenn autoReadReg = 0, dann kommt nämlich phyLevel nur wenn ich "set device xx pct" mache:
2015-02-14 20:01:31 CUL_HM licht_EG_Esstisch_Sw phyLevel: 45
2015-02-14 20:01:31 CUL_HM licht_EG_Esstisch_Sw level: 45
2015-02-14 20:01:31 CUL_HM licht_EG_Esstisch_Sw pct: 45
wenn ich set device on mache kommt phyLevel gar nicht:
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch_Sw set_on
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch CMDs_done
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch_Sw level: 100
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch_Sw pct: 100
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch_Sw deviceMsg: on (to ccu)
2015-02-14 20:00:24 CUL_HM licht_EG_Esstisch_Sw chn:on phys:32
level und pct kommen aber immer. Mir ist aber nicht klar warum phyLevel nur bei pct gesendet wird?
phyLevel ist also, wenn ich das richtig verstanden habe der wert aller 3 Kanäle falls diese verknüpft sind und Level/pct ist der wert von dem jeweiligen kanal.
Aber was ist dann eigentlich der Unterschied zwischen level und pct?
Und das mit dem ignore habe ich gar nicht verstanden. Auf die channels kann ich keine ignoremachen: "ignore only valid for devices". Und wenn ich das Device auf ignore stelle-, ist das Device nicht mehr im Raum die der channel aber schon noch. Allerdings konnte ich dann keine Aktionen mehr auf den Channel ausführen.
Grüße
Autoreadreg hat unterschiedliche level. Nach einem restart sollte es nicht zu einem overload kommen, da es automatisch verzoegert wird, wenn ein gewisser level an load im io erreicht ist (einstellbar ). Wenn du mehrere reboots in ein h machst stimmt die berechnung natuerlich nicht mehr.
Physlevel wird vom device gemeldet und kommt nicht nur bei pct. Hat nichts direkt damit zu tun. Es kommt mit den device staus. Der wiederum wird manchmal vom device gesendet, manchmal nicht. Autoreadreg holt den status, wenn der zu fehlen scheint, also nicht final ist. Wenn du es abschaltest musst du manualRead machen, also statisrequest wenn du erkennst oder glaubst es fehlt etwas. Notwendig ist es bei allen verzoegerten aktionen wie dimmerrampe, timed on jeglicher art, rolofahrten, treppenhausschaltungen......
Hi,
"Physlevel wird vom device gemeldet und kommt nicht nur bei pct ... Es kommt mit den device staus. "
Also bei mir kommt es immer nur z.B. bei pct, down, up aber nie bei On oder Off. Und wenn Du sagst es kommt mit dem Device-Status dann müsste es doch auch bei on und Off kommen. Und ich frage mich halt warum.
Weil pct und level kommen auch bei set On und set Off.
Und ich weiß leider immer noch nicht wie mir Ignore helfen soll, meintest Du eher hmManualOper, oder?
physLevel wir nur und ausschliesslich aus den empfangenen Daten von Device generiert.
pct ist ein Kommando - das ändert direkt NICHTS an phyLevel.
wenn ich ein statusRequest auf meinen dimmer-channel ansetze wird phyLevel gesetzt - kann ich am Timestamp sehen.
Bei mir kommt es auch bei "on". Ich nutze aber auch autoReadReg.
Bei dir kommt evlt. nur ein ack nach dem Kommando. Das zeigt evtl an, dass der Dimmer das kommando verstanden hat, aktuell auf off ist und nun hoch dimmt.
Es kommt - wie beschrieben - oftmals keine statusmessage. ACK und Status sind ähnlich, nicht identisch.
ZitatUnd wenn Du sagst es kommt mit dem Device-Status dann müsste es doch auch bei on und Off kommen.
nein - so funktionieren die devices nicht. noch einmal: autoReadReg sorgt dafür, so die das Device es nicht freiwillig sendet. Wenn du es abschaltest musst du damit umgehen.
Du scheinst am Punkt zu sein, dass du das ack bekommst, aber nicht die Statusmessage. Diese kannst du dir holen... per kommando, manuell. Oder automatisch per autoreadreg.
mit ignore meinte ich, dass du die beiden virtuellen Kanäle unsichtbar machen kannst, so du willst. Sicher wäre hidden besser.
hmManualOper meine ich mit Sicherheit nicht. Das habe ich auf vielfachen Wunsch eines Einzelnen eingebaut, der im Nachhinein anmerkte, es nicht zu nutzen. Mir schient es ... exterm fragwürdig. ich erwarte von meinen System, dass alle angezeigten Werte aktuell und bestmöglich abgeglichen dargestellt werden. Geht nicht zu 100%, aber was möglich ist, muss gemacht werden. Wer es anders will hat verschiedenen Level, es einzuschränken und abzuschalten.
Your choice.
ZitatautoReadReg sorgt dafür, so die das Device es nicht freiwillig sendet.
Bisher hatte ich das so verstanden das autoReadReg nicht vorhandene register 'anfordert' und nicht das ich damit dem Device mitteile das es etwas nicht mehr freiwillig senden soll. Deshalb hatte ich es auch deaktiviert, weil ich nicht will das das HMLAN übermässig viel sendet.
Was ist denn jetzt richtig?
mit ignore meinte ich, dass du die beiden virtuellen Kanäle unsichtbar machen kannst,Wie schon vorher geschrieben, funktioniert das nicht auf den Channels: "ignore only valid for devices ".
Und wenn ich es auf dem Device mache kann ich das ganze Device nicht mehr verwenden.
Ich hatte mich korrigiert: hidden ist die wahl. Stelle es einfach in einen room, den du nicht siehst... sehen willst. Jedenfalls so lange du es nicht nutzen willst.
Autoreadreg liest automatisch register und stati. Level sind einstellbar. Manchmal sind stati auch in registern zu finden - da wird die unterscheidung schwer.
Die level haben alle einen kurztext dabei... schon nachgesehen? 8statonly oder so.
Es stimmt so, wie ich es gesagt habe. Schon einmal vorsichtig einen blick in die optionen gewagt?
Hi,
das hab ich schon gesehen. Aber bisher lief es halt mit autoReadReg = 0 wunderbar. Ich hab es jetzt mal auf 8_StateOnly gesetzt und hoffe das es nicht zu viel Funkverkehr bei mir gibt. 8_StateOnly ist glaube ich auch erst später hinzugefügt worden.
Zitathidden ist die wahl. Stelle es einfach in einen room, den du nicht siehst
Ok, ich dachte halt Du meinst etwas spezielles. In einem anderen (abstell-)Raum sind die überflüssigen Devices und virtuellen Kanäle bei mir schon immer.
Ich Danke die erst mal für deine Erklärungen, jetzt komme ich zurecht - bis zur nächsten Änderung ;)