Conseils pour Box de secours

[henri-allauch]

Pour essayer de mettre fin à mes reboot très aléatoires (Je ne suis pas le seul)  j'envisage les actions ci-dessous.

Achat d'une BOX HC3 neuve.
Transférer la dernière sauvegarde Cloud de la Box OLD sur la NEW.
La box NEW Devient la box de Production.
La box OLD devientt la Box de Développement et de test.



Si je retrouve sur ma Box de Production mes problèmes de reboot intempestifs {
	cela peux venir de ma programmation ou d'un problème dans mon réseau zwave

	Pour réinstaller le réseau zwave:
	Je re-transfère une sauvegarde Cloud sur la box de développement pour assurer le quotidient.
	Je reconfigure usine la box de production
	Je transfère un à un mes devices de la box de développement sur la box de production avec les QA_concernés.
	Nota : j'ai une solution déjà utilisée pendant la migration HC2 vers HC3 Qui consite à capter les évènement principaux sur la HC2 et
		d'envoyer une requete sur un QA de la HC3 qui traite alors cet évènement HC2 reçu en évènement Local.

	Si je retrouve sur la box de production mes reboot intempestifs { 
		c'est soit un problème d' un appareil z-wave particulier ou un problème spécifique de ma programation.
		Il sera coton à identifier : 2 mois sans plantage (à plusieurs reprises) puis suite à une savegarde ou une mise à jour, plantage aléatoire 
		de 2 fois par jour à 2 fois par semaine. Puis le calme revient ...
	}
	else {
		Ouf,  j'ai une box de production (neuve) et une box de développement (ancienne) saines.
	}

}
else {
	les incidents provenaient de la box ( Plus de garantie )
	Pas grave elle me servira tout de même pour du Développement et des Tests
	Elle pourra servir de box de secours au cas où
}

Je ne suis pas pressé et j'attendrais une bonne promo.

Si vous avez des idées ou des conseils merci.

Modifié le 5 mai 2023 par henri-allauch

[Lazer]

ça me parait un bon projet

 

[jojo]

Je viens juste d'acheter d'occase (grâce à ce forum !) une HC3 spare (dont j'espère ne jamais avoir besoin !)

 

De ce que j'ai compris, la box a les identifiants de chacun des modules, et chaque module a l'identifiant unique de la box utilisée lors de l'inclusion.

C'est ce qui fait qu'un simple restore d'un backup sur une autre box, ne permettra pas à cette autre box de commander les modules (et heureusement que c'est ainsi !).

 

Alors j'ai cru comprendre qu'avec des backup cloud (cfr la description ci-dessus) il y aurait moyen de passer d'une box à l'autre,

