Neuigkeiten:

Am Sonntag den 8.12.2024 kann es ab ca. 8:00 Uhr zu kurzzeitigen Einschränkungen / Ausfällen bei den Diensten des FHEM Vereines kommen.
Die Server müssen mal gewartet und dabei neu gestartet werden ;)

Hauptmenü

72_FRITZBOX.pm ab Version 07.57.10

Begonnen von JoWiemann, 05 Januar 2024, 10:39:57

Vorheriges Thema - Nächstes Thema

RalfRog

#195
Hallo Jörg

habe mir mal die neuen Funktionen "set <name> wlanGuestParams <paramter value>" angeschaut.
Mögliche Kombinationen aus <paramter value>
  <wlan on|off>
  <ssid name>
  <psk password>
  <mode private|public>
  <tmo minutes> , tmo == timeout in Minuten (15 - 4320). Wird tmo gesetzt, so wird automatisch isTimeoutActive auf on gesetzt.
  <isTimeoutActive on|off>
  <timeoutNoForcedOff on|off>
Status in Reading: retStat_wlanGuestParams

Das findet man im Prinzip ja auch so in der Oberfläche im WLAN>Gastzugang.

Zwei Fragen dazu, da ich nicht probieren wollte ob und wie die Fritzbox darauf reagiert (falls du es weisst):
  • <tmo minutes> --> die Box hat im eigenen Dropdownmenü ja fixe Wert. Was passiert wenn man z.B. nicht vorgesehene 17 Minuten eingeben würde?
  • <isTimeoutActive> --> existiert soweit ich das sehe nicht als eigener Menüpunkt in der Oberfläche sondern nur "tmo" und "NoForcedOff"

Gruß Ralf

Edit:
Achso...  Es heisst "Mögliche Kombinationen aus <paramter value>". Kann man mehrere Kombinationen eingeben? Was wäre der Trenner- Blank, Komma?
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

Hallo Ralf,

mit möglich Kombination meine ich eigentlich nur die unterschiedlichen Kombinationen Parameter mit Wert. Eine Auflistung mehrerer Parameter, Wert habe ich noch nicht implementiert.

Bei den Minuten kommt kein Fehler zurück und es scheint zu funktionieren.

<isTimeoutActive> == automatisch deaktivieren nach

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

RalfRog

Hallo Jörg
Danke für die Info. Interessant, dass beliebige tmo akzeptiert werden. Hatte schon was wie Reboot befürchtet  ;D

Die Frage war rein interessehalber. Nutze an sich nur das "alte" Kommando "set <name> guestWlan <on|off>" in meiner FUIP Übersichtsseite.

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 12 September 2024, 08:53:54Die Frage war rein interessehalber. Nutze an sich nur das "alte" Kommando "set <name> guestWlan <on|off>" in meiner FUIP Übersichtsseite.

Hallo Ralf,

ich habe einen Taster im Eingangsbereich "WLAN Gäste an". Damit kann der Gast das WLAN einschalten. Durch TMO schaltet es sich dann automatisch aus, ohne das Fhem involviert ist. Und da die FB die Einstellungen nicht verliert, funktioniert das ziemlich gut.

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

mi.ke

Zitat von: mi.ke am 08 September 2024, 15:44:07Die Readings "box_dns_Server0" und "box_dns_Server1" zeigen immer den Provider DNS-Server an und nicht den manuell eingetragenen.

Hallo Jörg,

bis auf die DNS Einträge funktionieren alle Änderungen für mich perfekt.

Ich switche mit "set Fritzbox switchIPv4DNS other" öfter auf die AdGuard Server um.
Da wäre es natürlich prima, wenn die aktuell eingestellte IP zu sehen wäre.

Danke und Grüße
mi.ke

FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

JoWiemann

Zitat von: mi.ke am 12 September 2024, 15:30:24Ich switche mit "set Fritzbox switchIPv4DNS other" öfter auf die AdGuard Server um.

