Lazer

Bon... bah si tu es gagnant, tu prendras soin de ne rien dire

@Did mais du coup tu es facturé comment ? Car le fournisseur (EDF ou un autre) va interroger Enedis, qui va lui renvoyer les index du compteur. Donc si tu es facturé n'importe comment, alors ça correspond à la téléinfo, et donc le compteur est vraiment naze. Si tu es facturé correctement (avec les 6 tarifs), alors le compteur fonctionne bien, et c'est certainement l'EcoDevice qui déconne => SAV GCE (avec peu de chance vu l'age du produit), ou passage au nouveau modèle RT2. @flacon030 merci c'est clair. Je suis bien d'accord avec toi, j'ai fait ma petite étude et j'en suis arrivé aux mêmes conclusions, la vente n'est pas du tout intéressante (elle l'était dans le passé), l'objectif c'est bien d'autoconsommer au maximum. En France en tout cas, c'est peut être différent en Belgique. Et OK pour le mode standard, du coup je pense que je demanderai la bascule à mon fournisseur (EDF en ce moment, offre Digiwatt, youhou je suis à 0.15€ le kWh, 5% de remise c'est la fête) avant d'installer des panneaux, comme ça je connaitrai dès le premier jour mon éventuel surplus injecté.

Ah c'est dommage ça.... après le JSON que tu affiches, c'est l'EcoDevice qui le génère, à partir de la Teleinfo envoyée par le compteur Linky. Mais le bug peut très bien être dans l'EcoDevice en fait, car c'est son logiciel interne qui décode le trame teleinfo et génère le JSON. A ma connaissance, il n'y a pas moyen de voir la trame teleinfo originale (ou alors il faudrait virer l'Ecodevice et installer un montage à base d'Arduino comme on en trouve plein sur le web) Tu as posé la question au support GCE ? Peut être un bug connu.... cela dit, je doute fort qu'ils remettent des ressources pour développer un correctif, ils sont focalisés sur l'IPX800 v5, même l'EcoDevice RT2 n'a plus le droit aux mises à jour récentes...)

En effet c'est exactement ça, le QA reçoit la réponse avec 1 train de retard, si on regarde les ID de ton log, on voit qu'ils sont décalés. Quand le QA emet une trame SNMP pour interroger l'onduleur, il reçoit en fait la réponse de la trame précédente. C'est étonnant que ça se produise si souvent chez toi, chez moi ce n'est jamais arrivé ce cas de figure. Rien de grave de toute façon, ça n'empêche pas le QuickApp de fonctionner, au pire il a un peu de retard dans la mise à jour des valeurs affichées, le temps qu'il reçoive une réponse correcte de l'onduleur. Théoriquement, je pourrais prendre en compte ce décalage dans le code LUA du QA, mais vu la complexité, je préfère même pas me lancer....

Mise à jour du QuickApp DomoCharts v7.11 : Correctifs et améliorations diverses (désolé je n'ai pas tout noté car j'ai fait quelques retouches au fil des mois...) Contenu des fichiers à copier/coller par dessus les originaux dans le QuickApp : Fichier main : DomoCharts v7.11.lua Fichier DomoCharts : Library - DomoCharts v7.10.lua Fichier tools : Library - tools v2.20.lua

