Laden...

PS Fritz!Box API - TR-064 Schnittstelle

Letzter Beitrag vor 2 Jahren 54 Posts 45.919 Views
PS Fritz!Box API - TR-064 Schnittstelle

Beschreibung:

Ich stelle hier meine Klassenbibliothek für den Zugriff auf die Fritz!Box bereit. Die Bibliothek enthält Klassen für den Zugriff auf verschiedene TR-064-Schnittstellen der Fritz!Box zur Abfrage von Informationen und zur Ausführung von Aktionen auf dem Gerät.

Projekt Informationen
Die Bibliothekist für .NET Standard Version 2.0 kompiliert und besitzt neben dem Standard SDK derzeit keine weiteren Abhängigkeiten.

Projekt auf Github: PS.FritzBox.API
Lizenz: MIT License
NuGet: PS.FritzBox.API

Hinweis Kabelboxen
_:::


DeviceLocator locator = new DeviceLocator();
var devices = await locater.DiscoverAsync();
if(devices.Count() > 0)
{
    var device = devices.First();
    ConnectionSettings settings = new ConnectionSettings()
    {
       UserName = "inflames2k";
       Password = "secret";
    };

    var client = await device.GetServiceClient<WANCommonInterfaceConfigClient>(settings);
    OnlineMonitorInfo monitor = await client.GetOnlineMonitorAsync(0);
}

Schlagwörter: Fritz!Box, Fritz!Box UPnP, Fritz!Box TR-064, TR-064

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Wäre es auch eine Option das Ganze auf GitHub Open Source zu machen, dass man hier auch aktiv mitmachen kann? Und als NuGet Paket anbieten...? Sharing via ZIP ist ja nicht so das Wahre 😃
Ansonsten fehlt mir hier auch die Angabe einer Lizenz.

Aber: super!

Habe das Projekt auf Github veröffentlicht und mich kurzerhand für die MIT-Lizenz entscheiden. - Link im Eingangsbeitrag. - Ein NuGet-Package habe ich ebenfalls erstellt und direkt bei NuGet veröffentlicht.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Also ich bekomme es trotz mehrere Anläufe nicht zum Laufen.

Trotz korrekter Settings gemäß Deiner Anleitung bekomme ich nur > Fehlermeldung:

System.Net.Http.HttpRequestException: 'An error occurred while sending the request.'

WinHttpException: A connection with the server could not be established

Und zwar mit Deinem Sample Code

            WANCommonInterfaceConfigClient client = new WANCommonInterfaceConfigClient("https://fritz.box", 10000);

            client.UserName = "Ben";
            client.Password = "xxxxxxxxxxxxxxxxxxxx";

            OnlineMonitorInfo monitor = await client.GetOnlineMonitor(0);

            Console.ReadKey();

Stelle ich interessehalber von https auf https, passiert einfach bis zum Timeout nichts.
Ich werde wohl ein wenig im Code Debuggen und wenn ich Zeit finde auch den ein oder anderen PR einreichen.
Generell bin ich zum Beispiel ein Freund eine von Connection Pooling statt überall das Passwort mitzugeben.
Ebenso ein paar Parameter Dinge; aber das bei Zeit dann.

Ist der Zugriff für Anwendungen auf deine Box aktiviert? Prüfen kannst du das im Webinterface der Box unter Heimnetz => Netzwerkeinstellungen im Bereich Heimnetzfreigaben. Bei mir ist das der Punkt "Zugriff für Anwendungen zulassen".

Ansonsten kann es u.U. auch sein, dass bei dir der Port für die Verbindung erforderlich ist. Probier mal mit der Url "https://fritz.box:49000".

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Ich hab eine 6490 Cable; unter System -> Fritz!Box-Benutzer -> Anmeldung im Heimnetz ist der Zugriff erlaubt. Unter Apps sehe ich meine Android App.
Also ja, soweit ich das sehe ist das alles aktiviert. Ich musste dies glaube ich schon für die Android FritzBox-App aktivieren; und die funktioniert.

Die Angabe des Ports war auch erfolglos.
Ich benutze meinen Adminuser.

Mit Port 49443 bekomme ich einen Internal Service Error.
Das is der Port, den ich bei meinen Versuchen damals genutzt hatte; denn 49000 dürfte kein HTTPS sein laut Doku.

