72_FRITZBOX: Sperren/Entsperren von Netzwerkgeräten / DECT Telefonen u weiteres

Begonnen von JoWiemann, 25 Januar 2021, 10:30:32

Vorheriges Thema - Nächstes Thema

RalfRog

Bevor ich an Testen komme vorab noch eine Info nach der Du mal schauen solltest.
Das Problem bestehr schon seit mehreren Versionen (ich glaube schon vor 0.2.11).
Wenn man das Attribut disableBoxReadings anfasst entsteht ein Reading namens ",". Das kommt wieder auch wenn es per deletereading gelöscht wird.
Siehe Bild:
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

RalfRog

Also mit FW 7.29 auf der 7590 und Beta5:

1. Beim Start ist mir nichts mehr mit WARNING etc. aufgefallen. Sieht dort gut aus
2. set <name> lockLandevice <MAC> on|off         =>  klappt und Reading "lockLandevStat" wird gesetzt
3. set <name> enableVPNshare <number> off|on =>  klappt für die Box Oberfläche, Reading bei OFF nicht beachtet aber bei ON: "enableVPNshareStat  vpn1->on"

Die Beobachtung der Readings war etwas kompliziert.

set Fritzbox enableVPNshare 1 off

1)
Log:      2022.12.29 13:39:53.062 4: FRITZBOX [fritzbox: Set.812] - INFO: set fritzbox enableVPNshare vpn1 off
Reading:  lastReadout    2 values captured in 1.83 s    2022-12-29 13:39:55 (nicht auf enableVPNshareStat geachtet)

2)
13:43 sind die "lock_x" Readings weg (auch lockLandevStat),   nachher wieder da

3)
Danach erst habe ich auf die jeweils 6 vpnx Readings geschaut, die haben korrekte Werte.

4)
Edit
Was merkwürdig ist, dass die SSH Verbindung zum Raspberry abgerissen ist. Ohne erkennbaren Grund.
Es sei denn, die WLAN Verbindung wird durch die Box kurz unterbrochen.

Da ist lt. RASPI-Log tatsächlich etwas mit dem WLAN passiert. Steht ab nicht im Zusammenhang mit  "nableVPNshare".

set Fritzbox enableVPNshare 1 on

1)
Dauerping auf FritzBox vom Rechner und RASPI (beide im WLAN) => ohne Unterbrechung

2)
Reading: enableVPNshareStat  vpn1->on
   => aber es werden 2 Readings am vpn1 gelöscht "vpn1_remote_ip" & "vpn1_state"
   
3)
Nach dem nächsten (Poll)Intervall kommen sie wieder wenn die FHEM Oberfläche aktualisiert wird (F5 oder Devicename anklicken).
Werte ok.



Logauszug set Fritzbox "enableVPNshare 1 off"
2022.12.29 13:39:53.059 4: FRITZBOX [fritzbox: Set.798] - INFO: set fritzbox enableVPNshare f▒r Version: 07.29
2022.12.29 13:39:53.062 4: FRITZBOX [fritzbox: Set.812] - INFO: set fritzbox enableVPNshare vpn1 off
2022.12.29 13:39:53.066 4: FRITZBOX [fritzbox: Set_Cmd_Start.2994] - INFO: Fork process FRITZBOX_Run_enableVPNshare
2022.12.29 13:39:53.375 4: FRITZBOX [fritzbox: Web_OpenCon.5962] - INFO: using old SID from 1672317379.72729
2022.12.29 13:39:54.531 4: FRITZBOX [fritzbox: Run_enableVPNshare.3468] - INFO: set fritzbox enablevpnshare vpn1 off
2022.12.29 13:39:54.535 3: FRITZBOX [fritzbox: Run_enableVPNshare.3481] - INFO: data.lua: xhr 1 lang de page shareVpn apply  connection1 off active_connection1 0
2022.12.29 13:39:54.539 4: FRITZBOX [fritzbox: Web_OpenCon.5962] - INFO: using old SID from 1672317379.72729
2022.12.29 13:39:54.542 4: FRITZBOX [fritzbox: Lua_Data.6174] - INFO: Request data via API dataQuery.
2022.12.29 13:39:54.545 4: FRITZBOX [fritzbox: Lua_Data.6178] - INFO: URL: http://aa.bb.cc.ff/data.lua?sid=ec5d3097db041944
2022.12.29 13:39:55.183 4: FRITZBOX [fritzbox: Lua_Data.6183] - INFO: Response: 200 OK
{"pid":"shareVpn","hide":{"rss":true,"mobile":true,"provServ":true,"liveTv":true,"dectMail":true,...........,"apply":"ok"},"sid":"ec5d3097db041944"}

