HM-SEC-SD-2 - Batterie leer nach einem Jahr ?!

[frank]

hallo martin,

vielleicht wäre es sinnvoll, zb in hminfo, burst messages zu zählen, die durch io's empfangen/gesendet werden.
mit einer tabelle ähnlich wie bei "get hminfo msgStat" hätte man einen schönen überblick über burstmessages und könnte einen "missbrauch" besser aufspüren.

für das problem in diesem thread wäre eine zusätzliche unterteilung in interne (von eigenen devices) und externe (vom nachbarn) burstmessages hervorragend.

ich würde mir ein entsprechendes "werkzeug", zb "get hminfo burstStat" wünschen, falls es der aufwand zulässt.

[martinp876]

Hm. Ich glaube nicht dass es viel hilft.
Zaehlen kann man am io was empfangen wird, auch wenn es nicht für die zentrale ist. Dann kann man burst separat zaehlen.
Was das device empfängt kann man nur zählen, wenn es das io auch sieht.
Das ergibt viele zahlen. Diese muss man stündlich erfassen. Und tages akkumuliert.

Ergibt viele schöne Statistiken und graphen. Kostet rechenzeit. Kann  kaum einer auswerten. Die, welche es könnten sehen an den vorhandenen statistiken schon eine menge. Fast alles. Bisher hat sich noch keiner die statistiken zeigen lassen.
Ich vermute stark  " Ausser Spesen nichts gewesen" . und das nicht wegen meiner arbeit.

Eine einfache Unterscheidung von burst ist natürlich machbar.
Also die Erwartung nicht zu hoch hängen. Das bat problem des sd-2 ist sicher kein burst problem. So viel bursten ist nach funkverordnung verboten. Hm unterbindet das. Die neue hm cul auch.

[Pfriemler]

Was im Funkband erlaubt ist, wird nicht unbedingt eingehalten. FHEM ist ja auch nicht DIE Zentrale, das Limit gilt je Gerät - vier IOs, vierfache Funklast erlaubt. Und ich wage doch zu behaupten, dass man mit der 1%-Regel einen SD in zwei Monaten fertigmachen kann.

Abgesehen davon erwartet keiner eine Statistik oder Grafiken - die kann sich jeder selbst bauen. Simpler Zähler, letzte Stunde, aktueller Tag, fertig. Natürlich nur die Bursts die das oder die IOs sehen können. Aber das reicht doch.

Abgesehen davon: würde es vielleicht helfen, die fhem.cfg mal zu inspizieren? Bugster muss sie ja nicht veröffentlichen, Mail an mich wäre ne Option.
Hardwarefehler will ich nämlich eigentlich ausschließen, wenn gleich mehrere davon identische Symptome zeigen.

[martinp876]

Klar macht die grafik jeder selbst. Die zaehler muessen aber erzeugt werden. Aber gut.
Fhem selbst wuerde ich ausschliessen. Aber hierzu gibt es schon hinreichend zähler.
Einfach einmal die vorhandene Statistiken ansehen.

Hminfo protoinfo
Msgstat der ios.
Zu sds wird quasi nichts gesendet. Einfach erst mal prüfen.

[martinp876]

nun - eingecheckt. Nicht allumfassend.
Wer sich mit sende und Empfangs-statistiken beschäftigt hat sicher HMInfo

Code Auswählen Erweitern

get hm msgStat
get hm protoEvents
get hm protoEvents long


Das ist nun erweitert um Burst. Insesondere das Senden einer BurstMessage von FHEM an das Device. Weiter alle von den FHEM IOs empfangenen Burst.
Nicht beinhaltet und Schwächen sind:
- bei mehreren IO devices wird das Senden eines IOs vom 2. Empfangen und gezählt (typisch - wenn die Reichweiten überlappen)
- send (snd und sndB{urst}) sind von der CCU (FHEM) gesendete messages werden nicht doppelt gezählt
- Wiederholungen des Sendens welche ein IO selbständig macht werden nicht erfasst (betrifft eQ3 IOs) - da nicht sichtbar.
- das Senden eines IOs wird von 2. als "receive" erfasst

Unterm Strich: Das ist nichts für Anfänger. Auch nichts für Fortgeschrittene in FHEM oder HM. Das ist etwas für Fortgeschrittene im Bereich FHEM ->HM -> Protokoll. Das ist nur ein recht begrenzter Nutzerkreis.

Den "Normalnutzer" empfehle ich die Auswertung dieser Daten in Größenodnungen. Nicht in Details.

[noansi]

Hallo Martin,

willst Du WakeUp zählen oder Burst?
Das Burst Bit ist im oberen Nibble, nicht im unteren. Ich denke, derzeit wird daher nicht wunschgemäß gezählt.

Gruß, Ansgar.

[martinp876]

Danke. Prüfe es.
Korrigiert. Jetzt auch mit receive countern.

[noansi]

Hallo Martin,

die HM_Info protoEvents Summenanzeige passt noch nicht ganz bei den Indices.

