Lazer

Ah OK. Donc c'est toujours autant incompréhensible.

Chien Électronique À Base De Sonos

J'ai pas l'impression qu'il existe de version EU. Pour rappel, les fréquences US et EU sont incompatibles.

Dommage que ça soit Philips, y'a rien qui me fait rêver ou dont j'ai besoin. Ca aurait été Sony, j'aurais fait un prêt àla banque avant de dévaliser la boutique

T'aurais pas forcé la vitesse des ports sur ton NAS par hasard ? SI ton switch n'est pas manageable, il faut laisser en autonégociation. Au cas où, vérifie aussi tes câbles réseaux.

Je ne suis pas certain de bien comprendre.... ton problème est sur ton LAN ou sur Internet ? Car tu parles de Freebox et de routeur, donc des équipements permettant d'aller sur Internet, et ensuite tu parles de brancher tous les équipements du réseau dessus, donc cela concerne la partie Switch, propre au LAN.

C'est exactement ça Captain ! En réalité, j'ai une API très proche d'un RESFULL. Les données sont échangées en JSON. Donc il est très facile de retenir le JSON dans une variable globale, et de ré-emmètre le tableau à la prochaine tentative. Seule limitation : la longueur maximale d'une chaine de caractère dans une VG. Voici un exemple de JSON valide : [{"id":0,"timestamp":"NULL","type":"temperature","value":10},{"id":1,"timestamp":"1427749407","type":"humidity","value":8},{"id":2,"timestamp":"NULL","type":"test","value":27},{"id":4,"timestamp":"1427749407","type":"water","value":0},{"id":1,"timestamp":"NULL","type":"temperature","value":12}] Comme tu peux le voir, on retrouve les champs suivants : ID du module (correspond à un ID réel de la HC2 pour un module Z-Wave, ou un ID fictif dans le cas d'un périphérique externe (par exemple un compteur d'eau issu d'un Eco-Devices stocké dans une VG.... dans la pratique, j'ai choisi des ID 2000, 3000, 4000 etc pour ce genre de devices) timestamp : si NULL, alors on prend le timestamp du NAS/Serveur Web. Sinon, la HC2 peut fournir la valeur, ce qui suppose que la clock de la HC2 soit synchro... il y a toujours un bug qui traine à ce sujet. type : le type de la donnée, afin de stocker la donnée dans la bonne table. value : la valeur

Ce qui me fait penser que je n'ai toujours pas mis le nouveau VD de Jojo en première page. J'attends de voir avec Sebcbien si y'a effectivement un bug àcorriger et je m'en occupe.

Ah vi, j'avais pas fait attention Donc si ça se trouve, la mise à jour vers la v4 a été déclenchée d'une façon ou d'autre autre, et c'est ce qui a provoqué les problèmes rencontrés.

Ça ça risque pas de fonctionner, c'est pas la même architecture processeur. !!!

Quoi ? Éric t'es en 3.6 et pas en v4 ? J'ai du louper qqch...

L'adresse du repository en question est déjà passée 2 ou 3 fois sur le forum.... bon courage pour la retrouver dans la masse de posts ! Tu peux facilement la trouver en mettant en place un proxy sur ton réseau. Cependant, à priori il n'existe aucun moyen de pousser la mise à jour vers la box, uniquement via l'interface Web. En tout cas si tu y arrives, je te tire mon chapeau. Et surtout, Fibaro refuse catégoriquement de forcer le déploiement de la v4, même avec reconfiguration complète de la box (=perte de la config). Et ça, je ne comprends pas pourquoi. Seules les nouvelles HCL sont installées nativement en v4.

C'est bizarre que ça plante quand le code 117 apparait, normalement le script est censé gérer le cas de figure d'un code inconnu en renvoyant "???" : ..(self.API_CAMERA_ERROR_CODE[tonumber(jsonTable.error.code)] or self.API_COMMON_ERROR_CODE[tonumber(jsonTable.error.code)] or "???").. Donc ça veut dire qu'il y a un endroit où on a oublié de mettre cette protection en place ? C'est àquelle ligne que ça se produit ?

Après un recovery, il n'y a plus de logs.... tout est formaté.

Oui, comme Jojo, Recovery puis restauration du dernier backup. Ca devrait revenir comme avant (sauf que tu perdras les icones, mais c'est un moindre mal).

Oui. Les validations sont automatiques dès que le paiement est enregistré, et ils se réservent le droit d'annuler àtout moment manuellement. C'est comme ça sur tous les sites web.... c'est un garde fou en cas de bug/abus/etc

Oui lol Le code donné en premier est bien valable, par contre rien ne dit que Philips n'annulera pas toutes les commandes

Ca c'est la classe

Oui je suis d'accord, sauf que ce n'est toujours pas implémenté ! Au pire, 5 minutes de coupure Internet, ça me fait 5 minutes de pertes de données, ça ne change pas grand chose sur les graphs de moyenne quotidienne. En cas de coupure plus longue d'Internet (ce qui ne m'est pas arrivé depuis 2 ans), je peux simplement rediriger les graphs vers mon NAS local, et je me débrouillerai plus tard pour merger les données. Bon c'est sà»r que c'est pas user-friendly tout ça !! Pourtant cette histoire de rétention des données est quelque chose que j'ai en tête, et qui est implémenté sur mon Raspberry PI (tu sais, celui qui compte les impulsions). Donc ça viendra probablement un jour sur mon VD Graphiques. En plus avec la nouvelle structure à paraitre bientôt, ça sera plus simple à mettre en place.