fritz.box:49000/igddesc.xml liefert mir aber ein sauberes XML.

Da die Fehlermeldung ja WinHttpException: A security error occurred lautet vermute ich, dass dem HttpClient die Einstellung des Security Protokoll fehlt.
Evtl. ist dies ja bei den Fritzboxen jeweils anders (zB. weil der Provider an der FritzBox rumfingert). Also wahrscheinlich irgendwas wegen HTTPS.

Ja, laut Doku dürfte der Port 49433 aber auch nicht notwendig sein, wenn man die https-Url verwendet. Nichts desto trotz habe ich mit meiner Fon mal eben getestet was passiert, wenn ich den App-Zugriff deaktivere. - Dann kommt direkt ein Internal Server Error zurück.

Habe aber gerade einmal recherchiert. - Handelt es sich dabei um eine Box von Kabel Deutschland bzw. eine Box die mit einem Installationscode eingerichtet wurde?

Dann trifft eventuell folgendes Zitat:

es ist von Kabel Deutschland nicht vorgesehen, dass Änderungen an der Konfiguration der Fritzbox vorgenommen werden können. Aus diesem Grund ist der Zugriff über TR-064 nicht möglich.

Quelle: TR064 - 6490 - Entwickleranfrage

Weitere Quelle mit folgendem Zitat:

Bei Fritz!Boxen für den Kabelanschluss (z.B. Kabel Deutschland) scheint neben Telnet auch die TR064-API nicht zu funktionieren. Vermutlich wurde die API von AVM auf Betreiberwunsch deaktiviert, da man sonst Dinge ändern kann, die das gesamte Kabelnetz stören können. FHEM - FRITZBOX

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Ich bin nicht bei Kabel Deutschland, aber die Box ist vom Provider.
Also vielleicht ist tatsächlich der SOAP Zugriff gesperrt (REST geht).

Super. (Du kannst dafür natürlich nichts).

Gibt es zu der REST-API auch irgendwo Informationen?

// EDIT: Ich vermute mal, du beziehst dich da auf die Schnittstelle für die Home-Automation?

Weitere Frage, was erscheint denn wenn du http://fritz.box:49000/tr64desc.xml aufrufst?

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Ne war nicht direkt Home Automation, aber war auf alle Fälle diese *.lua API.
fritz.box/login_sid.lua war dazu mein Endpunkt.

REST ist auch zu viel gesagt.
Nennen wir es lieber JSON API.

Hallo,

ich habe eine neue Version der API veröffentlicht. - In der aktuellen Version wurden einige Umstrukturierungen innerhalb der API vorgenommen. Fehlerhafte Schnittstellen wurden korrigiert und neue Schnittstellen hinzugefügt.

Um den Konfigurationsaufwand auf die Nutzerdaten zu beschränken habe ich einen DeviceLocator implementiert. Dieser sucht per UPnP nach Fritzboxen im Netz und liefert diese als FritzDevice-Objekte zurück. - Auf die bereitgestellten Service-Clients kann dann durch die Methode "GetServiceClient" zugegriffen werden. - Die Methode nimmt die Authentifizierungsinformationen entgegen. - Die Angabe der Base URL ist bei Verwendung der FritzDevice-Klasse in Verbindung mit dem DeviceLocator nicht notwendig. - Lediglich Timeout, Nutzername und Passwort müssen gesetzt werden.

@Abt: Aufgrund von mir durchgeführter Anpassungen würde ich dich gern mal bitten, die API noch einmal zu testen. Möglicherweise lag hier doch ein Fehler meinerseits vor.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Hi. Jetzz kam ich endlich dazu.

Ich bekomm zwar ein paar Exceptions in der CMD-Testanwendung, aber ich kann mich problemlos einloggen, Device Info und Co abrufen:

GetDeviceInfo ############################# ManufacturerName: AVM ManufacturerOUI: 00040E ModelName: FRITZ!Box 6490 Cable (lgi) Description: FRITZ!Box 6490 Cable (lgi) 141.06.88 ProductClass: FRITZ!Box SerialNumber: xxxxxxxx SoftwareVersion: 141.06.88 HardwareVersion: FRITZ!Box 6490 Cable (lgi) SpecVersion: 1.0 UpTime: 161071 StartTime: 08.07.2018 23:21:57 DeviceLog: 10.07.18 10:02:55 Internetverbindung wurde erfolgreich hergestellt. IP-Adresse: xxx.xxx.xxx.xxx, DNS-Server: xxx.xxx.xxx.xxx und xxx.xxx.xxx.xxx, Gateway: xxx.xxx.xxx.xxx

