Aller au contenu

HC3 - 5.050.13 - Stable - 09/10/2020


Messages recommandés

Posté(e)

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
Posté(e)

 

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" !!!

 

  • 4 semaines après...
Posté(e)
Il y a 1 heure, couillerot a dit :

au fait, ce n'était pas fin d'année que de nouveaux protocoles devaient être dispo sur HC3 ? :huh:

 

Stef

Pitié non :lol: Qu'ils stabilisent d'abord ceux déjà implémentés avant d'en ouvrir d'autres :lol:

  • Like 1
Posté(e)

Le COVID-19 est passé par là...

 

Puis bon, on peut garder espoir, il reste 1 mois et demi, une mise à jour à la veille des vacances de Noël est du ressort de Fibaro :D Comme ça ils auront tout 2021 pour stabiliser et rendre réellement fonctionnel ces nouveaux protocoles.

 

Cela dit, maintenant qu'on commence à avoir pas mal de recul, plus je lis de retour d'expérience réels d'utilisateurs ayant de grosses installations en Zigbee (plus de 50 modules, pas juste 2 ou 3 modules dans un coin), plus je me rend compte que Z-Wave reste largement devant techniquement parlant. Les instabilités du Zigbee sont plus fréquentes (et dues à différentes raisons : protocole moins éprouvé, firmware des modules buggué, interférences du 2.5 GHz avec le Wi-Fi, etc)

 

A la limite le Zigbee peut être utile en complément du Z-Wave pour certains cas bien précis. Genre une sonde de température murale (car en la matière, le Z-Wave est devenu très pauvre... étrangement)

Posté(e)

Tu attends quoi du Bluetooth ?

Je rappelle que c'est uniquement le Low Energy, ne t'attends pas à streamer de la musique depuis la HC3 !

Entre la portée ridicule, et comme pour le Zigbee les interférences avec le Wi-Fi en 2.5 GHz, faut pas s'attendre à des miracles

 

C'est tout juste bon pour des balises de détection de présence accrochées au porté clé, à part cet usage, je vois pas trop ?

Posté(e)

Bah écoute j'ai ça en place sur ma passerelle BLEA sur Jeedom avec grosse antenne, cela fonctionne plutôt pas mal et me détecte un tag à 15-20m : J'en ai dans chaque voiture pour savoir si elles sont à la maison oui non. Donc ça va encore, sachant qu'ils sont à l'intérieur de la voiture dans le cendrier :) L'antenne étant elle sur ma baie IT (Câble pour déport) dans un local dans le garage.

Posté(e)

@nico est en train de dire que jeedom a déjà tout ce que la HC3 nous promet. Serait-il moins sectaire en vieillissant

 

Moi je n'ai que du zwave en module sans-fil et je n'ai aucune envie de changer.

 

Ah j'avais oublié j'ai 3 hues qui communique avec un pont est cela restera comme cela même si je passe sous hc3

 

Le gros reproche que font les gens aux zwave c'est le prix. Je n'ai jamais vu de commentaires négatifs qui critique la technologie.

 

Pour moi la qualité à un coût surtout que maintenant on trouve facilement les modules Fibaro à moins de 40 euros j'en ai même eu à moins de 30 euros comme le smart implant, fgdw, fgms

 

Donc oui le zwave est le meilleur protocole radio. Le plus dur c'est de choisir la box.

 

Je trouve qu'au niveau box il y a moins de choix qu'avant.

 

Envoyé de mon BLA-L29 en utilisant Tapatalk

 

 

 

 

  • 3 semaines après...
Posté(e)

Salut tout le monde, 

 

Juste une petite update sur le problème des redémarrages intempestifs... J'ai ouvert un ticket au support, qui a nécessité l'intervention des développeurs. Ces restarts sont provoqués par la base de données des events qui est pleine (> 1 million d'events). Ca provoque une grosse conso de la RAM et ça redémarre. 

 

Un correctif est en route pour la prochaine release... 

 

Si ça peux en aider qui ont le même problème. 

  • Like 1
Posté(e)

Oui, effectivement, mais c'est bien corrélé. Je copie/colle la réponse du support pour le détail :

Citation

 

Our Software department verified your problem and at the moment we noticed problems with events. 

The database of events is full and this is the reason why your Home Center resets every now and then. 

This database has over 1 million events.

This translates into a very high RAM consumption when making backups (96.3%, 1.5GB RAM for backups) and a long backup time (~ 10 minutes)


I cleared this database and now everything should work correctly. 

I'm sorry for the inconvenience. We will fix this problem in the next update. 

 

 

  • Like 1
Posté(e)

heu pas d'accord avec les conclusions de Mr Fibaro, du moins il doit y avoir d'autres causes à ces reboots.

J'ai toujours de temps à autre des redémarrages sans explications aucunes, hors  je dumps tous mes events dans une BD pour triturer tout ça ailleurs et je les purge tous les soirs à 23:45.

Donc les seuls events que j'ai sont ceux de la journée, et les reboots sont complètement aléatoires, j'en ai eu au moins 2 ou 3 ce mois ci.

Cependant ce qui est certain , c'est que plus la db augmente plus la machine consomme de ressources, on peut facilement le voir sur le diag de conso de ram, d'où ma décision de la purger tous les soirs...

On verra bien ce qu'ils vont fixer et si cela affecte positivement la stabilité de ma HC.

Wait & see. :)

 

 

Posté(e)

Mmm.. Effectivement. 2 ou 3 ce mois-ci, c'est quand même mieux que moi, parceque en ce qui me concerne, c'est plutôt 2 ou 3 par jour... 

 

Depuis le cleanup (ce matin), pas eu de reboot... 21 heures d'uptime... Je crois que je vais battre un record personnel :60:

Posté(e)

ah oui 2 à 3 par jour, je m'incline :) C'est cool si ça se stabile ! 

Tiens au cas ou tu ais envie de faire du ménage sans faire appel aux services du support :

api.delete("/events/history?shrink=100")

Attention le 100 représente le nombre d'events laissés après purge !! si la DB contient 10000 après cette commande il n'en restera que les 100 derniers.

Le shrink de la DB est différé, le process doit être exécuté la nuit, je ne sais pas exactement à quelle heure, dans ton cas je suppose qu' il a du être lancé à la main par le support pour qu'il prenne effet immédiatement.

  • Like 3
Posté(e)

Ah non, pas normal, il doit encore y avoir un tas d'events dans ta db, fibaro n'a pas osé tout enlever :) , essaye de laisser un grand nombre d'events :

api.delete("/events/history?shrink=300000")

voir même plus que dans l'exemple si besoin, puis de le réduire pour arriver au nombre d'événements que tu souhaites conserver. 

Posté(e)

Hum... c’est quand même dingue plusieurs reboot/jour... et pourquoi autant d’événements ? Je suis sceptique sur les explications avancées.


Envoyé de mon iPhone en utilisant Tapatalk

  • Like 1
Posté(e)

J'ai eu 1 reboot au bout de (presque) 48h.. C'est donc une belle progression :60: Ce n'est peut-être pas la seule raison, mais ça doit y contribuer. J'ai réussi depuis à faire le shrink, que j'ai ajouté dans une routine quotidienne. On verra d'ici quelques jours si ça maintient la box en condition... Affaire à suivre...

×
×
  • Créer...