TitiXsi

C'est pour cette raison que je n'utilise pas le cumul... en revanche le json des microonduleurs semble fiable bien sûr réactualisé toutes les 15min..

Hello, quelques news sur ce sujet ... Problème isolé, compris, fixé, c'est vraiment un cas tordu... si la valeur renvoyé est Pile poil un entier (sans virgule). Bon ok, ca doit arriver 1 fois sur 1 000 000 000 ... le %d n'est pas content seulement si il y a plus d'un seuil de définit... Surement que le split transforme la variable de float à integer dans ce cas là ... C'est étrange, je pensait que le %d transformait un integer en Float dans le pire des cas... C'est fixé dans le getEvents ;-)

Merci, je vais me pencher sur le sujet

Salut @Lazer, j'ai une question pour toi J'ai vu dans le code qu'il était possible de mettre plusieurs seuils de déclenchement par Variable si on sépare les valeurs par une virgule : ProdThresUp : 1800,2000 Confirmes tu que c'est supporté et que la syntaxe est correcte ? Je rencontre un plantage lors que l'accès à getEvents si mon seuil dispose de plus d'une valeur. Merci Ps : J'apprends à utiliser les Events et c'est carrément Top ! Merci

Peut-être que ma qa est trop gourmande et plante par moment... j'avais lu un truc (peut-être gea) et sa capacité à détecter une sa ou un scénario dans les choux pour le redémarrer... je vais regarder .. mais étrange d'avoir un certificat à valider désormais sur la passerelle...

Et voilà... je le voyais venir. Fin d'api au 30.09... @Lazer ça fonctionne toujours chez toi ? J'ai l'impression que le production.json n'est plus accessible depuis cette nuit... Bon en fait, j'ai rien dit, c'est toujours accessible, mais il faut valider un certificat pour accéder à la passerelle... Enphase et ses entourloupes ...

Hello, quelques news avec 4 bonnes nouvelles de mon côté : Le passage à la fibre à permis de gagner un peu de latence sur le l'interrogation de la passerelle en Wifi --> problème de saturation de la passerelle au bout d'une journée, au lieu de quelques heures (avec un Timing refresh de 60sd) J'ai enfin compris l'origine du problème de saturation de ma passerelle. --> Je pensais à Tord que le Timeout était "intelligent" et qu'il n’enverrai la requête suivante que lorsque la précédente était terminée (asynchronisme et callback)... Erreur, si la requête précédente à pris du retard, les 2 requêtes s’emplafonnent et la passerelle perd les pédales... --> J'ai donc j'ajouté un simple compteur qui est incrémenté à l'exécution d'une requête et décrémenté quand celle-ci revient "SUCCESS" ou "ERROR". Ensuite un petit check qui permet vérifier qu'aucune requête n'est en cours, si tout est Ok, on peut soumettre la nouvelle requête. C'est simple et au moins si la passerelle a du retard, la requête suivante ne partira pas, tout fonctionne pour le moment avec toujours des retards... Fichu Wifi ... (avec un Timing refresh de 30sd) Je viens de câbler en RJ45 ma passerelle et clairement c'est plus rapide, le ping répond en 2ms contre un temps variable de 40ms à 1.7s en Wifi. --> Je pense que là je n'aurais plus ou encore mois d'erreur. J'ai normalement terminée ma QA, elle est en test pendant 1 semaine histoire de fixer les dernières broutilles non anticipées... et je ferai un fil dédié Encore Merci pour votre indulgence sur mes nombreuses interrogations parfois bêtes... 6mois que j'ai une box domotique, on ne peut pas tout savoir dès la première semaine... Surtout si on mets les pattes dedans franchement avec des QA

La bonne nouvelle est que les commandes garde le tempo de 10sd. Chez moi ça vrillait plusieurs fois par sd..

Ce n'était pas sans ce sens là. Mais c'est pas un problème. Je viens de découvrir qu'il y avait 3 codes dans ton QA. du coup, ça change la donne, j'ai les infos qu'il me faut... je pensai depuis le début que les fonctions enphase:... était liée un l'API directement et j'essayais de trouver en vain des infos dessus.. la buse... enfin.. j'apprends

On est bien d'accord, que lorsqu'il produit moins que la tension de démarrage des mo, ca coupe, c'était juste une remarque qui montre que j'ai un réseau de montagne, c'est pas tout lisse ... Sinon J'ai 3Qrelay et donc 3*30m de câble en 2.5 Pour le coup, ca c'est peut-être du à ma non connexion à internet. La passerelle essaie de transmettre ses infos (peut-être plus que l'envoi toutes les 15min) et un timeout de plusieurs heures en présent. On verra quand internet reviendra ... as tu pu essayer mon code ? :) Merci

J'ai pas compris, dès que je sélectionne Code et désigne un langage, j'au un truc tout pourri ... Same issue 20 Sonnenstrom Fabrik M60 + 3 Bisol Bifacial, le tout en Iq7+ Je viens de remarqué que j'ai eu plusieurs micro coupures de courant (mes fils pilote Qubino on resetés...) c'est au même moment que j'ai perdu progressivement la prod pui qui est revenus. Je suspecte quelques baisses de tension ... Sinon, cette nuit, erreur de getProduction de 23h à 9h15 et depuis tout va bien ... il se passe des choses étranges avec cette passerelle ...

