Lazer

tu parles de temps réel versus le périmètre. Donc tu pense qu'il y a un décalage temporel ? De quel ordre (secondes, minutes, plus ?). Dans le même genre, quel est l'intervalle de relevé de la position ? Ca fait beaucoup de questions pointues, mais je trouve que la localisation GPS est la principale utilité de ce module dans notre cadre domotique.

Génial Tu arrives à récupérer la localisation GPS de la voiture ? Parce qu'en utilisation domotique ça serait terrible !

OK c'est très clair. Bon du coup je ne vois vraiment pas ce qui cloche. Essaye de remplacer la ligne 14 comme ceci, afin de sauter l'ID 185, afin de voir si ça fait de même sur les ID suivants ou si c'est un cas isolé : if sensor == k and tostring(id) ~= "185" then

On ne ferme pas les yeux, on constate les propos des uns et des autres sur le forum. Et je vois plus souvent des gens se plaindre (moi le premier avec ma maigre expérience de seulement 60 modules.... bon allez, 62 modules avec ceux que j'ai renvoyé à l'expéditeur) des modules tiers que des modules Fibaro. Pourtant tu sais très bien qu'ici tout le monde est libre de se plaindre et ne s'en prive pas. Donc ton retour d'expérience est intéressant et bon à prendre en compte. Les WP qui te posent problème, est-ce que tu penses que c'est à cause du firmware du WP, ou de la box (tu ne dis pas si c'est une box Fibaro ou une autre)

J'ai regardé mais je ne comprend pas où est le bug. Bon on va reprendre. Déjà personne n'a les mêmes numéros de lignes, donc quand tu me dis qu'une instruction plante (Assertion failed) ou que tu insères un fibaro:debug(), il ne faut pas me donner le numéro de ligne du script LUA, mais le contenu de la ligne en question. AInsi j'ai plus de chance de m'y retrouver. Autre variante, je te partage le bloc fautif, et on se sert de la numérotation des lignes du forum : -- Get HC2 Netatmo Weather Station plugin device if version == 4 then payload = "/api/devices?type=com.fibaro.netatmoWeatherStation" response, status, errorCode = HC2:GET(payload) if tonumber(errorCode) == 0 and tonumber(status) == 200 and response ~= nil and response ~= "" then -- Get data jsonTable = json.decode(response) if jsonTable[1] and jsonTable[1].properties and jsonTable[1].properties.childTable and jsonTable[1].properties.childTable ~= "" then local childTable = json.decode(jsonTable[1].properties.childTable) for id, data in pairs(childTable) do local sensor = data:match("%.([^%.]+)") -- Split string after dot for k,v in pairs(netatmo) do if sensor == k then local deviceName = fibaro:getName(id) local roomID = fibaro:getRoomID(id) local roomName = fibaro:getRoomNameByDeviceID(id) if debug then fibaro:debug(id.." "..deviceName.." "..roomName) end datas[#datas+1] = {} datas[#datas].id = id datas[#datas].type = v datas[#datas].name = deviceName datas[#datas].roomid = roomID datas[#datas].roomname = roomName break end end end elseif debug then fibaro:debug('<span style="display:inline;color:red;">No Netatmo device found') end else erreur = erreur + 1 fibaro:debug('<span style="display:inline;color:red;">status='..status..', errorCode='..errorCode..', payload='..payload..', response='..(response or "")..'</span>') end elseif debug then fibaro:debug('<span style="display:inline;color:red;">Netatmo plugin not supported') end Donc dis moi où ça plante, où tu as inséré ton debug, et j'essaierai de trouver une solution.

Et justement, il faudrait le JSON du 185 pour voir. Sinon tu as essayé ma méthode de contournement avec : or "???"

Tiens au fait j'ai reçu mon switch et il fonctionne super bien. Il se stacke sur le G8, c'est très beau Donc geek, àdéfaut d'être WAF

Arf pas de chance. Oui c'est un peu ce que je me suis dit avec ce module, qu'il n'était bon qu'àcréer des problèmes. Tiens, imagine ce genre de module sur une porte de garage, et tu vois pourquoi je préfère assurer la sécurité A noter que de tel bugs peuvent même arriver avec un module FIbaro, même si c'est extrêmement rare.

Aujourd'hui les voitures se volent avec un boitier programmé par des hackers. Demain (reste à définir la date), les maisons seront cambriolées de la même façon. Pas besoin de connaitre la technique, li suffit d'utiliser une invention faite par d'autre. Quand tu vois sur Internet le tuto complet pour hacker du Z-Wave (conférence de janvier 2016), et qu'il n'y en a que pour 400€ de matos, une solution tout intégrée peut venir assez vite. Heureusement que le Z-Wave et les serrures Okidokeys (idem) ne sont pas (encore ?) très répandu, sinon ça serait trop facile. Mais ça viendra L'OS gère ce qu'il a a gérer. L'OS Linux de la HC2 n'a jamais planté. Donc l'OS fait parfaitement son job. Mais si les applis sont mal programmées, c'est leur problème. Quand tu fais du multithread et de la communication interprocessus, tu as plein de cas à gérer => genre que 2 thread/applications n'aillent pas modifier la même variable ou espace mémoire partagé simultanément, sinon tu as une corruption de ta donnée, et fatalement ça plante. Il faut pour cela gérer des mutex, permettant de bloquer la variable le temps qu'un thread travaille dessus. Le souci entre un CPU mono-coeur avec de l'Intel Hyperthreading et un autre CPU bi-coeur, c'est que le scheduleur des CPU ne travaillent pas de la même façon. Donc un programme qui fonctionne "par magie" sur une machine, va irrémédiablement planter sur l'autre. Bref la littérature est abondante sur le multithreading, c'est un piège à développeur tellement c'est complexe à gérer. Il faut être très rigoureux.

@Nico, sebcbien a parfaitement répondu, j'ajoute juste toujours la même chose: pour l'assurance il faut une effraction, donc pas envie qu'un bug/hack ouvre ma porte. Après tu fais comme tu veux,mais moi je suis parano, et j'habite le 93, donc y'a de quoi être parano.

A non moi ça sera pire : - l'alimentation du moteur sur un Wall Plug (ou un relai de l'IPX, peut importe ça revient au même) => permet de couper l'alimentation pendant notre absence, la nuit, etc, pour déjouer les replay du signal 433MHz - le contact sec d'ouverture/fermeture sur un relai de l'IPX et un relai d'un FGS, en série. Double protection => permet de sécuriser et d'éviter l'ouverture inopinée (piratage du réseau Z-Wave, bug du réseau Z-Wave, bug de l'IPX, bug de la HC2) Et évidemment, capteurs d'ouverture et de fermeture de la porte, avec GEA derrière pour traiter les différents cas de figure. Oui je suis un grand malade, mais vous savez que je ne rigole pas avec la sécurité

C'est un peu dans ce style là que je vais faire, avec un truc en plus : mettre un FGS et un relai d'un IPX800 en série pour piloter le contact sec du moteur. Ainsi je me protège contre le piratage du réseau Z-Wave (ou un simple bug) Mode parano

Absolument

Ca m'a l'air sympa tout ça. Continue de nous faire rêver PS : c'est "baveux et mou" ( ) parce que tu inclus les images dans le message, et le forum réduit la résolution. Il faut les mettre préalablement dans la galerie pour que ça soit beau.

oui ce n'est pas le 183 mais l'un des modules Enfants du Plugin Netatmo qui pose souci. SI tu regardes bien le code de la boucle, on parcours tous les modules enfants

En effet, étrange. Et si tu testes manuellement le fibaro:getName(183) dans un autre VD, ça fait pareil ? Sinon essaye cette technique de contournement : local deviceName = fibaro:getName(id) or "???"

J'adore En résumé, connaissant le contexte : bonjour j'ai une HC2, et c'est pas normal, l'utilisation RAM est maitrisée :2: Il faudra s'y faire, les problèmes de RAM sont en passe d'être résolus. Ce qui est étonnant c'est que tu sois encore en 4.080 alors que les améliorations ne sont qu'en 4.082. M'enfin tant mieux pour toi EDIT : 48h de uptime, RAM ULTRA STABLE en 4.082, un truc de fou, heureusement que j'ai mon graph pour y croire

Parce que ton FGMS doit maintenir son état pendant 30s. Voir la doc, je n'ai plus en tête. Ensuite dans ta scène, il faut d'abord faire un getvalue() et agir en fonction.

Est-ce que tu peux activer la variable debug=yes dans le bouton Devices ? Ensuite tu verras plein de choses, dont le device ID qui fait planter le getName. Ensuite regarde le JSON (/api/devices/ID) du module en question. On dirait qu'il n'a pas de nom, ou un nom invalide.

1/ Justement !!!! On sait que la main loop merde depuis toujours (c'était le cas en v1, en v3, et donc en v4), et là tu me dis que tu as une boucle qui interroge un périphérique IP (Eco-devices, IPX, etc... bref peu importe l'appareil). Donc tu es en plein dans le cas où tu sais pertinemment que ça va planter. STP ne vient pas te plaindre après.... Perso le script Eco-Devices, trouvé sur un blog, c'est le premier script LUA que j'ai mis en oeuvre sur ma HC2 il y a 2 ans et demi. Ca n'a pas loupé, 10 jours après il était planté. J'ai donc cherché, et compris que la main loop était amenée à planter systématiquement dans ce cas de figure précis (= 1 requête http dans la main loop). Donc il n'en faut pas plus pour trouver une autre solution. Tu écris une scène qui clique sur un bouton du VD et le tour est joué. Mon meilleur exemple : Domocharts. Terminé on n'en parle plus, on arrête de se plaindre, on passe à autre chose et on avance. Après je suis allé plus loin, en m'inspirant des techniques des Main Loops de Krikroff. Tu prends ses VD Sonos ou Freebox par exemple. C'est la recette que j'ai appliqué à mon VD Surveillance Station, il effectue plusieurs requêtes HTTP par minute, et il est ultra stable. Pourquoi ? Tu savoir que la main loop, comme son nom l'indique, est une boucle infinie. Dons en fait, ton code est exécuté en boucle, sans cesse. Fibaro a juste introduit une sécurité, un Sleep de 3s. Donc si tu déclares une variable, à chaque passage dans la boucle, tu la redéclare, Si en plus ta variable que tu redéclare à chaque passage est le contenu d'une requête IP, ça alloue bcp de RAM. Donc ta mémoire augmente vite, le garbage collector du LUA n'a pas le temps de faire le ménage, donc ta mémoire utilisée devient trop grosse et ta main loop plante (par sécurité, avant de planter tout le système.... l'isolation des processus des VD a toujours bien fonctionné sur la HC2). La technique de Krikroff justement, c'est de déclarer la variable en global, et à chaque passage dans la boucle, on ne la redéclare pas. Si maintenant ça variable est un objet LUA qui comprend des variables et des fonctions, tu fais tenir tout ton code dans une seule variable, qui ne sera pas réalloué à chaque passage => Gain de performance et de mémoire. Terriblement efficace, plus aucun plantage !!!! Et oui la programmation c'est pas simple..... c'est plus complexe que de prendre les 3 premières lignes de LUA trouvées sur le forum ou un blog tiers. Tu comprendras que pour les devs Fibaro, c'est la même chose en 10^10 fois pire. Imagine un peu Microsoft avec Windows qui a été critiqué pendant des 10zaines d'années pour les mêmes raisons. Ils sont finalement parvenu à livrer un OS ultra stable, qui résiste à tous les programmes mal codés par les dévs du dimanche que nous sommes. En attendant, quand on développe, qu'on soit devant ou derrière le système, il faut s'appliquer et ne pas systématiquement rejeter la faute sur les autres, surtout quand le bug est connu de longue date (là je parle de la main loop) 2/ C'est quoi un timer ? Une scène en mode bloc ? Tu as déjà converti une scène en mode bloc en LUA pour voir à quoi ça ressemble ? C'est de la merde. Donc une fois que tu sais ça, tu abandonnes les scènes en mode bloc, et tu codes un truc en LUA propre, ou si tu ne sais pas / n'a pas le courage de faire, tu utilises GEA. 3/ Tu as très certainement un module sur ton réseau Z-Wave qui fout la grouille, car il a été mal inclu. Toutes les fois où j'ai vu ce problème sur le forum, et que l'utilisateur a fini par le résoudre tout seul, ça a été simple : isoler tous les modules un par un, jusqu'à isoler le coupable, puis l'exclure, le reseter, et l'inclure proprement. Visiblement certains modules sont des candidats idéals : Aeon Labs, Fibaro RGBW, Swid, etc. Justement tu devrais commencer par exclure tes Swid pour voir, c'est un bon début. En ce qui concerne le Motion Sensor, 99% des problèmes remontés sur le forum sont un problème d'interface chaise/clavier => La doc est ultra complète, il faut la lire plusieurs fois pour comprendre les interactions entre les différents paramètres. Si ton capteur ne te voit pas, il y a peut être un souci de blind time. Ca tu le constateras facilement avec la diode du capteur. Il y a déjà eu de nombreuses discussions à ce sujet sur le topic dédié, que tu peux aussi relire si tu en as le courage, mais tu devrais prendre le temps pour arriver à tes fins. 4/ La limitation d'instance est une sécurité, justement à cause des scènes mal codées par les utilisateurs, et on en a vu plusieurs exemples sur le forum. Pour le coup, je trouve que Fibaro a eu parfaitement raison de limiter le nombre d'instances, et la valeur par défaut = 2 est juste parfaite, sauf pour GEA qui peut être amené à traiter un plus grand nombres d'actions simultanément du fait que cette seule scène gère tous les modules de la maison, par définition. 5/ C'est pour cela que je n'ai domotisé aucune ouverture, trop de risque de sécurité, et pas à cause de Fibaro, un bug ou une faille informatique est si vite arrivé, quelque soit la box. J'ai déjà réfléchi à comment je fais domotiser mon garage, ça va être assez sécurisé, je ferai un topic sur le sujet je pense. Des trucs ultras simples : des modules que nous avons tous, avec des scénarios ultra basiques d'ouverture/fermeture de volets et terminé. Pas de scripts LUA écrits à la va-vite, qui planteront inévitablement (cf bla-bla du dessus). Bref, de la domotique pour Mme Michu, ce qui doit bien représenter 99,99% du public. J'aime bien la comparaison avec le monde de l'informatique. Qui a fait du DOS ? Nous, parce qu'on est des powers users en avance sur notre temps (technologiquement parlant). L'informatique ne s'est démocratisée dans le foyer de Mme Michu qu'avec l'arrivée d'Apple, parce que l'interface est ultra simple, et ultra limitée aussi (l’utilisateur ne fait que ce que le constructeur a décidé). En domotique on appelle ça Somfy. Et le revendeur a l'expérience des modules qui posent problèmes, donc il évitera de vendre à ses clients les modules à mauvaise réputation (toujours les mêmes : Aeotec, Swid, Qubino, etc). En gros, en modules, Fibaro ce sont les meilleurs. Aucun risque avec ça. Pour info le vendeur/installateur auquel je pense n'est pas PITP2, et il n'installe que des HC2 depuis 3 ans car c'est la seule box (dans le cas de figure de la domotique de Mme Michu) avec laquelle il n'a aucun problème. Oui vous avez bien lu, et il a fallu que je lui fasse répéter 2 fois pour le croire. Donc encore une fois, je maintiens qu'outre les bugs du code de Fibaro, nos instabilités sont dues à nos scripts LUA et nos modules mal inclus et/ou firmware buggé. EDIT : en fait j'ai fait un long discours sur le LUA, mais ce qu'il faut retenir c'est : ce n'est pas les scripts complexes qui font planter la box, mais ce sont les scripts trop simples !!!! Oui c'est paradoxal quand on ne sait pas programmer, mais quand on creuse un peu le sujet, on s'aperçoit que les 3/4 d'un code source sont de la gestion d'erreurs et d'exceptions. Ce qui permet de rendre le script plus stable.

Avant le soft reconfigure, tu peux juste commencer par un truc ultra simple => re-sauvegarder les paramètres, ce qui va avoir pour effet de contacter le module (penser à réveiller le module si il est sur pile). J'ai constaté que certains attributs du JSON se mettaient à jour à ce moment là . Je n'ai pas poussé plus loin la comparaison des JSON avant/après pour savoir si un soft-reconfigure est nécessaire. Dans la pratique, je n'ai fait des soft-reconfigure que pour des modules qui me posaient problème (dont une fois un soft reconfigure qui avait fini en 503, puis 2 reboot avant qu'il ne se termine.... donc méfiance). Celle-là j'ai hésité à la faire hier soir quand j'ai partagé mon uptime de 28 jours Merci d'avoir relevé

J'ai 60 modules Z-Wave, plusieurs scènes et VD, et des fake modules EnOcean. Le tout depuis la v3, il y a 2 ans et demi, sans avoir jamais réinstallé ma box. Au final, elle est àpeu près stable, en tout cas plus stable que beaucoup de retours d'expérience que je peux lire ici. Je pense qu'il y a du vrai dans ce que chacun pense, les bugs viennent du code Fibaro, de la DB, mais surtout des scripts lua de chacun. On sait que le code de Fibaro de check rien, donc si on fait une erreur de script, ID de module, etc, alors ça débouche sur un 503. À ceux qui ont des 503 àrépétition, commencez par vérifier vos scripts ça ira beaucoup mieux. C'est pas normal car le code de Fibaro devrait gérer ces cas d'erreurs, mais malheureusement ce n'est pas le cas donc il faut s'adapter. Pour les cas extrêmes qu'on ne maîtrise pas, il y a le watchdog. J'ajoute que j'ai eu des retours d'expérience de revendeur/installateur qui ont déployé des 10zaines et des 10zaines de HC2 , qu'ils mettent jour àdistance depuis des années pour le compte de leur clients, et c'est rock stable, pas un plantage. Pourquoi ? Parce qu'il n'y a pas de script LUA tordu qui font n'importe quoi. Alors oui, nous on n'achète pas une HC2 pour allumer ses lumières avec son smartphone, mais ça suffit àbeaucoup de clients. Mais surtout, ça démontre que nos script LUA mal codés sont la cause principale des plantages (avec la non gestion des erreurs par le code de Fibaro, mais làdessus on voit qu'ils progressent.....tout doucement) En ce qui concerne le JSON des modules, oui Fibaro àfait évoluer les propriétés dans la DB, mais n'a pas forcé une mise àjour des modules existants. Je ne sais pas la raison, mais il vous suffit de refaire une configuration du module pour qu'il prenne toutes les nouvelles propriétés. Et hop vous avez une DB àpeu près propre, sans avoir besoin de repartir à0.

je ne sais pas, j'ai toujours 2 instances sur mes scènes, sauf GEA qui est au maxi à10

@jojo tu m'as fait peur, je viens de faire un test de backup manuel et c'est OK. Tu es sur que tu es bien passé en 4.082b et que tu n'es pas sur une demi-beta ?

Ah oui vu comme ça c'est pas idiot. 3 minutes de gagnées au reboot, c'est pas mal. Et puis c'est surtout le backup pré-update qui est utile, celui là ils l'ont laissé. Par contre quand je vois tous ces changements, faudrait vraiment qu'il nous fasse des changelogs complets la prochaine fois, car on passe notre temps à essayer de découvrir les nouveautés