PS:

Mir sind beim drüber schauen einige Dinge aufgefallen, die man verbessern könnte (Async-Naming, Task-Pitfalls, Enumeratoren werden mehrmals durchlaufen..)
Wenn ich dazu komm, mach ich Dir nen PR 😉

Sieht gut aus!

Alles klar, achte aber mit drauf, dass ich ja schon wieder an der nächsten Version arbeite (Development branch). Dort habe ich mir automatisch die "Proxies" generieren lassen und muss dies noch ein wenig Anpassen (doppelte Klassen etc. entfernen). Nicht das wir dann am Ende 2 Zweige haben, die nicht mehr kompatibel sind beim Merge vom Develop zum Master.

PS: Die nächste Version unterscheidet dann zwischen den IGD-Services und den durch AVM im TR064 abgelegten Services. - So können dann unabhängig voneinander die IGD bzw. TR064 Services verwendet werden.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Eigne Dir den GitHub-Flow an und arbeite mit Feature-Branches.
Das ist der übliche Weg in Open Source Projekten und ermöglicht erst eine ordentliche Zusammenarbeit.

Dev-Branch ist eher Git-Flow und hat leider nichts mit agiler, schneller Zusammenarbeit zutun 😉

Naja, werde jetzt sowieso demnächst den Dev-Branch (vermutlich am Wochende) bereinigen, in den Master übertragen und ab dann mit dem von dir beschriebenen Weg fortfahren. - Ich hoffe, du kannst bis dahin noch warten.

Die ganzen AVM-spezifischen Schnittstellen werde ich dann wohl sowieso erstmal wieder raus nehmen und an späterer Stelle wieder einbauen. So dass in der nächsten Version dann erstmal die ganzen WANDevice- und LANDevice Services sauber verfügbar sind.

Die Services wie z.B. das Telefonbuch würde ich dann über den von dir beschriebenen Weg (die Feature-Branches) hinzufügen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Wäre es eigentlich mit der Schnittstelle Möglich die Box neuzustarten?
Ich verteile an meinem Anschluss per Torrent Linux ISOs.
Hier scheint aber das Problem mit dem PUMA Bug aufzutreten, weshalb mein Upload und Download irgendwann zusammen brechnen und manchmal nur Kabel ziehen hilft.
Hier wäre es hilfreich, wenn ich über die Schnittstelle die Box neustarten könnte.
Dann könnte ich mir einen einfachen Task schreiben um die Box irgendwann in der Nacht mal neustarten zu lassen, wenn es klappt.

Wäre für feedback dankbar.

Nachtrag:
Hab es gefunden und ist möglich 😃
Die entsprechende Methode gibt es auch, leider bekomme ich in Version 1.2.1 eine Exeption bei wegen eines unerwarteten content-type.

Stacktrace (verkürzt):> Fehlermeldung:

