Lazer

J'ai eu un reboot, il y a 1 an, (avec un vieux firmware donc), et c'était clairement à cause de l'un de mes QuickApps qui faisait n'importe quoi. C'est à ce moment là que j'avais constaté le reboot. Depuis plusieurs jours, j'ai basculé toute ma production sur la HC3, et je dois dire que ça fonctionne très bien, malgré les nombreux QuickApps qui tournent. Après, 15 jours, c'est un nombre que je n'atteindrai jamais, vu que j'ai un backup auto chaque week-end (et tous les services sont automatiquement redémarrés)

OK, donc ça doit correspondre à la version 5.1. Il y a un endroit bien précis où tu peux faire la mise à jour : avec une box Fibaro. Et c'est tout. Comme tu le sais déjà, Fibaro ne partage pas ses firmwares.

Bah du coup je préfère ton retour d'expérience, car tu as montré que ça fonctionne depuis plusieurs mois, et les spécifications techniques annoncées sur la page de domotique-store sont OK, et même mieux que l'alimentation d'origine. Du coup c'est leur remarque que je ne comprends pas.

C'est quand même indiqué incompatible avec la HC2, car elle consomme trop. Pourtant 12V 2A max. (24W max.) c'est bon, et même mieux que l'alimentation d'origine si on en croit le relevé effectué par Gorn sur sa propre alim (cramée !)

Moi aussi je travaille dans l'ingénierie, j'aime bien creuser les choses pour comprendre et faire un choix judicieux. Et le choix le plus judicieux, c'est souvent le plus simple. Qui dit plus simple, dit plus fiable, plus robuste, plus simple à maintenir, à faire évoluer, etc. KISS = Keep It Simple & Stupid comme on dit. Parce que les usines à gaz, comment dire.... Et justement, je profite de ma migration HC3 en cours pour revoir pas mal de trucs complexes que j'avais fait en domotique à l'époque, faute de produits existants à ce moment là. Donc un exemple : je vais virer un Raspberry PI, qui sera avantageusement remplacé par un Eco Device RT2. C'est plus cher oui, mais ça sera plus simple, plus fiable et facile à maintenir dans le temps. J'ai encore du EnOcean qui traine, et pour l'instant je l'ai conservé car ça a été migré en 10 minutes, mais à terme je vais le virer et remplacer les quelques modules par du Z-Wave. Là encore, ça sera plus simple et plus fiable. Sinon oui les contacteurs c'est cher, c'est clair. Mais la qualité reste, le prix s'oublie

Je n'ai pas l'impression que ça soit des informations correspondant à la version du firmware. Sur ta Lifedomus, tu utilises la clé Aeotec ? Il faudrait la brancher sur un PC, et avec le logiciel Z-Wave PC Controller de Silicon Labs tu peux interroger le module pour connaitre toutes ses informations, dont le numéro de version.

je n'ai pas de retour d'état réel, mais j'ai un retour d'état théorique. En effet, tout l'intérêt d'utiliser un contacteur c'est qu'il "copie" la commande. Donc si le relai du l'IPX (FGS) est fermé, alors le relai du contacteur est fermé. Et inversement s'il est ouvert. Obligatoirement, par principe de construction. Même après une coupure de courant. Et c'est très fiable. (en complément, j'ai aussi une pince ampéremétrique sur la phase qui part vers la lampe, donc j'ai un vrai retour d'état de consommation électrique) Ton test du télérupteur semblait montrer que le télérupteur conserve son état après un coupure de courant, donc ça marche aussi, mais il faut également que le FGS/IPX garde lui aussi son état pour que ça fonctionne. Et là c'est plus difficile, je pense, car puisque tu pilotes un télérupteur, le relai de commande se ferme puis se réouvre quelques millisecondes plus tard. Ce n'est donc pas l'état du relai qu'il faut conservé, mais l'état de la charge (stocké où ça... dans la box domotique ?) Bref, les télérupteurs en domotiques, c'est la plaie. Perso je les ai tous virés de mon installation, puisque les modules domotiques jouent déjà pleinement ce rôle. Et j'ajoute les contacteurs dans les cas de puissance / appel de courant important. Le fonctionnement d'un contacteur est tellement basique qu'il n'y a pas à réfléchir, tu branches, et tu n'as plus à y penser, il copiera l'état du relai de commande domotique quoi qu'il arrive. Tu te fais des nœuds au cerveau pour rien, ce sont les télérupteurs qui sont compliqués, pas les contacteurs. Ou comment apprendre à oublier ce qu'on sait déjà pour repartir sur des bases propres PS : avant la domotique, j'avais même des modules DIN "télévariateur", des trucs super sophistiqués du 20ème siècle qui permettent de faire varier la lumière par un appui long sur n'importe lequel des boutons poussoirs de la pièce. Exactement ce qu'on fait avec un Dimmer FGD tout simple.... pour un volume 10 fois moindre. Et moins cher en plus !

