vravolta

Alors au début, j'étais parti sur le fait de remplacer le rotacteur par des relais, ce qui aurait été moins usine à gaz qu'un moteur qui fait tourner un bouton. Mais en fait, le rotacteur a été coulé avec toute une carte de commande dans de la résine (tropicalisé) et donc on ne peut pas accéder à ses contacts sans tout casser. Ensuite, je suis en Suisse où tout ce qui fait du feu est entretenu par un ramoneur officiel et qui n'acceptera en pratique pas de modifications internes d'un appareil homologué comme une chaudière. Donc soit il faut que la modification soit indétectable quand il ouvre la bête pour la contrôler, soit il faut que ce soit "par dessus". Ce qui est étonnant, c'est que les servo de radiomodélisme sont éprouvés, peu chers et ultra répandus tout en ayant plein d'usages et un protocole super simple de commande. Et apparemment, personne n'a songé à ce stade à commercialiser une passerelle entre notre Z-Wave et le protocole de commande des servos. En cherchant sur le web, on voit bien que plein d'amateurs bidouille des choses à base d'arduinos ou ce genre de choses, mais aucun fabricant avec un support digne de ce nom ne semble proposer la chose.

C'est physiquement ce type de chose qu'il me faut. Mais le pilotage par la durée me semble hasardeux et ce d'autant plus que le bouton peut être aussi tourné à la main. Donc il me faut ce principe là, mais avec une logique qui sait évaluer la position effective du servo, exactement comme avec un servo de modélisme. Ces servos coutent une misère (environ 5 EUR en Chine pour des modèles de qualité avec fort couple (2Nm), pignonerie métal et vitesse d'environ 0.1s pour parcourir 60 degrés) et donc ce n'est pas très difficile conceptuellement de faire un bridge entre leur protocole de commande (une série de créneaux dont le ratio temps haut/temps bas donne la position que le servo doit rejoindre) et nos protocoles domotique. On pourrait imaginer un module avec une valeur allant de 0 à 100% en lecture écriture. Si j'écris dedans une valeur, le servo s'y rend puis ne fait plus rien. Si je tourne le bouton à la main, la variable renvoie la valeur correspondant à la position. Et avec ca, on peut piloter simplement n'importe quel rotacteur. Pourtant, il s'emblerait que ca n'existe pas en Plug N Play ou alors je ne connais pas le nom que ca a dans le monde de la domotique.

Dans mon cas, j'ai un bouton à plusieurs positions quand on le tourne: ca passe de arrêt à eau chaude seulement, chauffage seulement, chauffage et eau chaude. Quand je pars pour plusieurs jours, je mets la chaudière sur off car sinon, elle continue de chauffer de l'eau qui ne sera pas consommée (donc en pure perte) et si je ne me suis pas amusé à baisser manuellement la dizaine de thermostats (perdant au passage leur réglage initial), la maison sera également chauffée en pure perte. Mais comme on parle de chauffage basse température, il faut bien 24 heures pour réchauffer la maison. Je pourrais programmer manuellement une heure de retour dans la chaudière, mais c'est fastidieux et si finalement je prolonge ou raccourcis mon séjour, ca ne va plus. Un autre cas c'est quand je suis en mode eau chaude seulement: selon la météo, si je sais qu'il va y avoir du soleil, il est inutile de réchauffer l'eau avec la chaudière en début de journée car le soleil va s'en charger un peu plus tard (solaire thermique). Donc si je veux être optimal, je dois avoir un pilotage dépendant de la météo. Or, nativement, ma chaudière ne connait pas la météo, contrairement à ma box domotique. Pour le dire autrement, en laissant ma chaudière branchée en permanence, j'arrive à avoir quelque chose qui fonctionne tout le temps, mais qui n'est pas optimisé en fonction de ma présence à la maison ou de la météo. Et donc si j'avais l'équivalent d'un servo que je brancherais sur le contacteur de commande de ma chaudière et pilotais via mon réseau domotique, pour pas bien cher, nettement moins que ce que je dépense en énergie supplémentaire si je branche en permanence ma chaudière, je peux piloter la chose intelligemment. A noter que je ne peux pas piloter simplement les circulateurs en sortie de chaudière car ils ne sont pas on-off mais fonctionnent en continu, pilotés eux même par ladite chaudière en fonction de plein de paramètres et donc interférer avec n'est pas une bonne idée: il faut que je donne des instructions à la chaudière qui elle même pilote ensuite tout son système, pas que je bypasse ses ordres (car elle apprend de ses actions et de leurs conséquences. Mais si je bloque ses actions sans qu'elle n'en ait conscience, ca va dérégler tous ses paramètres d'estimation de l'inertie de la maison, calcul de fuites thermiques, etc.).