Hallo mi.ke,

ich habe jetzt die Readings box_dns_Srv<lfnd Nummer>_used_IPv4_<lfnd Nummer> und box_dns_Srv<lfnd Nummer>_used_IPv6_<lfnd Nummer> implementiert.

Die Rückmeldung der FB zeigt, dass es wohl mehr als box_dns_Srv0 geben kann. In welcher Umgebung das zutrifft, keine Ahnung.

Die Redaings müssen über das Attribut enableBoxReadings aktiviert werden.

Ich hoffe, dass es das ist, was Du meintest.

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

juemuc

Hallo Jörg,

die Erweiterung funktioniert bei mir. Es werden die beiden DNS-Server angezeigt.
Du darfst diesen Dateianhang nicht ansehen.

Ich hoffe, damit beantwortet sich auch die Frage, warum es nicht nur box_dns_Srv0 gibt.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

mi.ke

#202
Zitat von: JoWiemann am 13 September 2024, 11:29:56ich habe jetzt die Readings box_dns_Srv<lfnd Nummer>_used_IPv4_<lfnd Nummer> und box_dns_Srv<lfnd Nummer>_used_IPv6_<lfnd Nummer> implementiert.

Klasse, das passt. Damit kann ich die Readings vergleichen.

und gleich unverschämt die nächste Frage:
Gibt es die Möglichkeit, den "guestWlanName" abzufragen?
Dynamisch ist er ja jetzt.

Danke und Grüße
mi.ke

FHEM 5.9 | RPi4 + 5 x RPi(Z) + FB7590 + FB 6890 LTE via LAN und WAN (VPN) verbunden.
2 x CUL868 + 3 x RFXTRX(e) + 6 x HMwLanGW + 4 x z2tGw + 5 x LGW + 2 x IRBlast + CO2 +++
FS20, FHT, FMS, Elro(mod), CM160, Revolt, LGTV, STV, AVR, withings, HM-sec-*, HM-CC-RT-DN, AMAD, PCA301, arlo, Aqara

RalfRog

Zitat von: JoWiemann am 13 September 2024, 11:29:56Die Rückmeldung der FB zeigt, dass es wohl mehr als box_dns_Srv0 geben kann. In welcher Umgebung das zutrifft, keine Ahnung.

Hallo
Ja...hm...
Bisher und mit der aktuellen Beta bekomme ich beim Dualstack (IPv4, IPv6) vier DNS-Server und bei DS-Lite zwei DNS-Server angezeigt (automatisch zugwiesen)
Dual Stack
07.57.13d
box_dns_Server0   2001:4dd0:100:4220:53:2::4   2024-03-15 17:58:13
box_dns_Server1   2001:4dd0:200:304:53:2::5    2024-03-15 17:58:13
box_dns_Server2   81.173.194.76                2024-03-15 17:58:13
box_dns_Server3   81.173.194.69                2024-03-15 17:58:13

07.57.15c BETA
box_dns_Server0   2001:4dd0:100:1020:53:2::1   2024-09-14 10:40:59
box_dns_Server1   2001:4dd0:100:4220:53:2::4   2024-09-14 10:40:59
box_dns_Server2   194.8.194.60                 2024-09-14 10:40:59
box_dns_Server3   81.173.194.76                2024-09-14 10:40:59

DS-Lite
07.57.15c BETA
box_dns_Server0   2a01:860::53                 2024-09-14 10:28:17
box_dns_Server1   2a01:860::153                2024-09-14 10:28:17
Soweit so korrekt. Die neuen Readings zeigen sich noch nicht.

Da spiel ich mal mit dem Manuellen Eintrag -- tatsächlich erst mit dem neuen Attribut erscheinen sie.
box_dns_Server0           2a01:860::53          2024-09-14 12:04:05
box_dns_Server1           2a01:860::153         2024-09-14 12:04:05
box_dns_Srv0_used_IPv6_0  2a01:860::53          2024-09-14 12:04:05
box_dns_Srv0_used_IPv6_1  2001:4860:4860::8844  2024-09-14 12:04:05
was AVM sich dabei denkt....

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

