hc3 HC3 - 5.040.37 - 23/07/2020

[Sowliny]

De mon côté, le tampon est à 22/21%, en plateau.

 

Il n'y a pas de tableaux, seulement une quinzaine de VG, et pourtant elle plante dès que j'enregistre une scène.

 

Enfin au bout de deux ou trois enregistrements, en 5.030... Bien moins qu'en 5.040... où là c'était immédiat !

 

Comme prévu je réinstalle ma HC2 que j'ai récupérée, pour assurer des éclairages principaux.

[mprinfo]

Chez moi ca ressemble a cela j'ai même ré-installer plusieurs QA par contre je n'ai que 3 modules qui sont en liaison directe avec la box

 

elle n'a pas planté depuis la mise à jour.

 

[Sowliny]

J'ai eu une réponse intéressante du support Fibaro :

 

"The problem is that every home center 3 that I have plugged in in our office is not having this problem so it's hard for me to diagnose the root of it.

Can you please, just for the purpose of test update your hc3 and activate remote support for 7 days, so I will be able to collect logs and data about this case?"

 

J'ai donc validé le support pour 7 jours, refait mes sauvegardes, et relancé la m.à.j. en 5.040...

 

Si ça se trouve, je ne rencontrerai plus de problèmes, comme @jjacques68.

C'est peut être le foisonnement électromagnétique du précédent emplacement de la box qui aurait pu corrompre la mis à jour ???

Ce qui me semble malgré tout un peu ésotérique.

 

Un peu plus tard...

Je vais essayer de la planter volontairement à nouveau, histoire de faire bosser un peu le support 

Modifié le 28 juillet 2020 par Sowliny

[Sowliny]

Depuis le seconde mise à jour en 5.040..., j'ai des mises à jour pour des FGS223 à passer en 3.4 qui viennent d'apparaître...

 

Serait-ce à corréler avec la prise en main par le support ?

Modifié le 28 juillet 2020 par Sowliny

[mprinfo]

J'ai la même chose pour mon FGS223 sur ma HC2 la mise a jour a du être publier aujourd'hui car je ne l'ai pas vu ce matin

[Sowliny]

Je pense aussi, pas vue avant.

Coincidence alors.

Modifié le 28 juillet 2020 par Sowliny

[jjacques68]

alors je pense avoir mis le doigt sur ce qui fait plané la box depuis la dernière mise à jour (en tout cas dans ma situation)

 

J'ai une scène qui est triggée et suivant la valeur du trigger, elle se fige, obligé de faire un hard reboot.

Cette scène malheureusement lane plusieurs autres scènes ou action...

 

Donc pour trouvé ce qui plante réellement, ça va être joyeux !

[Lazer]

Faut pas t'étonner qu'elle plante ta box, si tu mets le doigt dedans 

 

En tout cas c'est cool d'avoir trouvé origine de ton problème

[jjacques68]

je vais désactiver toutes les action, et les remettre une par une jusqu'à trouver celle qui plante...

 

j'espère juste que les reboot continuel ne vont pas la crasher elecroniquement...

[mprinfo]

Elle est encore sous garantie.
C'est franchement bizarre tout ces problèmes. Je suis amusé aujourd'hui à mettre pleins de QA en double voir en triple
La HC3 encaissé sans bronché. Par contre je n'ai qu'une scène pour le démarrage de la box

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

alors j'ai trouvé le code qui me fait planté la box.

 

Mais alors pourquoi ???

 

Pour ceux que ça interesse, le voici, il est pas si compliqué que ça.

Il permet de d'activer/désactiver les notifications push en cas d'absence/présence : 

 

Le code me semble propre, mais il est gourmand, la CPU monte en flèche lors de son utilisation...

 

-------------------------------------------------------------------------------------------------
-- V1 - 25/03/2020 - Active/désactive les notifications push
-------------------------------------------------------------------------------------------------
function QuickApp:onInit()
    __TAG = string.format("QA_%s_%s",self.id, self.name)
    self.ListeEvent = {
        "IsOpening",    --Volet ouvert
        "IsClosing",    --Volet fermé
        "TurningOn",    --lumière ON
        "TurningOff",   --lummière OFF
        "Motion",       --détection PIR
        "Flood",        --détection inondation
        "Opening",      --ouverture d'une porte/fenêtre   
    }
end

function QuickApp:turnOn()
    self:updateProperty("value", true)
    self:UpdateNotif(true)
end

function QuickApp:turnOff()
    self:updateProperty("value", false)
    self:UpdateNotif(false)
end