Hello, je reviens sur mes erreurs liant une saturation de la passerelle. Étant privé de connexion internet depuis 1 semaine, j'ai pu en profiter pour debugguer. Première chose, je confirme que la vérification du token, se fait bien en local, d'ailleurs, on peut mettre un vieux Token, du moment que la date encodé en unixbase n'est pas dépassé, c'est fonctionnel. La seconde, J'ai enfin trouvé le point bloquant qui "spammait" ma passerelle de requetes, j'ai rajouté un check dans le code qui permet de de vérifier qu'on est bien en présence d'un refresh, sinon on sort avec un callback. Ca semble fonctionner correctement . La dernière chose que j'ai pu noter, est dès qu'on essaie d'aller sur la passerelle via un navigateur en même temps que la QA tourne, on tombe face à une erreur d'accès côté QA. Ceci confirme qu'une limitation du nombre de "connexions" simultanées est présente. A ce sujet, je vois également passer quelques erreurs non liée à une double connexion coté user/qa, peut-être qu'elles sont liées à l'exportation des data via enlighten... et que durant ce même laps de temps, la QA n'a pas accès à l'api...? je ne sais pas. c'est peu fréquent et pas bloquant. J'avance sur mon fork et je viens de voir aujourd'hui que plusieurs MO arrêtent de produire par moment, certes, c'était un journée très très nuageuse et la prod n'était que de quelques W par panneaux, mais je trouve ceci intriguant. -> Ceci me conforte dans le choix d'aller vérifier qui produit toutes les 5 min du levé du soleil +1h au couché du soleil -1h. En revanche, je bloque toujours pour aller chercher les infos de la page : https://<ip gateway>/api/v1/production/inverters Impossible de récupérer les datas, je suis toujours bloqué avec une erreur de certificat...(Est-ce lié au fait que je n'ai pas internet, et que la vérification n'est pas possible..., je ne pense pas...) Je m'y prends surement très mal, je suis une vrai quiche en requêtes HTTP et autres... Voici mon code (pour le moment dans uns scène, je le transférerai en QA une fois fonctionnel) print("GET INVERTERS (MicroInverters details)") -- date du Token = aout 2023 local Token = 'eyJraWQiOiI3ZDEwMDA1ZC03ODk5LTRkMGQtYmNiNC0yNDRmOThlZTE1NmIiLCJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiJ9.eyJhdWQiOiIxMjIxMzEwMjE4MzMiLCJpc3MiOiJFbnRyZXoiLCJlbnBoYXNlVXNlciI6Im93bmVyIiwiZXhwIjoxNzI2NDIxMTA2LCJpYXQiOjE2OTQ4ODUxMDYsImp0aSI6Ijg4MDRlNWU0LWNjZTItNGFiZC04N2EwLTI2YmQ3NTQ5NGY4ZiIsInVzZXJuYW1lIjoicmVtaS5tYWdhbmRAZ21haWwuY29tIn0.jiaR5_XA0Hew7TkmBZ_Kc-22zW4hTeQj6hd6VPpXc0xZq0PIyoBVdXD_4SIKTzz-IU94916J-54sU3GWT7U09g' local Bearer = 'Bearer ' .. Token local URL = "https://192.168.1.89" local API = "/api/v1/production/inverters" local http = net.HTTPClient() function RequestHTTP() print("START") http:request(URL .. API, { options = { method = 'GET', checkCertificate = 'false' , headers = { ['Accept'] = 'application/json', ['Content-Type'] = 'application/json', ['Authorization'] = Bearer }, timeout = 10000 }, success = function(response) local result = response.data; if response.status == 200 or response.status == 201 then -- réponse OK print("OK") fibaro:setGlobal("TableEnvoy", response.data) hub.debug(response.data) TableEnvoy = json.decode(response.data) hub.debug("activePower =" .. TableEnvoy[2].activePower) else -- réponse Pas OK print("KO : ".. response.status) hub.debug('response code : ' .. response.status) hub.debug("TableEnvoy -> False") setGlobal("TableEnvoy", "False") hub.debug(response.data) end end, -- Erreur sur la fonction error = function(err) print("ER :".. err) hub.debug("TableEnvoy -> False") --setGlobal("TableEnvoy", "False") end }) --fibaro.setTimeout(1*1000,RequestHTTP) -- boucle toute les secondes end fibaro.setTimeout(0,RequestHTTP) print("END GET INVERTERS (MicroInverters details)") et la sortie qui va bien jusqu'au bout, mais présente l'erreur de certificat: Merci pour votre aide. (Merci @stipower pour ton code HC2 ;)) Rémi

Tiens une question de pur curiosité sur les variables Pourquoi j'en ai qui ne sont pas éditables ?

J'ai passé le settimeout général à 15sd au lieu de 1sd... à voir, ca semble être plus stable même si il y a des déco. J'ai tourné en mode debug je vais suivre ...

