HC3 & HC3L - 5.150.15 - STABLE - 08/11/2023

[henri-allauch 217]

 

Trouvé, mais bizarre : pas d'appareil à mettre à jour, alors que j'ai des détecteurs de fumées en 3.1  et d'autres en 3.3 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Modifié 6 janvier par henri-allauch

[jojo 2 613]

oui, sauf que là tu ne vois que les appareils pour lesquels ily a une maj de dispo, pas la version actuelle du fw.

Pour la version FW installée d'un appareil spécifique, n'est-ce pas verion dans l'onglet général de l'appareil ?

[henri-allauch 217]

Oui la version du device est indiquée dans son onglet général et c'est pour cela que j'ai dit bizarre : j'en ai plusieurs avec des versions différentes 

[mprinfo 3 336]

ce sont bien tous les mêmes car il y a eu plusieurs version j'ai même la version secteur le tout premier modéle

[jojo 2 613]

depuis mon FW upgrade à cette version (le 19/11/2023), je n'ai plus eu aucun reboot non sollicité

[TitiXsi 66]

Idem et je n'ai plus de plantage de qa. Je pense même que c'est le plantage des qa que j'avais qui obligeait un reboot de la box de façon automatique.

[Lazer 8 477]

Non rien à avoir avec le code LUA de nos QA / Scènes.
Fibaro avait donné une demi-explication, le bug venait de l'un des chipset (on ne sais pas lequel) de la box.
Entre les générations, il y a eu plusieurs révision des différents chipset, c'est une pratique courant chez les constructeurs (dans à peu près tous les appareils électroniques qu'on achète)
Le patch appliqué l'année dernière au cas pas cas par le support Fibaro consistait à mettre à jour le firmware du chipset incriminé.
Tandis qu'une mise à jour du firmware Stable de la box (peut être bien celui-ci, je ne me souviens plus exactement) embarque la mise à jour du firmware du chipset en question, donc maintenant toutes les box sont patchées, celles qui étaient touchées par le bug, comme les autres.

[henri-allauch 217]

