Lazer

Qu'est ce que tu appelles compter les 503 ? Il suffit de faire ton propre relevé, mais si tu regardes le topic, je crois que Jojo maintiens son propre journal de bord détaillé. Perso j'ai pas énormément de VG, mais comme je le disais, de toutes façons je limite au maximum les écritures, donc ça joue peut être sur la stabilité de ma box. D'ailleurs un bon exemple est le code source du VD Surveillance Station, j'applique cette recette également aux labels des VD (on ne modifie que si la nouvelle valeur est différente de la précédente.... ce qui impose une vérification systématique de la valeur à modifier.... le code est plus lourd, mais plus fiable)

oui c'est vrai en plus mais il y aura de nouvelles mesures, avec de la chance on aura les plugins

Autant je suis d'accord que pour avoir une interface propre, l'Ajax c'est génial, autant tu racontes n'importe quoi sur les couleurs, c'est bien connu que ça délave Plus sérieusement je suis parfaitement d'accord avec toi, une fois qu'on utilise l'interface en vrai, c'est plus pratique que celle de la HC2, même si ça ne rend pas beau sur les screenshots.

up 5 days, 2:09 Et surtout RAM ultra stable au dixième de pourcent près ! Normal quoi, mais ça me surprend tellement je n'étais plus habitué. J'ai une autre théorie sur les 503 : puisqu'on parlait de race condition quelques pages plus tôt, je pense que le problème est là . A mettre en corrélation avec les expériences de certain sur les création de VG et des saves de Scènes. En gros, à chaque fois qu'on fait une écriture dans la DB, il y a risque de race condition, et donc plantage 503. Perso mes scripts lisent toujours la valeur d'une variable globale avant de la modifier, afin de ne pas la modifier inutilement si celle-ci a même valeur que précédemment. Question d'optimisation afin de maximiser les performances de mes scripts (une écriture est toujours beaucoup longue qu'une lecture), et d'usure de la mémoire flash de la clé interne (inutile d'écrire un truc identique). Au final je me dis que les scripts qui effectuent de trop grandes modifications dans la DB ont plus de chance de planter le logiciel. Et pour le coup, la main loop n'y est pour rien, car c'est bien le code derrière les boutons de VD ou dans les scènes qui seraient à l'origine de ces écritures. Juste une idée comme ça.....

Euh.... je n'ai pas touché àça depuis des mois. Je n'ai ni le courage ni le temps de m'y remettre ces temps-ci, donc il faudra être patient

arf, c'est trop bête comme bug. Merci Steven pour la correction, rapide et efficace

Ca m'a l'air bien compliqué tout ça. Pourquoi n'utilises tu pas GEA ?

oui PITP2, je suis 3ème du concours car j'ai attendu 1 ou 2 jours avant de faire l'update sur ma box de prod. Ce qui est déjàun exploit, car je croyais en cette beta

Moi comme Shad, c'est rock stable depuis 5 jours, même la RAM est stable. Pour le moment la meilleure v4 de mon point de vue, mais comme déjàdit, je suis toujours aussi sidéré par les différences de fonctionnement d'une box àune autre.... et le pire dans tout ça, aucune piste commune

Le lien que tu me donne, le mec dit qu'il n'a que des problèmes avec les HCL. Je n'ai jamais dit le contraire, et je n'ai jamais conseillé la HCL à quiconque et je pense exactement la même chose que le gars. Sinon oui j'ai confiance dans l'installateur en question, il n'a rien à me vendre, j'ai déjà 2 HC2 Il m'a fait part de son retour d'expérience, c'est tout. Mais je reprécise bien que c'est de la domotique "à la Mme Michu", c'est à dire pas de VD complexe ou modules exotiques qui va tout faire crasher. Donc pas trop le type d'installation des membres de ce forum car nous cherchons toujours à en faire plus et à tirer le maximum de notre installation. Donc pas vraiment comparable avec notre expérience.

yes aucun souci, ne te stresse pas de toutes façons je ne fais pas trop de domotique ces temps-ci

Oh punaise, je l'avais raté celui-là(le sèche cheveux). Ils n'y vont pas avez le dos de la cuillère

OK, tiens nous au courant de tes tests, ça pourrait me décider àpasser àl'achat

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