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

[the ratman]

wie wird den das werden? kann ich die daten des alten moduls irgendwie einfach in deines übernehmen, oder wirds 'ne abschreibübung?


btw - den sinn der fork versteh' ich halt nicht wirklich. warum muss sowas doppelt gemoppelt werden? im alten modul passiert doch scheinbar eh nix mehr.
bin aber sehr dankbar, dass du da weiter bastelst und wahrscheinlich das nicht in deiner entscheidungskompetenz liegt. ich hätt's nur immer gerne so simpel wie möglich.

[frank]

danke.

die version erscheint mir seltsam im vergleich.

Code Auswählen Erweitern

FB-Fork 0.14.0

wenn man die bisherige definition auf den neuen modulnamen ändert, muss man das passwort erneut setzen.
sonst keine auffälligkeiten.

[JoWiemann]

danke.

die version erscheint mir seltsam im vergleich.

Code Auswählen Erweitern

FB-Fork 0.14.0

wenn man die bisherige definition auf den neuen modulnamen ändert, muss man das passwort erneut setzen.
sonst keine auffälligkeiten.

Das ist so gewollt, da das Passwort vom Device-Namen und Modul-Name abhängig ist.

[RalfRog]

...
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.

Code Auswählen Erweitern


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.

Zum Absegnen muss ich mich raushalten, da ich mich mit den Gepflogenheiten der Entwicklung und Benamung nicht wirklich auskenne.

Aber den Fork unter eigenem Namen und mit dem separatem Update-Mechanismus (wie z.B. auch bei FUIP von Thorsten Pferdekaemper) ist ja gut handhabbar.
Der Sprung von FB-Fork 0.2.13 auf FB-Fork 0.14.0 mit kurzer Erläuterung in #1 sicher auch kein Problem für die, die die letzten Wochen nicht verfogt haben.

Vielleicht schaut TUPOL trotz seines letzten Eintages (Bin aus diversen Gründen kaum noch aktiv in FHEM) ja nochmal hier rein... oder ne PM 

Gruß Ralf

[RalfRog]

wie wird den das werden? kann ich die daten des alten moduls irgendwie einfach in deines übernehmen, oder wirds 'ne abschreibübung?
....

uups... das gabs ja noch Abhängikkeiten zu Notify's, Abfrage MAC-Adressen  in 99_myUtils.pm usw.

Muss man doch ein wenig drüber nachdenken wie man das dann am geschicktesten bewerkstelligt (oder selber die bisherige Methode beibehalten).
Könnte man sich vielleicht in einem separaten Thead drüber austauschen?

Gruß Ralf

Edit:
Fangen die Nebenwirkungen nicht schon hier an?  ==> define Fritzbox FRITZBOX
Neues/weiters Modul braucht ein neues def? Oder?

[JoWiemann]

Der Sprung von FB-Fork 0.2.13 auf FB-Fork 0.14.0 mit kurzer Erläuterung in #1 sicher auch kein Problem für die, die die letzten Wochen nicht verfogt haben.

Die 14 ist verrutscht. Sorry für die Verwirrung. Also Fork 0.2.14. Ändere ich.

Repository ist aktualisiert.

Grüße Jörg

[JoWiemann]

uups... das gabs ja noch Abhängikkeiten zu Notify's, Abfrage MAC-Adressen  in 99_myUtils.pm usw.

Edit:
Fangen die Nebenwirkungen nicht schon hier an?  ==> define Fritzbox FRITZBOX
Neues/weiters Modul braucht ein neues def? Oder?

Ich habe das RAW in die Zwischenablage kopiert, das alte Device gelöscht und ein neues über das RAW, in dem ich das defmod angepasst habe, erstellt. Damit bleiben eigentlich alle Abhängigkeiten erhalten, da der Name des Device ja der selbe ist. Sollte auch für Sub's in der 99_myUtils.pm gelten.
Ein Restart von Fhem muss allerdings danach durchgeführt werden.

Grüße Jörg

[JoWiemann]

Vielleicht schaut TUPOL trotz seines letzten Eintages (Bin aus diversen Gründen kaum noch aktiv in FHEM) ja nochmal hier rein... oder ne PM 

Gruß Ralf

Das mit der PM habe ich schon versucht, als es um die ersten Anpassungen für die FritzOS 7.29 ging.

[eisman]

Ich habe das RAW in die Zwischenablage kopiert, das alte Device gelöscht und ein neues über das RAW, in dem ich das defmod angepasst habe, erstellt. Damit bleiben eigentlich alle Abhängigkeiten erhalten, da der Name des Device ja der selbe ist. Sollte auch für Sub's in der 99_myUtils.pm gelten.
Ein Restart von Fhem muss allerdings danach durchgeführt werden.

Grüße Jörg

shönes und gesundes jahr

habs auch so gemacht, und ging gut,,,,

ein paar Meldungen kommen dennoch

Code Auswählen Erweitern

