Hallo allerseits,
mir gelingt der Betrieb des 72_FRITZBOX.pm nicht. Eine FritzBox 7490 im Originalzustand mit aktueller Firmware FRITZ!OS: 06.80 soll mit 72_FRITZBOX.pm an FHEM 5.8 (Latest Revision: 13571) gekoppelt werden. Dabei läuft das FHEM auf einem NUC der über LAN an der FritzBox hängt. Der Telnet-Zugang ist bei FRITZ!OS: 06.80 nicht mehr vorhanden und die Koppelung sollte mit TR064 erfolgen. Auf der FritzBox wurde dazu ein Benutzer "fhem" mit eigenem Passwort angelegt. Da ich bei vorherigen Versuchen schon diverse Meldungen "403: Forbidden" bekommen habe, wurden dem Benutzer "fhem" erst mal alle Rechte zugeteilt. Das FHEM Modul wurde wie folgt angelegt:
defmod FritzBox FRITZBOX 192.168.5.1
attr FritzBox allowTR064Command 1
attr FritzBox boxUser fhem
attr FritzBox fritzBoxIP 192.168.5.1
attr FritzBox icon it_router@blue
attr FritzBox room IO
attr FritzBox verbose 5
set FritzBox password ganz_geheimes_Passwort
Im event monitor erscheint alle 10s die Meldung "4 : FRITZBOX FritzBox: Readout_Start.675 Skip fork process FRITZBOX_API_Check_Run". Im Wiki gibt es unter https://wiki.fhem.de/wiki/FRITZBOX#Modul_bleibt_im_Status_.22Check_APIs.22_h.C3.A4ngen (https://wiki.fhem.de/wiki/FRITZBOX#Modul_bleibt_im_Status_.22Check_APIs.22_h.C3.A4ngen) den Hinweis, dass in gewissen Situationen ein FHEM-Neustart hilft. Das ist bei mir nicht der Fall. Auch ein Neustart der Fritzbox und danach des kompletten NUC auf dem das FHEM läuft ändert nichts.
Es ist mir irgendwie ein einziges mal gelungen vom FHEM aus einen DECT-Sammelruf (call **9) zu veranlassen. Aber ich konnte das nie wieder reproduzieren. Die ständigen API-Checks machen auf der FritzBox offenbar soviel Stress, dass die (zumindest teilweise) im Laufe des Tages neu startet. Ich habe einen e-Mail-Push bei neuer DSL-IP-Adresse laufen. Das kommt normalerweise einmal pro Nacht vor. Wenn 72_FRITZBOX.pm (mit allen Rechten) läuft, kommt diese e-Mail auch tagsüber. Deshalb würde ich eigentlich gerne die Rechte wieder reduzieren.
Hat außer mir jemand ein aktuelles FHEM an (nicht in) einer aktuellen FritzBox laufen und könnte mir die genaue Vorgehensweise schildern?
Danke
Hallo,
ich würde diese Frage nicht im Anfänger bereich sondern im Fritzbox Bereich stellen. Verschieben kannst Du den Thread selbst.
Ich betreibe das ohne separaten boxUser, die Rechte Verwaltung auf der FB mit unterschiedlichen Usern hat bei mir nie zu einem funktionierenden und von mir erwarteten Ergebnis geführt.
Gruß Otto
mein fhem ist zwar 4 wochen alt, aber 7490 mit fw 06.80 funktioniert.
ich nutze die "normalen" zugangsdaten und habe keine besonderen berechtigungen gesetzt.
poste mal die ausgabe von "list FritzBox".
hast du alle perl module?
The modul uses the Perl modul 'Net::Telnet', 'JSON::XS', 'LWP', 'SOAP::Lite' for remote access.
Hallo,
@Otto123 ist verschoben. Danke. Mich hatte nur irritiert, dass die FritzBox hier nur unter "FHEM - Hardware" auftaucht. Weil genau als solche betreibe ich die FritzBox ja gerade nicht. Der Hinweis mit dem Benutzer ist interessant. Wird nachher gleich mal probiert. Es widerstrebt mir nur, den "heiligen" root-Account für automatische Dinge irgendwo anders einzutragen. Aber einen Versuch ist es wert zumal der frank das wohl auch so macht.
@frank Der "normale" Benutzer hatte für meinen Geschmack einfach zuviel Rechte. Aber wenn es anders nicht geht. Die Module sind installiert:
Net::Telnet 3.04
JSON::XS 3.03
LWP 6.15
SOAP::Lite 1.20
Hab eben noch ein cpan-outdated -p | cpanm laufen lassen und beide Geräte neu gestartet. Werde gleich über Erfolg oder Misserfolg berichten und die Ausgabe von list FritzBox posten.
ZitatDer "normale" Benutzer hatte für meinen Geschmack einfach zuviel Rechte. Aber wenn es anders nicht geht.
anders habe ich es nie probiert.
So jetzt erster Versuch: Das ganze Perl Zeug mit cpan-outdated -p | cpanm auf Stand gebracht und FritzBox und NUC gebootet. Den Benutzer hab ich erst mal gelassen. Der erste Erfolg besteht darin, dass Check-API auch wieder aufhört und im Eventlog die Meldungen ausbleiben. Es werden sogar Werte von der FritzBox gelesen. Ein call **9 tut nicht. Allerdings wird die FritzBox derartig gestresst, dass sogar meine DECT-Geräte zum Teil ihre Basis verlieren und auf der Web-Oberfläche seltsame Dinge passieren (flimmerndes Menue). Stellt man 72_FRITZBOX.pm ab, ist der Spuk vorbei.
Zweiter Versuch: Das FRITZBOX Modul im FHEM und den Benutzer "fhem" in der FritzBox gelöscht. Das Modul mit dem "normalen" Root-User neu angelegt. Das Modul beschwert sich erst mal, dass es keine Session ID bekommt, dürfte am fehlenden oder falschen Passwort liegen. Also Passwort neu eingetragen und FHEM neu gestartet. Jetzt kommen wieder alle 10 Sekunden die Meldungen
4 : FRITZBOX FritzBox: Readout_Start.675 Skip fork process FRITZBOX_API_Check_Run
und ein list FritzBox zeigt:
Internals:
APICHECKED 0
DEF 192.168.5.1
HOST 192.168.5.1
INTERVAL 300
LUAQUERY -1
NAME FritzBox
NR 130
REMOTE -1
STATE Check APIs
TELNET -1
TR064 -1
TYPE FRITZBOX
WEBCM -1
Readings:
2017-03-02 11:59:42 alarm1 Wecker 1
2017-03-02 11:59:42 alarm1_state off
2017-03-02 11:59:42 alarm1_target FON 1
2017-03-02 11:59:42 alarm1_time 00:00
2017-03-02 11:59:42 alarm1_wdays daily
2017-03-02 11:59:42 alarm2 Wecker 2
2017-03-02 11:59:42 alarm2_state off
2017-03-02 11:59:42 alarm2_target FON 1
2017-03-02 11:59:42 alarm2_time 00:00
2017-03-02 11:59:42 alarm2_wdays daily
2017-03-02 11:59:42 alarm3 Wecker 3
2017-03-02 11:59:42 alarm3_state off
2017-03-02 11:59:42 alarm3_target FON 1
2017-03-02 11:59:42 alarm3_time 00:00
2017-03-02 11:59:42 alarm3_wdays daily
2017-03-02 11:59:42 box_connect 5
2017-03-02 11:59:42 box_cpuTemp 56
2017-03-02 11:59:42 box_dect on
2017-03-02 11:59:42 box_fwVersion 113.06.80
2017-03-02 11:59:42 box_guestWlan off
2017-03-02 11:59:42 box_guestWlanCount 0
2017-03-02 11:59:42 box_guestWlanRemain 0
2017-03-02 11:59:42 box_ipExtern <Meine_IP>
2017-03-02 11:59:31 box_model FRITZ!Box 7490 [avm]
2017-03-02 11:59:42 box_moh sound
2017-03-02 11:59:42 box_powerRate 45
2017-03-02 11:59:42 box_rateDown 0.149
2017-03-02 11:59:42 box_rateUp 0.116
2017-03-02 11:59:42 box_stdDialPort allFons
2017-03-02 11:59:42 box_tr064 on
2017-03-02 11:59:42 box_tr069 off
2017-03-02 11:59:42 box_wlanCount 2
2017-03-02 11:59:42 box_wlan_2.4GHz on
2017-03-02 11:59:42 box_wlan_5GHz off
<Meine DECT Geräte>
2017-03-02 11:59:42 fon1 Telefon
2017-03-02 11:59:42 fon1_intern 1
2017-03-02 11:59:42 fon1_out SIP1
2017-03-02 11:59:42 fon2 Telefon
2017-03-02 11:59:42 fon2_intern 2
2017-03-02 11:59:42 fon2_out SIP1
2017-03-02 12:02:47 lastReadout Error: Timeout when reading Fritz!Box data.
<MAC-Adressen meiner Netzteilnehmer>
2017-03-02 12:02:47 state Error: Timeout when reading Fritz!Box data.
2017-03-02 11:59:42 tam1 Anrufbeantworter
2017-03-02 11:59:42 tam1_newMsg 0
2017-03-02 11:59:42 tam1_oldMsg 0
2017-03-02 11:59:42 tam1_state on
2017-03-02 11:59:42 user01 (guest)
2017-03-02 11:59:42 user01_thisMonthTime 0:00
2017-03-02 11:59:42 user01_todaySeconds 0
2017-03-02 11:59:42 user01_todayTime 0:00
2017-03-02 11:59:42 user01_type Guest
2017-03-02 11:59:42 userTicket01 584896
Fhem:
LOCAL 0
definedHost 192.168.5.1
is_double_wlan -1
lastHour 0
modulVersion $Date: 2017-01-27 19:09:22 +0100 (Fri, 27 Jan 2017) $
Helper:
TimerCmd FritzBox.Cmd
TimerReadout FritzBox.Readout
Readout_running_pid:
abortFn FRITZBOX_Readout_Aborted
arg FritzBox
bc_pid 3
finishFn FRITZBOX_Readout_Done
fn FRITZBOX_API_Check_Run
pid DEAD:3096
timeout 55
Abortarg:
Attributes:
allowTR064Command 1
boxUser root
fritzBoxIP 192.168.5.1
icon it_router@blue
room IO
verbose 5
Ist also nicht wirklich besser geworden, vor allem dürften die vielen '-1' nicht unbedingt Betriebsbereitschaft signalisieren. Die Frage ob Check-API im 10s Dauerbetrieb hängen bleibt, scheint Glücksache zu sein. Bei manchen Neustarts klappt das dann auch mal und man erhält STATE WLAN: on gWLAN: off. Nur ein call **9 tut auch dann nicht. Das list FritzBox unterscheidet sich dann in:
APICHECKED 1
LUAQUERY 0
M3U_LOCAL ./www/images/FritzBox.m3u
M3U_URL unknown
NAME FritzBox
NR 130
REMOTE 1
SECPORT 49443
STATE WLAN: on gWLAN: off
TELNET 0
TR064 1
TYPE FRITZBOX
WEBCM 0
Ein get FritzBox ringTones liefert ein plausibles Ergebnis. Aber das set FritzBox call **9 führt weiterhin zu zwei Meldungen:
3 : FRITZBOX: set FritzBox call **9
4 : FRITZBOX FritzBox: Set_Cmd_Start.2071 Fork process FRITZBOX_Call_Run_Web
und danach passiert nichts. Gerade ist die FritzBox wieder durchgestartet (die haben da vermutlich eine Art Watchdog). In der Art kann man das nicht betreiben. Das sabotiert mir den stabilen Betrieb der FritzBox. Interessanterweise auch als "normaler" Root-User bekomme ich ab und zu "403 Forbidden". Das löst also leider beides nicht das Problem.
Wie aktuell ist das FHEM?
Läuft übrigens bei mir mit einem eigenen User.
Hast Du in der Fritte User/Passwort eingestellt? Oder nur "Passwort"?
lösch mal folgendes attribut
ZitatfritzBoxIP <IP Address>
Depreciated.
du hast auch einige timeout. schau mal hier https://forum.fhem.de/index.php/topic,67828.0.html (https://forum.fhem.de/index.php/topic,67828.0.html)
für call's nutze ich mittlerweile das 96_sip modul.
die "-1" zeigen sicherlich an, dass noch nicht gecheckt wurde.
Hallo Wernieman, der Setup und die Versionen stehen in meinem ersten Beitrag. Alles so aktuell wie möglich und der User wird im FHEM mit attr FritzBox boxUser fhem eingestellt und in der FritzBox wie üblich auf der Web-GUI. Die Passwörter hatten auch jedes mal geklappt. Ansonsten bekommt man eine Meldung dass die Session-ID nicht geholt werden konnte. Das wäre auch ein toller DOS-Bug im FritzOS, wenn man die "Fritte" ohne gültigen Account rebooten könnte. Dass es keinen Unterschied macht ob man den Default-User oder einen angelegten verwendet kann ich nach dem letzten Test jetzt auch bestätigen.
Hallo Frank, das
fritzBoxIP ist draußen. Ich hab auch (wie in dem referenzierten thread beschrieben) den Timeout von 55 auf 132 gepatched und FHEM neu gestartet. Das ändert aber nichts an dem Call-Timeout:
2017.03.02 13:34:54 3 : FRITZBOX: set FritzBox call **9
2017.03.02 13:34:54 4 : FRITZBOX FritzBox: Set_Cmd_Start.2071 Fork process FRITZBOX_Call_Run_Web
2017-03-02 13:34:54 FRITZBOX FritzBox call **9
2017.03.02 13:36:24 1 : Timeout for FRITZBOX_Call_Run_Web reached, terminated process 19331
2017.03.02 13:36:24 1 : FRITZBOX FritzBox: Set_Cmd_Aborted.2118 Timeout reached for: call **9
Einige Timeouts im Log sind vermutlich auch eine Folge der durchbootenden FritzBox. Da verhaspelt sich irgendwas gründlich.
Aber 96_SIP.pm ist vermutlich die stabilere Methode. Werde ich mal probieren. Ich hatte nur gehofft, dass man mit 72_FRITZBOX.pm auf ein paar von den "Smart Home" Geräten wenigstens lesend zugreifen kann. Aber 72_FRITZBOX.pm listet (wenn es mal gerade läuft) einen Haufen Zeug aber nichts von dem was interessant wäre. Hauptanliegen bei mir ist im Moment
- interne Sammelrufe erkennen (Türsprechanlage ist ein DECT-Gerät)
- Sammelrufe absetzen (für sonstige Signalisierungen)
Die Temperaturen der diversen AVM-Smart-Komponenten wären noch schön gewesen. Aber Signalisierung mit SIP ist wie es jetzt aussieht die bessere Methode. Danke
NACHTRAG: Hab eben SIP eingerichtet. Allein diese
sip_listen dtmf Funktion ist ja herrlich. Da wird jedes Telefon zur FHEM-Fernsteuerung. Allerdings hab ich noch so ein Henne-Ei-Problem. Das SIP-Modul nimmt jetzt natürlich blitzschnell auch alle Sammelrufe (z.B. von der Türklingel) an. Das ist zum einen gut, weil ich am Teilnehmer im FHEM erkenne, dass es die Türklingel ist. Zum anderen ist es aber schlecht, weil kein anderer mehr die Türklingel hört. Jetzt könnte man ein Notify einrichten um bei einem eingehenden Sammelruf selbst wieder einen zu erzeugen, aber dann klingeln zwar die anderen Telefone aber mit falscher Anzeige und wenn man dran geht kann man nicht mit dem netten Herrn von DHL sprechen. Den Sammelruf erkennen aber nicht annehmen wäre das richtige Verhalten. Nur wie?
NOCH EIN NACHTRAG: Sogar das Problem DTMF-Fernbedienung und Sammelruferkennung gleichzeitig lässt sich lösen. In der Fritzbox einen zweiten SIP-Account als Türsprechstelle einrichten. Die Türsprechstelle bekommt keine Sammelrufe lässt sich aber explizit anrufen. Auf diesem Account lässt man
sip_listen dtmf laufen. Auf dem als Telefon konfigurierten Account lässt man eine zweite Instanz von SIP mit
sip_listen wfp laufen. Der erkennt dann den Sammelruf aber geht nicht dran.