Je confirme La réponse de @Lazer  une de mes 2 box ayant été fortement impacté par ce problème (comme d'autres signalèes sur ce forum et sur le forum officiel).

Le 8/9/2023 un support fibaro s'est connecté sur ma box pour faire des modifications .

Depuis elle n'a plus jamais planté.

j'ai pu faire normalement en Novembre et Décembre les mises à jours 5.150.15 et  5.150.18 

Toutes les box ont été mise à jour lors de la MAJ  5.150.15

J'ai demandé sur le forum officiel à mroszak s'il y avait une explication : 

Citation

As I am not a technical guy I can tell you that there has been a change in the low-level (system) configuration related to energy-saving functions, resulting in instability of the home center 3 platform in sporadic cases.

Pour moi tout est rentré dans l'ordre et c'est parfait

 

Modifié 22 janvier par henri-allauch

[jluc2808 61]

bonjour, truc bizarre hier soir avec un HC3 sous 5.150.18 et que des modules z-wave.

sur HC3 avec la version stable 5.150.18 et aucune modifications depuis quasiment 2 mois, hier l'utilisation s'est retrouvée avec quasiment plus aucun modules zwave ne répondant aux ordres simples ou aux scènes . 

Volets, lumières sans actions, alors que la box a bien tous les ordres dans l'historique avec semble-t-il les bons horaires. Les capteurs (zooz detecteur d'ouverture pour le portail, Steinel mouvement et lux pour l'escalier exterieur) eux ont remonté les infos correctement dans l'historique.

Ce qui m'a le plus surpris c'est la consommation d'un wallplug fibaro qui normalement tourne autour de 4,4w et 4,8w et vu dans l'historique comme consommant 13,8Kw.

je n'ai pas pu regarder la consommation CPU et MEM, parce que je n'ai été alerté que ce matin du souci arrivé hier entre 21h et 22h.

 

Après reboot de la box tout est rentré dans l'ordre, mais cette séquence avec quasiment tout bloqué (sans actions) me gêne.

 

Auriez-vous une explications ou une piste pour savoir ou chercher le pourquoi ?

[Lazer 8 477]

Probablement un module qui floode le réseau.
Tu peux tenter d'utiliser le nouveau panneau de diagnostique Z-Wave pour essayer d'identifier ce module trop bavard, mais tu sembles avoir un coupable avec ton Wall Plug.

[jluc2808 61]

Il y a 2 heures, Lazer a dit :

Probablement un module qui floode le réseau.
Tu peux tenter d'utiliser le nouveau panneau de diagnostique Z-Wave pour essayer d'identifier ce module trop bavard, mais tu sembles avoir un coupable avec ton Wall Plug.

oui j'ai regardé le nouveau panneau, mais après reboot ça dit plus rien

est-ce qu'on a une solution pour être alerté ou même déclencher une scène de reboot si ça floode comme ça ?

[jojo 2 613]

Cela faisait longtemps que jr m'interrogeait à propos du panneau de Diagnostique Z-Wave, ais maintenant qu'on en parle, je pose ma question.

Je suis TRES loin de tout voir : il ne m'affiche que les ID 2 à 118 ...

[Lazer 8 477]

Il y a 13 heures, jluc2808 a dit :

est-ce qu'on a une solution pour être alerté ou même déclencher une scène de reboot si ça floode comme ça ?

Oui, en faisant un script LUA de monitoring de ce panneau.
Sur le topic de la version du firmware sur laquelle était apparu ce nouveau panneau, j'avais fait un récapitulatif de l'API utilisée, mais tu la retrouveras très facilement avec F12 sur ton navigateur.

 

il y a une heure, jojo a dit :

il ne m'affiche que les ID 2 à 118 

Etonnant ça, on a exactement le même nombre de modules Z-Wave

 

Je te rappelle que ce n'est pas l'ID du module qui est affiché, mais son numéro de noeud sur le réseau.

 

Mon noeud 118 correspond bien au dernier que j'ai installé.

[jojo 2 613]

Il y a 1 heure, Lazer a dit :

ce n'est pas l'ID du module qui est affiché, mais son numéro de noeud sur le réseau.

ah ok, pour moi, il y avait ID, et donc je pensais que c'était l'ID du module.

et du coup, c'est l'ID du noeud ? (ça correspond aux parents uniquement  ?)

[Lazer 8 477]

Oui et oui.

[jojo 2 613]

 chouette, si ma femme me tue ce soir, je mourrai (un peu) moins con ...

[jojo 2 613]

je vous écris de l'au delà ...

[Lazer 8 477]

Qu'est ce que t'as encore fait comme bêtise pour mériter ça ?

[jluc2808 61]

bonjour, il y a un truc que je comprend pas trop dans ce panneau, j'ai quelques modules avec des communications et communications failed, mais je ne sais pas comment interpréter cela , est-ce que les chiffres affichés sont bons , pas bons , critiques et quelles valeurs commencent à être critiques, parce que la pastille est verte donc z-wave considère cela comme normal ?

 

 

@lazer j'ai pas compris comment monitorer (ou quoi monitorer dans ce panneau ?)

je vois bien les URL avec F12 mais je vois pas comment traiter cela ?

 

 

Modifié 19 février par jluc2808

[Lazer 8 477]

La pastille verte c'est juste pour dire que les modules sont correctement configurés, et à priori pas du tout pour dire si leur fonctionnement est normal ou pas.

 

Par exemple mes modules Qubino Fil Pilote, qui ne finissent pas l'inclusion correctement (bug de leur firmware) ont une pastille d'avertissement :

 

 

On constate que les compteurs restent à 0 pour ces modules, néanmoins ils fonctionnent parfaitement.

De manière similaire, leur table de routage reste désespérément vide, je n'ai jamais pu savoir s'ils utilisent le maillage ou non.

 

 

J'ai envie de dire que la moindre erreur n'est pas normale et doit être analysée.
Après si c'est une erreur tous les 36 du mois, c'est peut être pas bien gênant.
Si c'est tous les jours, là on peu commencer à analyser la situation.

Quant à l'API, c'est à toi de fixer tes règles, justement basé sur l'expérience et l'analyse du dessus.

Un nœud mort, ça fait longtemps qu'on sait lever une alerte (avec GEA ou un script dédié).... on peut imaginer quelque chose de similaire en fonction de 2 conditions par exemple :

- nombre d'erreur > 0

- nombre de frame/hour > à un certain seuil

 

Là tout de suite, chez moi, ça monte à 492 frames/heure pour une multiprise Greewave, ce qui n'empêche pas le réseau de fonctionner parfaitement (pas de latence, ou alors assez rarement)

Le second module est aussi une Greewave Powernode, puis c'est un module Qubino Flush Shutter DC pour Velux mais équipé d'une sonde de température déportée et réglée avec une sensibilité de 0.1°C donc bavard.

En 4ème position, le relai Aeotec Heavy Duty de ma PAC, qui remonte la consommation électrique régulièrement.

 

 

 

 

Chez moi, je n'ai aucun "failed communication"

 

 

Modifié 19 février par Lazer

[jojo 2 613]

Il y a 11 heures, Lazer a dit :

Qu'est ce que t'as encore fait comme bêtise pour mériter ça ?

je suis au 7° ciel ...

 

[jluc2808 61]

je lâche pas l'affaire

quand je regarde mon panneau diagnostic j'ai une série de composant fibaro qui sont avec NA (et mon wall plug suspicieux est lui à 0 - 0)

 

 

ce qui me gêne c'est que tout ceux avec la coche verte et qui sont en N/A - N/A sont des composants fibaro (je ne parle pas de ceux avec le triangle orange qui sont des composants non fibaro) :

FGS224, FGWD111 (variateur walli), FGWDS221 (walli), FGBS222 (smart implant), FGWCEU-201 (walli controller sur secteur 24v) et des FGR223 (BSO), donc dedans des composants bien connus et utilisés par ailleurs

j'en ai plein d'autres de même nature et quasi contigu dans l'espace qui ne sont pas dans la même situation, par exemple tous mes FGR223 et tous mes FGS224 sont dans un tableau au même endroit)

 

autre point qui me chagrine depuis le début et pour lesquels je constate des latences ce sont les composants fibaro qui sont quasiment tous dans le RDC et dont je ne sais plus quoi faire pour éliminer ces latences

ce sont à peu près tous des inter walli controller (tous sont sur secteur en 24v) et le maillage est dense puisque j'ai une quarantaine de composant z-wave sur l'étage RDC et une trentaine de composant z-wave juste

au dessus quasi tous à l'aplomb des composants qui sont avec des failed, et la box HC3 à l'étage (donc environ entre 4 et 6m par rapport à ces composants).

De plus mon maillage doit être conséquent puisque j'ai 112 modules connectés.

 

j'ai tenté hier et quelques jours avant de forcer une reconfiguration du maillage avec les composants présentant le plus de 'failed communication', ça n'a pas changé grand chose, pour certains on est passé de 3x.xx à 2x.xx mais pas à 0

 

 

[Lazer 8 477]

J'ai aussi pas mal de modules, Fibaro ou autre marque, qui ont N/A.

 

Quand on cherche dans l'API, ce sont des modules qu'on ne trouve pas, donc pour une raison que j'ignore, le moteur Z-Wave n'a pas de statistique pour ces modules là :

/api/apps/com.fibaro.zwave/diagnostics/transmissions

 

Je n'avais pas fait attention qu'on était sur le topic où j'ai justement fait un topo sur cette nouvelle API de diagnostique Z-Wave, donc je renvoie vers le message en question qui décrit l'API.

Après il reste à construire un script LUA pour analyser tout ça, fait des notifications, statistiques, ou que sais-je... je n'ai pas encore eu le temps, ou plutôt l'occasion vu que mon réseau est pleinement fonctionnel, pur me pencher plus que ça sur le sujet :

 

[jluc2808 61]

ok merci j'ai juste fait un ordre avec api/apps/com.fibaro.zwave/diagnostics/transmissions pour voir ce que ça restitue

 

 

et j'ai comparé avec ce que restitue le panneau officiel

 

quasi en même temps

là je ne comprend pas les différences ou je ne sais pas lire ce que restitue l'API ?

mon exemple:

dans la partie communication on a 21 et si on additionne incomingTotal et outgoingTotal on a 18

de même on a 14.29 de Failed Communications alors que l'API en restitue 0

 

de plus si je regarde dans l'API de tous les NodeId j'ai toujours 0 sur les partie Failedxx que ce soit en incoming ou outgoing

[Lazer 8 477]

Ce sont de bonnes questions....