OK je vais regarder ça, j'essaierai de reproduire l'EnergyMeter sur ma box de test. En tout cas un EnergyMeter, c'est bien des Wh (Watt.heures) qu'il lui fait, et non pas des Watts (ça c'est pour le PowerSensor) Du coup j'ai des questions sur ton installation solaire, pour éclaircir une question que je me pose. Tu vend ton surplus ou tu l'injectes gratuitement ? Quand tu as déclaré ton installation à Enedis, est-ce qu'ils ont activé eux-même la téléinfo en mode Standard, ou bien c'est toi qui en a fait la demande spécifiquement ?

Attention, ton Temp_Piscine n'est pas une variable, mais un label du QuickApp. Cela n'est pas le sujet de ce topic qui traitait à l'origine des variables du QuickApp, qu'on retrouve dans l'onglet présenté sur la capture d'écran de Krikroff. Les labels servent à afficher des informations, pour l'utilisateur. Cela se fait avec la fonction updateProperty(), voir la documentation officielle : https://manuals.fibaro.com/home-center-3-quick-apps/ Lire un label n'a que peu d'intérêt, voire même aucun. Les valeurs des labels ne sont pas persistants, contrairement à ce qui était le cas sur les VD de la HC2. La doc officielle n'est pas très détaillé, et surtout assez peu didactique. Il faut bidouiller par mal pour finir par comprendre la logique des QA. Il n'y a pas de tutoriel complet à ma connaissance, en tout cas pas sur le forum, si ce n'est plusieurs discussions plus ou moins poussées autour de différents sujets. Si tu veux devenir un dieu du QuickApp, que tu as pas mal de temps à y investir, et que tu lis l'anglais, je te conseille le topic de @jang sur le forum officiel : https://forum.fibaro.com/topic/49113-hc3-quickapps-coding-tips-and-tricks/ Lire en particulier les 4 (longs) messages sur l'anatomie d'un QuickApp (Part 1 à 4) et de leurs enfants (voir table des matières du 1er post) Il y a un début très théorique sur les notions de bases du LUA, indispensable pour bien comprendre comment sont construits les QuickApps, avant d'aborder des aspects plus pratiques.

Rectificatif : ce BIOS hacké permet d'activer le support du protocole AHCI du contrôleur RAID. Donc en pratique, permettre le hot-plug des disques, mais également la possibilité de connecter autre chose qu'un disque dur sur les ports (un lecteur de CD/DVD par exemple)

Problème de communication avec l'onduleur... ça peut venir d'une lenteur au niveau du réseau lui-même, de la carte contrôleur SNMP de l'onduleur, voire de la HC3. Il n'y a rien qu'on puisse faire, mais l'erreur n'est pas gênante et non bloquante, le QuickApp est prévu pour gérer ce cas de figure et ne pas planter. Pour preuve, il continue son fonctionnement normal. J'aurais pu faire le choix de cacher cette erreur et ne pas l'afficher, mais je préfère la laisser, au moins on voit ce qui se passe (ou ne passe pas en l'occurrence).

Non le Push c'est toujours le 3ème argument. Dans ton cas tu as laissé "", donc une chaine vide, donc pas de notification. Voilà : GEA.add( {{"Days", "Monday, Tuesday, Wednesday, Thursday, Friday"}, {"Time", "00:00", "00:31"}}, 30, "Push eco énergie", {"TurnOff", {id["Prise_Sapin"]}}, "Eco énergie prise OFF") Pour ta condition de variable globale, oui c'est ça. Attention à la terminologie, dans cette règle cette condition n'est pas un "trigger" (= déclencheur), mais juste une condition. Elle serait un trigger si elle était utilisé dans une règle à déclenchement instantané (avec une durée = -1)

De mémoire, le BIOS hacké, c'était sur le G7, pas sur le Gen8 ? ça servait juste à débrider le contrôleur RAID, afin de lui permettre le hot-plug des disques durs (fonctionnalité volontairement limitée par HP sur ce micro-serveur d'entrée de gamme, pour forcer les clients d'entreprise qui ont besoin de cette fonctionnalité à acheter un modèle de gamme supérieur.... pas au même tarif) Donc aucune limitation, bien au contraire, tu peux garder ce BIOS.