System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.Xml.XmlException: Unerwartetes Token 'content-type'. Das erwartete Token ist '"' oder '''. Zeile 4, Position 18.
bei System.Xml.XmlTextReaderImpl.Throw(Exception e)
bei System.Xml.XmlTextReaderImpl.Throw(String res, String[] args)
bei System.Xml.XmlTextReaderImpl.ThrowUnexpectedToken(String expectedToken1, String expectedToken2)
bei System.Xml.XmlTextReaderImpl.ParseAttributes()
bei System.Xml.XmlTextReaderImpl.ParseElement()
bei System.Xml.XmlTextReaderImpl.ParseElementContent()
bei System.Xml.XmlTextReaderImpl.Read()
bei System.Xml.Linq.XContainer.ReadContentFrom(XmlReader r)
bei System.Xml.Linq.XContainer.ReadContentFrom(XmlReader r, LoadOptions o)
bei System.Xml.Linq.XDocument.Load(XmlReader reader, LoadOptions options)
bei System.Xml.Linq.XDocument.Load(TextReader textReader, LoadOptions options)
bei PS.FritzBox.API.SOAP.SoapClient.<ExecuteAsync>d__2.MoveNext()

Code sieht aktuell so aus


public static void Main(string[] args)
		{
			try
			{
				RebootAsync().Wait();
			}
			catch(Exception e)
			{
				Console.WriteLine(e);
			}
		}

		private static async Task RebootAsync()
		{
			ConnectionSettings settings = new ConnectionSettings()
			{
				UserName = ConfigurationManager.AppSettings["Username"],
				Password = ConfigurationManager.AppSettings["Password"],
				BaseUrl = ConfigurationManager.AppSettings["BaseUrl"]
			};

			DeviceConfigClient client = new DeviceConfigClient(settings);
			await client.RebootAsync();
		}

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Funktionieren denn andere Schnittstellen oder ist nur die Schnittstelle betroffen?

Probier mal folgendes:


DeviceLocator locator = new DeviceLocator();
var devices = await locater.DiscoverAsync();
if(devices.Count() > 0)
{
    var device = devices.First();
    ConnectionSettings settings = new ConnectionSettings()
    {
       UserName = "inflames2k";
       Password = "secret";
    };

    var client = await device.GetServiceClient<DeviceConfigClient>(settings);
    await client.RebootAsync();
}

Möglicherweise passt deine Base-Url nicht. Das könnten wir auf diesem Weg ausschließen, da die BaseUrl hier automatisch ermittelt wird.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

@inflames2k
Habe ich mal probiert, hier gibt es aber auch eine Fehlermeldung.


System.AggregateException: Mindestens ein Fehler ist aufgetreten. ---> System.Net.Sockets.SocketException: Ein ungültiges Argument wurde angegeben
   bei System.Net.Sockets.Socket.SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, Int32 optionValue, Boolean silent)
   bei System.Net.Sockets.Socket.SetSocketOption(SocketOptionLevel optionLevel, SocketOptionName optionName, Int32 optionValue)
   bei PS.FritzBox.API.DeviceLocator.<BeginSendReceiveAsync>d__3.MoveNext()

Nachtrag:
Nicht unwichtig sollte sein, dass ich ebenfalls eine Fritzbox 6490 Cable habe, aber eine eigene ohne Provider Branding/Firmware.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Hast du den Zugriff per TR64-API in der Box aktiviert?

Ansonsten, falls du dir bei Github mal den Source gezogen hast versuche mal in den Control-Pfaden "/upnp/" durch "/igdunpn/" zu ändern. - Eventuell funktionieren damit die Zugriffe, habe ich gerade im Internet entdeckt. - Sicher bin ich allerdings nicht, habe auch keine Cable mit der ich das testen kann.

Sollte es der Fall sein, überlege ich mir noch etwas wie man den Control-Pfad dynamischer gestalten kann.

Ich werde mich nun erst mal an das versprochene aufräumen machen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Sollte es der Fall sein, überlege ich mir noch etwas wie man den Control-Pfad dynamischer gestalten kann.

Wenn ich in IoT Projekten Eigenheiten für gewisse Devices hab, dann erstelle ich Profiles.
Sprich es gibt ein Standardprofile mit Settings; und wenn dann halt nen anderes Device gefunden wurde, wird das Profile gezogen.

Im Prinzip nichts anderes als das neue Konfigurationsmodell von .NET.
Das basiert ja auch auf dem Profile Prinzip.

Da ich nun wiedererwarten die letzten Monate nicht dazu gekommen bin, starte ich jetzt mit der Weiterarbeit am Projekt. - Den Development Branch lasse ich stehen, der wird aber derzeit keine Anwendung finden.

Weitergearbeitet wird mit dem Stand des Master Branches. Das aus dem Grund, dass damit auch die extremen Breaking Changes aus dem Development Branch entfallen.

@Abt: Das bedeuted jetzt natürlich, dass du auch auf den aktuellen Stand Änderungsvorschläge machen kannst.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

@inflames2k
Schön zu hören, dass es dort weiter geht 😃
Ich habe mitlerweile auch meinen Reboot Task zum laufen bekommen.
Soweit klappt also mit dem aktuellen Stand schon alles was ich brauche.
Wünsche aber denoch viel Erfolg bei der Weiterentwicklung.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Musstest du denn noch sachen Ändern, um den Reboot-Task auszuführen oder klappte das mit dem aktuellen Code? Das wäre insofern interessant als das ich etwaiige Änderungen für die nächste Version ja übernehmen könnte.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Der Code war soweit in Ordnung, nur die Url musste ich in der Config umstellen.

Url:
http://fritz.box:49000

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Hallo MyCharp-Mitglieder und Thread-Ersteller,

das ganze klingt super, aber kann ich damit auch die Voip/Call-Methoden aufrufen - wie hier beschrieben?

Vielen Dank im Voraus!
copa017

Im aktuellen Ausbaustand ist das leider nicht möglich.

// EDIT:
Da ich aktuell an meinem "FritzBox Manager" weiterarbeite werde ich bei Gelegenheit die VOIP Schnittstelle mit implementieren und eine neue Version der API bereitstellen in der auch die letzten Bugfixes enhalten sind.

Im übrigen: Falls jemand einen Weg findet, das komplette LOG der Box auszulesen per TR064 wäre ich sehr dankbar. - Scheinbar geht das nur für die Internetverbindung selbst, Telefonie und WLAN Logs habe ich bisher nicht lesen können.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

👍 👍

Hallo inflames2k!

Kannst du mir bitte kurz einen Status der Entwicklung der FritzboxAPI geben? Werden die vorhandenen Issues (https://github.com/inflames2k/PS.FritzBox.API/issues) in einer aktuellen Release berücksichtigt beziehungsweise arbeitest du noch an der API?

LG cop

Hallo,

ja ich arbeite noch da dran, bin aber in den letzten Monaten leider nicht mehr dazu gekommen. Natürlich werden auch die bekannten Probleme behoben. Da ich das Projekt aber privat bearbeite kann ich dir hier keinerlei zeitliche Schiene geben.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Gerade auch das Issue mit FritzOS7.10 dürfte noch etwas dauern.
Die Verteilung ist immer noch im Gange.
Für die Cable Boxen gibt es leider auch noch keinen Termin.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Hallo,

ja ich arbeite noch da dran, bin aber in den letzten Monaten leider nicht mehr dazu gekommen. Natürlich werden auch die bekannten Probleme behoben. Da ich das Projekt aber privat bearbeite kann ich dir hier keinerlei zeitliche Schiene geben.

Ok danke dir. Vielleicht kommst du ja demnächst dazu.

LG cop

Gerade auch das Issue mit FritzOS7.10 dürfte noch etwas dauern.
Die Verteilung ist immer noch im Gange.
Für die Cable Boxen gibt es leider auch noch keinen Termin.

T-Virus

Um welches Problem handelt es sich hier? Hat dies mit der FritzOS zu tun? Könnte man diesen Issue in der API von inflames2k fixen oder ist man abhängig von AVM?

LG cop

Ich hatte mich auf das Issue im Repository bezogen.
Ansonsten habe ich bereits seit einiger Zeit FritzOS 7.10 auf meiner 6490 Cable und bin soweit zu frieden.
Läuft alles rund und stabil.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Code Beispiel

Hallo inflames2k!

Ich hätte kurz deine aktuelle API ausprobiert, erziele dabei jedoch keinen Erfolgt.

Verwende ich deinen Code falsch?



FritzDevice device = new DeviceFactory().CreateDeviceAsync(System.Net.IPAddress.Parse("10.0.0.138")).GetAwaiter().GetResult();

ConnectionSettings settings = new ConnectionSettings();
settings.UserName = "username";
settings.Password = "passwort";
settings.BaseUrl = "http://10.0.0.138:49000/";

WLANConfigurationClient client = device.GetServiceClient<WLANConfigurationClient>(settings).GetAwaiter().GetResult();
client.SetEnableAsync(false);


Es tut sich einfach nichts. Vergleichbar jedoch mit einem PHP Skript kann erfolgreich das WLAN geschaltet werden:



$client = new SoapClient(null,array(	'location'		=> "http://10.0.0.138:49000/upnp/control/wlanconfig1",
										'uri'			=> "urn:dslforum-org:service:WLANConfiguration:1",
										'soapaction'	=> "urn:dslforum-org:service:WLANConfiguration:1#SetEnable",
										'noroot'		=> True,
										'login'			=> "username",
										'password'		=> "passwort"
	));

$client->SetEnable(new SoapParam(0, 'NewEnable'));


Lg cop

Was heißt denn, es passiert nichts?
Läuft der Code im Debugger bis zum Clientaufruf durch?

Funktionieren denn andere Anfragem auf den WLanConfigClient?

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Was heißt denn, es passiert nichts?
Läuft der Code im Debugger bis zum Clientaufruf durch?

Funktionieren denn andere Anfragem auf den WLanConfigClient?

Korrekt es läuft alles im Debugger einwandfrei durch, jedoch bleibt das WLAN auf der Fritzbox aktiv. Jeder Codezeile wird durchlaufen.

Vergleichbar mit dem PHP Skript, wird das WLAN einwandfrei deaktiviert.

Bevor ich hier deine API debugge wollte ich nachfragen, ob der von mir gepostete Code korrekt verwendet wird oder eventuell eine Codeanpassung für die Nutzung deiner API notwendig ist.

Andere Abfragen vom WLanConfigClient habe ich derzeit noch nicht probiert.

LG cop

Grundsätzlich sieht es eigentlich gut aus mit dem Code. Habe ihn mir jetzt aber nicht vollständig angesehen.

Allgemein kommst du wohl sowieso besser, wenn du async/await richtig implementierst statt mit den Awaitern manuell zu arbeiten.

Kann deinen Code allerdings momentan leider nicht ausprobieren, da mein Notebook in der Reparatur ist.

Es wird aber auch keine Exception geworfen?

Wie auch immer, versuch mal den Code umzustellen. Du arbeitest ja bestimmt auf einer Konsolenanwendung für den Anfang.

Probier mal:


        static async void Main(string[] args)
        {
            DeviceFactory factory = new DeviceFactory();
            FritzDevice device = await factory.CreateDeviceAsync(System.Net.IPAddress.Parse("10.0.0.138"));


            ConnectionSettings settings = new ConnectionSettings();
            settings.UserName = "username";
            settings.Password = "passwort";
            settings.BaseUrl = device.Location;

            WLANConfigurationClient client = await device.GetServiceClient<WLANConfigurationClient>(settings);
            await client.SetEnableAsync(false);
        }

Möglicherweise reicht es aber auch schon die BaseUrl wie ich es im obigen Code mache auf "device.Location" zu setzen.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

static async **Task **Main(string[] args) nicht static async void Main(string[] args)

static async **Task **Main(string[] args) nicht static async void Main(string[] args)

Ok danke für die Aufklärung.

Was aber würde hier den Unterschied machen bezüglich der Funktionalität wenn die Asynchrone Programmierung verwendet wird?

Sollte hier nicht das gleiche Ergebnis sein, sprich es egal ist ob async oder nicht.

LG cop

Hauptsächlich geht's dabei ums ExceptionHandling und ums "Timing" sprich das auf den Abschluss des Tasks gewartet wird was in deinem o.g. Beispiel nicht der Fall war und zu dem Fehler führte.

Wenn du Fiddler nebenher laufen lässt siehst du auch das der Request unvollständig ist.

Siehe: https://msdn.microsoft.com/magazine/jj991977

static async **Task **Main(string[] args) nicht static async void Main(string[] args)

Wobei ich dachte mir immer:

Die Methode mit dem async Schlüsselwort muss ein Task-Objekt (seit .Net 4.0) zurückgeben oder void zurückgeben.

Hauptsächlich geht's dabei ums ExceptionHandling und ums "Timing" sprich das auf den Abschluss des Tasks gewartet wird was in deinem o.g. Beispiel nicht der Fall war und zu dem Fehler führte.

Wenn du Fiddler nebenher laufen lässt siehst du auch das der Request unvollständig ist.

Siehe:
>

ok danke!

LG cop

Wobei ich dachte mir immer:

Die Methode mit dem async Schlüsselwort muss ein Task-Objekt (seit .Net 4.0) zurückgeben oder void zurückgeben.

Dann schau Dir nochmal async/await an - es gibt nur einen einzigen Fall, bei dem async void erlaubt ist.
Bitte aber nicht hier diskutieren - das ist der Snippet-Bereich.

Ich habe nun eine neue Version (1.2.2) hochgeladen. Diese ist mit FritzOS 7.10 getestet. Soweit konnte ich keine Probleme feststellen.

Folgende Änderungen haben sich ergeben:


[list]
\* Korrektur von Datentypen und Schnittstellen
\* Schnittstelle für WANDSLIfConfig verfügbar (WANDSInterfaceConfigClient)
\* Schnittstelle für 5GHz WLAN Konfiguration verfügbar (WLANConfigurationClient2)
\* Schnittstelle für Gäste WLAN Konfiguration verfügbar (WLANConfigurationClient3)
[/list] 

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Hab meinen Restart Task auch gleich mit der neuen Version bestückt und auch gegen meine Cable 6490 mit 7.10 getestet.
Funktioniert soweit reibungslos ohne Code Anpassungen auf meiner Seite.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Da bin ich ja beruhigt. Allerdings scheint der Reboot die ganze Zeit sauber gelaufen zu sein.

An der Stelle habe ich keine Anpassungen gemacht und lediglich gestern mal getestet wie es sich verhält. Dachte zwar im ersten Moment 'Da seh ich ja wo es knallt' aber als dann einfach die WLAN Verbindung weg war wusste ich, dass es ja grundsätzlich noch funktioniert.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Jopp läuft super 😃
Ohne deine lib hätte ich sonst irgendwas selbst basteln müssen, damit ich die Cable neugestartet kriege.
Ohne den täglichen Restart ist die Box dank Intels PUMA 6/7 Bug nach einigen Tagen einfach nicht mehr nutzbar.
Manchmal ist die Box auch schon nach einem Tag nicht mehr nutzbar, dann hilft eben nur Neustarten.
Und da hat dein Lib mir eine Menge Zeit und Nerven gespart 😃

Vielleicht brauche ich später mal ein paar Tools um die Box auch ohne direkten Zugriff etwas zu verwalten.
Aber bis dahin reicht mir der Neustart.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

Nur um noch einmal einen aktuellen Stand zu bringen. Aktuell arbeite ich an Version 1.2.4.

Was wird die Version bringen?* derzeit fehlende Service-Clients werden vollständig implementiert

  • Optimierungen für Verwendung der Klasse FritzDevice

Für die Klasse FritzDevice ändert sich folgendes:* erhält Property für Credentials: Dient der Erzeugung der ServiceClients. Eine Konfiguration von Nutzername und Passwort pro ServiceClient entfällt damit. Auch die Ständige Übergabe der ConnectionSettings.

  • neue Methode GetServiceClient<T> ohne Parameter: Erzeugt auf Basis der Einstellungen (Nutzername, Passwort, Basis URL) den gewünschten Service Client.
  • GetServiceClient<T>(ConnectionSettings) wird als Obsolete gekennzeichnet. - In späteren Versionen (vermutlich 2.0) wird diese entfallen.
  • Die Validierung ob ein Service durch die FritzBox überhaupt bereitgestellt wird entfällt.
  • FritzDevice erhält eine Statische Methode zum Suchen nach FritzBoxen (verwendet intern den bereits vorhandenen DeviceLocator der damit in direkter Verwendung Obsolete wird und spätestens in Version 2.0 entfällt.

Sollte nun noch jemand die ein oder andere Änderung wünschen oder hat fehlende Methoden in den bestehenden Clients gefunden, bitte bescheid geben. Dann kann diese Änderung in der Version mit einfließen.

Hinweis: Die Erzeugung der ServiceClients durch manuelles erzeugen bleibt wie bisher. Wer also ganz ohne Verwendung von FritzDevice die Service Clients nutzt kann das auch weiterhin tun.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

Hallo zusammen,

ich habe das Projekt herruntergeladen und in Visual Studio versucht zu öffnen. Die API.CMD wird mir auch geöffnet, aber die API Komponente kann nicht geladen werden.

Es kommt die Fehlermeldung "Der MSBuild-XML-Namespace muss der Standard-XML-Namespace des Projekts sein." usw.

Kann mir jemand sagen was ich falsch mache.

Grüße
Eric

Der Fehler hört sich danach an, dass Du ein sehr altes Visual Studio verwendest, das den Projekttyp nicht unterstützt.
Da das Projekt hier mit .NET Standard umgesetzt ist, kannst Du zB. kein Visual Studio 2015 verwenden.

Danke für die schnelle Antwort.

Ich verwende VS2015. Ich habe ehr die Vermutung gehabt, das ich zu neu bin. Da in der PS.FritzBox.Api.csproj was von DOTNET2.0 steht.