Lazer

Je ne pensais pas qu'il était encore vendu.

Et bien faire le triple clic sur le micro-switch à la place du triple-clic sur l'interrupteur connecté sur le bornier du module. C'est indiqué dans la doc normalement.

Essaye une exclusion du module, c'est même une habitude à prendre avant toute inclusion, car on ne sait jamais vraiment si le module n'a pas déjà été inclus dans un autre réseau préalablement (module testé en usine, d'occasion, etc...) A noter que j'ai eu certains modules où j'avais du mal à faire l'inclusion avec avec l'interrupteur branché sur le module, alors que ça fonctionnait avec le triple clic sur le micro-switch encastré dans la coque du module, accessible avec un petit tournevis.

fronius.Body.Data.Inverters[1].SOC Essaye ça

L'URL que tu utilises n'est pas valable, le user/password donné dans l'URL est une pratique dépréciée depuis des années (si ce n'est pas des décades... car le temps passe vite). Elle est encore tolérée par les navigateurs pour faciliter la vie des utilisateurs, mais en fait ça ne les aide pas tant que ça, la preuve ça t'a fait perdre du temps. On a déjà évoqué cet usage plusieurs fois sur le forum, il faut perdre la mauvaise habitude de mettre user/password dans l'URL. Les identifiants doivent passer dans l'entête (headers) de la requête HTTP. C'est d'ailleurs ce que fait le navigateur, quand tu tapes l'URL avec le user/password dans l'URL, il le détecte, décompose l'URL pour extraire les identifiants, reconstruit l'URL normalement, et envoie les identifiants dans les headers. Tu peux le voir dans les outils de développement du navigateur accessibles avec F12. En dehors du navigateur, et c'est donc le cas de la HC3 mais aussi de tout autre appareil comme les caméra/sonnette/interphone/whatever, tu doit donc mettre les identifiants dans les headers de la requête. En LUA sur HC3, voir :

Bon bon bon.... bah... Je suis un peu un boulet quand même. J'ai cherché, je ne comprenais pas, puis j'ai fini par piger le problème. La mécanique d'authentification dans mon QuickApp était bonne pour obtenir le token, et correspond bien à ce qui est documenté par Enphase. Ce que j'avais codé à l'époque est toujours valide. Mais en fait, le QA n'arrivait plus à obtenir le nouveau token pour 2 raisons : - j'ai changé l'adresse email de mon compte Enphase en cours d'année, ce que j'avais complètement oublié ! Mais cet email est utilisé par le QA pour l'authentification en ligne afin d'obtenir le token... sauf que je ne l'avais jamais changé dans les variables du QA ! - mon email comporte maintenant un caractère qui ne passe pas dans les données d'une requêtes HTTP de type POST, car il contient un signe +. J'ai donc été obligé de modifier une ligne dans mon QA pour ajouter un urlencode(). Et maintenant ça refonctionne, le QA a obtenu un nouveau token valable 1 an

Euh... merci... mais pas besoin non ? C'est bien documenté par Enphase dans le PDF, il y a juste une requête à faire en LUA. Le seul problème, c'est que ça dépend du cloud... donc en cas de panne d'accès Internet, de panne des serveurs Enphase, de changement de politique, ou que sais-je encore, on perdra l'accès au monitoring de notre production PV. Et ça c'est lamentable. Triste monde que celui dans lequel les fabricants de technologies high-tech nous rendent captifs APSystems c'est tout pourri en comparaison à Enphase, mais au moins on conserve l'accès 100% local... mais pour combien de temps ? Vu que eux aussi poussent les mises à jour sans prévenir...

La procédure officielle pour obtenir le token en ligne via l'API d'Enphase dans le cloud est donnée dans le PDF suivant : https://enphase.com/download/accessing-iq-gateway-local-apis-or-local-ui-token-based-authentication Je vais essayer de coder ça se soir, ça me saoule de changer le token 2 fois par jour, encore ce matin à 11h. EDIT : et aussi essayer avec un compte invité (non installer donc) IQ Gateway Local API or UI Access using Token-TEB-00060.1.0-EN-2023-08-14.pdf

