Seither, jeder Empfanger
(siehe Anhang / see attachement)
Jetzt nur noch der Cul
(siehe Anhang / see attachement)
da gefällt mir die alte Variante besser
aufgefallen ist mir noch, das alle attr devInfo jetzt einen Punkt davor haben "attr .devInfo"
Hallo Hary,
devinfo habe ich verschoben um es 'unsichtbar' zu machen. Es ist ein Parameter der nur (bestenfalls) experten etwas sagt.
Idee: entschlacken der Ansicht aber die Daten dennoch halten.
Ist devInfo wichtig fuer dich? FHEM braucht es zu nichts.
An der RSSI-Anzeigen wollte ich nichts aendern - sollte immer noch gleich sein. Die Daten fuer HMInfo halte ich in helper. Bei mir wird HMLAN und CUL immernoch und parallel angezeigt.
Bist du sicher, dass es sich geaendert hat?
Wo wir beim Thema sind
Was noch offen ist beim 'entschlacken': Daten bezueglich IO sollten am device gehalten werden, Kanaele haben dies nicht wirklich. Dies betrifft
IODev, LastIODev RSSI, RAWMsg
Diese wuerden dann nur noch im device zu finden sein
Beibehalten koennte man einen
MsgCounter oder eventCounter, last actionTime
fuer den Channel
Was meinst du?
Gruss
Martin
ich habe auch nur noch die cul rssi daten. die vom hmlan sind in der device übersicht nicht mehr zu sehen.
mit hminfo sind sie noch da.
gruss
andre
Hi,
RSSI in HMinfo basiert auf einer anderen Methode. Das ist "stabiler". Die vorhandene Methode aus fhem.pl konnte ich nicht verwenden, da sie erst nach den Parsen eingetragen werden.
Zu den 'traditionellen' RSSI Werten:
das ist nicht geaendert, der Wert wird durch die Zentrale eingetragen.
Der Wert wird aber nur eingetragen, wenn ein notify zurückkommt.
Daher werden die RSSI werte nicht eingetragen wenn
- die message duplicate ist
- die message nicht geparst werden konnte.
In eurem Fall ist es eine duplicate message da CUL und HMLAN das Gleiche empfangen.
Es wird also nur der RSSI der Quelle eingetragen, der zuerst die Message vermeldet! Wird aber nicht aus CUL gesteuert...
Zu sehen ist dies im Beispiel, dass last Message in CUL und HMLAN unterschiedlich sind.
Unklar ist mir, warum die Messages der beiden HMLAN eingetragen wurden.
Generell stellt sich mir die Frage ob die RSSI Werte aus HMINFO auch im web-interface sichtbar genacht wreden sollten. Ich denke aber, dass es das web-layout überfrachtet - und daher in einem expert mode verpackt werden sollte
Gruss
Martin
Nachtrag -
es gibt noch ein dup-handling in fhem.pl - das ist wohl der Triggern zum Schreiben der doppelten RSSI werte.
Da ich jetzt RSSI an die parser uebertrage sind die Werte nicht mehr duplicate...
werde einmal nachdenken...
hallo martin,
du kennst den code... und doch koennte ich wetten das vorher immer alle rssi werte da waren. auch die verworfenen. ich hatte bei allen devices immer beide werte. und jetzt bei keinem mehr.
auch auf dem screenshot sind alle drei rssi zeiten gleich. sollten also in irgendeinem zusammenhang stehen.
hminfo liefert mehr info. es ist aber nicht so einfach schnell mal nachzuschauen. und es nicht zu sehen von welchem zeitpunkt der rssi wert ist. ich kann also nicht genau dann schnell nachschauen wenn es ein empfangsproblem gab und gezielt dir beiden letzten vergleichen und schauen ob sie den gleichen timestamp haben.
gruss
andre
edit: hab deinen zweiten post eben erst gesehen.
so habe es korrigiert.
Das Verhalten sollte sich leicht geaendert haben. RSSI taucht nur beim Device auf, nicht mehr bei reinen channels.
Es gibt jetzt noch einen EVENT Zähler. Der gibt die Anzahle der zu dieser entity assoziierten messages, die erfolgreich geparst wurden, wieder. duplicate werden also nicht gezaehlt.
Hoffe es passt jetzt so.
Die RSSI auswertung in HMinfo sollte jetzt auch verbessert sein und doppelte HMLAN sauber erfassen.
Gruss
Martin
So,
mit der 10_CUL_HM.pm 2808, von heute
Ich kann damit leben, dass die Cul und hmlans im Device sind, das alte hat mir trotzdem besser gefallen :)))))), egal
Problem habe ich mal wieder mit dem toggle auf meinem 4 Kanal Hutschine Switch.
wenn ich das Lampensymbol direkt klicke schaltet der Kanal, aber das Symbol wechselt nicht, sondern es bleibt set_toggle in der Anzeige stehen.
wenn ich webcmd toggle drücke, schaltet der Kanal und die Lampensymbol wechselt, so wie es sein soll.
bei den 1 KanalSwitch habe ich kein Problem, betrifft nur bei dem 4 er.
ZitatGenerell stellt sich mir die Frage ob die RSSI Werte aus HMINFO auch im web-interface sichtbar gemacht werden sollten. Ich denke aber, dass es das web-layout überfrachtet - und daher in einem expert mode verpackt werden sollte
Meine Meihnung:
ich möchte gerne alles sehen, dafür hat Maus ein Scrollrad :)
ne im ernst, ich ärgere mich immer wenn ich schalter(attr) suchen muß, um Funktionen frei zuschalten.
Und wenn schon verstecken, dann den umgekehrten Weg,
wer etwas nicht sehen will soll sich das attr selber setzen, das kann auch der neue User (den hier einige zur Zeit versuchen zu schützen), den es stört.
Zitat von: fhem-hm-knecht schrieb am Di, 26 Februar 2013 15:47So,
Problem habe ich mal wieder mit dem toggle auf meinem 4 Kanal Hutschine Switch.
wenn ich das Lampensymbol direkt klicke schaltet der Kanal, aber das Symbol wechselt nicht, sondern es bleibt set_toggle in der Anzeige stehen.
wenn ich webcmd toggle drücke, schaltet der Kanal und die Lampensymbol wechselt, so wie es sein soll.
bei den 1 KanalSwitch habe ich kein Problem, betrifft nur bei dem 4 er.
Das Problem habe ich auch. Es tritt bei mir mit HM-LC-SW2-FM und HM-LC-SW4-DR auf... Es scheint als würden die Status Rückmeldungen des Aktors verworfen...
ZitatIch kann damit leben, dass die Cul und hmlans im Device sind, das alte hat mir trotzdem besser gefallen
ist sauberer so. Zum einen sendet immer das device, nie der channel - schon wegen der Steuerung. Die uebrigen Werte wie RSSI beziehen sich auch auf das Device, nicht einen channel. Ausserdem sind einige Antworten wie das Lesen von Daten nich einfach dem Kanal zuzuortnen, obwohl sie dazu gehoeren. Damit ist die auswertung nicht komplett sondern verschmiert.
Welche Werte sind wichtig im Channel web-frontend ohne es zu ueberfrachten?
ZitatProblem habe ich mal wieder mit dem toggle auf meinem 4 Kanal Hutschine Switch.
wenn ich das Lampensymbol direkt klicke schaltet der Kanal, aber das Symbol wechselt nicht, sondern es bleibt set_toggle in der Anzeige stehen.
wenn ich webcmd toggle drücke, schaltet der Kanal und die Lampensymbol wechselt, so wie es sein soll.
Also scheint die Auswertung ok zu sein. Es sollte das identische Kommando gesendet werden, eben toggle.
Ich nehme an du hast einen automatischen update eingestellt oder die Webseite manuell refreshed?
Es scheint also ein Problem des timings im web-frontend zu sein. Ggf einen Log bitte - das timing im frontend muss ich erst ansehen...
Zitatne im ernst, ich ärgere mich immer wenn ich schalter(attr) suchen muß, um Funktionen frei zuschalten.
das heisst, dass ich deiner Meinung nach den expert-mode per default auf 'max' setzen sollte. Ist dann nicht konsistent mit "showinternals" von Rudi. Mir aber egal ich kann auch mit Max-Display beginngen.
Wenn keiner widerspricht werden ich das attribut "expert" auf "3" setzen - im device!
Wenn attribut geloescht dann kein expert.
Zitatich möchte gerne alles sehen, dafür hat Maus ein Scrollrad :)
nun, ich habe gerne auch eine Kompaktansicht. Geschmackssache.
Aber im Device sollte Platz sein. Die RSSI Auswertung habe ich erst 'geuebt'. Nachdem jetzt device alles was Protokoll heist beinhaltet sollten hier auch die RSSI werde auftauchen. Da ich nicht gruppieren kann mussich es mit den Namen steuern: Die werte werden rssi... benannt werden und entsprechend HMinfo eingetragen.
Kommentare, Vorschlaege?
Gruss
Martin
...ich habe an einem Aktor per notify ein dumms device für eine andere Darstellung angehängt
define zi_noRasen notify CUL_HM_switch_1DC622_Sw_03 set ga_bewaessRasen %
und dieser dummy bleibt immer im Zustand set_toggle stehen. daher denke ich, daß die Status Rückmeldungen des Aktors nicht ihren Weg ins FHEM finden.
Mein momentaner workaround ist, nach updaten das alte ./FHEM/10_CUL_HM.pm aus dem Backup zu restoren...
schicke einmal ein Log mit
attr global mseclog 1
attr global verbose 1
attr <hmlan> loglevel 1
und ein
list ga_bewaessRasen
Events:
Events:
2013-02-27 12:29:26.581 dummy ga_bewaessRasen set_toggle
2013-02-27 12:29:26.581 CUL_HM CUL_HM_switch_1DC622_Sw_03 set_toggle
Log:
2013.02.27 12:30:08.712 1: cuno: A0CB586701ED32A000000000064 -93.5
2013.02.27 12:29:55.037 1: cuno: A0CAC86701CCD8000000000165F -85.5
2013.02.27 12:29:26.942 1: cuno: A0E0D80021DC6221907620103C8003C -57.5
2013.02.27 12:29:26.582 1: SW: As0E0DA0111907621DC6220203C80000
2013.02.27 12:29:26.582 2: CUL_HM set CUL_HM_switch_1DC622_Sw_03 toggle rxt:1
list ga_bewaessRasen:
Internals:
NAME ga_bewaessRasen
NR 240
STATE set_toggle
TYPE dummy
CHANGETIME:
Readings:
2013-02-27 11:15:01 state set_toggle
Attributes:
fp_Garten 550,350,0,
fp_Zisterne 460,435,0,
room Garten
sieht erst einmal nicht schlecht aus, meine ich.
Du hast einen dummy, das ist schon eine wichtigen Info.
was sagt den ein
list CUL_HM_switch_1DC622_Sw_03
? Das ist doch eine CUL_HM entity. Hier sollte auch der Wert gesetzt werden.
Frueher ist ga_bewaessRasen auch gesetzt worden? Wie lange ist dies her, also wann war der letzte Update der Funktionierte?
das mit dem set dummy muss ich erst ansehen, habe ich nicht probiert
Gruss
Martin
10_CUL_HM.pm 2782 2013-02-21 19:26:18Z martinp876 nutze ich als funktionsfähigen stand... bin nich t gleich draufgekommen da ich zunächst Änderungen im Floorplan modul vermutete...
Output list CUL_HM_switch_1DC622_Sw_03:
Internals:
DEF 1DC62203
EVENTS 10
NAME CUL_HM_switch_1DC622_Sw_03
NR 129
STATE off
TYPE CUL_HM
chanNo 03
device CUL_HM_switch_1DC622
CHANGED:
deviceMsg: off (to cuno)
off
CHANGETIME:
Readings:
2013-02-22 12:19:57 CommandAccepted yes
2013-02-27 13:07:12 deviceMsg off (to cuno)
2013-02-27 13:07:12 state off
Attributes:
alias zi_rasen
fp_Zisterne 310,648,0,
model HM-LC-SW4-DR
peerIDs
room Zisterne
webCmd toggle
...vielleicht noch ein Hinweis: wenn ich direkt am HM-LC-SW4-DR den Umschaltknopf drücke wird bei mir wohl auch kein notify durchgeführt...
habe nochmals mit den Versionen auf Sourceforge gespielt. Das Problem kam mit version 2799...
Zitat...vielleicht noch ein Hinweis: wenn ich direkt am HM-LC-SW4-DR den Umschaltknopf drücke wird bei mir wohl auch kein notify durchgeführt...
es kommt kein notify - wird der Status im channel geaendert?
Ich habe eine Ansatz - muss noch einmal das Notify verfahren checken.
Kannst du noch einmal bestaetigen:
- der Status der Devices und channels (CUL_HM!) wird immer aktualisiert.
- Probleme gibt es bei abgeleiteten Aktionen,Zustaenden die moegl. an notify haengen.
- der state 'set_on' bleibt NICHT in CUL_HM haengen sondern in anderen entities wie 'dummy'
so korrekt?
Gruss
Martin
Hallo Martin,
ich bin mir nicht sicher ob ich die Fachbegrifflichkeiten richtig verstanden habe deshalb bitte nochmal rückfragen (evtl mit den entsprechenden Kommandos um die Daten zu besorgen...
Zitat von: martinp876 schrieb am Do, 28 Februar 2013 09:18Zitat...vielleicht noch ein Hinweis: wenn ich direkt am HM-LC-SW4-DR den Umschaltknopf drücke wird bei mir wohl auch kein notify durchgeführt...
es kommt kein notify - wird der Status im channel geaendert?
nach Betätigung des Tasters am HM-LC-SW4-DR wird zunächst keine Änderungs im Frontend sichtbar (mit 10_CUL_HM.pm 2782 erfolgte eine Aktualisierung). Ein Refresh des Browsers zeigt dann den korrekten Status an.
ZitatIch habe eine Ansatz - muss noch einmal das Notify verfahren checken.
Kannst du noch einmal bestaetigen:
- der Status der Devices und channels (CUL_HM!) wird immer aktualisiert.
- Probleme gibt es bei abgeleiteten Aktionen,Zustaenden die moegl. an notify haengen.
ja. Notify funktioniert nicht und auch structures kommen "aus dem Tritt"
Zitat- der state 'set_on' bleibt NICHT in CUL_HM haengen sondern in anderen entities wie 'dummy'
korrekt. ich habe es bei über notify angehängten Aktionen, structures und im floorplan beobachtet, daß die "set_xxx" Zuständen hängen blieben.
Viele Grüße,
Uwe.
ZitatEin Refresh des Browsers zeigt dann den korrekten Status an.
Dann ist CUL_HM - hier - aus dem Schneider. Offensichtlich wird der Status korrekt gesetzt. Das web-interface macht nach dem Absetzen des Kommanods einen refresh. Der dann verfuegbare Status wird angezeigt.
Offensichtlich wird der endgueltige Status erst danach verarbeitet. Dieses Problem kannst du mit auto-refresh erschlagen - ich denke "longpoll" liefert dir dies.
Zitatja. Notify funktioniert nicht und auch structures kommen "aus dem Tritt"
das werde ich mir ansehen. Das ist wohl das ganze Problem.
Gruss
Martin
Hallo Martin,
Zitat von: martinp876 schrieb am Do, 28 Februar 2013 13:28ZitatEin Refresh des Browsers zeigt dann den korrekten Status an.
Dann ist CUL_HM - hier - aus dem Schneider. Offensichtlich wird der Status korrekt gesetzt. Das web-interface macht nach dem Absetzen des Kommanods einen refresh. Der dann verfuegbare Status wird angezeigt.
Offensichtlich wird der endgueltige Status erst danach verarbeitet. Dieses Problem kannst du mit auto-refresh erschlagen - ich denke "longpoll" liefert dir dies.
Sorry, aber ich bin da anderer Meinung. Ich habe longpoll aktiviert und ich habe das Problem auch zunächst beim Frontend gesucht allerdings dürfte dann das einpielen von Version 2782 keine Veränderungen bei der Anzeige veranlassen was es aber definitiv tut.
/* Klugscheissmodus on */
Leider weis ich zu wenig über die interne Programmstruktur von FHEM aber ich habe den Eindruck, daß der FHEM Kern einfach einen "Stupser" braucht um mitzubekommen, daß sich ein HM Wert geändert hat. Mit dem Refresh löse ich wahrscheinlich ein polling über alle Werte aus während das bisherige Verhalten anscheinend durch einen von CUL_HM veranlassten Trigger reagierte.
/* Klugscheissmodus off */
gut - werde mal nachsehen, wann das web-interface einen update macht - evtl ist es auch an das notify gehaengt.
Alle readings lasse ich mit dem Auftrag 'notify' vom fhem-kern setzen... das scheint nicht zu reichen... den hier war die Aenderung.
loesen muss ich es generisch denn da muessen noch viel mehr Eintraege Probleme haben...
externes schalten der Lampe faellt in diese Kategorie - und wurde bei mir im web noch nie auto-upgedated.
Gruss
Martin