Aller au contenu

Messages recommandés

Posté(e)

Bah moi les 2 FGMS ont le même souci qu'en 4.017 : Ils ne fonctionnent plus en association direct avec mes FGS. Mais vu que je n'ai plus le bug du -123456.0, au moins je peux les faire s'allumer avec GEA. Je vais rouvrir un ticket sur le bugtracker.

Posté(e)

Deja ma sirène everspring. Après les autres j'ai pas eu le temps d essayer mon fils dort Xd. Je verrais demain pour le reste. Pour ma scène d association, sa tombe bien je voulais la dégager pour essayer directement depuis les modules.

Posté(e)

Je dois avoir de vilains problèmes de conversion, mes danfoss ne reçoivent pas les consignes, et je n'ai aucune remonté de conso sur tous mes aeon. Vous auriez un conseil àme donner svp?

Posté(e)

Argl, bug de l'exclusion toujours présent.... :(

Après 1 exclusion, plus aucune inclusion/exclusion n'est possible.

Bon c'est repartie pour un recovery...

Posté(e)

Non Yohan, j'ai un gros doute sur les exclusions inclusions et après restore, je m'explique quand àmes interrogations, voilàce que je comprends, lors d'une inclusion, le module prends un nouvel identifient d'association avec la box et j'ai l'impression que lors du restore d'un backup la base de donnée du hc2 en prend un coup et fini par se corrompre. Mais je me fait peut être de fausses idées.

Qu'en penses tu? Risqué ou pas? Il a 3 semaines que j'ai réinstallé tout mes joujoux car àforce de jouer avec alpha/beta mon je constatais que mon système devenait instable ça m'a pris 3 jours et maintenant je flippe un peu :)

C'est sûrement débile comme réflexion mais le comportement après mise àjour d'une personne àl'autre me semble bien souvent si différent, un peu perdu j'avoue sur ce sujet.

Posté(e)

Laisse passer la nuit tu verras demain matin le comportement de tes Danfoss.

 

Tu vas devenir parano avec cette box !  :D

Posté(e)

Lazer, pourtant moi aucun souci àce niveau, j'ai exclu et réinclu un module sans problème...

Posté(e)

@Lazer, c'est pas cool :(

 

EDIT: comme Nico idem pour moi j'ai exclu et réinclu un module sans problème.

Posté(e)

C'est le parano qui cause :D mais comment explique t-on ces différences d'une installe àune autre? Vous avez une idée? Type ou nombre de modules autre chose docteur?

Posté(e)

moi ca m'a fait planter la hc2... 

remarque: elle marche parfaitement avec l’application du téléphone et de la tablette...

par contre en web ... le cercle avec deux petits cercles dedans tournent sans arrêts ... sauf si je force le lien "fibaro/en/configuration/" et là  je vois tout les item de configuration sauf mes sauvegardes ... argghhh

mais des que je cliques sur autre chose que la configuration, la roue folle repart

 

quand je repars sur recovery... et que je télécharge mes sauvegardes (après la 4.018) ca plante pareil... 

bref mon choix est soit des rester en 4,017 ou de tout refaire à  zero sous la 4,021

Posté(e)

Je confirme le bug avec les hue, a chaque reboot un nouveau device est créé pour chaque ampoule hue. bug #2156

 

le problème c'est que maintenant je suis en ID 347...

il n'y avait pas un soucis pour les id superieurs à  300? ou bien c'est GEA? je me souviens plus

Posté(e)

En 4.019 j'étais au dessus de 900 et rien àsignaler.

C'est incroyable autant de bugs dans les plugins Fibaro ! Ex: si une erreur lors de la première configuration du plugin Netatmo et bien c'est cuit, H.S il faut le supprimer puis le creer de nouveau !

Envoyé de mon iPhone àl'aide de Tapatalk

Posté(e)

Moi je retente de mettre le VS après, mais je crains que cela ne tue ànouveau mon panneau de chauffage...

Posté(e)

Pour qu'il y ait autant de cas spécifiques différents, je ne serais pas vraiment surpris qu'ils ne maîtrisent le multithreading, spécificité de la version 4, si je ne me trompe pas. Pour les non-initiés, en multithreading, le code ne s'exécute pas de façon linéaire, mais en process parallèles. Si le multithreading permet un gain de performence considérable, le débugger, c'est parfois à  s'arracher les cheveux.

 

Alors que nous développons en LUA, un langage supposé en une seule thread, j'ai pu lire ici qu'une boucle sur un fibaro:debug(getValue(id, "properties")) n'affiche pas forcément les infos dans l'ordre qu'on pourrait supposer (de mémoire, c'était au sujet des résultats bizarres de lecture de sondes de Nico). 

 

Appliquons ce problème lors d'une mise à  jour, avec, semble t-il, de grands changements dans l'architecture de la base, on peut imaginer facilement qu'il y a un risque important d'arriver à  une base corrompu (violation de clés, pertes d'intégrités entre les tables...). Et là , c'est la cata...

 

Et comme le moindre toussotement du processeur peut changer le résultat final... à‡a fait presque autant de cas qu'il y a d'utilisateurs

Posté(e)

Effectivement Lionel, cela peut être une des causes. Et je rajouterai la dessus une gestion des BDs qui doit être bof. Et pour finir la gestion du moteur Zwave qui n'est peut être pas 100% maîtrisé. Car de toute façon pour le reste, tout le monde àle même matos, un simple PC en qque sorte, donc impossible d'avoir une différence de résultat.

Posté(e)

@Lionel57, Le problème sur le debug est très simple et n'a rien a voir avec la programmation asynchrone ou le multithreading, en fait il manque un discriminant en cas de debug concurrent pour ordonner les résultats ;)

 

@Nico, pour la gestion de la bd je suis d'accord, j'ai des doutes aussi.

 

Aussi le panneau de chauffage fonctionne très bien maintenant avec 5 instances du Virtual Sensor :60:

×
×
  • Créer...