Est-ce que tu as réalisé ton installation toi-même (installer) ou bien est-ce que quelqu'un d'autre l'a fait pour toi (ce qui fait de toi le owner)... ça devrait répondre à la question. Car j'ai regardé vite fait sur mon compte en ligne, et je ne trouve pas où faire apparaitre l'information... après j'ai peut être mal cherché. Par contre je vois qu'on peut "inviter" des utilisateurs, c'est peut être ça l'astuce, créer un compte et l'inviter en consultation uniquement, et utiliser ce compte pour générer le token valide 1 an. J'ai essayé ce soir de modifier le timestamp d'expiration à la main, et pas moyen, le token réencodé en base64 n'est pas accepté par la passerelle, je suppose qu'ils ont renforcé le contrôle. Pour info j'ai découvert que je suis en version D8.2.4264

Y a un truc là... ça a encore sauté ce soir. Visiblement la durée de validité du token est de 12 heures seulement. EDIT : bon bah..... Trouvé ici : https://forum-photovoltaique.fr/viewtopic.php?p=774043&sid=96ec333f9d4ef781d5626f79dd55765b#p774043 Je cite l'auteur forum6691 :

Merci pour l’expérimentation... et le retour d'expérience !

Étrange... le token généré hier soir a bien fonctionné jusqu'à ce matin 10h précisément, depuis le QA se fait à nouveau jeter... ça commence à être relou cette histoire...

Oui j'ai essayé aussi, mais sans succès, et c'est logique car mon code tente d'obtenir un nouveau token à chaque démarrage, avant d'utiliser l'ancien. Donc que l'ancien soit réellement l'ancien ou bien un truc vide ou bidon, ça ne change rien, il se fait jeter en erreur HTTP 401. C'est une bonne idée la vérification de la durée de validité avec avertissement; mais à l'occasion j'essaierai quand même d'automatiser la récupération du token en ligne.... c'est ce que fait l'intégration pour Home Assistant. Reste le plus dur : faire en fort que cette occasion surviennent avant 1 an !

Cool

Bon... bah.... 1 an plus tard... J'ai eu le problème du token expiré, et non renouvelé. En plus j'étais en déplacement aujourd'hui, coup de flippe en sortant le téléphone du mode avion, je vois la production à 0, alors que le soleil se levait au moment au décollage et que la météo annonçait une journée parfaite (comme sur toute la France d'ailleurs, assez incroyable, vue de malade sur les Alpes à plusieurs centaines de km à la ronde, magnifique... tout le monde a pu profiter ce soleil en ce jour Tempo Blanc.... d'ailleurs ils ne sont pas malins chez RTE cette année, après avoir cramé les jours rouges en décembre quand il faisait chaud, on a eu des jours blancs en février quand il faisait froid... et maintenant ils nous balancent des jours blancs alors qu'il fait soleil... du coup Tempo est encore plus rentable que l'année dernière !!) Bref, vite je vérifie sur les caméra, et non le disjoncteur n'est pas tombé. Le système APsystems a bien commencé à produire de son coté. L'application Enphase Enlighten (via le cloud) m'a permis de confirmer que les micro-onduleurs produisaient bien. Bref, pas eu le temps de m'en occuper avant ce soir en rentrant.... et là j'ai constaté qu'à chaque démarrage du QuickApp il tente d'obtenir un nouveau token, et se fait jeter... comme tu l'avais déjà constaté il y a quelques mois. J'ai réussi avec difficulté à générer manuellement un nouveau token en ligne, car depuis la passerelle Envoy en local, ça semble impossible maintenant. Une rapide rechercher sur les internets mondiaux semble dire qu'on ne peut plus générer le token en local... C'est très inquiétant pour l'avenir. Bref dans l'urgence j'ai copier/coller le token dans mon QA et c'est reparti. Dommage, pas de statistique aujourd'hui dans DomoCharts, c'était une (très très très très.... très) rare journée parfaite, avec une belle courbe en cloche. Au moins, au redémarrage du QA, il a mis à jour les compteurs de production d'énergie (kWh), donc l'information la plus importante n'est pas perdue pour mes statistiques quotidiennes