Non, là encore tu mélanges les circuits de puissance et les circuits de commande Le contacteur de puissance n'alimente pas le FGS. Voici le schéma correspondant à la photo présentée précédemment (enfin presque, le disjoncteur n'apparaissait pas sur la photo, et en réalité chaque circuit de lumière est sur 1 disjoncteur différent. Sécurité maximale... mais j'ai simplifié le schéma en ne représentant qu'un seul disjoncteur) (et puis les néons ont été remplacés par les rubans LED + alimentation, de toute façon l’icône de la lampe ne correspond pas) Il te suffit de remplacer les borniers de l'IPX800 par le contact sec du FGS, c'est exactement pareil. L'IPX800 prend son alimentation sur un circuit séparé (protégé par un disjoncteur de faible puissance), mais dans le cas du ton FGS, tu peux prendre son alimentation sur le disjoncteur qui alimente le contacteur et la lampe. Pour reprendre ta formulation, on pourrait écrire : le disjoncteur alimente : le contacteur de puissance qui lui-même alimente les LED le FGS (ou IPX) qui lui pilote le conctacteur Et pour faire un câblage dans les règles de l'art, car on a 2 circuits (puissance et pilotage), alors on devrait avoir 2 disjoncteur séparés : un de 16 A pour le circuit de puissance un de 2 A pour le circuit de pilotage D'ailleurs, le contacteur devrait être alimenté comme le FGS, sur le circuit de contrôle. ça parait bien compliqué tout ça, mais en fait c'est exactement le principe du contacteur de puissance du chauffe-eau qu'on utilise depuis des lustres, rien de nouveau.

Effectivement, le mail stipule bien que la tentative d'accès se fait bien sur le site de Fibaro, et non pas sur ta box. Est-ce que tu n'aurais pas un Google Home, Alexa, ou autre service qui tenterait de s'y connecter ?

Ta box n'affiche pas cette information ? Mais ce qui est certain, c'est que tu ne pourras pas le mettre à jour sans box Fibaro. Pour info les versions connues à ce jour du Smart Implant FGBS-222 : 5.2 DS18B20 temperature sensor support has been improvements to make it more reliable, especially in long wiring cases. Optimized input/output behavior after power reset. Other minor improvements. Support for version 5.2 devices is available from 4.601 Beta for HC2/HCL. 5.1 Initial release 

Meanwell c'est top. Mais c'est "brut", sans connecteur DC, donc il faut acheter les connecteurs séparément, souder, mettre de la gaine thermo.... à voir si tu es bricoleur. Sinon n'importe quelle alimentation 12V et suffisamment puissante (la HC2 consomme 14W, donc je dirais que l'alim doit faire au moins 20 voire 30 Watts pour le démarrage. En fait je ne souviens plus, regarde la puissance de l'alim d'origine c'est encore le mieux. De toute façon l'alimentation d'origine de la HC2 c'est du générique chinois standard à pas cher, typiquement le genre de produit que tu trouveras sur Amazon. Souvent vendues pour alimenter des rubans LED d'ailleurs...

Je n'ai aucune idée de la tension d'un chargeur de voiture... Regarde ici, tu as les 2 références de carte mère connues pour la HC2, avec des liens vers les docs. Tu y trouveras les brochages, et les tenions inadmissibles, qui sont plus large que juste 12V.

Sans le bandeau de LED, la carte mère devrait au moins démarrer, et avec un clavier USB branché dessus tu devrais pouvoir accéder au BIOS.... enfin, si tu as un affichage avant le plantage !

Attention, si tu mesures l'alimentation à vide, ça ne veut rien dire. Il faut mesurer sa tension en charge, ce qui est difficile avec le connecteur branché.... Si la tension s'effondre avec la box allumée, c'est qu'elle est morte. Je te conseillerais quand même de tester une autre alimentation.

Bienvenue sur le forum

Non, pas directement. C'est à toi de les créer avec des Variables Globales, qui sont exploitables dans GEA avec "Global" Au fait, quand il n'y a pas de message d'erreur, parce que le script a planté de façon inattendue, tu peux aussi activer GEA.debug=true dans tes options, cela permet d'en voir un peu plus

OK merci, je surveillerai pour voir si les erreurs se reproduisent.

Ah mon tour d'avoir des problèmes, depuis ce matin je constate des messages "ID XXX: System hardware failure. Read the manual." pour mes 2 Smart Implants. A priori ils fonctionnement toujours, les sondes de températures DS18B20 continuent de se mettre à jour, et les valeurs sont cohérentes dans DomoCharts. Je ne sais pas quoi en penser....

Quand tu dis que ça bloque GEA, il faut donner les logs, sinon difficile de t'aider. Cela dit, dans le cas présent, l'erreur saute aux yeux, il ne faut pas mettre de > dans ton option "Value+", mais juste une virgule. Réfère toi toujours à la doc de syntaxe si tu as un doute. {"Value+", id["Temp_Ext"], 22}

Tu peux aussi tenter de contacter le support, parfois, ça arrive, ils ont une idée de génie.

OK, c'est assez similaire à mes graphs Rien d'anormal en tout cas.

Oui voilà je pensais à DomoCharts, il permet de voir l'évolution CPU/RAM sur une longue période (ce que ne permet pas le panneau de diag de la HC3, c'est juste du temps réel) Le monitoring à l'intérieur du QA (garbage collection), c'est pratique, mais çà ne permet de voir que le QA, pas la box. Bref, rien d'anormal sur le graph de Domocharts je suppose ? Donc ce bug ne serait pas lié à une trop importante quantité de CPU/RAM utilisé... Autre chose, tu reboot ou fait un backup régulier de ta box ? Chez moi, le backup, c'est une fois par semaine, si bien que tous les services sont redémarrés au minimum tous les 7 jours, c'est pas un vrai reboot, mais c'est presque pareil.

Ce qui importe, c'est que le type du QA correspond au type de device qu'on cherche à créer. mais ton souci semblait être dans la lecture de la value d'un autre device, donc c'est le type de ce device là qui compte, pas celui de ton QA je sais pas si c'est clair...

Au fait, tu monitores l'utilisation CPU et RAM sur ta box ? Afin de savoir si ce genre de comportement anormal est prévisible

Ah bien