Aller au contenu
TonyC

HC3 - 5.050.13 -Stable - 09/10/2020

Recommended Posts

Oui je suis d'accord, et je ne dis pas le contraire sur l'attention qu'il faut porter à cette instabilité.

A ce sujet, je conseille de commencer par isoler le Quickapp ou la Scène qui est responsable de ce changement de comportement.

Et si ça se trouve, cette recherche aboutira à désactiver tous les Quickapps/scènes pour se rendre compte que l'instabilité ne vient pas de là.... on ne sera pas plus avancé, mais on aura éliminé une piste.

 

Quand au sleep, je ne suis pas si extrémiste, il est encore supporté, mais il faut l'utiliser avec parcimonie :)

 

Pour l'instant je trouve cette HC3 très stable, pour mon usage (qui encore une fois comporte très peu de modules Z-Wave, juste pour tester, mais par contre j'ai beaucoup de QuickApps actifs)

 

Ces discussions me rappellent celles qu'on a eu au sujet de la HC2, en v4, une fois que Fibaro avait corrigé tous les bugs de jeunesse, certains utilisateurs se plaignaient encore de plantage, et en arrivait à supprimer totalement les Main Loops de leurs modules virtuels. C'était bien selon moi un mauvais codage LUA des dites Main Loops.

 

Dans un autre registre, dans mes codes j'ai toujours limité les écritures dans la DB (tant pour les performances, que pour l'usure de la mémoire flash). Que ce soit une variable globale, un label, etc.... je vérifie l'ancienne valeur, avant de potentiellement modifier la nouvelle valeur. Cela évite de réécrire inutilement une valeur identique.

A l'époque de la HC2, à un moment donné j'avais même soupçonné que trop d'écriture simultanées dans la DB pouvaient occasionner des plantages par effet de bords de plusieurs écritures qui se télescopent (au passage en v4, Fibaro avait introduit un process au niveau de Linux par lequel étaient censées passer toutes les écritures)

 

De même, il ne faut jamais supposer qu'une fonction va renvoyer une donnée attendue, il faut toujours la tester avant de l'exploiter dans la suite du code (tester son type, et sa valeur....)

 

Ce sont quelques pistes, certes lourdes à mettre en place dans l’écriture de nos codes, mais qui les rendent plus robustes, et évitent bien des plantages.

  • Like 1

Partager ce message


Lien à poster
Partager sur d’autres sites

 

Il y a 4 heures, Lazer a dit :

On a le même firmware, la différence, ce sont nos codes LUA.

Bien d'accord, je n'ai (pas encore) de QA installée.

Le sleep opérationnel qui je n'ai pas (encore) converti en setTimeout est de l'ordre de 4 minutes - à la limite du tolérable certainement, et sont relancés à chaque déclenchement d'un FGMS (éclairage d'un couloir d'entrée).

 

Cependant (et fort heureusement), aucun redémarrage de services, ou autre. Elle tourne comme une "HC2" !!!

 

Partager ce message


Lien à poster
Partager sur d’autres sites

×