Stats

      Stats

      So ich fange mal an zu sammeln was denn interessant wäre an Stats zu sammeln und auswertbar zu machen.
      Angetrieben durch emkay war ich ja von gnuplot begeistert und mußte aber feststellen....
      1. für schöne Auswertungen bedarf es vieler Daten :)
      2. gnuplot ist nicht wirklich einfach


      also habe ich einfach mal auf einer Linuxkiste herumgespielt.

      Herausgekommen ist:


      Wärend ich daran bastelte stellte ich halt fest das es so wenig Daten sind.
      Also logge ich nun jede Minute auf dem Ubunturechner folgendes:
      Tunnel Status LTE DSL
      Ausgabe sphfreq
      Ausgabe xdslcmd



      So ich hab dann schonmal zur Liveansicht online :)
      Aktualisierung sollte alle 5 Minuten geschehen.
      domainzentrale.eu/mystats/index.php

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Heiko“ ()

      Ahhhhhhhhhhhhhhhh Ihr antwortet gleichzeitig in mehreren Foren das gemein :)
      ich wollte Dich ja nicht überlesen :)

      Ich muß nun auch noch schnell Ostereinkauf machen!


      Ahja die 3 kleinen weißen "LEDs" sind aktuell natürlich fest...

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Heiko“ ()

      xdjbx schrieb:

      ich finde das alles (Auch die LED Steuerung) nur in bin/cms

      Kann man die zerlegen?


      Hast Du mal versucht /var/lte/signal_level den Wert zu ändern?
      Vielleicht ändert das auch die LED Anzeige?
      Danach müßte man nur noch die anderen Statuseinträge ausfindig machen.
      Ich gehe da eher mit dem Gedanken heran zu improvisieren da mir zerlegen und co. niemals in den Sinn kommen würde :)

      also nur so ein spontaner Gedanke um überhaupt mal zu schauen worauf die LEDs reagieren auf Einträge ala Logs oder direkte Kommandos.

      ich habe mir mal angeschaut, was der Router in der Console ausgibt, wenn man WLAN abschaltet...
      vielleicht hilft's

      Quellcode

      1. Check CSRF Token OK
      2. csrf_token=>hiermeintoken
      3. lang=>de
      4. use_wlan=>0
      5. use_wlan=0
      6. .....submit....
      7. [wlan_tr181.c WlanRadioIntfCmsAddSetObjProc:3892] ATP_SYS_LOG_WLAN_DEACTIVED (W007) 802.11g/n
      9. [wlanbcmcms.c WlanSetupAllEx:1160] WlanSetupAllEx idx0, bOnlyAppendCmd:1
      11. [wlanbcmcms.c WlanSetupAllEx:1183] BHAL_LED_Wlan off
      12. check 2.4G FON status
      13. 2.4G FON status enable
      14. wl0 : 00:11:3A:xx:xx:xx android-3xxxxxxxxx is disconnected
      15. WlanSetSsid: SSID=WLAN-Hybrid
      16. WlanSetSsid: SSID=Telekom_FON
      17. [wlanbcmcms.c WlanDoSetupAllCmd:1029] WlanDoSetupAllCmd
      19. Need to save to flash now.
      20. FILE: foncmsmsgproc.c FUNC: ATP_FON_WlanUpdateMsgProc LINE: 1257: ATP_FON_WlanUpdateMsgProc: ulWlanUpdate:0
      21. FILE: foncmsmsgproc.c FUNC: ATP_FON_WlanUpdateMsgProc LINE: 1260: ATP_FON_WlanUpdateMsgProc: bWLANEnable:0
      22. echo -n "2" > /var/fon/fon_offreason
      23. killall fonap
      24. killall: fonap: no process killed
      25. /etc/init.d/fonap stop
      26. killall: pppd: no process killed
      27. dhcp.c: 3777: 0 (Debug) Layer2 PROT: 0x886c dropped
      28. Setting SSID: "WLAN-Hybrid"
      29. Setting SSID: "Telekom_FON"
      30. ************************Write db to flash now ...
      31. 2: received SIGINT or SIGQUIT or SIGTERM
      32. 6: chillout successfully finished
      33. 6: End chillout successfully finished
      34. xl2tpd[20124]: chillout_accept() failed
      35. xl2tpd[20124]: death_handler: Fatal signal 2 received
      36. xl2tpd[20124]: clear_network: close sockets
      37. killall: chillout-client: no process killed
      38. Terminated
      39. 10Stopping chilli: chilli.c: 361: 0 (Debug) SIGTERM: shutdown
      40. chilli.c: 5846: 0 (Debug) CoovaChilli shutting down
      41. options.c: 621: 0 (Debug) Unloading module fon-api
      42. options.c: 627: 0 (Debug) Removing /var/run/chilli.14032.cfg.bin
      43. chilli.
      44. chilli.
      45. done sync
      46. [STOPFONAP]FON SSID DOWN
      47. killall: fonsmcd: no process killed
      48. sh: you need to specify whom to kill
      49. iptables -t mangle -D FORWARD -s 172.17.2.0/24 -j MARK --set-mark 0x1
      50. WlanWpsIntfCmsGetObjProc iWlWpsCtl :0.
      51. LastChange: 20921
      52. LastV6Change: 20919
      53. LastChange2: 20921
      54. do basinfo
      55. ProvisioningCode=000.003.433.000
      56. ModeEnabled: WPA2-Personal
      57. X_error:0

      @Heiko: viele der Werte unter /var sind ja nur für die WebUI gecached - manche sind ja nichmal da, bevor man nicht auch eingeloggt war.
      Du brauchst jetzt aber noch'n LED-Beamer, welcher das auf deinen SPH projiziert ;)

      @xdjbx: die muß man ja nich zerlegen - dafür haben wir ja den Quellcode :D
      Für die LED-Steuerung gibt es API-Funktionen (diese nutzen dann wiederum 'libbhal' - den Broadcom-Hardware-Abstraction-Layer). Wenn man allerdings 'ne LED abstellt, kann's gut sein, daß sie beim nächsten Refresh der Firmware wieder angeht ;)
      (man konkurriert da wahrscheinlich mit der Firmware...)
      Ein /proc- oder /dev-Ansatz wär' mir am liebsten, weil da extra'n Binary in C/C++ fänd' ich übertrieben... (ginge aber wohl)

      mfg, emkay

      Hehe also /var/lte/signal_level
      keine Ahnung für was es ist aber im Webgui interessiert Ihn das auch nicht :)
      hab den Wert mal auf 3 gesetzt...
      im Gui sehe ich nix davon.

      Überschrieben wird es scheinbar auch nicht.Doch wenn man LTE aktiviert bzw. deaktiviert hahahaha

      @genevt: Du hast (halb-) Recht... in den neuen Quellcodes (.010) fehlen die betreffenden Dateien - in den alten sind sie noch da... das erklärt dann auch, warum die Neuen nur noch fast halb so groß sind, wie die Alten... (in sphfreq nutze ich ja auch Huawei-APIs - gehen tut das ;) )

      @xdjbx: Nöö. Das mit den APIs ist hier nie in dem Sinne angesprochen worden - einfach, weil C/C++-Coder eh wissen, wie's geht :D
      Das einzige Problem dabei ist, das die APIs nicht dokumentiert sind (zumindest nicht für uns greifbar) und es deshalb erstmal einer gewissen Suche bedarf, bis man die passende Funktion und die dazugehörende Library etc. gefunden hat.

      Aber wie gesagt: sphfreq macht genau das - es ist dynamisch an die Libraries des SPHs gebunden und nutzt dessen AT-API für seine Funktionen.
      Und irgendwo hab' ich eben auch APIs gesehen zum Setzen der LEDs... weiß aber grad' nich' wo :D

      mfg, emkay

      EDIT: Soooo.... @Heiko
      Huawei-LTEs melden den RSRP normalerweise nicht in dBm - sondern in Stufen/Prozent von 0-97
      0 ==> kleiner -140dBm
      1 ==> -140dBm oder mehr
      2 ==> -139dBm oder mehr
      ...
      95 ==> -46dBm oder mehr
      96 ==> -45dBm oder mehr
      97 ==> -44dBm oder mehr
      Ich würd' jetzt mal grob schätzen: Anzahl Balken = ROUND((140+RSRP)/20)
      (Achtung RSRP mit Vorzeichen!)

      Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „eMKay77“ ()

      eMKay77 schrieb:

      Huawei-LTEs melden den RSRP normalerweise nicht in dBm - sondern in Stufen/Prozent von 0-97
      0 ==> kleiner -140dBm
      1 ==> -140dBm oder mehr
      2 ==> -139dBm oder mehr
      ...
      95 ==> -46dBm oder mehr
      96 ==> -45dBm oder mehr
      97 ==> -44dBm oder mehr
      Ich würd' jetzt mal grob schätzen: Anzahl Balken = ROUND((140+RSRP)/20)
      (Achtung RSRP mit Vorzeichen!)


      Oder, wenn man nich rück-rechnen will vom sphfreq-/RSRP:

      Quellcode

      1. atcmd csq display
      (muß man natürlich runden :D ) EDIT: obwohl ich da nich' ganz sicher bin - csq scheint eher am RSSI zu hängen...

      mfg, emkay

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „eMKay77“ ()