Internet est un Spof je suis d'accord, mais mon NAS aussi (vu que je n'arrête pas de jouer avec). Enfin maintenant mon NAS est stabilisé et tourne bien, mais je garde quand même mes données chez OVH car je consulte souvent mes graphs de l'extérieur, et si les données étaient sur mon NAS je serai limité par l'upload pourri de ma ligne ADSL pour la vitesse de chargement des graphs. Alors que chez OVH, c'est rapide tout le temps. Le PHP c'est crade quand tu mélanges code PHP et code HTML dans la même page, comme aux débuts du langage. Maintenant avec Ajax tu sépares bien les fonctions dans des fichiers différents, donc c'est beaucoup plus propre (Ajax, Propre, tout ça... désolé)

Générer des pages Web avec du Python, je ne trouve pas ça très contemporain, c'est carrément un retour aux scripts CGI là . Ou alors j'ai pas compris ton idée ? Tu peux faire des choses très propres en Ajax, avec un mix de fichiers Javascript et PHP. Et le Python ne tournera pas sur les hébergements mutualisés. Tout le monde n'a pas un NAS à dédier aux graphs. Alors que du PHP/MySQL/Javascript, ça tourne absolument partout. Concernant l'évolution de la DB pour le Noob, ce qui importe c'est qu'il n'aie pas besoin de taper des requêtes SQL dans phpMyAdmin. Donc il faut lui faire un frontend, une bête page Web qui lui permette d'ajouter un nouveau type de capteur. Ce qui se traduira pas la création de la table correspondante. L'inconvénient (encore que ça n'en soit pas vraiment un), c'est qu'on va vers une multiplication des tâbles dans la DB. Depuis que j'ai intégré Netatmo, j'ai des tables CO2/Pression/Bruit/etc avec seulement une sonde dedans. Si demain on ajoute tout types de mesures, ça va multiplier les tables, mais le SGBD le gère très bien. Pour tout dire, avant d'isoler les types de sondes dans des tables différentes, tout était dans la même table. Au bout de quelques semaines j'avais dépassé le million de lignes dans la DB. Avec les bon index, je n'avais pas de problèmes de performances lors des requêtes, mais comme je supprime les données au bout de 3 semaines pour limiter l'accroissement de volumétrie, je lance des Optimisations de tables. Ces optimisations plantaient sur mon hébergement mutualisé, tout comme ça aurait aussi planté sur un petit NAS. Si tu veux que le Noob, toujours lui, puisse utiliser la solution, il faut penser qu'il n'a pas à sa disposition un hardware de folie, donc la solution doit être la plus interopérable possible. Ce qui implique : - performances (petit NAS, hébergement mutualisé) - ergonomie (interface Web qui permette d'administrer facilement la solution) - interopérabilité (utiliser des outils standards dispos partout) Pour info, dans la prochaine version de mon outil, il n'y aura plus besoin de passer par phpMyAdmin pour l'installation, je suis en train de créer un mini-installer.

Le souci, c'est que Nest et Netatmo dépendent du Cloud. Je sais que Mme Michu adore ça, mais pour moi c'est rédhibitoire.

Le panneau de chauffage, je ne pense pas. Mais si on pouvait récupérer cette consigne en LUA via l'API, après c'est facile de faire des scénarios (en direct ou via le panneau de chauffage). Bien que prévue pour le système Danfoss avec leurs vannes, j'aimerai bien l'utiliser comme "thermostat d'interface" avec lecture de la température et changement de la consigne avec les boutons + et - dans mes scénarios. C'est assez ergonomique je trouve.

C'est pas le prix le souci, c'est de savoir si il fonctionne avec nos box ? Je n'en n'avais jamais entendu parler avant que la dernière mise à jour de l'eedomus annonce sa compatibilité.

Si j'ai bien compris ton idée "simple une table queue avec Timestamp, nomdonnee, valeur, unité", je t'avoue que ça me semble plutôt limité en terme d'évolutivité. Parce que tout mettre dans une table, c'est simple, mais par la suite, ta table va gonfler très vite (puisque tu vas stocker du texte identique à de multiples reprises (nomdonnee, unité) inutilement. Au final, quand tu auras beaucoup de données et que tu voudras faire une requête, ça fera d'autant plus de données à manipuler inutilement. Alors sur ton NAS puissant ça ne sera pas un problème, mais c'est pas très propre quand même. Dans ma solution, j'ai bien séparé les notions de devices, types, et valeurs, sachant qu'on a une table par type de valeur (température, humidité, etc). Donc c'est ultra simple d'ajouter juste une nouvelle table pour gérer un nouveau type de données.