mais APRES intervention de Fibaro ? (que font-ils ? Manip sur les backup (mais quoi ?) ? ou Intervertir les identifiants des 2 box, et ainsi les modules n'y voient que du feu ? (mais alors on pourrait ensuite restauré un backup local généré par le script de @Lazer ?) ou ???)

 

Je me demandais s'il n'y aurait pas moyen de faire ces manips en full autonomie (car évidemment la box plantera un vendredi soir, juste avant un looong WE)

 

[jojo]

Du coup (comme je suis impatient ) j'ai regardé sur Fibaro-ID, et il y aurait moyen de le faire en toute autonomie .

Cela génère évidemment des questions:

1. est-ce fiable ? (car je voudrais faire un essais, mais évidemment sans casser tout le travail de migration de @mprinfo. (certes; si j'avais une 3° box, je pourrais ter la procédure de migration, mais qui me l'offre ?)
2. je ferais la migration avec le dernier backup cloud dispo (et qui donc sera vieux), mais est-ce que après je pourrai faire un restore de mon backup local ?

[henri-allauch]

D'après ce que j'avais lu il y a quelques temps seul le backup cloud permet de redescendre sur une autre box.

Le backup de la box X est crypté avec une clé propre à la box X Elle est décryptée  et re-cryptée avec une clé de la box Y avant sa restauration sur la box Y

Automatiquement  ou avec l'intervention de Fibaro je ne sais pas ( j'ai qu'une box )

Mais certain l'on déjà fait je pense entra autre @ROBBEJP qui dans la même situation de reboot intempestif que moi à remplacé sa box sous garantie.

[Lazer]

Le transfert de configuration d'une box à une autre passe obligatoirement par le cloud Fibaro, qui possède la clé permettant de déchiffrer le backup de la box source (lié à son numéro de série) pour ensuite le rechiffrer à destination de la box cible (lié à son autre numéro de série)
Question de sécurité.

Donc c'est en autonomie, mais via le cloud Fibaro quand même... donc pas vraiment autonome (panne de serveur, tout ça tout ça...)

 

A noter :

- il faut un backup cloud récent, forcément

- la box source est réinitialisée à la fin de l'opération (comme neuve, elle a perdu toute sa config) => on ne peut pas "cloner" une box, on peut seulement "transférer" le contenu d'une box vers une autre.

- si la box source est HS et qu'on n'a pas de backup cloud récent, le support Fibaro peut faire l'opération manuellement à partir d'un backup local qu'on leur aurait fourni (par exemple le backup local stocké sur NAS par mon script automatique)

 

EDIT : henri-allauch a répondu entre temps

 

Modifié le 5 mai 2023 par Lazer

[jojo]

il y a 7 minutes, Lazer a dit :

- la box source est réinitialisée à la fin de l'opération (comme neuve, elle a perdu toute sa config) => on ne peut pas "cloner" une box, on peut seulement "transférer" le contenu d'une box vers une autre.

Pout le fun (car c'est parfaitement inutile) on pourrait quand-même faire un pseudo 'clone', il suffirait de restaurer sur la box source un backup local ?

 

@Lazer, as-tu déjà tenté la manip, ou attends-tu le crash réel pour tester ?

Les modules n'ont donc pas chacun l'identifiant unique de la box à laquelle ils sont associés (son # de série), mais une clé qui est transférée d'une box à l'autre ?

(La dessus je lance un backup cloud ...)

[Nico]

Moi j'ai l'ai déjà fait, mais sur HC2 Aucun souci à signaler. Je l'avais d'ailleurs fait il y a longtemps avec nos clefs hein, et une autre fois quand le Cloud est apparu, toujours bon de tester un PRA.

Après oui c'est dommage que cela ne fonctionne pas avec le backup local, on devrait pouvoir avoir le choix (Sécurité ou pas, que chacun puisse choisir), mais ce n'est plus la mode du monde d'aujourd'hui.

[Lazer]

Il y a 11 heures, jojo a dit :

Pout le fun (car c'est parfaitement inutile) on pourrait quand-même faire un pseudo 'clone', il suffirait de restaurer sur la box source un backup local ?

  

@Lazer, as-tu déjà tenté la manip, ou attends-tu le crash réel pour tester ?

Oui en théorie ça devrait fonctionner.
Et non, je n'ai jamais testé.
J'aurais dû le faire lorsque j'ai reçu ma seconde HC3 avant de la mettre en production... maintenant j'ai pas trop envie de risquer de tout crasher, surtout que chez moi les 2 HC3 sont hyper stables.
Les 3 ou 4 plantages que j'ai eu sur ma box de test étaient bien liées au firmware beta bien pourri que Fibaro avait sortit il y a 2 mois... après passage en stable, tout est revenu à la normale.

Du coup ce système d'avoir 2 box, une de test pour valider les firmwares (associé aux retours d'expériences des copains du forum), avant de mettre en production uniquement les versions stable quelques jours/semaines plus tard sur la box de prod, est juste parfait pour mon usage.

 

 

Il y a 11 heures, jojo a dit :

Les modules n'ont donc pas chacun l'identifiant unique de la box à laquelle ils sont associés (son # de série), mais une clé qui est transférée d'une box à l'autre ?

L'identifiant unique, c'est en fait l'ID du réseau Z-Wave, auquel les modules s'associent.

Tu peux avoir plusieurs réseaux Z-Wave, chacun avec un ID différent, ça fonctionne très bien. C'est le cas chez moi avec 2 box distinctes, et même plus, puisque occasionnellement j'ai encore d'autre réseaux (box HC2 de prod, box HC2 de dév, clé Aeotec qui m'a servi pour des tests Jeedom ou la mise à jour des modules Aeotec/Remotec via PC Controller)

 

Par contre, avoir 2 contrôleurs avec le même ID de réseau, c'est compliqué.

En théorie, le protocole le supporte, via le mécanisme de contrôleur principal et contrôleur secondaire.
Mécanisme que Fibaro est censé supporter.... depuis la HC2.
A l'époque de la HC2 j'avais testé, ça avait tellement mal fonctionné que ça m'avait planté tout mon réseau, car je me suis retrouvé avec 2 contrôleurs secondaires, sans possibilité de réactiver un contrôleur principal. C'est d'ailleurs la seule fois où j'ai fait un recovery de ma HC2 de mémoire.

Par contre, avoir 2 contrôleurs principaux (ce que tu peux arriver à faire en "clonant" comme tu l'as indiqué, c'est à dire transfert de config vers une nouvelle box, puis restauration du backup local sur l'ancienne box) n'est pas supporté du tout... aucune idée de ce qui se passe si les 2 box réagissent de concert aux sollicitations des modules... on peut imaginer une saturation du réseau dans le meilleur des cas... et un fonctionnement complètement erratique dans le pire.

Donc si tu fait ça, il faut impérativement que la box clonée reste éteinte.

[henri-allauch]

il y a 8 minutes, Lazer a dit :

Tu peux avoir plusieurs réseaux Z-Wave, chacun avec un ID différent, ça fonctionne très bien.

Il n'y a pas de problème d'avoir les 2 Box Proches. Pas d'interférences ?

Je suppose que c'est sur la même fréquence (Z-Wave) mais avec une adresse  différente.

Donc plus de traffic et de décodage pour chaque appareil ?

 

[Lazer]

Les interférences, c'est un peu une légende urbaine... je n'ai jamais vu de retour d'expérience réel de personne nous disant qu'il en avait eu.

Pour le fun, une Fibaro HC2 et une Orange Homelive posées l'une sur l'autre :

 

 

Et 3 x HC2 ensemble :

 

 

Et sur mon bureau j'ai aussi une HC3 posée par dessus la HC2.... (bon OK, la HC2 est éteinte depuis 2 ans....)

 

 

C'est bien la même fréquence 868.42 MHz pour tous les réseaux Z-Wave, mais ce réseau est conçu pour ne pas occuper le réseau à 100%, contrairement à des protocoles comme le Wi-Fi (très bavards...)

Cela permet plusieurs choses :

- évite les collisions de paquets, c'est à dire le risque que 2 modules parlent au même moment (du coup, que ça soit des modules d'un même réseau ou de réseau distincts : même combat)

- permet de réduire la consommation électrique

- permet de réduire les ondes, donc l'impact potentiel sur le corps humain (même si personne n'a jamais réussi à le prouver...)

 

A mon avis, que tu aies 1 ou 10 réseaux Z-Wave dans la même maison ne change rien du tout au risque de saturation des ondes.
Dans tous les cas, on est limité à 232 modules par réseau (limite binaire pour l'encodage des adresses des modules), et on doit prendre soit de limiter le traffic des modules trop bavards en cas de saturation réseau... ça avait été mon cas pour le Wall Plug branché sur le réfrigérateur (classe A++++++++ (au moins tout ça) très basse consommation dont la puissance varie constamment entre rien du tout et presque rien du tout.... même le simple fait d'ouvrir le porte déclenchait des trames Z-Wave à cause de la LED... ce qui m'a permis de conclure une bonne fois pour toute à la plus grande interrogation de l'être humain : oui la lumière s'éteint quand on ferme la porte )

[jojo]

Il y a 2 heures, Lazer a dit :

Donc si tu fait ça, il faut impérativement que la box clonée reste éteinte.

ma question était purement théorique.

Mais avec les explications que tu viens de donner :

1. je ne ferai pas de test de transfert. Si la box principale plante, je ferai la migration en espérant que ça fonctionne
2. ensuite je restaurerai le dernier backup sur la box plantée, pour voir si en laissant une box off, je peux avoir toujours une box de réserve qui serait prête à prendre la relève en 3 min....

L'autre option serait que je joue et gagne au lotto pour acheter une 3° box et des modules de tests (maintenant je n'en ai que 1) pour valider tout ça ...

Avec 3 box, j'aurais :

• une de prod
• une de failover (toujours arrêtée)
• une de Dev/Test

Modifié le 6 mai 2023 par jojo
typo

[Nico]

J ai 2 HC2 en prod, une master et une slave, 2 réseaux Zwave du coup  aucun souci depuis des années. 

[Lazer]

Effectivement ça fait déjà des années que @mprinfo et moi-même ne sommes par venus constater un plantage de ton HC2 en live

[Lazer]

Juste pour rappel, le mode "slave" / "esclave" utilise le mécanisme de passerelle / gateway entre 2 box Fibaro, cela crée 2 réseaux Z-Wave complètement distincts, chacun avec son contrôleur principal (la box master, et 1 ou plusieurs box slave, bref autant de box que de réseau)

Le mode passerelle permet aux 2 (ou plus) box de communiquer ensemble via le réseau IP, pour une intégration native de tous les modules dans la box maitre.

 

Donc tout à fait différent des notions de contrôleur principal / secondaire dont je parlais un peu plus haut, qui s'appliquent à un unique réseau Z-Wave.

[mprinfo]

Effectivement ça fait déjà des années que [mention=374]mprinfo[/mention] et moi-même ne sommes par venus constater un plantage de ton HC2 en live

Je m'en souviens comme si c'était hier

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jojo]

ça, c'est le propre des jeunes

[henri-allauch]

Pour info :

Depuis l'installation de la version 5.140.17  le 7/5 les messages système ont disparus mais les reboot persistent : 8/5 à 04:09 - 19/5 à 17:00 - 20/5 à 17:45 - 21/5 à 08:02 - 22/5 à 18:06 - 29/5 à 04:13 - 30/5 à 14:06 

J'ai donc installé une deuxième HC3 (neuve) : hc3.new

J'ai fait le transfert de hc3.old sur hc3.new le 30/05 par l'intermédiaire du cloud Fibaro

Bien qu'il soit trop tôt pour tirer des conclusions la hc3.new tourne sans incident depuis ce transfert ( 14 jours )

La hc3.old bien que peu sollicitée à déjà eu un reboot 

-   Elle n’a pas de device zwave actif

-   Seulement 4 QA ( idem de ceux de la hc3.new) tournent. Ils sont à mon sens les principaux consommateurs de mon installation. 

-      Un déclenche les actions cycliques ( Toutes les xx minutes  ou à telle Heure …) sur la hc3.old il tourne mais ne déclenche rien.

-      Deux sont basées sur refreshStates pour traiter les évènements (peu nombreux sur hc3.old)

-      Un me remonte les mails et les notifications (pour ne pas utiliser ceux de Fibaro pas toujours fiable)

Mon idée c’est d’isoler ces QA au fur et à mesure et voir si la hc3.old continue de rebooter aléatoirement.

 

Ici et sur le forum officiel nous sommes au moins 4 (avec donc des configurations et des utilisations complètement différentes) à avoir transféré notre installation sur une nouvelle box.

D'ici quelques mois nous devrions être fixé ???

[Lazer]

ça semble ressembler à une panne matérielle de l'ancienne box quand même... corroborée par certains retours sur le forum officiel.

[henri-allauch]

J'aimerai arriver à tirer un dump ( apres reboot) avec la box vide de toute scène, QA et Device 

Ce serais vraiment une preuve ...

 

 

Ce genre de PB est très difficile à identifier : ma fille avait en 2010 un PC  Portable HP sous windows qui plantait dès qu'il y avait un peu d'activité.

Je l'ai récupéré, passé sous ubuntu il me sert de serveur php, de serveur Mysql et autre serveur multimédia. iI n'a jamais planté donc depuis 13 ans.

Le diag est difficile dans des cas pareils.

Suis persuadé qu'il à une case mémoire déficiente. Le tout c'est de ne pas y tomber dedans ou de l'exclure 

Modifié le 13 juin 2023 par henri-allauch

[Lazer]

Le fait d'avoir changer d'usage de ce PC ne met pas forcément en évidence le problème.
Exemples de pannes très fréquentes sur les ordinateurs :

- alimentation sous-dimensionnée (par design, ou par fatigue des composants) : si on a un usage trop intense de la machine (vidéo, jeu, etc), on tire sur l'alim, qui ne suis plus, le PC manquant de courant va planter/rebooter. Je l'ai constaté très fréquemment à l'époque où j'étais plus jeune, on montait des PC avec de gros composants (la course aux MHz...), mais avec l'alim la moins cher possible. Plus récemment, sur le forum, à chaque fois que l'alimentation d'une HC2 fatigue, ça occasionne des reboots intempestifs, voire l'impossibilité de booter tout court quand l'alim est vraiment HS. La tension à vide mesurée est OK, mais dès qu'on tire un peu dessus, l'alimentation s'effondre.

- barrette RAM défectueuse... là aussi ce sont des pannes intermittentes, tant qu'on n'utilise pas la case mémoire concernée, pas de souci. Mais plus on va charger la mémoire, plus on risque de tomber dessus (raison pour laquelle les serveurs et stations de travail haut de gamme sont équipés de barrettes à correction d'erreur)

 

Finalement le mieux (ou le pire c'est selon) ce sont les pannes de stockage (disque, SSD), car là c'est généralement clair et net, des pannes bien franches.
Le pire, c'est les données perdues si on n'a pas fait un backup préalable.

[henri-allauch]

Sur le forum officiel (ICI) @SDeath qui comme moi à acheté une deuxième box ... a été contacté par le support qui aurait résolu 90% de ce problème

Son ancienne box à été "patché" par le support, elle est en test et surveillée par @SDeath

[jojo]

je ne crois pas que un de tes 4 QA soit responsable, car comme ils tournent également sur HC3.new et qu'elle ne semble pas avoir de soucis ...

[henri-allauch]

@jojo de plus en plus moi non plus ... et je crois que j'affine la preuve

 

Parmi les 4 QA j'ai désactivé les 2 qui utilisent refreshStates ( les plus consomateurs ... ) résultat cette  hc3.old à planté encore à 2 reprises en 8 jours.

Alors que la hc3.new avec tous les devices et QA tourne parfaitement sans reboot depuis 25 jours

 

Dans la hc3.old , j'ai cette fois tout viré, j'ai un seul QA réveillé à chaque minute qui a trois actions

1 voir si la box à redémarré.

2 à la minute 00 (donc toutes les heure) envoi un mail pour dire en service depuis X Jours X Heures

3 toute les 5 minutes envoi un debug : Display LUA memory consumption every 5 minutes (ID  @Lazer)  c'est plus pour la faire un peu travailler 

 

Donc j'attend la suite si toutefois le peu d'activité reste suffisant pour déclencher le reboot. 

Faut être patient ...

 

Coté garantie j'ai passé la garantie de 2 ans constructeur, mais je viens de me rendre compte que mon fournisseur ajoute une année supplémentaire (fin février 2024 pour moi) 

Je verrai donc avec lui en temps voulu ce qu'il peu faire ...

Modifié le 24 juin 2023 par henri-allauch

[henri-allauch]

Rappel : 

J'ai donc installé une deuxième HC3 (neuve) : hc3.new

J'ai fait le transfert de hc3.old sur hc3.new le 30/05 par l'intermédiaire du cloud Fibaro

 

Suite :  

La Hc3.new à travaillé sans problème pendant 30 jours puis elle à du rebooter suite à une panne prolongée du réseau Enedis. Depuis ce reboot : 70 jours sans incident.

HC3 Version: 5.140.17 Le 04/09/2023 à 12:00:00 En service depuis 69 jours, 13 heures, 39 Minutes et 30 secondes  RAM Disponible : 61%  Cache : 34% Buffers : 7%  Utilisée : 37%

 

Donc cela fait 100 jours sans plantage, tout fonctionne parfaitement et c’est rassurant.

Pendant ce temps j’ai un peu travaillé sur des essais de QA sur la HC3.old et j’ai obtenu tout de même 20  reboot non sollicités.

Le dernier en date hier à 18h32 :

Ce reboot intervient 4 jours après un reboot demandé suite à la suppression des QA d’essais. La configuration est  donc : Pas de device, juste un QA qui surveille les reboot.

 

----------------------------------------------------------------------------------------------------------------
-- QuickApp . QA_CtrlRestartHc3
-- Author   . Henri
-- Date     . Aout 2023 0.00
-----------------------------------------------------------FONCTIONS LOCALES------------------------------------
local loop
-----------------------------------------------------------INIT-----------------------------------------
function QuickApp:onInit()
    QuickApp._VERSION = "DVP-0.00"
    QuickApp._NAME = "Ctrl Restart Hc3"
    self.admin = 2

    __TAG = "QA_" ..self._NAME .."_" .. plugin.mainDeviceId
    self:trace(" - *** QuickApp " ..self._NAME .." - onInit V: " .. (self._VERSION) .." -") 

    -- Start sur la minute suivante 
    local delta = 60 - math.floor(os.date('%S')) 
    local loopTimestamp = os.time() + delta 

    local message = "Il est : " .. os.date('%H:%M:%S') .. " Start at : " .. os.date("%H:%M:%S", loopTimestamp) .. " dans " .. tostring(delta) .. " secondes..."
    self:trace(message)
    fibaro.call(self.admin, "sendEmail", "Start "..self._NAME, message)

    fibaro.setTimeout(delta*1000, function() loop(self) end)
end
---------------------------------------------------- Fonction loop Chaque Minute---------------------
function loop(self)
    local data = api.get("/settings/info")
    local Hc3Name = data.hcName
    local uptime = data.serverStatus  or 0

    -- self:trace("In Loop()") 
    -- Test Activité HC3
    if os.time()-uptime < 120 then 
        local sujet = " ReStart HC3 (Boot ou Backup)"
        local message = "La Box " ..Hc3Name  .." a redémaré  : " ..  os.date("%H:%M:%S", uptime)
        self:trace(message)
        fibaro.call(self.admin, "sendEmail", Hc3Name ..sujet, message)  
    end

    -- Relancer la boucle dans 1 minute
    self.timeoutId = fibaro.setTimeout(60 * 1000, function() loop(self) end)
end

Cette Box à bien un problème.

 

Pendant ce temps :

Sur le forum officiel d’autres utilisateurs ayant des reboot intempestif ont aussi ajouté une nouvelle HC3. Certain comme moi n’ont plus d’incident, d’autres ont retrouvé le problème quelques semaines après. Pour ces derniers, le support Fibaro leur a proposé un rapatriement de la box en usine ou un patch de firmware par réseau. Il semble que ce patch ai solutionné le problème. Mais il n’y a que très peu de communication sur le sujet. ( FIRMWARE à Quel Niveau ??? )

A voir : ICI ... LA  et d'autres

 

Peut être que nous en serons plus d’ici quelques jour s’il y a une nouvelle version.