2023.01.09 17:00:20 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused
2023.01.09 17:01:13 3: FB_FORK [FritzBox: API_Check_Run.1360] - INFO: FB_FORK modul runs in remote mode.
2023.01.09 17:01:13 3: FB_FORK [FritzBox: API_Check_Run.1380] - INFO: API webcm does not exist (404 Not Found)
2023.01.09 17:01:14 3: FB_FORK [FritzBox: API_Check_Run.1431] - INFO: Created m3u file '/opt/fhem/www/mp3/Fritzbox.m3u'.
2023.01.09 17:01:14 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused
2023.01.09 17:01:37 3: FB_FORK [FritzBox: API_Check_Run.1360] - INFO: FB_FORK modul runs in remote mode.
2023.01.09 17:01:37 3: FB_FORK [FritzBox: API_Check_Run.1380] - INFO: API webcm does not exist (404 Not Found)
2023.01.09 17:01:38 3: FB_FORK [FritzBox: API_Check_Run.1431] - INFO: Created m3u file '/opt/fhem/www/mp3/Fritzbox.m3u'.
2023.01.09 17:01:38 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused

gruss

[prodigy7]

Danke JoWiemann für deine Mühe!

Ich finde, dafür kannst du aber nichts, dass das so unglücklich ist. Die letzte Anpassung im SVN ist wenn ich es richtig gesehen habe, am 06.06.2020 passiert. Seitdem ist viel passiert und so ein Modul lebt auch davon, dass es weiterentwickelt wird, wie du es auch tust. Da dein Modul ja in dem Sinne keine Breaking-Changes beinhaltet und der vorherige Entwickler scheinbar nicht mehr aktiv ist, wäre ich eher dafür, dass dein Modul die Version ersetzt.
Finde so wie es jetzt ist, macht es dass nur unnötig kompliziert für jeden der FHEM nutzen möchte bzw. auch Einsteiger blicke da nicht wirklich durch. Bin jetzt nicht so drin, wie das FHEM organisatorisch aufgebaut ist, aber wird doch bestimmt jemanden geben, der hier eine Entscheidung treffen kann?

[JoWiemann]

shönes und gesundes jahr

habs auch so gemacht, und ging gut,,,,

ein paar Meldungen kommen dennoch

Code Auswählen Erweitern

2023.01.09 17:00:20 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused
2023.01.09 17:01:13 3: FB_FORK [FritzBox: API_Check_Run.1360] - INFO: FB_FORK modul runs in remote mode.
2023.01.09 17:01:13 3: FB_FORK [FritzBox: API_Check_Run.1380] - INFO: API webcm does not exist (404 Not Found)
2023.01.09 17:01:14 3: FB_FORK [FritzBox: API_Check_Run.1431] - INFO: Created m3u file '/opt/fhem/www/mp3/Fritzbox.m3u'.
2023.01.09 17:01:14 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused
2023.01.09 17:01:37 3: FB_FORK [FritzBox: API_Check_Run.1360] - INFO: FB_FORK modul runs in remote mode.
2023.01.09 17:01:37 3: FB_FORK [FritzBox: API_Check_Run.1380] - INFO: API webcm does not exist (404 Not Found)
2023.01.09 17:01:38 3: FB_FORK [FritzBox: API_Check_Run.1431] - INFO: Created m3u file '/opt/fhem/www/mp3/Fritzbox.m3u'.
2023.01.09 17:01:38 3: FB_FORK [FritzBox: API_Check_Run.1529] - ERROR: Could not open telnet connection to xxx.xxx.xxx.xxx: Connection refused

gruss

Die API Checks werde ich auf verbose 3 belassen. Der ERROR wird noch auf INFO umbenannt. Die Log=Einträge kommen eigentlich nur bei der Initialisierung des Devices.

Grüße Jörg

[JoWiemann]

Bin jetzt nicht so drin, wie das FHEM organisatorisch aufgebaut ist, aber wird doch bestimmt jemanden geben, der hier eine Entscheidung treffen kann?

Der Entscheider ist Rudi. Allerdings weiß ich nicht, ab wann ein Modul als verwaist angesehen wird.

Grüße Jörg

[the ratman]

Der Entscheider ist Rudi. Allerdings weiß ich nicht, ab wann ein Modul als verwaist angesehen wird.

also wenn ich nicht zu viel damit nerve, würde ich dich bitten, dass noch mit rudi abzusprechen.
vielleicht gibts ja doch 'ne möglichkeit, dich zum offiziellen maintainer zu machen und vielleicht das alte modul auf "*_alt" umzubenennen. das würde so herrlich viel probleme beseitigen, von denen ich bisher nicht mal 'ne ahnung habe ... aber die kommen sicher, das weiß ich *g*

[prodigy7]

Der Entscheider ist Rudi. Allerdings weiß ich nicht, ab wann ein Modul als verwaist angesehen wird.

Ich wollte ihn gerade mal persönlich anschreiben, um ihn auf das Thema hier aufmerksam zu machen, geht aber nicht weil er private Nachrichten blockiert hat. Vielleicht liest er ja aber mit und meldet sich

[enno]

Hallo Jörg,

Ich würde sagen: Einfach Rudi informieren und dann geht es seinen Weg. Ich würde für die Übernahme stimmen! Alles andere klingt nach Problemen wegen doppelten Modul...

https://forum.fhem.de/index.php/topic,129846.msg1241444.html#msg1241444

Gruss
  Enno