J'ai une chaudière qui fonctionne très bien mais qui a un défaut: elle n'a pas été prévue pour être domotisée. J'ai regardé avec le fabriquant qui peut me proposer de changer sa carte électronique par une plus récente qui elle est connectable au wifi puis pilotable, mais la facture est pour le moins conséquente et donc le jeu n'en vaut pas la chandelle. Comme les fonctions de base (arrêt, marche pour l'eau chaude, marche pour l'eau chaude et le chauffage) sont toutes pilotables à travers un unique bouton rotatif, je me dis que s'il existait un module domotique qui serait l'équivalent d'un servomoteur, comme dans le monde des véhicules radiocommandés, je pourrais rendre ma chaudière connectée à moindre frais. De Même, j'ai d'autres usages (ouvertures/fermetures de trappes) où un tel module me serait fort utile. Sauf que j'ai beau chercher, je ne trouve rien qui ressemble ou qui puisse être détourné pour l'usage que je souhaite. Quelqu'un a une idée de comment résoudre cette question? J'imagine que je ne suis pas le premier à vouloir piloter un servo via une box domotique. Si cela peut aider, j'ai une HC3 et donc je peux piloter une bonne variété de protocoles.

Bon, ben je vais m'y mettre alors ;-) Les premiers steps seront de trouver comment obtenir une liste des ID des capteurs ayant un historique activé puis de créer un device child de type température. Jusque là, je ne vois pas de souci majeur si ce n'est de trouver la bonne syntaxe. Ce qui me fait un peu plus peur, c'est qu'à priori, le graphique historique des devices température va pointer sur l'historique officiel Fibaro en utilisant sans doute en dur l'ID du device. Il faut donc trouver un moyen de lui dire d'utiliser l'ID du device physique et le cas échéant de pouvoir appliquer une conversion si le range d'un capteur devait être très différent du range usuel des températures. Typiquement, une pression, c'est de l'ordre de 1000 et je ne suis pas certain que le graphe natif de Fibaro sache afficher des valeurs si élevées. Toute idée ou documentation du fonctionnement des graphiques natifs serait bienvenue ;-) .

Le but étant uniquement de faire un affichage en plus, je ne perds pas la fonctionnalité du capteur d'origine avec ma méthode, c'est juste que je voudrais essayer de détourner le seul moyen d'origine qui affiche des graphes pour le faire pour n'importe quel capteur. Un truc du style QA qui scanne tous les capteurs ayant l'historique activé et qui crée un child de type température pour chacun de ces capteurs, child qui du coup aurait la fonctionnalité d'afficher un historique via un graphique. C'est ca mon idée, mais je ne sais pas si c'est techniquement faisable.

Sauf que du coup, si ca résiste au changement de box, ca devient sensible aux MAJ d'OS du NAS, aux changement de version de la DB et à la capacité de tout ce petit monde à se parler. J'ai installé pas mal de choses sur mon NAS, mais force est de constater que ce n'est pas d'une stabilité mythique. Et par ailleurs, pour des raisons de sécurité, je n'aime pas trop exposer mon NAS à l'extérieur. Et là, on n'a pas encore parlé de Yubi qui par construction n'a pas de raison de bien intégrer un serveur web hébergé hors de la galaxie Fibaro. Du coup, se pose une question: si je force le type de capteur à "température", est ce qu'il y a moyen de bidouiller quelque chose pour avoir les graphiques historiques de ce type de capteur? En essayant rapidement (et naïvement), ca ne semblait pas fonctionner, mais il y a peut être une bidouille à effectuer ou peut être qu'il faut passer par un QA qui lit les infos dans l'historique et simule un capteur de température pour les afficher.

Je suis en cours de remplacement de mes anémomètres et pluviomètres Netatmo par du Zwave, dans le but de ne plus devoir dépendre des serveurs capricieux de Netatmo. J'ai donc installé les capteurs, coché le fait d'enregistrer l'historique. Et là, je m'attendais à ce que nativement, ledit historique soit affiché, comme on peut le voir par exemple pour la température du QA Netatmo. Mais en fait, rien, nada. J'ai bien vu le sujet avec export d'une base de données (donc duplication de la data) puis intégration dans un server web qui lui même tourne sur un NAS. Mais je trouve bizarre qu'il faille déployer une telle énergie pour avoir quelque chose de basique et à mon avis indispensable à partir du moment où on dispose d'un historique. N'y a t il pas une option que je n'imagine pas pour que la HC3 affiche l'historique de n'importe quel capteur historisé voire permette de le voir sur Yubi?

Alors je confirme que cette solution fonctionne. Merci!

