yves.guern

Bon navigateur a décider de me faire... Je disais donc: Je suis loin de chez moi et de ma box, cela va être difficile. Je commencerais par: utiliser l'interface avec l'API qui est inclue dans la box, cela permet de faire un tri dans les commandes qui existent (malheureusement cet engin n'est pas exhaustif...) et/ou utiliser le F12 de votre navigateur pour espionner plus précisément ce qui est échangé. (Pour cela j'aime bien Firefox qui a une interface plus claire que chrome). Voilà c'est peu mais c'est tout ce que je peux faire pour le moment... A+

Bonjour, avez vous fait un clean de votre DNS? In the PowerShell window, type: Clear-DnsClientCache ou sous console ipconfig /flushdns Les 2 en administrateur Avez vous essayé depuis un autre PC

Bonjour, avez vous fait un clean de votre DNS? In the PowerShell window, type: Clear-DnsClientCache ou sous console ipconfig /flushdns Les 2 en administrateur Avez vous essayé depuis un autre PC

Cela ressemble à une erreur de DNS: il ne sait pas à quelle IP correspond hc3-00006080. soit c'est chez vous, soit c'est fibaro nice, soit... Si cela recommence tester avec l'adresse IP en dur (si c'est sur du réseau local). Bonne journée

Bonsoir Chistb, D'abord BRAVO!!! Superbe travail!!! Bon, quelques critiques qui se veulent positives quand même: Le code: ya encore un peu de français mais est-ce bien grave Si c'était pour moi je l'aurais coupé en 2 (au moins) on n'est pas loin de 1000 lignes c'est trop. Mais pour le mettre à dispo sur un forum n'avoir qu'un fichier c'est plus facile pour la maintenance (à condition d'être sûr de n'avoir rien laissé qui ressemble à un paramètre (qqchose qu'un utilisateur pourrait vouloir changer) dans le code) La doc: soyons honnête je n'ai fait qu'une lecture diagonale, mais: Cela semble un peu ardu, très 'geek'. Il manque une ou deux pages d'introduction avec des dessins pour montrer à quoi tout ça peut servir. Une espèce d'apéritif avant le repas en somme. Dis autrement vous avez écrit cela alors que vous avez encore le nez dans le guidon, je serais de vous je laisserais la pression retomber pour être en mesure de faire une relecture 'dégagée' Mais bon, pour mettre à dispo sur un forum de geek... Bonne soirée et bien entendu je ne m'oppose à rien!

Oui à tout y compris aux erreur de tabulation dans python. Sur le papier c'est mieux, plus pratique que {,} ou begin,end. Mais cela rend le code moins facile à lire en diagonale, à moins d'utiliser des tabulations d'au moins 4 caractères ce que je n'aime pas. Quand je fais du python avec du code un peu long j'ai pris l'habitude d'ajouter en fin de blocs qqchose du genre #end while ou #end if,... avec la bonne indentation, les choses sautent plus facilement aux yeux... Bon WE

Bonjour Chistb, Je vous laisse mariner mais vous avez l'air d'aller vite... N'hésitez pas quand même à poser des questions, vous pourriez tomber dans un moment dispo. Ceci dit IAQwant c'est forcement mieux que moi en délai. A+

Bonsoir Chirstb, En fait, en termes de disponibilité, vous tombez un peu mal c'st ce que j'ai le moins en ce moment et pour quelque mois encore je crois. Mais je vais essayer de vous guider... Le point le plus important pour vous (ce que j'en comprends): OUI on peut utiliser Python pour toutes les commandes via l'api, d'ailleurs il y a des exemples dans le code dont on parle Et d'ailleurs Python est plutôt plus puissant que lua. Donc les questions du genre 'Peut-on faire la même chose avec un script Python?' n'ont pas vraiment lieu d'être. Je pense que l'urgence n'est pas forcément 'comment' faire (dans le sens 'quel langage?') mais quoi faire avec quelles interfaces sur la HBOX Il faut se faire une liste des API utilisables pour modifier ce que vous voulez modifier. Faire un code qui modifie toutes les QA pour ajouter une fonction (si elle ne l'ont pas déjà) OUI c'est faisable J'ai même le code mais de mémoire il est en PHP ? A minima c'est une base si vous ne savez pas faire tourner du PHP (Pour avoir pratiqué, faire du PHP et du Python en même temps c'est un peu complexe: cela se ressemble suffisamment pour faire de gros mélanges qui ne fonctionnent pas !) La seule difficulté dans ce code c'est la manipulation de string pour vérifier que le code n'y est pas déjà! Questions: Est-ce qu'une QA sur la home box qui ferait l'interface entre "l'extérieur" et les autres QA ne serait pas un moyen simplificateur et éventuellement plus 'safe' ? (c'est une idée qui me vient à l'instant, elle n'est pas plus mûre que cela Puisque vous connaissez jgab: utilisez vous sa librairie fibaroExtra? Cela simplifierait beaucoup de choses, je l'utilise partout dans mes QA Et je ne suis pas sûr de comprendre ce que vous cherchez à faire: Si c'est juste modifier l'icone d'une QA: Changer directement avec un code Python l'icône courante par sa nouvelle en utilisant l'id du QA et son nom défini dans la QuickAppVar 'myIconIds'. c'est OUI Mais j'avais développé le code dont on parle 'surtout' pour certaines de mes QA dont je fait changer l'icone 'en temps réel' pour qu'il soit le reflet de l'état courant de ce que la QA gère. Dans ce cas c'est plus compliqué : chaque QA a de toute façons son propre code de gestion. Bonne soirée PS je découvre que vous habitez dans une région que je connais un peu: mon père est né à Saumur et a fini ses vieux jours à Vouvray. Et mon grand père habitait pas loin de l'embouchure du Thouet où il pêchait beaucoup, ma grand mère était originaire des 2 sèvres. Mon frère habite Cholet.

RE bonjour Christb Je suis perturbé par le fait que votre message n'est pas celui que j'ai reçu par mail. Maintenant que j'ai compris que vous l'avez modifié entre temps cela va mieux. Donc vous avez progressé, c'est bien! \\* et désolé pour les commentaires *\\ Quant à votre question finale je ne suis pas sûr de comprendre le but (ni de bien me souvenir de ce que mon code faisait d'ailleurs). Il me semble que, dans tous les cas, il y a des modifs de code à faire pour y intégrer l'existence et l'utilisation d'une variable du genre self.tMyIconIds.? Si votre question est : Est-ce que c'est possible en remote et HTTP(s) de faire des modifications de QA: OUI on peut recharger tous les codes qui constituent une QA, en ajouter et en supprimer. et : cela provoque un redémarrage automatique de la QA. Je fais cela 'tous les jours'. Je n'utilise que très peu l'éditeur intégré à la HomeCenter. Mes codes chargés et sauvegardés sur mon PC. Edités sur le PC lors des changements puis reversés sur la box (le tout avec du python). MAIS : on est en remote, et rien n'empêche de télécharger un bug!!!! Souhaitez vous que je partage plus ou ce dernier point vous semble trop risqué? A+

@Chistb Houlà va falloir que je creuse... Ya longtemps que je n'y ai pas touché A+

Bonjour Eric Moi aussi je suis passé à 7.3 et moi aussi cela plantait . et pas de la faute du filtre sanitaire (donc pour toi il y a peut être 2 choses à faire...) PHP oui c'est la bonne piste! Paskeu lorsque tu es passé à 7.3 'ytaprévenu' que cela allait mal se passer. Moi aussi je me suis dit on verra bien. Et ce fut le drame Après tâtonnements : c'est webstation qui plante en n'assurant plus les services PHP. Pour les rétablir : ouvrir WebStation dans le centre de paquets dans la "vue d'ensembl"e vérifier que php 8.2 est bien actif: (éventuellement desactiver/desinstaller les autres versions php) toujours dans WebStation, dans l'onglet "Parametres du langage script">"PHP": Vérifier le profil par défaut: il faut qu'il soit 'disponible' et pointe vers php8.2 double cliquer dessus, on tombe sur les paramètres de PHP: dans l'onglet "extensions" valider l'activation des modules requis. C'est là que j'en ai eu marre et que j'en ai validé plein. Sûr qu'ils ne sont pas tous nécessaires! Au point que je vais la faire à l'envers: ceux que je n'ai pas validés sont: bz2,calendar,dba,imagick,phar,sodium, sysvmsg, sysvsem, sysvshm (Il me semble que Lazer avait fait une liste des modules vraiment requis...) A chaque fois que l'on veut tester une modif (ou un paquet de modifs) Centre de paquets > Apache Server >Stop puis restart Et voilà.... PS j'ai bien dit "Après tâtonnements" j'espère qu'ils n'avaient rien modifié d'indispensable... A+

J'utilise des thermostats aeotec: bof! Avec le HC3 (ou HC2) cela fonctionne mais pas comme ce que laisse penser la notice. Principaux défauts : consommation piles (2 jeux/an), seul le mode 'HEAT' est utilisable dans la pratique, comportement parfois curieux lorsque la température est proche de la consigne.

Bonjour, La chose s'appelle un disjoncteur d'abonné. Et, malgré son nom il n'appartient pas à l'abonné qui ne peut intervenir que sur les plots de sortie après l'avoir désarmé. Une 'exception': lorsque le compteur (linky) est loin (plus de 30m) du point d'utilisation. L'installation a alors 2 disjoncteurs d'abonné, un à coté du compteur l'autre dans la maison. Dans ce cas le second est propriété de l'utilisateur. Je suis dans ce cas et il m'est arrivé de changer moi même ce second disjoncteur arrivé en fin de vie (il ne voulait plus réenclencher). Mais grâce au premier disjoncteur j'ai fait le remplacement en toute sécurité. Sources: c'est clair là: LEGRAND et ici LABRICOELEC. Le but du compteur linky étant aussi (surtout?) de virer du personnel, toute intervention physique sur place doit être devenue un cauchemar de DRH.... D'où le jeu de patate chaude dont vous êtes victime

???? le second message d'erreur est 'normal' (ou du moins il est ordinaire) Le premier n'a rien à voir avec ce que l'on cherche? Ce pourrait être un problème d'accès au NAS; As tu un user/mot de passe pour/dans domochart.lua (NAS_User/NAS_Password)? Si oui il faudrait modifier l'url à tester.

@Jojo: tu vois j'y réfléchi ... Sais tu utiliser 'F12' sous ton explorateur internet? si oui, peux tu m'envoyer une copie de la console au retour de la commande: http://192.168.1.xxx/domocharts/trend.php?HourTableOnly

Bonjour jojo, Désolé pour ce début de réponse tardive j'ai passé une bonne partie de ma journée dans les embouteillages hier... Tu as raison il faudrait un debug message plus détaillé mais au premier coup d'oeil la modification n'a pas l'air simple. J'y réfléchi et je te fait savoir. (Ne t'inquiète pas pour la suite, les calculs de 'trends' peuvent remonter loin en arrière: on a un peu de temps...) En attendant: Est-ce que dans ton log homeBox le message à minuit est correct? Pour ce qui est de CallTrendEveryH: elle est expliquée dans Domochart+Manuel.pdf. Mais tu as raison (encore) il y a trop de sous-entendus dans l'explication... A+

@jojo: As-tu installé le nouveau domochart sur la home box? et mis/vérifié les valeurs des variables locales: NAS_Path pour indiquer le répertoire où tu as installé trend.php et ses copains sur le nas CallTrendEveryH à true (sinon la maj des tables _hour ne se fait qu'à minuit, ce qui n'est pas un drame en soit...) Toutes les heures, la console de la homebox affiche la Mise à Jour des tables _hour: [26.05.2025] [11:38:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11795.36 ms ( 0.164 % ) [26.05.2025] [12:00:00] [TRACE] [QA_DOMOCHARTS(921)]: DomoAddsDBCompress: Mis en DB = 2051/6960 (Compression: 71%) [26.05.2025] [12:00:30] [TRACE] [QA_DOMOCHARTS(921)]: Generate trends with:/trend.php?HourTableOnly [26.05.2025] [12:00:33] [DEBUG] [QA_DOMOCHARTS(921)]: Mises à jour des tables '_hour':OK, 77 lines affected [26.05.2025] [12:08:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11844.00 ms ( 0.164 % ) [26.05.2025] [12:38:00] [DEBUG] [QA_DOMOCHARTS(921)]: Total memory in use by Lua : 844.54 KB, CPU consumed : 11469.57 ms ( 0.159 % ) [26.05.2025] [13:00:00] [TRACE] [QA_DOMOCHARTS(921)]: DomoAddsDBCompress: Mis en DB = 2066/6960 (Compression: 70%) [26.05.2025] [13:00:31] [TRACE] [QA_DOMOCHARTS(921)]: Generate trends with:/trend.php?HourTableOnly [26.05.2025] [13:00:33] [DEBUG] [QA_DOMOCHARTS(921)]: Mises à jour des tables '_hour':OK, 77 lines affected ... Oui sûr! on va y arriver

@Jojo Expert? je ne sais pas... Fournir des fichiers .../... en y ajoutant juste ta compression, sauf erreur c'est bien le fonctionnement par défaut Donner un fichiers de config basique standard, je crois que c'est ce que j'ai fait: Reste à définir ce que c'est que "basique et standard", dans mon esprit ce n'est pas de valider toutes les capacités/possibilités pour se poser des questions après. Je n'ai aucune idée des capacités en mémoire et en CPU des NAS qui vont supporter les calculs et les quantités de données Le configPlus.inc.php fourni est donné à titre d'exemple (et c'est celui que j'utilise pour moi). Dans ce fichier est écrit : * trend ne génère que des requêtes 'standard' sur des tables 'standard': ne cherchez pas à mettre à jour une table '_cpu_month' ou '_energy_month' par exemple avec une valeur de 'trendsType' => [0,2,1] Un peu plus de détails: Pour ce qui est des tables water,rain, energy, cpu, memory & network ce sont des tables pour lesquelles sont mémorisées plusieurs 'choses' à chaque enregistrement. (Ce ne sont pas des tables 'simples'). A partir de ces tables brutes, pour obtenir une des tables dite 'de moyennes' il faut donc dire quoi et comment moyenner, la réponse n'est pas unique... Histoire d'en rajouter une couche: pour la table energy, le calcul qui est fait n'a rien à voir avec une moyenne. pour les autres tables, à la question quoi? on réponds 'le champs "value" ' et à comment? on réponds 'en utilisant la fonction sql "AVG" ') PS: sur ces 6 tables, les tables water et rain sont comprimées les autres sont 'intactes' En résumé: je ne sais faire 'beaucoup de choses' que sur les tables qui ne sont pas water, rain, energy, cpu, memory & network. Pour ces tables il faut se 'contenter' de ce que fait Lazer, au moins pour l'instant. Je déconseille donc de modifier les champs trendsType pour ces 6 lignes dans configPlus.inc.php.

@Jojo, En réponseS à ta question: Pourquoi vouloir conserver 100 jours de données water (même si cette table va être comprimée) si il y a une table _hour? //created via database.sql signifie que la table n'a pas un format 'simple' et que install.php utilise ce qu'il y a dans le fichier database.sql pour créer ce qu'il faut, il te faut donc modifier database.sql. Les table qui ne se font pas toutes seules sont 'donc' water energy cpu memory & network... Il n'y a que water qui pourrait accepter d'avoir une table '_hour' la table n'a pas un format simple => trend.php ne saura pas 'calculer' les tables hour day et/ou month: il faut lui dire comment faire dans les variables $tSpecialSQLQuerys ou $tVerySpecialPHPQuerys => tu as modifié ['water']['trendType'] à [1,1,1] je ne sais pas ce que cela va faire mais probablement rien de bien... rester avec [0,1,2] me semble une bonne option si tu ne crées pas 'water_hour' ou [1,1,2] dans le cas contraire. pour créer une table '_hour' à la main : il s'agit de table dont la structure est identique à la table '_day'... A+

Bonsoir Jojo, Merci pour les fleurs, fallait pas... Surtout avant d'avoir essayé! 1 backup vous manque et tout est dépeuplé.... Oui! j'avais mis ce qui me concerne en commentaire. Mais cela ne t'empêche pas: de vérifier que les DLC correspondent bien à tes besoins... de choisir pour quels types de données tu veux créer des tables _hour (et aussi _day &_month) Oui les DLC de config.inc.php sont ignorées (après beaucoup d'hésitations) ET maintenant il faut aussi définir des DLC pour _hour, _day & _month Là je dois avouer que je me suis dit "et mmrrdd.. j'y avais pas pensé". Bon mais ce n'était qu'un coup de fatigue (ou une préalerte Alzheimer)!!! Il suffit de lancer install.php qui s'occupe de tout en fonction de configPlus.inc.php (ie : tu modifies configPlus.inc.php et tu lances install.php) Si si!; Lazer le faisait pour toi, il se relevait toutes les nuits à minuit pour cela . Trend.php était (et est toujours) appelé par le code du home center un peu après minuit et effectue toutes les mises à jour des tables _hour, _day &_month. Pour les tables _hour cela présente l'inconvénient qu'elle ne sont pas à jour avant minuit (mais à minuit il fait nuit: peut-on être à jour alors? Comme aurait dit ton regretté compatriote Devos) Donc il y a une petite modif du code lua qui appelle trend.php toutes les heures (si la variable 'OuiJeSuisImpatient' est armée....) Bonne soirée.

Mais non ça fait juste réfléchir sur le rapport qualité/prix !!! 37octets pour une température cépamoikildi c'est phpMyAdmin... (voir l'onglet structure,de chaque table, en bas à droite) Avec chaque valeur de température (par exemple) l’enregistrement contient id : index d'enregistrement, on va dire que c'est pour la cuisine interne de MySql device_id: pour savoir où est-ce qu'il a fait aussi chaud que ça? time: quelle heure etait-il? value (enfin): kombien y faisait chaud? et il faut ajouter les index (qui représente plus de 60% de la taille) Primary device_time autres (parfois...) On en 'déduit' qu'en gros les trois premiers items et les deux derniers coûtent ~30 octets. Surtout il ne faut pas pleurer: ce sont eux qui permettent de retrouver/trier les autres !!

Suite à mon message ci-dessus et pour avoir quelques ordres de grandeur en tête, j'ai calculé l'encombrement des tables de domochart pour une installation avec 100 capteurs: J'ai utilisé 37octets par donnée pour les tables brutes et 47 pour les tables moyennées (il y a au moins 2 valeurs de plus/enregistrement pour ce type de table ). On y voit bien l'intérêt (ou la contrainte) qu'il y a à effacer les vielles données 'brutes' et le compromis intéressant qu'offre la table des moyennes horaires.

Bonjour Jojo Le fichier Readme.pdf répond à tes questions, (les réponses sont globalement positives avec 'subtilités') Pour les On/Off : Oui ce serait possible mais je ne suis pas loin de penser comme Lazer: "pour quoi faire"?, "comment représenter"?,"que fait-on des changements brefs"?, ... Au début moi aussi j'en avais envie et puis j'ai mis cela de côté... Et toi qui cherche (ou va chercher ) à diminuer la taille de ta base, les On/Off ne vont pas du tout dans le bon sens: Un enregistrement d'une donnée 'binaire' devrait coûter 32 octets/pièce [contre 37octets/pièce pour une température (pourtant enregistrée en 'flottant')]. A priori ton installation comporte plus de On/Off que de capteurs de température, on ne va donc pas du tout dans le bon sens! 50 émetteur/receveur binaires c'est 2.5Mo/jour de données brutes dans la base! => On court à la catastrophe, sauf à ne sélectionner que très peu de devices ce qui revient à répondre (et de façon très raisonnable) aux questions de Lazer ci-dessus... Bonne journée

Yen a pas un de vous deux qui croit aux théories sur la Synchronicité par hasard?

DomoCharts+ Version 2.0 J'utilise LE domocharts de Lazer (cf DomoChartsV7) avec bonheur depuis un moment déjà. J’ai fait quelques personnalisations qui peuvent en intéresser d’autres, je partage donc ici. PRESENTATION: Dans les grandes lignes les personnalisations sont : Une librairie de fonctions complémentaires à domoCharts.lua dont la plus intéressante est un filtre qui n'envoie vers la DB que les données qui ont changé depuis le dernier envoi vers la bas de donnée. J'obtiens ainsi une 'compression' de 70% de la taille des envois et donc de la base. Côté serveur, j'ai modifié trend.php pour que certaines données soient aussi moyennées heure par heure. Il me semble en effet que les données brutes représentent une quantité de données trop importante pour être raisonnablement conservée (et utilisable) sur une longue période mais que la moyenne journalière n’est souvent pas assez détaillée. J'ai interfacé "un autre highcharts" que je connaissais du boulot (fusioncharts). Le principal avantage que j'ai trouvé est de pouvoir définir des groupes de données (constitués d'ensemble de capteurs en BdD) à afficher selon 1 ou plusieurs axes Y. Les groupes sont définis dans un fichier json essentiellement par des listes de nom de capteurs. Les deux premiers points (qui ne sont pas aussi indépendants que cette introduction peut laisser entendre) sont suffisamment mûrs pour être partagés ici mais ce n’est pas encore tout à fait le cas du dernier. Pour le moment, j’ai juste fait en sorte que l’interface avec HighCharts puisse accepter des données moyennées sur une heure. INSTALLATION : Il ne s’agit là que de modifications légères du code original ! Le post initial (DomoChartsV7) doit être lu avant d’aller plus loin : il reste une référence pour l’installation et le ‘paramétrage’ de base. Bien sûr, si vous aviez la version précédente, des sauvegardes s’imposent : la FQA, le dossier domocharts/ sur le serveur et la base de donnée… Comme pour domochart, l’installation peut se faire · ‘sur une page blanche’ avec un fichier ‘.fqa’ pour la Box et un ‘.zip’ pour la partie serveur, · ou comme s’il s’agissait d’une mise à jour : à l’aide de fichiers indépendants remplaçant ou complétant ceux qui existent. Dans les deux cas il semble logique de continuer à utiliser la même base de données, mais on peut tout à fait repartir d’une neuve en donnant un nom différent dans config.inc.php. Le fichier joint readme.pdf donne plus de détails sur l'installation de 'la chose' et de ce qu'elle fait. FICHIERS JOINTS : Installation complète : FQA pour HC3:QA_DomoCharts+V2.0.fqa ZIP pour le serveur domocharts+V2.0.1.zip Mise à jour de la QA : la librairie:DomoAddsLibV2.0.lua le 'main' modifié:DomoChartsModifieV2.0.lua Mise à jour du serveur : les fichiers modifiés côté serveur:DM+MajSvrV2.0.1.zip Notes : Ce que fait la QA (et son paramétrage) :DomoChart+Manuel.pdf Synthèse façon ‘readme.txt’ sur les différents éléments et l’installation :readme.pdf 16/05/2025 : Pour ceux qui utilisent une table 'energy': il y a 2 erreurs de syntaxe dans configPlus.inc.php et dans data.php. corrigées par la version 2.0.1 (cela ne concerne que le serveur)