Petits bug de la HC3

[Lazer]

Pas bête l'API, merci je n'y avais pas pensé

 

 

[jjacques68]

Le 12/03/2020 à 07:09, jjacques68 a dit :

hé bé... la photo parle d’elle même :

 

 

Pourtant je vous jure que je suis bien réveillé, les 6 volets sont bien ouvert...

 

??????

 

Le problème est toujours d'actualité chez moi...

 

J'ai fais et refais une calibration, mais ça change rien...

[Krikroff]

1 sur 2 c’est dingue... tu aurais voulu le faire exprès que tu n’aurais pas réussi !

[jjacques68]

c'est clair, mais là ce soir par exemple, j'ai un volet qui aurait dû s'ouvrir et qui ne l'a pas fait...

Et la box le voyait ouvert, alors qu'il était fermé...  

 

Je teste la valeur du volet avant de faire bêtement un Open ou Close...

Mais si la box me renvoie une valeur pas réelle, j'ai l'air c...

 

Modifié le 2 juin 2020 par jjacques68

[mprinfo]

Moi j'utilise toujours des valeurs pour les volets de 0 à 99
Pour le moment j'ai pas de modules fgr sur ma hc3 tout est resté sur ma hc2

Envoyé de mon BLA-L29 en utilisant Tapatalk

[TonyC]

Salut les gars bon @jjacques68 tu souffres avec tes volets d'un problème sérieux sur lequel je planche depuis un bon moment avec quelques personnes du fofo officiel.

J'ai identifié le problème et sais en gros comment le contourner mais je dois contacter fibaro pour remonter ce merdier, qui est un merdier sans...  nom...

En gros tu ne pourras rien faire sans analyser ton réseau, pas cool comme discourt je sais mais rien à faire sans sniffer tes trames zwaves et les analyser dans leur moindre détails.

J'en avais déjà parlé je ne sais plus sur quel thread, mais en gros certain device font un wake up beam sur sur le controller (ta hc) mais la source est 0, ce qui ne peut normalement pas arriver. Mais ça c'est le préambule du problème car après ça il y a des explorer frames(pour identifier les noeud permettant le routage) puis puis la misère quoi  

J'ai isoler le problème sur les devices ayant une version du protocole (zwave version) en 3.52. Je viens d'identifier ce soir une autre version qui génère le souci mais là je dois gratter encore et ça fais 3 semaines que je gratte et j'en ai mare de gratter

Pour que le problème arrive il faut qu'il est des rebonds entre le device en 3.52 et ta hc. En liaison directe ça n'arrivera pas. Mais quand ça arrive ça pète les route et tes devices perdent tour à tour le route la plus directe pour en prendre une plus longue donc génère de plus en plus de rebond doc augment la probabilité de générer le pblm....

Bref tu peux essayer d'identifier tes devices en 3.52, remesher ces devices. Les pires des devices FGRM222 et oui les volets  et les wallplugs,. Sur les FGRM il faut que tu les mettes tes param 40,42,43 à 0 pour éviter que tes devices reportent. 

Ca marche très bien sur les FGRM, mais je n'arrive pas à endiguer sur les wallplug, et le paradox vient des fgms211 qui bien que n'ayant pas de report d’énergie générèrent tout de même cette daube.. 

Pas top,  j'attendais que qlq en parle pour ne pas créer de panic, en parler à mr fibaro, ce que je prépare car faut un peu documenter sans quoi je vais perdre mon temps et attendre un fix car là tôt ou tard ça va péter entre les doigts de plus d'un d'entre nous.

Je ne pourrai pas créer le ticket avant ce we par faute de temps. Je vous tiendrai au jus en fonction de l’intérêt porté par fibaro.

 

EDIT:

Si tu n'as pas de devices en 3.52 alors sais pô

 

Modifié le 2 juin 2020 par TonyC

[jjacques68]

@TonyC, je vais me faire une liste des versions de device...

 

pas top ça...

 

 

[jjacques68]

allé !!! le premier roller que je vérifie...

 

Modifié le 3 juin 2020 par jjacques68

[mprinfo]

voila une scène pour voir la version des modules en 3,3,52

 

fonctionne sur HC2

 

local TousLesModules = api.get("/devices/")
local IdEnd = TousLesModules[#TousLesModules].id
print ("Nombres de modules : " ..#TousLesModules)
print ("Dernier ID : "..IdEnd)
print ("-----------------------------------------------------------")
print ("------- Listes de modules version 3,3,52")
print ("-----------------------------------------------------------")

for i,v in ipairs(TousLesModules) do
    --local id = TousLesModules[i].id
    local Nom = TousLesModules[i].name
    local visible = TousLesModules[i].visible
    local modifier = TousLesModules[i].modified
    local Valeur = TousLesModules[i].properties.value
    local zwaveInfo = TousLesModules[i].properties.zwaveInfo
    local theType = TousLesModules[i].type 
    if visible == true and zwaveInfo ~= nil then
        if zwaveInfo == "3,3,52" then
           local id = TousLesModules[i].id
           print (zwaveInfo.." - Type = "..theType.." Id = "..id.." - Nom = "..Nom)
        end
    end
end

 

[Lazer]

Super, j'ai 33 modules en version 3.52.

 

ça promet

 

[mprinfo]

@lazer moi c'est pas mieux

 

donc HC3 = console de QA (Jeux)

[Lazer]

Au fait ton script bien pratique affiche les modules enfants.

J'ai remplacé le test de la propriété visible par parentId == 1 pour avoir un affichage exact des modules physiques.

[TonyC]

Les gars j'arrive a contourner le pblm, avec les fgrm comme indiqué ci dessus le simple fait de couper le reporting auto (param 40 à 43 à 0) stop net le souci sur ce module, je ne constate aucun problème sur les FGS (en v3.52) en gros les wall plugs et fgbs001 et FGD211 sont à risque car je n'arrive pas à endiguer ce pblm sur ces modèles. Donc vérifier les modules à risque ayant cette version.

Qui plus est il faut des rebonds donc pas de liaison directe avec le controller ce qui augment le facteur emmerde. Les divices proche de la hc ne devrait pas occasionner ce truc, j'en ai un tétra chier pas loin de la hc3 et aucun ne m'a jamais ennuyé.

Modifié le 3 juin 2020 par TonyC

[mprinfo]

il y a 11 minutes, Lazer a dit :

Au fait ton script bien pratique affiche les modules enfants.

J'ai remplacé le test de la propriété visible par parentIid == 1 pour avoir un affichage exact des modules physiques.

c'est parentId == 1 est non parentIid == 1

 

local TousLesModules = api.get("/devices/")
local IdEnd = TousLesModules[#TousLesModules].id
print ("Nombres de modules : " ..#TousLesModules)
print ("Dernier ID : "..IdEnd)
print ("-----------------------------------------------------------")
print ("------- Listes de modules version 3,3,52")
print ("-----------------------------------------------------------")
local cpte = 0
for i,v in ipairs(TousLesModules) do
    --local id = TousLesModules[i].id
    local Nom = TousLesModules[i].name
    local parentId = TousLesModules[i].parentId
    local modifier = TousLesModules[i].modified
    local Valeur = TousLesModules[i].properties.value
    local zwaveInfo = TousLesModules[i].properties.zwaveInfo
    local theType = TousLesModules[i].type 
    if parentId == 1 and zwaveInfo ~= nil then
        if zwaveInfo == "3,3,52" then
           cpte = cpte + 1
           local id = TousLesModules[i].id
           print (cpte.." - "..zwaveInfo.." - Type = "..theType.." Id = "..id.." - Nom = "..Nom)
        end
    end
end

22 chez moi

[jjacques68]

23 chez moi...

 

@TonyC je vais essayer de modifier tes paramètres 40 à 43 à 0

[TonyC]

après modifs remesh tes noeuds. Si tu ne le fais pas c'est pas très grave mais tes routes seront probablement plus courtes... enfin pour des volets,qlqs millisecondes ne changeront rien

Modifié le 3 juin 2020 par TonyC

[jjacques68]

@TonyC : ben je crois bien qu'en effet, le changement de ces paramètres a réglé le problème.

j'ose pas m'avancer trop vite, mais cela fais 2 jours que j'ai les volets qui ont enfin le bon status dans la HC3...

[TonyC]

@jjacques68 cool  mais comme tu dis ça peut revenir, mais si ça revient remesh tes fgrm car ça sera le seul moyen, crois moi

Modifié le 5 juin 2020 par TonyC

[Lazer]

Si je comprends bien, quand je referai mon réseau, j'ai tout intérêt à mettre les vieux modules à côté de la HC3 (pas de routage), et les modules Z-Wave+ (avec le nouvel algorithme de routage optimisé) à l'autre bout de la maison.

[TonyC]

oui et non  @Lazer oui car ça augmente les chances d'être en direct et de fixer le pblm lié à cette version 3.52 toute pourrite  mais pas obligatoire, obstacles ... bref tu sais tout ça  mais après  positionner toutes les devices série 300 tout  autour de la HC aura plus de proba que ces noeuds servent de rebond avant d'atteindre la hc et donc de ralentir la com du réseau car goulot d'étranglement lié à une débit qui bagotera entre 9.6 et 40 kbit/s. Pour l'instant hormis les devices en 3.52 je n'ai identifier qu'un truc bizarre sur version que dois identifier car j'ai viré le device à l'arrache  et c'est un door/window sensor qui balance des trames pourri quand il reste breach ... Donc peut être privilégier les 3.52 pas loin de la hc puis pour les autres versions en s300 si je devais refaire sur ce principe je les mettrais au point le plus éloigner pour éviter qu'il ne servent de noeuds de rebond.

Modifié le 5 juin 2020 par TonyC

[Lazer]

Oui je pensais bien à maximiser les chances en étant proche, aucune certitude

 

Par contre je n'avais pas pensé au goulot d'étranglement lié à la vitesse réduite des anciens modules, c'est pas bête.

 

Les Door/window sensor de toute première génération, j'ai déjà prévu de les virer. Leurs remplaçants sont déjà en route Rien que le problème de pile qui se vide en 7 mois c'est insupportable.

De même que le Remotec ZXT120, celui là il a déjà planté mon réseau 2 fois (il floode de trames, je n'ai pas fait d'analyse Z-Sniffer pour connaitre la cause exacte).

Je vais aussi remplacer les FGS de première génération sans mesure de consommation.

Je réfléchis aussi à virer les FGBS de 1ère génération, car ils ont une portée vraiment ultra faible et ils passent tous par des relais, donc je risque de rencontrer le problème mentionné.

 

Bref, autant profiter de la migration pour faire le ménage, et installer quelques nouveaux modules : je réduis les modules aux firmwares buggés, je profite des améliorations du protocole Z-Wave+, et des nouveautés diverses (durée de vie des piles, mesure de consommation, etc)

Je ne vais pas tout remplacer (trop couteux), mais déjà faire un bon upgrade

 

 

[TonyC]

il y a 2 minutes, Lazer a dit :

Je ne vais pas tout remplacer (trop couteux), mais déjà faire un bon upgrade

il y a 2 minutes, Lazer a dit :

Je vais aussi remplacer les FGS de première génération sans mesure de consommation.

en 3.52 avec la version actuelle du moteur zwave il sont pénibles surtout si souvent sollicités.

il y a 4 minutes, Lazer a dit :

Je vais aussi remplacer les FGS de première génération sans mesure de consommation.

Eux sont des tueurs toujours sur la version actuelle du moteur car ils bavardent en permanence enfin ça dépend bcp de leur cas d'usage et leurs params.

il y a 6 minutes, Lazer a dit :

Remotec ZXT120

Je n'en ai pas donc pas de rex possible de mon coté.

il y a 7 minutes, Lazer a dit :

Rien que le problème de pile qui se vide en 7 mois c'est insupportable.

Agreed !  mais ils m'ont couté bcp de temps car remplacer par du filaire sur satel alors bcp de diy à retaper les dégâts, mais c'est une autre histoire, mais en partie pour la même raison trop de piles !

[jjacques68]

y aurait pas un tableau recap des modules bon à changer qqpart ?  

[TonyC]

ceux en 3.52 

[Nico]

Mais le souci n'existant pas avec la HC2, ils devraient pouvoir le corriger aussi sur la HC3... Ou alors ce flood existe déjà mais ne pose pas de souci à la HC2 ??

 

Lazer, si tu as des vieux FGS 211/221 que tu changes, je t'en rachèterai qquns.