TitiXsi

Hello, La freebox dispose de 4 racks 2.5 et est nativement un NAS. donc je ne pense pas que la perte de données soient un problème. en revanche, oui, à chaque changement de box, il faut remonter la VM, ce qui peut être plus simple sur le CuBox. Je travailles sur Unix côté client mais pas côté Serveur... Donc je n'y connais pas grand chose... A voir avec le temps dispo et la motivation... Pourquoi pas un jour/semaine de pluie :-)

On est d'accord, mais il existe bien d'autres solutions... Capteur d'ouverture de porte, capteur de luminosité, de mouvement... Bref... Je demandais qu'elles étaient les nouvelles installations pérennes et un retour d'expérience

Hello, Je m'intéresse aux stockage des datas et graphs de nos chers capteurs et je vois avec un grand intérêt DomoCharts :). @Lazer, je dispose d'un SolidRun Cubox 4Core, 4Gde RAM (https://www.solid-run.com/news/mini-computer-cubox-i-4x4/) qui dort mais également d'une freebox delta, quel est selon toi la meilleure option pour l'installation du serveur ? Merci Edit : rajout du lien pour le SolidRun

Hello, de quoi parles tu ? relais pour permettre de couvrir la distance jusqu'à la boite aux lettres ?

Bonjour à tous, en 6ans, quels sont vos retours, modifs ou nouvelles solutions pour la "boite aux lettres" avec ouverture porte et a la trappe à lettre Merci

Bonjour à tous, je rebondis sur ce sujet, est'il possible de définir les limites du slider et son step ? Merci Edit : J'ai rien dit, enfin si, mais j'ai trouvé, je ne comprenais pas pourquoi celà ne fonctionnait pas, en faite, ca fonctionne, seulement le gui de debug n'est pas updaté... c'est dommage self:updateView("slider","min","15") -- set absolute min of slider / ref self:updateView("slider","max", "30") --set absolute max of slider / ref self:updateView("slider", "value", "21") --set slider at 21 at start self:updateView("slider", "step", "0.5") --step 0.5 at the time

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...