caldir65

Moin,

ich habe ein Problem mit ledsetting im Zusammenspiel mit Homemode - da ich nicht genau weiß, wo es einzuordnen ist, habe ich es in Automatisierung angelegt, will aber hier kurz darauf verweisen, um nicht doppelt zu posten ...

Gruß. Christoph
Alte Techniker-Regel: "kaum macht man es richtig, funktioniert es auch"
------
Dell Wyse5070 ThinClient 16GBRam, 128GB SSD, Lubuntu 24.04.01LTS, fhem (aktuell), debmatic, Homematic-Devs, ConBee II und deConz, viele Shellys, Rademacher, NextCloud-Anbindung, FullyKioskBrowser+FUIP uvm.

RalfRog

#205
Hallo Jörg zur 07.57.15c BETA
Ich habe eine per VPN angebundene 7430 (FW 146.07.31)

Heute Nacht gab es die Meldung: "Timeout when reading Fritz!Box data. 285 | BlockingKill"

state                   Error: Timeout when reading Fritz!Box data. 285 | BlockingKill  2024-09-15 00:28:55
retStat_lastReadout     22 values captured in 9.24 s                                    2024-09-15 10:54:11
retStat_processReadout  0.08 s                                                          2024-09-15 10:54:11

Der Zustand ist bis jetzt 11 Uhr geblieben. Lediglich 22 values werden in jedem Intervall abgefragt.
Nach "check API" passt es wieder.

Bin leider unterwegs und komme heute nicht mehr dazu das genauer zu checken bzw. per Log festzuhalten.

uups... im Logfile vor 0:28 Uhr pro Abfrage im Intervall
2024.09.14 12:14:17.662 2: [fritzkat | 7430 | 146.07.31 | Readout_Response.5736] - SIGNIFICANT:no HASH from JSON returnedbzw. nach 0.28 Uhr
2024.09.15 00:46:03.814 2: [fritzkat | 7430 | 146.07.31 | Readout_Response.5736] - SIGNIFICANT:JSON: Old SID not valid anymore.
2024.09.15 00:46:04.387 2: [fritzkat | 7430 | 146.07.31 | Readout_Response.5736] - SIGNIFICANT:303 See Other

Ich schau mir das morgen nochmal an. Es sein denn du hasst ad hoc ne Idee zum Verhalten.

Gruß Ralf

P.S.
liegt vielleicht am aktiven Attribut "enableBoxReadings" obwohl dazu keine Daten kommen und das Attribut die Readings auch nicht in der Liste erscheint.
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

ch.eick

Hallo zusammen,
ich betreibe seit Jahren mehrere Fritz!Box, alle mit VERSION 07.57.13d

1. FRITZ!Box 7490 (UI)
    ZentrumRouter
2. FRITZ!Box 7490 (UI)
    ZentrumRepeater01
3. FRITZ!Box 7362 SL (UI)
    ZentrumRepeater02

FVERSION 72_FRITZBOX.pm:0.289950/2024-06-21

Seit geraumer Zeit kommt es jedoch bei allen Shellys zu Netzwerkproblemen,
die dann wegen des Timeouts zum kurzen Stocken in FHEM führen.
Die Shellys sind auf aktueller FW und sind mit "FVERSION 36_Shelly.pm:v5.21.1-s28696/2024-03-22" in FHEM eingebunden.
Ein connect auf die Shelly GUI läuft problemlos.

Da auch ebenfalls Timeouts 72_FRITZBOX.pm kommen vermute ich hier ein Problem.