Bienvenue sur le forum

Après... c'est étonnant quand même, venant de AEOTEC, qui est quand même un gros fabricant de module Z-Wave, de ne pas proposer de box permettant de modifier les paramètres de ces modules, sachant que l'un des avantages du Z-Wave sur les autres protocoles, c'est quand même de proposer de multiples paramètres sur les modules. Tu es sûr que tu as bien cherché dans les menus ? Tu dis que c'est un module Fibaro, est-ce que par hasard AEOTEC ne s'amuserait pas à faire comme Fibaro avec feu Qubino, leur mettre des batons dans les roues en ne proposant pas les templates pour les modules, voire une intégration carrément défectueuse ?

Je ne savais même pas que Aeotec faisait une box domotique... Donc je ne la connais pas du tout, mais je connais d'autres box, par exemple chez Somfy, ou encore feu la Homelive d'Orange, qui ne permettent pas de changer les paramètres des modules... à mon avis, ce genre de box ne devrait même pas exister tellement ça rend les modules inutiles !

Bienvenue sur le forum

Dans l'absolu, oui, c'est à dire que les plus puissants processeurs x86 sont plus puissants que les plus puissants processeurs ARM, mais au prix d'une consommation gargantuesque. Il y a pire... par exemple les processeurs IBM Power (architecture RISC) Mais dire que les processeurs ARM ont une meilleure efficience énergétique, c'est qu'à consommation égale (donc chauffe égale), un processeur ARM sera plus puissant. Ou bien, que pour un même besoin de puissance, un processeur ARM consommera beaucoup moins. Et c'est justement ça qui fait qu'on retrouve de l'ARM dès lors qu'on parle d'embarqué.$ En effet, on n'a pas besoin de la puissance d'un supercalculateur dans notre poche. En revanche, on a besoin d'avoir de l'autonomie (même si bon... sur ce point un Nokia 3310 d'il y a 25 ans faisait mieux que n'importe quel smartphone d'aujourd'hui )

Pour le current tu devrais lire les messages de la page, car en haut de la page tu as déjà la solution complète Pour le water.... hum... c'est bien possible... mais comme j'ai un peu modifié la version qui tourne chez moi, j'avoue ne plus trop savoir ce que j'avais fait à l'époque... car je vois des tables water_day et water_month

Oui voilà tout ça D'un coté tu as une architecture x86 qui est reconnue pour son inefficacité énergétique, et de l'autre une architecture ARM qui est au contraire connue pour son efficacité énergétique. C'est pas pour rien que les smartphones, tablettes, montres, et quasiment tous les objets mobiles utilisent une architecture ARM. Et que les processeurs x86 sont restés cantonnés aux serveurs et PC... et encore, même là, ARM essaye de prendre des parts de marché.

Hum... bonne question... j'ai toujours utilisé les favoris du navigateur pour ça, je ne me suis jamais posé la question. Mais il ne me semble pas avoir vu ce type de fonctionnalité. Peut-être au travers d'un plugin additionnel...

C'était quoi le problème ? Que tu te demandais un nouveau token à chaque connexion ? C'est bête, je t'ai mis sur la piste quand on en avait discuté il y a quelques mois, car tu affirmais pourtant réutiliser le code LUA concernant l’authentification de mon propre Quickapp... ce qui n'était manifestement pas le cas sinon tu n'aurais jamais eu ce problème. Bon bref, dommage qu'on se soit mal compris et que tu aies perdu autant de temps que ça, et que tu m'en ai fais perdre au passage

Bah vu la chaleur du boitier alu au toucher, clairement ça en transmet pas mal de la chaleur ! C'est pas une question de étanche (qu'elle n'est pas de toute façon, aucune certification IPxx), mais de transmission de la chaleur entre l'air et la paroi. Deux fois, une première fois de l'intérieur vers le boitier, puis une seconde fois du boitier vers l'air extérieur. Mais oui, on était plusieurs à avoir remplacé les cotés par des grilles pour favoriser l'aération. Mais voilà, pareil, on ne saura jamais si c'était utile ou non... l'électronique étant relativement résistante.