--------------------------------------------------------
-- Modifie l'API suivant l'argument true ou false
--------------------------------------------------------
function QuickApp:UpdateNotif(value)

    --liste tous les device VISIBLE
    ListeDevice = api.get("/devices/?visible=true")
    
    --pour chaque device trouvés
    for i = 1, #ListeDevice do

        --récupère les notifications de ce device
        MyNotif = api.get("/deviceNotifications/v1/"..ListeDevice[i].id)
    
        --pour chaque notif de ce device
        for j = 1, #MyNotif do

            --teste pour chaque Evenement
            for k,v in pairs(self.ListeEvent) do
                --si l'évenement est trouvé, on modifie
                if v == MyNotif[j].type then
                    MyNotif[j].active = value
                end
            end            
        end

        --applique les modifications pour ce device
        api.put("/deviceNotifications/v1/"..ListeDevice[i].id, MyNotif)
    end

    self:trace("Notification = "..tostring(value))
end

--------------------------------------------------------
-- EVENT OBJET
--------------------------------------------------------
function QuickApp:BTN_ENABLE(event) self:turnOn() end
function QuickApp:BTN_DESABLE(event) self:turnOff() end

 

Et la seul chose que j'ai modifié qui me semblait louche (mais c'est très con, tellement con que je pense pas que ce soit la cause...) c'est :

 

c'est le nom des boutons pour faire les actions, donc maintenant "BTN_Enable" et "BTN_Desable", que l'on peut voir dans la section "EVENT OBJET".

lors de l'avant dernière mise à jour, le nom de ces boutons étaient automatiquement attribué par le box.

Ils avaient un nom comme "button2_1_OnRelase_Event" et "button2_0-OnRelase_Event"...

 

et depuis j'ai beau faire des essais, ça plante plus...

 

????? !!!!! ?????

 

EDIT : ha ben non j'ai crié victoire trop vite, ça vient de cracher en jouant avec le QA, la charge CPU est montée à 100 % sur 3 core / 4 !!

 

 

Modifié le 28 juillet 2020 par jjacques68

[Lazer]

Oui donc normal en fait, on en avait déjà parlé il me semble, les Quickapps DOIVENT rendre la main au système régulièrement.
Là ton code est totalement séquentiel, il n'y a aucun settimout ou autre fonction asynchrone pour rendre la main, donc la HC3 n'aime pas.

 

Je ne sais pas trop ce que fait ton code, mais je te suggère :

- limiter tes 2 boucles imbriquées, notamment la première, est-ce bien judicieux de parcourir la liste de tous les devices, ce peux-tu pas filtre un peu mieux ?

- sinon, faire un algo récursif, qui appelle une fonction en asynchrone (via settimeout) pour rendre la main au système régulièrement.

 

Parcourir la liste de tous les devices, c'est vraiment bourrin.... même dans Domocharts je filtre au maximum à la source (au moment de l'api.get) pour n'avoir que les températures, puis une autre boucle pour n'avoir que les humidités, etc.... mais je ne parcoure pas un device "pour rien"

Ça tourne toutes les 60 secondes, et comme tu le vois sur mes graphs présentés, aucune surcharge de la box.

[mprinfo]

@jjacques68 laisse la tranquille est observe comment ça évolue
Sinon tu n'y arrivera jamais
Il faut savoir être patient...

Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

mais je filtre sur la propriété visible, vu que ça concerne tous les device visible ! je peux faire plus ...  

 

oui donc on revient à la manière de coder  

 

je vais regardé ce que peux faire avec les fonctions récursives...

[jjacques68]

@mprinfo, ça marchait avant la dernière mise à jour, donc pas trop envie de la laisser tranquille !

[Sowliny]

Nouveau plantage ce soir en enregistrant une scène !

 

Comme à chaque fois d'ailleurs.

J'ai joué toute la journée avec les modules (inclusion, renommage, etc...) et aucun souci.

 

J'ai noté l'heure pour remonter à Fibaro, via le ticket...

Ils pourront peut-être cerner le (bug ?)

[Lazer]

@jjacques68

Mais dans les visibles, tu as les Z-Wave, les QuickApps, leurs enfants, etc.... t'as vraiment besoin de parcourir tout ça ?

 

La manière d'optimiser le code est une chose en effet.

Mais je constate que tu n'as pas du tout la même façon d'utiliser ta box que beaucoup d'entre nous. Outre ce QuickApp qui parcoure tous les devices, je sais que tu récupères aussi tous les événements pour les envoyer sur une base de données externe.... bref ça plus ça plus ça, etc.... ça commence à faire beaucoup de code bien lourd, qui charge beaucoup la box

[jjacques68]

tu as raisons, tu suis bien ce que fais  

 

