jojo Posté(e) le 1 août Signaler Posté(e) le 1 août Le 31/07/2025 à 10:33, flacon030 a dit : Oui c’est se que je fait aussi pour domochart, mais pour grafana et influx db c’est pas la même histoire, sans parler des scènes et de gea que je dois modifier à chaque fois Chez moi Grafana va lire la même DB que Domochart, et oui, il faudra également faire la modif dans Grafana. Pour GEA et autres, j'utilise la QA DeviceID, certes c'est chi..., mais ça facilite Le 31/07/2025 à 10:33, flacon030 a dit : brefs j’en ai marre, je voie pour supprimer un maximum d’éléments de netatmo bienvenue au club !
flacon030 Posté(e) le 1 août Signaler Posté(e) le 1 août Je ne connais pas le qa DeviceID il se trouve ou? Merci
Sankotronic Posté(e) le 2 août Signaler Posté(e) le 2 août Le 31/07/2025 à 10:48, flacon030 a dit : si non autre suggestion, faire un qa crypté avec jeton payant avec mise à jour automatique comme le qa de influx db qui est payant mais avec mise à jour automatique Interesting. Please, can you provide me a link to mentioned Influx db QA? Where I can find it? Thank you
flacon030 Posté(e) le 2 août Signaler Posté(e) le 2 août voici le liens merci https://forum.fibaro.com/topic/58669-qa-influxdb2/
jojo Posté(e) le 11 août Signaler Posté(e) le 11 août Le 01/08/2025 à 22:43, flacon030 a dit : Je ne connais pas le qa DeviceID il se trouve ou? dans ma signature ...
Nico Posté(e) le 6 septembre Signaler Posté(e) le 6 septembre Le 31/07/2025 à 09:27, Sankotronic a dit : Hi @flacon030, You are completely right about needing to reinstall encrypted QA each time when there is an update released. I guess with encrypted QA that will be always the case, needing to replace QA, because I do not believe that Fibaro will change anything related to encrypted QA and security in the future. On the other hand I do not find that as a big problem. Most of my work does not need much of the upgrades except in case like with Netatmo decided to again change their API or server domain. Since that is something that does not happen very often... In case of my work, there is always possibility to get unencrypted version that can be then easily upgraded by changing code, but that has a price. Hello Sankotronic. Plugin was working fine until today, after a problem with global variable on another point. I just seen after that I have not moved all to .com address, so done (I am on HC2 version). But always the same, I have already regenerated token, I have : Any idea ? Update : I found, I need to delete NetatmoW_scene_[scene ID]
Sankotronic Posté(e) le 10 septembre Signaler Posté(e) le 10 septembre Hi @Nico, Sorry for late replay. To renew tokens for Netatmo Weather station standalone version follow this steps: Get new tokens at Netatmo my apps Open Netatmo weather scene and paste new tokens to code Delete global variable NetatmoW_scene_[scene_ID] Save scene and run it at least once manually so that global variable is generated with new tokens Instead of deleting global variable you can just change local variable scVersion from "3.2" to "3.3" and then save scene and run manually at least once. Hope this helps.
Nico Posté(e) le 10 septembre Signaler Posté(e) le 10 septembre Thanks ! I did by deleting the global variable
SebDel Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre (modifié) Bonjour à tous, J'utilise la version la version 2.6 de netatmo weather (Gsmart et Lazer) station depuis quelques temps et bizarrement, lors des lectures des réponses de l'API qui remontent bien, les childs ne se mettent pas à jour malgré le setvalue qui va bien sur les bons ID. Est ce que c'est un bogue générique, ou cela est du à un changement récent de la manière de mettre à jour les childs ? Quand je récupére la value sur le child, il n'est pas mise à jour du tout. Par exemple un nouveau child est indiqué 0 et on n'arrive plus à pousser la value avec setvalue. Merci de votre retour si vous avez remarqué des bizarrerie du genre, même dans d'autre QA. SOLUTION ET RECTIFICATION : Je viens de trouver en fait le problème Les setvalue ne marchaient plus child:setValue("dead", not module.reachable) child:setValue(self.NetatmoTypesToHC3[data_type].value, value) child:setValue("batteryLevel", module.battery_percent) J'ai remplacer par : child:updateProperty("dead", not module.reachable) child:updateProperty(self.NetatmoTypesToHC3[data_type].value, value) child:updateProperty("batteryLevel", tonumber(module.battery_percent)) Et cela refonctionne comme avant. Si cela peut servir à tous ceux à qui le problème pourrait arriver. Bon après je ne suis peut être pas non plus à jour avec mon QA... Amicalement Seb Modifié le 24 septembre par SebDel
Lazer Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre Non effectivement, il me semblait même que cette version du QuickApp ne fonctionnait plus depuis un petit moment... mais pour d'autres raisons (token...) Tu ne le précises pas, mais tu as peut être fait une mise à jour du firmware de ta box qui modifierait le comportement des QuickApps ? Par exemple la dernière beta...
SebDel Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre Bonjour Lazer, A vrai dire j'avais 2 boxes actives à la maison, HC2 et HC3 et de mémoire je faisais le taffe sur la HC3 et je rebalancer en live sur la HC2 avec des requêtes pour mettre à jour les valeurs sur HC2, mais comme j'utilisais les données brutes, je ne me suis pas rendu compte du problème. En revanche depuis la semaine dernière, ma HC2 a crashé et j'ai du faire un recovery en 3.584 (avant 3.60) et du coup je suis bloqué avec les mise à jour (on me propose plus que la 4.07). DOnc j'ai basculé ce qui me resté de device sur la HC3 et j'ai du utilisé les valeurs en local de la HC3 qui n'était plus à jour. Tout ca pour dire que effectivement, cela doit faire un bout de temps que cela ne marche plus, mais en réalité, dans le boulot que vous avez fait qui est superbe, le setValue appelle une méthode de la class du child du QA et ce dernier utilise bien updateproperty. Donc le dysfonctionnement ne doit pas venir directement de l'appel de méthode mais plutôt que le child, depuis une mise à jour de la box 5.XXX, n'implémente plus la fonction setvalue pour ce child et donc la méthode de la class override n'est même plus appelé. J'ai recopié le code qu'il y avait dans la class du child directement dans la reponse au niveau du QA et ca remarche. Effectivement aussi, pour l'histoire du token, j'ai du changer le comportement afin que je ne sois pas obligé toutes les 20 minutes, d'aller regénérée les id et token dans l'API de netatmo. (Le passage au management Legrand n'a pas arranger les choses depuis En tout cas merci pour ton retour. Amicalement Séb
henri-allauch Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre J'ai fait une recherche dans mes QA installés (et ceux chargés et installés depuis le forum) et effectivement il n'y as pas des child:setValue mais des child:updateProperty
SebDel Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre Bonjour Henri, Je pense que ca fait un bout de temps que setvalue ne doit plus être utilisé, mais en y regardant de plus prêt, c'est peut être dans l'instance du child, celui que l'on dérive dans les QA qui ne doit plus avoir de setValue systématique. Cela a du être remplacé par l'updateproperty avec "value" en dernier paramètre. Ce qui permet aussi de récupérer les autres properties de la même manière. A+ Séb
Lazer Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre De ma compréhension, le setValue n'est pas implémenté de base, c'est à nous de l'implémenter dans le code LUA de nos QuickApps.... pour ceux de type actionneurs. Car c'est la méthode qui est appelée par l'interface Web, l'application mobile, pour toute action lorsque l'on clique sur un module pour changer son état (allumé, éteint, dimmer, ouvert, fermé, etc). Le setValue est donc nécessaire pour que le QuickApp réagisse normalement dans l'interface et se comporte comme n'importe quel autre module Z-Wave. Les capteurs, eux, n'ont aucunement besoin de setValue. Et pour changer la propriété d'un module (QuickApp ou Physique), on utilise updateProperty ou setProperty... il y a eu une discussion récemment sur le sujet GEA, voir mon message et le suivant de @jang qui apporte des précisions complémentaires : En résumé, pour un QuickApp, qu'il soit enfant ou parent, ça ne change rien au principe : actionneur : implémenter setValue qui va à son tour appeler updateProperty capteur : appeler directement updateProperty Conséquence, dans le QuickApp Netatmo, qui par principe n'a que des modules enfants de type capteur, on n'a pas besoin d'implémenter setValue. 1
SebDel Posté(e) le 24 septembre Signaler Posté(e) le 24 septembre Bonjour Lazer, Merci pour le développement de ton explication, tout devient cohérent. Venant en partie de la HC2 et du code que l'on utilisait à l'époque, c'est vrai que les interactions était souvent entre le device virtuel et un module physique. D'où l'habitude du getValue et setValue que l'on retrouvait un peu partout. Dans la logique des QA aujourd'hui surtout avec les capacités d'interaction avec les childs cela devient presque naturel d'utiliser les propriétés sur le fond, un peu d'ailleurs comme les variables persistantes que nous n'avions pas directement sur la HC2. En tout cas la structure des QA permettent de restructurer l'ensemble des concepts sur des schémas plus cohérents et j'espère pérenne... A+ Séb
flacon030 Posté(e) le 27 septembre Signaler Posté(e) le 27 septembre Il semble que les serveur netatmo sont encore en vrac Cela me réconforte dans le fait de trouver des solutions alternative Il n'y a que le pluviomètre qui pour le moment me pose problème pour une solution de remplacement Mai je pense que je vais passer avec cette solution https://fr.aliexpress.com/item/1005006160477600.html?spm=a2g0o.productlist.main.11.3b3b228eRwpjOk&algo_pvid=e436fb94-1480-488f-bebc-8070476931dc&algo_exp_id=e436fb94-1480-488f-bebc-8070476931dc-10&pdp_ext_f={"order"%3A"7"%2C"eval"%3A"1"%2C"fromPage"%3A"search"}&pdp_npi=6%40dis!EUR!123.98!61.99!!!1008.79!504.40!%402103985c17589553289764800ead06!12000036047244327!sea!FR!0!ABX!1!0!n_tag%3A-29910%3Bd%3Ac85a3bc%3Bm03_new_user%3A-29895&curPageLogUid=dkUY9Gx0Jo5B&utparam-url=scene%3Asearch|query_from%3A|x_object_id%3A1005006160477600|_p_origin_prod%3A en 0/10V et un RGBW de chez fibaro Si non il y a aussi une version avec pulsation mais je ne sais pas comment le gérer, peut être avec un le compteur a impulsion de l'ecodevice
Sankotronic Posté(e) le 27 septembre Signaler Posté(e) le 27 septembre Hello, this morning at around 07:50h CET all my virtual devices and quick apps for Netatmo weather station and Air Quality monitors reported problem with Netatmo servers. HC2 Virtual devices reported 30 minutes no response. Scene for Netatmo weather get stuck in negotiations and I had to stop it manually by flipping the switch auto/manual. Quick app just reported connection error: Operation canceled and continue working properly. At about 08:25h CET everything come back to normal operation and none of my VD and QA reported invalid tokens. If you notice any problems please check first in debug if it is interruption of the service or your token is invalidated. In case that you have problems with token then you will have to generate new ones and paste them to either Netatmo scenes or Quick apps. BTW - I noticed also that their mobile apps had problem with connection with servers including Netatmo, Energy and Home coach. I'm talking about these solutions: https://marketplace.fibaro.com/items/netatmo-weather-station-qa-v1-1 https://marketplace.fibaro.com/items/netatmo-indoor-air-quality-monitor-qa-v1-1 both on version 2.1 1
Messages recommandés