Ich habe bereits "nonblockingTimeOut 75" gesetzt und sehe diese Meldungen aktuell nicht mehr.
2024.09.15 09:58:10.744 2: [ZentrumRepeater01 | 7490 | 113.07.57 | open_Web_Connection.9555] - SIGNIFICANT:Web connection could not be established. Please check your credentials (password, user).
2024.09.15 09:58:10.745 2: [ZentrumRepeater01 | 7490 | 113.07.57 | Readout_Response.5182] - SIGNIFICANT:Web connection could not be established
2024.09.15 10:00:59.197 2: [ZentrumRepeater01 | 7490 | 113.07.57 | open_Web_Connection.9555] - SIGNIFICANT:Web connection could not be established. Please check your credentials (password, user).
2024.09.15 10:00:59.199 2: [ZentrumRepeater01 | 7490 | 113.07.57 | Readout_Response.5182] - SIGNIFICANT:Web connection could not be established
2024.09.15 10:03:59.641 2: [ZentrumRepeater01 | 7490 | 113.07.57 | open_Web_Connection.9555] - SIGNIFICANT:Web connection could not be established. Please check your credentials (password, user).
2024.09.15 10:03:59.643 2: [ZentrumRepeater01 | 7490 | 113.07.57 | Readout_Response.5182] - SIGNIFICANT:Web connection could not be established
2024.09.15 10:07:58.791 1: [ZentrumRepeater01 | 7490 | 113.07.57 | Readout_Aborted.5522] - ERROR:Error: Timeout when reading Fritz!Box data. 285 | BlockingKill
2024.09.15 10:20:36.000 1: [ZentrumRepeater01 | 7490 | 113.07.57 | Readout_Aborted.5522] - ERROR:Error: Timeout when reading Fritz!Box data. 285 | BlockingKill

2024.09.15 11:06:39.632 2: WB_1_MQTT2: No PINGRESP for last PINGREQ (at 2024-09-15 11:05:58), disconnecting
2024.09.15 11:06:39.633 1: 192.168.178.61:1883 disconnected, waiting to reappear (WB_1_MQTT2)
2024.09.15 11:06:39.641 3: [Shelly_status] shelly06: Error in callback, update in 60 seconds
2024.09.15 11:06:39.641 1: [Shelly_status] Device shelly06 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.09.15 11:06:39.643 3: [Shelly_status] shelly03: Error in callback, update in 60 seconds
2024.09.15 11:06:39.644 1: [Shelly_status] Device shelly03 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.09.15 11:06:39.650 3: [Shelly_status] shelly01: Error in callback, update in 60 seconds
2024.09.15 11:06:39.651 1: [Shelly_status] Device shelly01 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.09.15 11:06:39.669 3: [Shelly_status] shelly07: Error in callback, update in 60 seconds
2024.09.15 11:06:39.670 1: [Shelly_status] Device shelly07 has Error 'Error: Timeout connecting', state is set to 'Error: Network'
2024.09.15 11:06:39.686 3: [Shelly_status] shelly01: Error in callback, update in 60 seconds
2024.09.15 11:06:39.687 1: [Shelly_status] Device shelly01 has Error 'Error: Timeout reading', state is set to 'Error: Network'
2024.09.15 11:06:39.692 3: [Shelly_status] shelly06: Error in callback, update in 60 seconds
2024.09.15 11:06:39.693 1: [Shelly_status] Device shelly06 has Error 'Error: Timeout reading', state is set to 'Error: Network'
2024.09.15 11:06:40.176 1: 192.168.178.61:1883 reappeared (WB_1_MQTT2)

Das habe ich bereits gemacht:
- FHEM "update all" (was ich regelmäßig mache)
    >> keine Updates verfügbar
- Fritz!Box
    >> keine Updates verfügbar
- Shellys
    >> keine Updates verfügbar

- 5 GHz abgeschaltet
- nonblockingTimeOut 75
- check API

- Reboot der Fritz!Boxen
- Reboot der Shellys

