seit update 23.02.13 Anzeige der cul und hmlans im Device (fehlerhaft?)

[LuckyDay]

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"

[martinp876]

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

[justme1968]

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

[martinp876]

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

[martinp876]

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...

[justme1968]

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.

[martinp876]

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

[LuckyDay]

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.

Generell 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.

[thunder]

So,

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...

[martinp876]

Ich 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?

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.

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...

ne 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.

ich 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

[thunder]

...ich habe an einem Aktor per notify ein dumms device für eine andere Darstellung angehängt

Code Auswählen Erweitern


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...

[martinp876]

schicke einmal ein Log mit
attr global mseclog 1
attr global verbose 1
attr <hmlan> loglevel 1

und ein
list ga_bewaessRasen

[thunder]

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

[martinp876]

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

[thunder]

 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