Code Auswählen Erweitern

    my @plSum; push @plSum,0 for (0..11);#prefill

Code Auswählen Erweitern

      $ftr = sprintf("%-${maxNlen}s%-17s|%-10s|%-10s|%-10s#%-10s|%-10s|%-10s|%-10s","sum",@plSum[1..3],@plSum[7..11]); #short

Code Auswählen Erweitern

      push @paramList, sprintf("%-${maxNlen}s%-17s|%-18s|%-19s|%-19s|%-19s|%-19s|%-19s#%-18s|%-19s|%-19s|%-19s",
                    @{$_}[0..11]) foreach(@paramList2); #long

Code Auswählen Erweitern

      $ftr = sprintf("%-${maxNlen}s%-17s|%-18s|%-19s|%-19s|%-19s|%-19s|%-19s#%-18s|%-19s|%-19s|%-19s","sum",@plSum[1..11]); #long

Ansonsten ein schöner Aktivitätsüberblick. 

Gruß, Ansgar.

[frank]

danke für die burst counter, sieht gut aus. 

neben den bereits angesprochenen summenfehlern, könnte man noch die linie direkt über den summen bei "protoEvents long" verlängern.

werden denn nun auch externe burst messages vom nachbarn bei "io receive burst" unter msgStat mitgezählt? wegen fehlender nachbarn müsste ich zum testen erst einen nachbar installieren.

[martinp876]

Sollten. In msgstat. Da stehen empfangene bursts.
Testen kannst du durch
Nehme einen sender der burst kann und auch eingestellt hat. Bspw einen button oder remote. Falls noch nicht gepeert peere den button. Egal, auch mit einer nicht vorhandenen id. Setze peerneedsburst.
Lösche das device aus fhem. Lese msgstat. Drücke den button. Lese msgstat. Es sollte ein burst gezaehlt sein. Wenn du ein hmio hast und der peer nicht antwortet sendet das device 3 burst.
Dann ein shutdown restart und das device ist wieder da. Unpeeren. Fertig ist der nachbar-burst-simulator. Ganz ohne Anbau.
Berichte.
Solltest du 2 ios haben zählt der eine immer alles vom anderen.

[bugster_de]

Hatten wir schon gefragt ob Du sicher bist, dass bei Dir im Haus nachts nicht irgendwas Amok läuft - ein Allroundschlag "getConfigs" oder so

nicht dass ich wüsste. Mein FHEM läuft permanent durch.

Ich habe eine readingsGroup für den RSSI Wert der HM Geräte definiert
TYPE=CUL_HM:+.*_RSSI

Dann habe ich einen Action-Detector, der anzeigt, ob Geräte tot sind
Und noch ein HMInfo Device

[Pfriemler]

Ich habe eine readingsGroup für den RSSI Wert der HM Geräte definiert
Dann habe ich einen Action-Detector, der anzeigt, ob Geräte tot sind
Und noch ein HMInfo Device

Das ist alles unschädlich. Aber mach doch mal ein "update" und schaue nach einem Tag mal beim HMINfo-Device mit dem o.g. Befehl
"get <HMInfoDevice> protoEvents long" (den Namen Deines HMINfo einsetzen).
In der großen Übersicht schau in die Spalte "SndB" nach ungewöhnlich hohen Zahlen (20 oder höher).

[frank]

hallo martin,

bei "get hminfo msgStat" gibt es noch ein problem mit dem zurücksetzen der burst counter. für send burst und receive burst werden mindestens die std-counter und der 24h-counter nicht resettet.

die externen burst werde ich demnächst natürlich auch noch testen.

allerdings ist jetzt schon klar, dass man mit mehreren und über die fläche verteilten io dem nachbarn ohne weiteres kein eindeutigen burst missbrauch nachweisen können wird.
denn das burst "handling" scheint bei unterschiedlichen io teilweise verschieden zu sein.

ich habe 3 verschiedenene io in einem raum. cul, hmlan und hmuart hören im prinzip immer alle messages.
eine einzelne von fhem über hmuart gesendete burst message wird von cul und hmlan immer doppelt als receive burst gezählt. dem gegenüber werden autarke burst messages des hmuart nur einfach unter receive burst gezählt.
auch von fhem über hmlan gesendete burst messages werden von hmuart und cul nur einfach gezählt.

seltsam ist der unterschied beim hmuart zwischen autarken und von fhem iniziierten burst messages.

vorteilhaft wäre also eine separate zählung der externen burst messages, um bei einem problem mit burst vom nachbarn einen eindeutigen hinweis in der hand zu haben.

[martinp876]

danke ihr beiden. Sorry für die Schlamperei.
Jetzt aber

[frank]

ok, jetzt werden fhem-bursts über hmuart nicht mehr doppelt gezählt.

externe burst funktionieren auch.
ich habe dazu mit der eq3-konfigurationssoftware ein anlernen mit fiktiver seriennummer und für fhem unbekannter hmid gestartet. hier sendet eq3 die msg auch immer 2x als burst.

das problem der identifizierung externer bursts bleibt allerdings bestehen.