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

Otto123

Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

prodigy7

Zitat von: Otto123 am 05 Januar 2023, 09:31:24
mach doch einfach einen Eintrag
attr global exclude_from_update ...
Cool! Kannte ich noch nicht 😊 Unabhängig davon wäre es aber toll, mit Updates einfacher auf dem laufenden zu sein. Es wirklich tolle Arbeit die er da leistet mit der Erweiterung an dem Modul.

JoWiemann

Zitat von: prodigy7 am 05 Januar 2023, 08:13:38
@JoWiemann

Könntest du deine Variante mit der "offiziellen" Variante zusammenführen oder aber eine Update-URL einrichten, über die man deine Variante direkt in FHEM einbinden kann? Leider zerschießt mir ein FHEM Update jedes mal deine Variante und es wäre toll, wenn ich die ohne händisches wieder reinkopieren behalten kann.

Zusammenführen geht leider nicht, da ich nicht Maintainer bin. Einen Update Link kann ich aber einrichten. Hierfür muss das Modul umbenannt werden. Ideen sind willkommen.

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

prodigy7

Zitat von: JoWiemann am 05 Januar 2023, 16:08:53
Zusammenführen geht leider nicht, da ich nicht Maintainer bin. Einen Update Link kann ich aber einrichten. Hierfür muss das Modul umbenannt werden. Ideen sind willkommen.
Das wäre lieb von dir, Danke! :-) Ist die Umbenennung notwendig? "Überschreiben" geht nicht?

JoWiemann

Zitat von: prodigy7 am 05 Januar 2023, 16:32:56
Das wäre lieb von dir, Danke! :-) Ist die Umbenennung notwendig? "Überschreiben" geht nicht?

Bei mir sehe ich, dass das Fhem Update immer zuerst kommt. Sollte also funktionieren.

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

prodigy7

Zitat von: JoWiemann am 05 Januar 2023, 16:52:28
Bei mir sehe ich, dass das Fhem Update immer zuerst kommt. Sollte also funktionieren.
Dann wäre ja Überschreiben sinnvoller. Prinzipiell ist es ja kein komplett neues Modul sondern nur von dir erweitert. Entweder oder wird man vermute ich nicht benötigen.

dinkel75

Toll gemacht!
Würdest du mal gucken, ob du es irgendwie schaffts, dass set guestWlan onf/off funktioniert.
Bei mir funkt das nicht!
Danke!

RalfRog

Kann ich bestätigen.
Im FB-Fork 0.2.11c auf dem Produktivsystem geht es noch - mit dem aktuellen FFB-Fork 0.2.12 Beta 7b auf dem Testsystem nicht.
Habe beide parallel am Laufen.

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

Hm,

an guestWLAN on/off habe ich gar nicht gearbeitet. Ist immer noch so, wie seit der letzten originalen Version von tupol.

Ich Euch hier mal die Version an, die ich eigentlich veröffentlichen wollte. Bei mir funktioniert guestWLAN weiterhin.

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: prodigy7 am 05 Januar 2023, 16:53:45
Dann wäre ja Überschreiben sinnvoller. Prinzipiell ist es ja kein komplett neues Modul sondern nur von dir erweitert. Entweder oder wird man vermute ich nicht benötigen.

Leider nicht so einfach. Wird mit "update add" ein Repository ergänzt oder einfach nur ein "update all" für ein externes Rposirory gemacht, dann greifen bei Namensgleichheit die normalen Update Prozesse.

exclude from update -> beide Repositories werden für 72_FRITZBOX.pm gesperrt

ohne exclude from update:

es wird immer die 72_FRITZBOX.pm gezogen, die nicht den Bedingungen im Repository entspricht.

72_FRITZBOX.pm (Fork) aktuell, dann 72_FRITZBOX.pm (Fhem) nicht aktuell und überschreibt Fork
72_FRITZBOX.pm (Fhem) aktuell, dann 72_FRITZBOX.pm (Fork) nicht aktuell und überschreibt Fhem

Somit ein schönes Ping/Pong Spiel.

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

Zitat von: JoWiemann am 05 Januar 2023, 19:36:14
...
Ich Euch hier mal die Version an, die ich eigentlich veröffentlichen wollte. Bei mir funktioniert guestWLAN weiterhin.
...

Auf FB 7590 mot OS 7.29

  • Keine Meldungen im Hochlauf aufgefallen

Eine Auswahl mal quer durch den Garten

> set <name> guestWlan <on|off> => ok
> get <name> luaInfo <landevices|vpnShares|kidProfiles|userInfos>  => alle ok
> set <name> lockLandevice <number> <on|off>  => ok
> set <name> enableVPNshare <number> <on|off>  => ok
> get <name> tr064ServiceListe => ok
> get <name> tr064Command WANPPPConnection:1 wanpppconn1 GetInfo => ok
> get <name> ringTones  => ok
> set <name> macFilter <off>

die Userattribute funktionieren
> disableDectInfo 0/1
> enableUserInfo 0/1
> disableBoxReadings  kreut und quer an/abgehakt (Komma-Reading mal abwarten)
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

dinkel75

Bei mir funkt jetzt Gäste Wlan ein/aus. Hatte nach einer Neuinstallation die notwendigen Perl Module noch nicht drin.

RalfRog

@Jörg

Im genannten Fork "FB-Fork 0.2.12 Beta 7b" war denkke ich trotzdem etwas kaputt. Bei mir hätte es sonst funktionieren müssen, da nix fehlt.
Muss allerding zugeben nicht in der Box kontrolliert zu haben sondern nur im "state/STATE WLAN: on gWLAN: off"

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

prodigy7

Zitat von: JoWiemann am 05 Januar 2023, 19:42:19
Leider nicht so einfach. Wird mit "update add" ein Repository ergänzt oder einfach nur ein "update all" für ein externes Rposirory gemacht, dann greifen bei Namensgleichheit die normalen Update Prozesse.

exclude from update -> beide Repositories werden für 72_FRITZBOX.pm gesperrt

ohne exclude from update:

es wird immer die 72_FRITZBOX.pm gezogen, die nicht den Bedingungen im Repository entspricht.

72_FRITZBOX.pm (Fork) aktuell, dann 72_FRITZBOX.pm (Fhem) nicht aktuell und überschreibt Fork
72_FRITZBOX.pm (Fhem) aktuell, dann 72_FRITZBOX.pm (Fork) nicht aktuell und überschreibt Fhem

Somit ein schönes Ping/Pong Spiel.
Also doch eigene Bezeichnung? Oder vielleicht wäre der Maintainer des Modules bereit, deine Änderungen zu übernehmen und ihr pflegt das Modul zusammen? Wäre die Frage, was dagegen spricht. Aus meiner Sicht wäre das doch sinnvoller, wenn keine Stabilitätsgründe dagegen sprechen, als redundant Code zu schaffen.

JoWiemann

Hallo,

ich habe jetzt eine 72_FB_FORK.pm erstellt. Sofern von Euch abgesegnet würde ich diese in mein Repository stellen, so dass neue Versionen über das Fhem Update geholt werden können.

Grüße Jörg

PS: Wer das automatisierte Update ausprobieren möchte, dann bitte folgendes in die FhemWeb Kommandozeile eingeben:


update add https://raw.githubusercontent.com/jowiemann/FritzBox-for-Fhem/master/controls_fb_fork.txt


Das Repository ist unter: https://github.com/jowiemann/FritzBox-for-Fhem zu erreichen.

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