Tous les projets

La page de configuration Espace abonné permet de paramétrer le Freebox Server. Les paramètres définis sur cette page ont des relations de prévalence inconsistantes avec les paramètres définis au travers de l’interface Freebox OSRéseau Local & Mode Réseau ou l’application Freebox:
si il fonctionne selon le principe dernier spécifiés = actifs au prochain redémarrage, parfois les paramètres de la page de configuration Espace abonné prennent le dessus sur ceux préexistants localement (adresse IP du routeur par exemple ou clé de sécurité Wi-Fi par exemple), parfois non (réponse au ping, proxy WOL), enfin certain paramètres sont limitatif sur la page de l’Espace abonné (comme le type de sécurité Wifi).
Ces manques de consistances ou incohérences sont trompeuses et nécessitent à mon avis une redéfinition de la nature de la page Espace abonné (par exemple paramètrage du firmware de secours) ou des paramètres modifiables (par exemple en les limitant) ou des règles de persistence entre les différents types de configuration.

D’abord une imprécision:
Sur la page “Freebox OS developer API” située ici http://dev.freebox.fr/sdk/os/, dans le chapitre “Discovery using HTTP” la version de l’API donnée dans l’exemple est api_version: “1.0”.
Cela pourrait sous-entendre au travers des guillemets que api_version est de type string or l’exemple du chapitre suivant “Building the API request URL” (et de nombreux autres dans la documentation) tend à démontrer que ce jeton est de type number.
L’implémentation en 2.0.2 le renvoie entre guillement mais l’usage demandé par la documentation (cf. paragraphe “API Version” de la même page “Current API version is: 1”) et par le logiciel voudrait que nous l’utilisions en number converti en entier uniquement.
.
Donc qu’en est-il? Devons-nous lui donner un type entier, réel(équivalent number), texte pour sa stabilité dans le temps?

De même une “anomalie” est glissée dans l’exemple concernant l’échappement de “api_base_url”: “/api/”; il devrait être consigné “api_base_url”:”\/api\/”. Dès lors le chapitre suivant devrait, au lieu d’indiquer “http://[freebox_ip]:[freebox_port]/[api_base_url]/v[api_version]/[api_url]”, faire apparaître “http://[freebox_ip]:[freebox_port][api_base_url]v[api_version]/[api_url].

Enfin l’usage des guillemets sur les identifiants des objets est largement incorrect dans la documentation, l’implémentation elle intègre les guillemets, conformément à du JSON courant.

Actuellement, ma Freebox HD, plante après une utilisation variable mais jamais en sortie de veille; les symptômes sont toujours les mêmes:
L’écran, un plasma Pioneer avec une entrée HDMI commute de 1125 lignes entrelacées sur 525 lignes entrelacées et le boitier HD semble se bloquer après quelques instants ne répondant plus aux injonctions de la télécommande et des boutons de la façade.
Le redémarrage à froid par la coupure de l’alimentation électrique devient obligatoire, le boitier HD est brulant à ce moment là.
Ce phénomène se produit sur tous les types chaines diffusées: ADSL, ADSL Bas-débit et TNT.
A noter que le problème intervient 2 à 3 fois par jour pour 1h à 1h30 d’usage.

Il serait pratique d’employer la Freebox HD en tant que point d’accès Wi-Fi configurable appartenant ou non (selon si elle est connectée en Ethernet ou pas) au réseau d’infrastructure de la Freebox v.5.

La configuration de l’adressage IP nécessiterait aussi de la flexibilité, permettant à la Freebox HD d’être accessible depuis le réseau de diffusion de Free, comme actuellement pour la télévision et la VOD, mais aussi directement depuis un sous-réseau défini en par l’utilisateur.

Cela permettrait de mailler nos habitations en Wi-Fi de manière satisfaisante avec seulement le matériel de Free seulement et de proposer ultérieurement un ensemble de services supplémentaires sur les Freebox HD (stockage attachés au réseau, serveur d’impression, de diffusion de média).

La possibilité d’utiliser le protocole IPv6 sur le réseau interne serait un plus indéniable.