Sur les anciens firmwares de la HC3, on pouvait mettre n'importe quel appareil rapportant une mesure d'énergie (en clair, un module possédant l'interface energy). Mais c'était trop pratique, du coup Fibaro a décidé qu'il fallait changer cela Donc sur les firmware récents, si je ne dit pas de bêtise, seuls les modules de type com.fibaro.EnergyMeter peuvent être affectés en mesure de la consommation principale de la maison (ça a été expliqué sur le forum officiel, c'est une conséquence du nouveau panneau d'énergie) Donc dans mon QuickApp GCE, en théorie il faudrait créer un enfant de type EnergyMeter. Je dis en théorie, car je n'ai pas testé, vu que je suis encore sur un ancien firmware de la HC3 qui me permet d'utiliser le module que je veux. @Did étrange ça, mais la téléinfo de ton Linky, elle est en mode Historique (censé être identique aux anciens compteurs électroniques) ou en mode Standard ? Autre chose, tu utilises quel appareil pour relever la téléinfo ? Je pense aux anciens Eco Devices v1 qui ne sont pas compatibles avec la téléinfo du Linky (électriquement parlant, il faut une adaptation du circuit électronique de l'EcoDevices) En fait la question que je me pose, c'est si les champs de couleur ont été retirés de la trame téléinfo émise par le Linky, ou bien si tu as une incompatibilité quelconque ? En tout cas moi je suis très content d'être enfin passé à Linky, ça fait un peu plus d'un an. J'ai pu simplifier mon installation car j'ai retiré mon compteur électronique que j'avais ajouté dans mon tableau, et je récupère maintenant directement la téléinfo sur le Linky. Et ça correspond exactement à ce qui est facturé, aucune surprise. J'ai changé de fournisseur récemment (ekWateur => EDF), aucune démarche à faire, aucun relevé à transmettre, le fournisseur interroge Enedis qui donne l'index du compteur relevé à distance, et la facture est ajustée au Wh près à l'heure précise du changement de fournisseur, au jour que j'ai choisi à l'avance. J'ai aussi changé de tarif (HC/HP => BASE), pareil, opération faite à distance, le jour programmé, et cela gratuitement puisqu'il n'y a pas eu besoin de faire intervenir un technicien sur place pour reprogrammer le compteur. Bref, très content de Linky, il rempli ses promesses (et je met de coté toutes les théories fumeuses sur les ondes, l'espionnage, la caméra intégrée, etc... un vrai business rentable pour certains... je ne vous met pas de liens pour ne pas leur faire de pub, mais les lits anti-ondes à plusieurs milliers d'euros, fallait y penser...)

J'ai pas compris ? Si tu veux changer d'OS, tu as juste à installer le nouveau, ça va écraser ce que tu avais avant, c'est tout.

C'est très étrange tout ça. J'ai migré mes modules de HC2 à HC3 (exclusion pour inclusion), j'ai tout reconfiguré pareil (intervalle de réveil, et certains paramètres Z-Wave), et le comportement des modules est exactement identique à avant. Et c'est bien normal. Il doit y avoir quelque chose que tu as fait différemment.

Attention lors du passage HC2 => HC3, les modules ne prennent plus la même valeur (propriété value dans le JSON du module, visible via l'API) Sur HC2, Fibaro avait mal fait les choses, les détecteurs binaires (mouvement, ouverture, etc) prenaient les valeurs "0" et "1" (chaines de caractères contenant un nombre), tandis que sur HC3 c'est plus logique, on trouve des valeurs true et false (booléennes) De même, sur HC2 les multilevel (dimmer, volet, etc) avaient une valeur entre 0 et 99 mais sous forme de chaine de caractère (donc entre guillemets), tandis que sur HC3 c'est une vraie valeur numérique. C'est une différence fondamentale, donc il faudra adapter les valeurs dans tes règles GEA. Pour voir les valeurs des modules, tu peux utiliser l'API HTTP pour voir le JSON du module directement depuis ton navigateur, connaissant son ID : http://.../api/devices/ID Et tu cherches la valeur de la propriété value La syntaxe qui t'a été donnée est une écriture abrégée, les 2 conditions suivantes sont identiques : -- écriture complète corrigée : GEA.add({"Value", id["Detecteur_Allee"], true}, -1, ...) -- écriture abrégée : GEA.add(id["Detecteur_Allee"], -1, ...) Voilà c'est exactement ça. Et même, on pourrait être encore plus précis, vu que la durée = -1, c'est donc un déclenchement instantané, donc ta phrase aurait pu commencer par "Dès qu'il y a une détection dans l'allée, ..." Ton écriture de Days est mauvaise, voir la doc de syntaxe (comme sur HC2, ça n'a pas changé) : {"Days", "Saturday, Sunday"} Tu n'as pas besoin des parenthèses autour de "Time", les parenthèses ne sont utiles que dans les déclenchement instantanés (donc avec durée = -1) pour exclure la condition du déclenchement (comme sur HC2, ça n'a pas changé) De plus, évite les conditions Time avec une heure précise à la minute près, en cas de freeze de la HC3 (constaté par quelques utilisateurs de façon aléatoire), GEA pourrait manquer le bon moment. Préfère une durée de 2 ou 3 minutes par sécurité : {"Time", "00:15", "00:16"}