Concernant le max charging power (et discharge) cela permet de forcer la vitesse de charge/décharge de la batterie stationnaire Fronius, comme dans l’onglet de la gestion de l’énergie, sauf qu’ici, on peut le piloter finement depuis la HC3. Dans mon cas, mon onduleur a une puissance d’ondulation (AC) max de 5.2kW mais mes panneaux peuvent produire jusqu'à 8.2kW (DC). Donc les jours de plein soleil, j’ai intérêt à vider ma batterie sur le réseau en début de journée pour que quand la puissance des panneaux dépasse 5.2kW, l’excédent soit injecté directement dans la batterie qui elle se charge en DC. Sinon, ils sont perdus. Quand je veux forcer la décharge, je fixe une puissance mini de décharge. Et quand je veux éviter que ma batterie ne se charge trop vite (et ne puisse plus encaisser le surplus de production), je mets une puissance max de charge. Ceci est valable les jours de plein soleil car quand il fait gris, j’ai intérêt à maintenir la batterie totalement chargée. Ca, c’est ce à quoi je veux arriver, ce qui implique d’intégrer dans ma QA non seulement la partie Fronius mais aussi les prévisions météo couplées avec mon capteur de luminosité. Et effectivement, il faudra que je me penche sur la création des enfants pour créer ce qui manque dans le QA Fronius qui utilise l’API et pas le Modbus. Un autre avantage de Modbus, c’est qu’il est possible en un seul appel de récupérer l’entier des paramètres là où via l’API, il faut faire une requête par paramètre. Mais au final, je manque de temps en ce moment pour terminer totalement mon projet. En le rendant public, au moins le boulot de debug (les message d’erreur Modbus sont quasi inutilisables car en gros, il répond juste : « j’ai pas compris » dans le meilleur des cas, voire rien du tout tant que tout n’est pas parfaitement formaté. Pour la température de la batterie, je n'ai rien trouvé dans les registres de mon onduleur, mais peut être que selon les modèles, c'est dispo. La seul température que j'ai, c'est celle de l'onduleur qui est dans le bloc I160, adresse absolue de registre 42290.

La bonne nouvelle, c'est qu'on arrive à la même conclusion = les scénarios de la HC3 sont une impasse car bien trop limités en fonctionnalités: je n'avais jamais essayé jusque là car par principe, je me dis que ces trucs graphiques ne génèrent jamais ce dont on a vraiment besoin. Puis je me suis ravisé en me disant qu'après tout, les box domotiques ne sont pas utilisées que par des geeks comme moi qui savent raisonnablement coder et donc que mes problèmes basiques d'automation devraient avoir une solution native simple sur la box car sinon, 80% des gens avec une maison intelligente ne pourraient pas gérer des BSO en fonction de la luminosité. C'est là que je me suis planté. Je viens donc d'installer GEA et je vais me mettre dessus et ce d'autant que j'ai pas mal de choses qui attendaient que je les automatise mais comme je n'avais pas trouvé comment le faire dans les scènes, je me disais que ca venait du fait de mon ignorance de leur fonctionnement. Merci pour le tuyau!

Juste pour être bien sur, GEA, c'est l'interface dans laquelle on fait des scénarios avec du drag & drop, avec une colonne pour les triggers, l'autre pour les actions? Car c'est précisément là que j'ai voulu tenter la chose, mais je n'ai pas trouvé comment lui dire de lancer une action 1 minute après en avoir lancé une autre, d'où l'idée de basculer en LUA en me disant que si ce n'est pas possible avec l'interface graphique, ca doit l'être en codant. Mais si je peux le faire directement dans les scénarios (que je ne connais pas en détail), alors je serai le plus heureux!

OK, je vais poser mon QA modbus Fronius ce matin sur Marketplace. Il faut alors bien lire la doc Fronius sur le Modbus (de mémoire, elle n'est pas dispo en téléchargement sur leur site et il faut leur envoyer un mail pour l'obtenir) car des fois, il faut bouger des paramètres obscurs avant que des modifs soient prises en compte, mais la doc a le mérite d'être bien faite. Toute la couche technique de communication a été écrite, l'entier du paramétrage de mon registre y est (= il existe une sorte de structure standardisée pour les onduleurs modbus de toutes marques, mais selon les modèles, tous les registres ne sont pas exploités).

Effectivement, l'idée est de faire 0%, attendre une minute puis 1%. Sauf que dans une scène, je n'ai pas trouvé comment lui dire d'attendre une minute avant de remonter à 1%: j'ai d'un coté des triggers qui quand ils sont vrais lancent toutes les actions en parallèle et donc je termine avec des stores à 1% sans être passés par la case 0% et donc en pratique, je ne vois jamais le paysage avec mon setup actuel. Après, mais c'est un souci moindre, mes boutons de commande physique ont la possibilité d'être bloqués en position contact, typiquement pour descendre complètement un store sans devoir rester appuyé et quand ils sont dans la position contact fermé, ca donne des comportements bizarres. Mais je pense que je devrais trouver comment gérer la chose dans les paramètres des modules.

Alors dans mon cas, il s'agit de stores à lamelles. Quand on part de tout en haut pour les descendre, les lames se mettent à la verticale puis descendent. Si alors je remonte, les lames passent à l'horizontale la première seconde puis elles remontent. Si je mets directement 25%, les lames descendront jusqu'à la position 25% mais resteront verticales. Je les voudrais horizontales, ce qui permet de bloquer le soleil direct sans pour autant bloquer la vision horizontale. Et cela ne s'obtient qu'en remontant de 1% après avoir baissé à la position souhaitée. J'ai donc besoin de faire une descente puis, une fois terminée, de remonter de 1%. En faisant une scène qui remonte de 1% et en la mettant à la fin de la liste des actions, le résultat est un store qui va directement à 1%. Ce dont j'ai besoin est un store qui va à 0% puis remonte à 1%.