Attributes:
   INTERVAL   180
   alias      ZentrumRouter
   boxUser    fritz6716
   event-on-change-reading mac.*
   nonblockingTimeOut 75

Hat jemand einen Tip, wo ich noch weiter suchen könnte?

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

JoWiemann

Hallo ch.eick,

nimmt bitte einmal die Beta von hier:  https://forum.fhem.de/index.php?msg=1320025. hier sind ein paar Fehler gefixed.

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

Hallo ch.eick,

hm, Deine Shellys wollen jede Sekunde eine Verbindung. Sie fragen also jede Senunde den DNS der FB ab. Bei genügend Shellys scheint die FB ein Performance Problem zu haben und antwortet stark verzögert. Haben die Shellys auch Verbindung zur Shelly Cloud?

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

ch.eick

#209
Zitat von: JoWiemann am 15 September 2024, 19:03:32Deine Shellys wollen jede Sekunde eine Verbindung. Sie fragen also jede Sekunde den DNS der FB ab. Bei genügend Shellys scheint die FB ein Performance Problem zu haben und antwortet stark verzögert. Haben die Shellys auch Verbindung zur Shelly Cloud?
Moin Jörg,
nee, die Cloud habe ich nicht aktiviert.
In der Fritzbox habe ich jedem Shelly eine feste IP und einen Namen eingetragen.
Kann ich das mit dem DNS irgendwie abschalten?

- Im Shelly wäre auch noch die Möglichkeit eine static IP einzutragen
- SNTP Server steht auf time.google.com
- CoIot ist aktiviert

Dein neues Beta Modul habe ich gerade aktiviert
2024.09.16 10:40:31.707 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/72_FRITZBOX.pm line 3252.
2024.09.16 10:40:32.017 2: [ZentrumRepeater02 | 7362 | 131.07.14 | Readout_Response.5736] - SIGNIFICANT:no HASH from JSON returned

Bei den Shellys habe ich die static IP eingetragen und rebooted
Meine openWB, die auch Meldungen erzeugt habe ich ebenfalls neu gestartet
FHEM wurde inklusive HW auch neu gestartet

Jetzt sehe ich noch diese Meldungen und denke die Fritzboxen sind überfordert, oder irgend ein Gerät
überflutet das Netzwerk.
2024.09.16 13:24:56.541 1: 192.168.178.61:1883 disconnected, waiting to reappear (WB_1_MQTT2)
2024.09.16 13:24:56.800 1: 192.168.178.61:1883 reappeared (WB_1_MQTT2)
2024.09.16 13:24:57.252 3: EVU_Tibber_connect:ws_onConnectionAck: got connection ack
2024.09.16 13:26:00.493 1: Timeout for FHEM::BEOK::NBStart reached, terminated process 23593
2024.09.16 13:26:20.956 1: Timeout for LUXTRONIK2_DoUpdate reached, terminated process 23584
2024.09.16 13:26:21.001 2: WB_1_MQTT2: No PINGRESP for last PINGREQ (at 2024-09-16 13:25:40), disconnecting
2024.09.16 13:26:21.002 1: 192.168.178.61:1883 disconnected, waiting to reappear (WB_1_MQTT2)
2024.09.16 13:26:21.209 1: 192.168.178.61:1883 reappeared (WB_1_MQTT2)

Einer der Shellys scheint echt defekt zu sein, der kommt nach einem Power off/on zwar wieder ins WLAN, verschwindet dann aber immer wieder.
2024.09.16 14:39:30.322 2: (Shelly_HttpResponse:err) Device shelly05 has Error '192.168.178.51: No route to host (113) :: /relay'
2024.09.16 14:40:22.609 2: (Shelly_HttpResponse:err) Device shelly05 has Error 'connect to http://192.168.178.51:80 timed out :: /status'


Hätte jemand eine Empfehlung für einen echt guten Ersatz?

VG  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick