TonyC

Tu peux la débrancher / rebrancher ça devrait le faire, comme quoi entre la HC3 et la HC2 il y quelques points communs un peu de lecture : https://forum.fibaro.com/topic/50454-hc3-stock-in-the-update 5031/

Ils on l'air motivé, on va dire que c'est entre maintenant et la fin de l'année donc moins de 6 mois pour livrer toutes les promesses. Il y a environ 1 release toutes les 5 semaines si je ne dis pas de conneries, du moins jusqu'à présent. Les sprints sur la hc3 sont plus longs que ceux de la hc2. Bref tout ça pour dire que ça vite arriver et que je vais pouvoir enfin utiliser ma 2ème hc3 qui ne me sert strictement mais alors là strictement à rien pour le moment A mince mais ça ce n'est pas dans la liste des choses qu'il vont faire mais celle de ce qu'il ne feront pas. Elle est où la liste du plan 2020 ??? Je sais que la Gateway connection avec la HC3 y est car confirmé par A.Socha pour l'UDP aucune idée malheureusement. EDIT Message important à tout le monde JE DIS QUE DES CONNERIES LES UNE DERRIERES LES AUTRES ALORS JE VAIS ME COUCHER voilà En effet l'udp c'est de la roadmap donc va savoir ce que ça veut dire

keep cool les gars @Moicphil y'a moyen de customiser l’arborescence en fonction du profile des utilisateurs ? pouarfff j'ai vraiment des idées de génie parfois c'est pas le meilleur endroit pour poster ce qui suit mais au moins pour le zigbee ça nous laissera le temps de nous mettre d'accord. On a au moins un an pour y réfléchir et nous mettre d'accord Fibaro postponed some features until 2021.It is about this:▪ ZigBee devices support▪ Bluetooth Low Energy devices support▪ Energy management panel▪ Temperature charts panel▪ Energy consumption charts panel▪ Gateway connection with Home Center 2 / Lite Ca a un peu fuité, mais c'est officiel et entériné par A.Socha sur le fofo officiel, bref ça nous laisse du temps quoi. source: https://forum.fibaro.com/topic/50641-features-postponed-after-2020/

Oui je comprends la complexité, je n'ai pas encore essayé de jouer avec la génération des QA enfants, je dis ça s'en savoir mais il 'y a pas moyen de conditionner la création et propagation des variables selon une définition dans le QA parent je fais un parallèle avec le QA netatmo, qui ne créait que les devices que tu utiles mais pas toutes celles possibles. Je sais sans pour autant connaitre que le problème n'est pas le même, je parle plutôt de l'approche, bien que la définition du contexte d'utilisation ne pourra pas se définir tout seul dans le cas ipx/rt2/eco ... peut être un paramétrage "simple" dans le QA parent à positionner avant la création des chields. J'espère pas trop dire de conneries là

Hello Je trouve l'idée vraiment bonne, si il n'y a plus qu'un seul code pour l'ipx et l'eco ça serait peut être bien de gérer les cas d'usages, j'entends par là les contrats possibles tel que heures pleines/creuse ou standard. Sur l'eco, Il y a déjà des forks de ces codes rien que pour gérer ces deux cas, qu'on put multipliable par la techno utilisée eco ou IPX. Sans parler de la production !

Merci de me le rappeler, je n'ai pas mis l'annonce à jour et je vais le faire de ce pas car elle est partie aujourd'hui pour sa nouvelle vie !

On peut pas dire qu'on ai aidé, t'as tout fait tout seul, ce qui cool c'est que ça marche maintenant !

vous allez arrêter vos conneries oui il est où mon bescherelle ?? ! Aurait il fallut que nous n'eussions jamais eu ce problème sur la HC2 pour évoquer le fait que ce dernier eut été introduit par par la hc3. Que que nenni ! Cette grosse daube de bug existait dès la hc2 et persiste sur la hc3

Bonne question @Moicphil ! Je regardais l'arbo actuelle, elle est en grande partie déployée par typo de devices, eclairage, ouvrant, energie ... Hors les quick apps à la fin seront en partie à classer dans cette même typo d'arbo et parfois n'auront rien à voir avec des devices mais auront un scope radicalement différent. En gros tout mettre dans un menu quick app fera qu'on y aura de tout et des sous classification par type de quick sera redondant avec l'arbo actuelle des devices. Ca répond pas à la question ça mais juste un avis. Après on peut peut-être voir comment ça vie dans un premier temps avec l'arbo comme tu l'as construite et réaligner en fonction mais là ça pourra donner un peu de taff. Bref désolé de ne pas apporter un avis claire sur le sujet mais un un commentaire !

Ah oui pas cool, si tu l'as exclus par un autre moyen là ça va se compliquer et va falloir demander à fibaro de se connecter pour nettoyer la DB. Ce problème existait déjà sur la HC2, dans certain cas et je comprends pas exactement lesquels, le système refuse le force remove et oblige à faire une exclusion propre. Mais quand l'exclusion est faite par un autre biais tel que tu l'as fait ou un reset du device et que la HC refuse de forcer l'exclusion c'est ticket assurer chez Mr fibaro.

Hola qué tal ? Si on peut le faire @mprinfo, il suffit de filtrer par ZWAVE quand tu es dans le menu des modules(là ou il y a TOUS, ZWAVE,NICE,AUTRES) ,et tu vois apparaître une poubelle en face de tes devices. En cliquant dessus ça fait comme sur la HC2 un "forcer l'exclusion".

Salut Stef, je sèche je n'ai pas encore de compteur d'eau, enfin si comme tout le monde mais pas de remonté vers l'eco, donc jamais eu à manipuler les données. J'imagine que L doit être la conso temps réel, et J la valeur cumulée de ta conso/jour. Mais je suis peut être complètement à coté.

local selfId = fibaro:getSelfId() --local vanne = fibaro:getValue(700, "value"); --local Compteur_eau = fibaro:getGlobal("Compteur_eau") local Compteur_eau = fibaro:getGlobal("IC1") local Compteur_eau_jour = fibaro:getGlobal("Compteur_eau_jour") local Compteur_eau_mois = fibaro:getGlobal("Compteur_eau_mois") local Compteur_eau_annee = fibaro:getGlobal("Compteur_eau_annee") local total = Compteur_eau / 1000 pas fait attention que la ligne était commentée mais si c'est ok sur la connexion à l'eco alors il faut juste dé commenter la ligne ou la variable Compteur_eau = fibaro:getGlobal("Compteur_eau") devrait suffire non ? la var IC1 n'est pas utilisée par la suite donc pas besoin de la valoriser à son tour. Il y a une raison pour avoir commenté cette ligne? en essayant tout simplement ça ? local selfId = fibaro:getSelfId() --local vanne = fibaro:getValue(700, "value"); local Compteur_eau = fibaro:getGlobal("Compteur_eau") --local Compteur_eau = fibaro:getGlobal("IC1") local Compteur_eau_jour = fibaro:getGlobal("Compteur_eau_jour") local Compteur_eau_mois = fibaro:getGlobal("Compteur_eau_mois") local Compteur_eau_annee = fibaro:getGlobal("Compteur_eau_annee") local total = Compteur_eau / 1000

ahah ! et encore je répète pas tout ce qu'ils me racontent

jamais vu sur hc2 c'est une cuvée hc3 maintenant faut que Mr fibaro corrige, mais ça ce n'est pas gagné car mon petit doigt me dit u'il y a comme un projet de refonte totale de moteur zwave en gestation

@couillerot tu as quoi si tu fais un debug sur : response.INDEX_C1 ? tu es certain que ta connexion à l'eco est ok? ta variable "Compteur_eau" ( fibaro:setGlobal("Compteur_eau", response.INDEX_C1) ligne 10 sur le code que tu as copié) ne semble pas valorisée dès le départ ça ressemble quand même à un pblm de connexion à ton eco. EDIT: Dernier truc ton erreur est retournée ligne 48 il y a un bug dans les vd avec un décalage d'1 ligne vers le haut ce qui donne ton erreur ligne 47. Mais ce qui m'intrique sur le snapshot de ton code c'est qu'il y a un décalage de 10 ligne par rapport au code source que tu as mis plus haut comme s'il manquait 10 à ton vd??

ceux en 3.52

C'est à la hauteur de l'occasion !

en 3.52 avec la version actuelle du moteur zwave il sont pénibles surtout si souvent sollicités. 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. Je n'en ai pas donc pas de rex possible de mon coté. 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 !

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.

Oooooohh p't1 !! Champagne

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

faut relire

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

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é.