2022.12.29 13:39:55.187 4: FRITZBOX [fritzbox: Lua_Data.6228] - INFO: Response: {"pid":"shareVpn","hide":{"rss":true,"mobile":true,"provServ":true,"liveTv":true,"dectMail":true,...........,"apply":"ok"},"sid":"ec5d3097db041944"}

2022.12.29 13:39:55.194 4: FRITZBOX [fritzbox: Run_enableVPNshare.3491] - INFO: VPNshare vpn1 set to off
2022.12.29 13:39:55.232 4: FRITZBOX [fritzbox: Set_Cmd_Done.3014] - INFO: Back at main process
2022.12.29 13:39:55.236 4: FRITZBOX [fritzbox: Readout_Process.2613] - INFO: Processing 2 readouts.
2022.12.29 13:39:55.242 4: FRITZBOX [fritzbox: Readout_Process.2740] - INFO: 2 values captured in 1.83 s


Ich hoffe damit kannst Du was anfangen.
Es passiert zumindet nix "Schlimmes" wie Restart FHEM oder was krudes an der Box.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

JoWiemann

Zitat von: RalfRog am 29 Dezember 2022, 12:19:59
Bevor ich an Testen komme vorab noch eine Info nach der Du mal schauen solltest.
Das Problem bestehr schon seit mehreren Versionen (ich glaube schon vor 0.2.11).
Wenn man das Attribut disableBoxReadings anfasst entsteht ein Reading namens ",". Das kommt wieder auch wenn es per deletereading gelöscht wird.

Hallo Ralf,

das habe ich auch schon mal gesehen. Bekomme es aber nicht reproduziert.

Kannst Du das auf spezielle Redaings eingrenzen?

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

JoWiemann

Zitat von: RalfRog am 29 Dezember 2022, 14:49:17
Also mit FW 7.29 auf der 7590 und Beta5:

Die Beobachtung der Readings war etwas kompliziert.


Im Modul gibt es eine sub, die die Readings verarbeitet. Ist ein Reading leer, wird es beim zweiten update der Readings gelöscht. Für die vpn Readings setzte ich nun für vpn?_state und vpn?_remote_ip einen Defaultwert ein, da diese Informationen bei deaktiviertem VPN Share leer zurückgeben werden.

Grüße Jörg

Anbei eine Beta 6. Hinzugekommen ist unter get <FritzBox> luaInfo der Abruf von Benutzer-Informationen.

Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

RalfRog

Teste ich morgen.
Mir sind allerdings noch 2 Mails meiner Box aufgefallen.
Im zeitlichen Zusammenhang mit enableVPNshare ON und OFF habe ich wieder zweimal neue IP-Adressen bekommen (teilt die Box per Mail mit).

Hatte ich zuerst nicht drauf geachtet. Suche noch die Zeitstempel raus und melde mich.

Gruß Ralf
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

JoWiemann

Zitat von: RalfRog am 29 Dezember 2022, 16:07:15
Teste ich morgen.
Mir sind allerdings noch 2 Mails meiner Box aufgefallen.
Im zeitlichen Zusammenhang mit enableVPNshare ON und OFF habe ich wieder zweimal neue IP-Adressen bekommen (teilt die Box per Mail mit).

Hatte ich zuerst nicht drauf geachtet. Suche noch die Zeitstempel raus und melde mich.

Gruß Ralf

Hallo Ralf,

wenn Du die über VPN angebundene Box "abgeklemmt" hast, dann bekommt die doch neue IP's? Oder?

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

LuckyDay

Hallo Jörg,