j'avais pas pensé au QA qui sont visibles aussi etc... 

en effet je peux peut-être mieux filtrer du coup !

 

pour les fonctions récursives, le fait, dans une boucle, d'appeler une fonction par settimeout, impose de mettre une tempo dans les paramètres du settimeout !

ça va ralentir la vitesse d'exécution du QA !! ??

 

ou alors j'ai pas compris ! ?

Modifié le 28 juillet 2020 par jjacques68

[Lazer]

Pas besoin de tempo, moi je fais tous mes settimout avec une valeur de 0, ça s'enchaine hyper vite.

 

Ralentir la vitesse... en théorie oui, en pratique je ne sais pas si c'est sensible. Mais surtout si ça évite le crash, y'a pas trop de question à se poser

 

Cela dit, ta double boucle imbriquée, je suis quand même surpris qu'elle dire si longtemps.... tu devrais benchmarker chaque instruction, il doit y avoir un endroit où ça coince, c'est pas normal que ça dure longtemps (d'ailleurs, de combien de temps on parle ?)

 

 

Je me demande si ton problème ne serait pas ailleurs....

 

En effet, tu charges la liste de TOUS les devices, ce qui produit un tableau très gros en RAM. Et j'ai constaté dans mes tests de saturation mémoire, que la charge CPU augmente considérablement lorsqu'un QA alloue des trop gros tableaux. Genre comme si la box passait plus de temps à "chercher" de la RAM qu'à faire tourner le code pour utiliser le contenu de la RAM allouée.

N'oublions pas qu'en LUA (comme Java, et pleins d'autres langages évolués) il y a un Garbage Collector qui tourne "quand il a le temps" pour libérer la RAM allouée. Sauf que ça prend du CPU....

 

Donc j'en reviens à ce que je disais précédemment, il vaut mieux utiliser de petits tableaux, mieux filtrer ton api.get pour récupérer une liste de device la plus restreinte possible.

[mprinfo]

Je suis d'accord avec Christophe.
Autre chose pourquoi tu n'utilises pas les commandes fibaro. Si elles existent c'est qu'elles sont utiles ?


Envoyé de mon BLA-L29 en utilisant Tapatalk

[Lazer]

Autre chose, au point où tu en es, il faut aussi que tu optimises tes boucles for

Quand on a de grosses boucles récurrentes, il faut proscrire pairs et ipairs qui sont très lents.

 

De même que certaines instructions sur les tableaux comme table.insert()

 

Une saine lecture de référence pour optimiser son code : https://springrts.com/wiki/Lua_Performance#TEST_9:_for-loops

Remarque : ça n'empêche pas d'optimiser son code en amont, revoir l’algorithme global du script est plus pertinent que ces optimisations atomiques.... comme je te dis, filtre mieux tes devices

[jjacques68]

@mprinfo : y a pas de commande fibaro pour désactiver telle ou telle notification sur un device !

 

@Lazer : 

 

alors niveau temps on parle de en moyenne 4 secondes d'après les time code de début et fin de la fonction.

la première boucle est en effet très grosse (tous les device visible)

mais la seconde comporte 3 ou 4 éléments.

et la troisième comporte le nombre d'éléments visible dans la variable...

punaise ! oui oui dis comme ça, ça mouline sévère !

 

mais tu me fais pensé, avec ta remarque précédente sur les tableaux, j'avais vérifié les tableaux que je créé moi même, ex : MaTable = {}

J'ai pas pensé aux tables créées quand on fait des api.get() !

 

et comme tu l'as bien constaté, j'ai tendance, pour me faciliter le code, à abuser des api.get() pour des fonctions génériques !

donc de créer beaucoup de tableaux !!

 

en revanche, la gestion des socket par exemple, est bien gérée, malgré la quantité d'info qui passent, c'est hyper réactif !

mais j'ai de la récursivité partout pour ça  

 

pour pairs et ipairs, j'ai commencé à m'en séparer au profit de tableau indexé, si ça s'appel comme ça : {[1] = ..., [2] = …}

comme ça je tape directement sur la bonne valeur, sans avoir à le parcourir systématiquement...

 

bon ben je sens l'optimisation de code ces vacances  

 

PS : je savais pas qu'on pouvait faire du settimeout avec 0 en délais...

[jjacques68]

super interessant ton lien merci !

[mprinfo]

@jjacques68 un tableau est indexé
La tu parles d'un index numérique.
Pour trouver direct la valeur

[1]
ou
["toto"]



Envoyé de mon BLA-L29 en utilisant Tapatalk

[jjacques68]

oui voilà c'est ça