je suis déjà à 60sd, mais quand on regarde le log. on est à plusieurs tentatives par seconde (en cas d'echec)

@Lazer, je me rends compte que la QA quand elle rencontre un "can't get (production/inventory...) recommence immédiatement sauf que ma passerelle a un temps de réponse au ping aléatoire ... quelques ms à plusieurs secondes. Je parlais dans mes messages précédent de saturation progressive, ne serais pas lié au setTimeOut qui n'attends pas forcément la fin de la réponse précédente (ce n'est pas son rôle, on est en asynchrone) pour envoyer une nouvelle requête et rajouter de la latence de traitement à la passerelle jusqu'à ce qu'elle mouline complet et ne soit plus accessible ? Merci pour ton expertise

20 ième appel au support enphase : Oui monsieur c'est un problème connu, même pour nous, ça prends très longtemps d'avoir les infos et parfois les requêtes n'aboutissent pas... et ceci depuis la version D7 On ne sais pas vraiment d’où ça vient... on cherche toujours, on est entrain de développer un autre système d'authentification, le système va changer. Peut-être qu'il n'y aura plus de token en local, je ne sais pas mais on travail dessus. Malheureusement, je ne peux pas downgrader la passerelle en D5, ca serait trop simple pour nous. ceci n'a rien avoir avec votre Connexion Wifi ou autre on va vider le cache de la passerelle et vous allez ré-essayer A suivre ! Sinon Aeotec Gen 5 avec 3 pinces et j'en utiliserai que 2...

J'ai simplement une Doc qui explique que l'API la passerelle est accessible via IP/home et déjà, là, ça fonctionne pas.. donc bon... parlon de la base des choses... au ping j'ai rien.

Je ne comprends même pas la légalité de cette mise à jour forcée. Si cela rend obsolète certaines fonctionnalités du système...

Tous les problèmes reportés date d'après le token. Comme disait l'autre... c'était mieux avant... je soupçonne qu'ils aient mal anticipé les besoins de gestion de token et qu'ils soient un poil sous l'eau niveau serveur. D'ailleurs hier ça pedalait sous l'application... bref. J'adore enphase mais son api, beaucoup moins ...

Justement, depuis des mises à jour des passerelles post D7, certains micro onduleurs on du mal à retrouver le nord par moment, je suis sur le groupe facebook Enphase france et c'est au minimum 2,3 personnes par semaine qui ont des perte de mo, et comme l'application n'envoie pas de notification en cas de problème... bref, si ca intéresse que moi, c'est pas grave :p Edit : J'ai rajouté mon 3eme Qrelay avec mes nouveaux panneaux et j'ai pu les voir passer via la QA (le seul moment ou elle a marché d'ailleurs)

oui, j'ai toujours eté en wifi 2.4ghz, j'ai essayé en 5ghz. j'ai même tenté de passer en RJ45, ça n'avait pas été folichon non plus, mais j'avais un câble très vieux un cat 4e je crois Bref, je vais profiter du cat5e qui passe à proximité de la passerelle et qui alimentait ma box free en adsl. Je vais lui mettre une prise et on verra déjà ce que ça donne. Je te rejoins sur le fait qu'il n'y a pas de grosses à transiter, mais il y a toujours un check du token qui à mon avis prends du temps, je ne sais pas comment c'est géré cette histoire en local... J'ai édité mon précédent message entre temps, et rajouté un snapshot sur mon état de codage Merci pour les devices zwave, je regarderai ça quand j'aurais abandonné l'api enphase ...

Bouh que j'en ai marre de cet accès à la passerelle qui ne marche jamais ou du moi très rarement... comme si il fallait des plombe pour répondre à la requête et qu'elle s'accumulaient... plantage toutes les 1h puis toutes les 15min, puis tout le temps ... J'ai contacté le support Enphase qui au début a été bien sympa, mais là visiblement, ils bottent en touche... ca vient de l'api et pas de la passerelle, merci de contacter le support api. et de l'autre côté, ca vient de la passerelle et pas de l'api ... Je viens d'être fibré et je pensais que ceci arrangerai peut-être les choses ... Que Nenni ! Du coup je vais essayer de la relier en RJ45, même si avant le déploiement D7, je n'avais aucun problème à taper l'api toutes les 500ms ... c'est dommage, j'avais un chouette truc pour vous .. le nombre Qrelay UP et le nombre de micro-onduleurs qui produisent... En codage la puissance par micro-onduleurs... mais là je suis bloqué dans le dev ... :'( Il existe quoi en device zwave afin de trouver un woraround fiable pour mesurer 2 puissances (j'ai vu quelques pinces, mais lesquelles sont fiable et jusqu'à quelle puissance) ?

Effectivement j'ai galéré à l'ajouter... Réseau en bois également....

Par contre as tu suivi le changement de profil qui limite les micro onduleurs avec 7% de marge sur le cos Pi ? Ca parle pas mal là dessus en ce moment et je viens de voir que ma passerelle à été mise à jour aujourd'hui J'ai une courbe très étrange et surtout mon pic de prod est à 4.9kw contre 5.4 hier ! soit 8% de moins ... même température, même temps ... J'adore Enphase mais là avec l'api locale injoignable et ses updates de ***