benutze gerade die FB-Fork 0.2.12 Beta 6 auf meiner 7530 Labor 39 version.
und hätte eine Bitte
aktuell liest du die
box_dsl_downStream 38.772 und
box_dsl_upStream 9.768
nur die Netto daten aus.
seither hatte ich über UserReadings die Brutto Daten ausgelesen
box_DownstreamVDSLRate:lastReadout.* { my $resp=fhem("get $name tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);;$resp =~/'NewDownstreamCurrRate' => '(.*)'/;;return $1/1000;;}, box_UpstreamVDSLRate:lastReadout.* {   my $resp=fhem("get $name tr064Command WANDSLInterfaceConfig:1 wandslifconfig1 GetInfo",1);;$resp =~/'NewUpstreamCurrRate' => '(.*)'/;;return $1/1000;;},

Könnest du das noch integrieren, da userReadings blockierend sind? bei mir 0,7-1 Sekunde

Danke

JoWiemann

Zitat von: fhem-hm-knecht am 29 Dezember 2022, 17:58:35
Hallo Jörg,

Könnest du das noch integrieren, da userReadings blockierend sind? bei mir 0,7-1 Sekunde

Danke

Hallo Ralf,

ich habe die Readings als:
box_vdsl_downStreamRate
box_vdsl_upStreamRate

eingebaut. Die Umbenennung legt die Readings in der Sortierung hintereinander.

Anbei also die Beta 7.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM

LuckyDay


Jamo

ZitatKönnest du das noch integrieren, da userReadings blockierend sind? bei mir 0,7-1 Sekunde
UserReadings sind nicht blockierend.
Schau mal hier, das Problem ist ein ganz anderes: https://forum.fhem.de/index.php/topic,105187.msg991411.html#msg991411
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

RalfRog

Zitat von: JoWiemann am 29 Dezember 2022, 15:53:40
Hallo Ralf,

das habe ich auch schon mal gesehen. Bekomme es aber nicht reproduziert.

Kannst Du das auf spezielle Redaings eingrenzen?

Grüße Jörg

Jörg, ich antworte stückweise auf deine Fragen. Die hier kann ich auswendig.

Ein Eingrenzung habe ich nicht hinbekommen. Das "," ist gefühlt immer dann entstanden wenn ich das Attribut in der Oberfläche angefasst habe - egal was ich aus- oder abgewählt habe.
Ich habe nicht versucht das Attribut über die Kommandozeile einzugeben.

Gruß Ralf

=> Weiteres morgen.
FHEM auf Raspi 2B mit nanoCUL, HM-MOD-RPI-PCB und über LAN MAX!Cube mit a-culFW (Stack 868 + 433)
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder

LuckyDay

Zitat von: Jamo am 29 Dezember 2022, 20:32:43
UserReadings sind nicht blockierend.
Schau mal hier, das Problem ist ein ganz anderes: https://forum.fhem.de/index.php/topic,105187.msg991411.html#msg991411

2022.12.29 16:55:23.854 1: Perfmon: possible freeze starting at 16:55:23, delay is 0.854
2022.12.29 16:55:04.742 1: Perfmon: possible freeze starting at 16:55:03, delay is 1.742
2022.12.29 16:50:25.425 1: Perfmon: possible freeze starting at 16:50:24, delay is 1.425
2022.12.29 16:45:26.440 1: Perfmon: possible freeze starting at 16:45:25, delay is 1.44
2022.12.29 16:45:00.229 1: Perfmon: possible freeze starting at 16:44:59, delay is 1.229
2022.12.29 16:40:27.421 1: Perfmon: possible freeze starting at 16:40:26, delay is 1.421
2022.12.29 16:39:58.811 1: Perfmon: possible freeze starting at 16:39:58, delay is 0.811


Klar sind die blockierend,

Ich schreibe das nicht zum Spass!

Jamo

Nein, userReadings 'per se' sind nicht blockierend. Dann liegts an dem 'get <device> tr064command ....', oder an was anderem, oder weil das userReading sich ständig selbst triggerd. 
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/ConbeeII, FB, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack

LuckyDay

Zitat von: Jamo am 29 Dezember 2022, 23:42:54
Nein, userReadings 'per se' sind nicht blockierend. Dann liegts an dem 'get <device> tr064command ....', oder an was anderem, oder weil das userReading sich ständig selbst triggerd. 

ich habe doch das userReadings gepostet,
du stellst gerade mein Posting in frage ohne nachzukontrllieren,
und nochmal userReadings sind blockierend! die werden nicht geforkt -> also blockiernd ! was ist daran so schwer zu verstehen?
ud jetzt von dir eine Antwort - fundiert!

JoWiemann

Zitat von: RalfRog am 29 Dezember 2022, 22:54:25
Jörg, ich antworte stückweise auf deine Fragen. Die hier kann ich auswendig.

Ein Eingrenzung habe ich nicht hinbekommen. Das "," ist gefühlt immer dann entstanden wenn ich das Attribut in der Oberfläche angefasst habe - egal was ich aus- oder abgewählt habe.
Ich habe nicht versucht das Attribut über die Kommandozeile einzugeben.

Gruß Ralf

=> Weiteres morgen.

Hallo Ralf,

anbei eine neue Beta 7a. Ich habe in die zentrale Sub zur Behandlung von Readings eine Abfrage auf "," eingebaut. Es wird dann ein Log mit caller und Zeilennummer des Aufrufs geschrieben. Vielleicht finden wir so den Verursacher.

Grüße Jörg
Jörg Wiemann

Slave: RPi B+ mit 512 MB, COC (868 MHz), CUL V3 (433.92MHz SlowRF); FHEMduino, Aktuelles FHEM

Master: CubieTruck; Debian; Aktuelles FHEM