Lazer

Ah toi aussi ? Je savais pas L'utilité elle est claire, et ça a été défini il y au moins 20 ans lors de l'élaboration du cahier des charges. Les compteurs communicants servent à l'équilibrage du réseau (grid), de façon bidirectionnelle, car dans le futur (ça a déjà commencé) il y a aura de plus en plus d'instabilités : - des sources d'énergie renouvelables d'un coté, donc intermittentes et totalement imprévisibles par nature (nuages, vent), qu'il faut impérativement que le réseau puisse absorber sous peine de surtension (insérer ici le débat sur la stabilité du nucléaire et l’aberration de la fermeture des centrales... merci les Allemands qui n'ont juste rien compris au problème énergétique) - et d'un autre coté, de plus en plus de charges, notamment à cause de l'électrification massive de gros consommateurs liés à la réduction des énergies fossiles. Essentiellement le chauffage (fuel + gaz => PAC) et les voitures pour les particuliers. Le cas des voitures est intéressant, parce qu'à terme elles seront réversibles, c'est à dire que par moment elles vont se charger, et à d'autres moment elles vont devoir se décharger pour soulager le réseau. Le compteur permettra de réguler tout ça : - Soit par des facturations par tranche horaire fluctuantes (fini les bonnes vieilles tranches HC/HP statiques, d'ailleurs ça a déjà commencé, il y a 10 ans il y avait 30% entre les 2 tarifs, maintenant seulement 20%... et l'écart va continuer à se réduire jusqu'à la suppression totale de ce tarif, qui sera remplacé par un autre plus modulant.. Une sorte de TEMPO en puissance) - soit, quand ça ne suffit pas car le réseau est vraiment trop contraint, par des délestages, ou bien l'inverse, pas l'appel de courant depuis les batteries chargées de véhicules (à noter que pour l'heure, seule la Nissan Leaf est techniquement prêt, mais que Enedis ne l'autorise pas... il y a encore du chemin à parcourir) La force du compteur communicant c'est de pouvoir délester intelligemment des charges qui peuvent l'être sans incomber le confort, comme le ballon d'eau chaude, la voiture, etc. Parce que sinon, c'est le délestage par coupure préventive de toute un quartier (Linky ou non ne change rien à ce niveau là, c'est un faux débat), et pour le coup ça fait des milliers de mécontents (et on ne parlera même pas des personnes sous assistance respiratoire...) De ce point de vue là, je salue personnellement l'initiative d'Enedis de faire un délestage intelligent sur les ballons d'eau chaude cet hiver. Comme je le disais hier, j'espère que ça suffira et qu'on ne devra pas aller aux coupures généralisées par quartier (2h, comme annoncé par Enedis), voire au blackout (le carnage... y'aura même plus Twitter pour que les complotistes puissent comploter, un comble !) Car cela résout le problème du pic de charge à midi... mais pas celui du 18 à 20h, qui promet d'être... "intéressant".

Du coup le mode d'administration du vaccin c'est par des ondes radiatives ? Oui c'est judicieux de baisser la température du ballon, le miens le fait nativement avec son électronique embarquée + télécommande externe. Depuis que j'ai domotisé mon ballon, j'ai encore plus optimisé. Mais attention au risque de légionellose, il faut faire des cycles > 60°C au minimum une fois par mois.

Désolé mais je n'ai pas du tout de temps pour faire du LUA en ce moment. @mprinfo avait partagé un script quelque part sur le forum pour forcer la calibration de tous les volets, peut être que tu peux t'inspirer de sa structure pour construire ton propre script. Remarque : l'exercice du LUA est intéressant, mais si tu débutes, tu auras plus vite fait de repasser manuellement les paramètres sur les modules. Reste à voir si l'investissement en temps en vaut le coup pour tes futurs projets domotiques.

Ah j'avais oublié que mprinfo fait partie des anti-Linky C'est un mythe le rayonnement. ça a été mesuré par Stéphane Marty sur sa chaine Deus Ex Silicium, le rayonnement est tellement faible qu'il n'est même plus mesurable passé quelques centimètres. Pendant ce temps là on a des tonnes d'appareils qui rayonnent de partout dans la maison. Et le pire de tous, et de très loin, on l'a dans notre poche à quelques centimètres de.... voilà quoi Ce que je trouve amusant dans l'affaire, c'est que Pulsadis c'est également CPL, ça n'a jamais posé aucun problème à personne depuis que ça existe. Bref, quand les gens arrêteront d'écouter les complotistes et qu'ils écouteront la science, on aura fait un grand pas en avant. Mais c'est toujours le même débat, on tourne en rond avec ces histoires.

Au cas où tu veuilles te mettre à GEA, ça te permet de faire des scénarios puissants sans connaitre le LUA. Et ce que tu veux faire présentement se fait en une règle d'une seule ligne avec GEA.

Quelle est la question ? Tu l'utilises déjà le QA EDRT2 non ? Les valeurs d'énergie sont OK. Mais je ne calcule pas les tarifs, aucun intérêt pour mon usage de l'avoir sur la box, c'est dans une base de données SQL que je calcule les tarifs, avec historisation long terme.

Je pense aussi, c'est la trame Pulsadis qui existe depuis des décennies. Véhiculée par courant porteur de ligne. Captée par les relais spécifiques installés à côté des anciens compteurs électromécaniques à disque. Je vais me marrer quand les anti-linky s'en rendront compte (Même si pour les raisons évoquées au dessus, ça reste bénéfique pour leur facture au final)

[Clubic] Domotique : le protocole Matter est enfin là, pourquoi est-ce une petite révolution ? https://github.com/project-chip/connectedhomeip Cette fois-ci tout est prêt, les appareils compatibles vont pouvoir arriver en masse à Noël J'espère juste qu'ils ont prévu des appareils qui fonctionnent sans électricité

Nom de Zeus, grâce aux ballons d'eau chaude, on va enfin avoir nos 2,21 Gigowatts nécessaires pour faire voyager la Delorean dans le futur, c'est fantastique Depuis le temps que j'attends ce jour

A peine l'annonce est tombée, que tous les sites complotistes se sont réveillés en masse, participant à une large campagne de désinformation reprise un peu trop hâtivement par certains médias Heureusement d'autres sont plus factuels Cela ne concerne que les 2 bornes situées en bas du compteur, qui permet de faire commuter le relai jour/nuit du ballon d'eau chaude. Donc par définition, que les abonnés qui sont en tarif HC/HP (et TEMPO aussi je suppose), mais pas les gens en tarif de BASE, puisque dans ce cas le relai est toujours actif (voire il n'y a pas de relai du tout) Ensuite comme c'est dans la tranche entre 12h et 14h, ce n'est qu'une partie des abonnés HC/HP. Perso quand j'avais encore le tarif HC/HP, je n'avais pas de tranche HC en journée, mais seulement la nuit, donc à la limite je n'aurais même pas été concerné par cette mesure. Il est important de préciser que ce n'est que le contact sec qui ne sera pas activé. Le compteur basculera bien en tarif HC, donc les autres consommateurs de la maison bénéficieront bien du tarif HC. Après on peut se poser la question : est-ce pénalisant ? Mon analyse personnelle : non Explication rationnelle : le ballon a suffisamment d'inertie pour tenir 24h (et même bien plus, chez moi je tiens 2 à 4 jours selon la saison et la consommation d'eau chaude... avec un 300L tout de même) Donc il ne chauffera pas à midi, et après ? Il chauffera la nuit pendant les 6h restantes en HC, c'est très bien. Et même en bonus : j'ajoute que les clients concernés auront une bonne surprise à la fin de l'hiver, c'est la réduction de leur facture d'électricité Car un ballon qui chauffe à midi, c'est quand même une belle aberration, il va remonter la température au max (65°C par défaut), donc augmenter les pertes thermiques, pour rien car on n'a pas besoin de toute cette eau chaude brulante à disposition. Surtout qu'il y a toujours la nuit pour remonter et maintenir la température. Après la personne qui a absolument besoin de prendre 3 douches et 2 bains l'après-midi, il pourra toujours forcer la marche forcée sur le relai de son tableau électrique, mais ça va représenter quoi.... 0.01% des gens, donc bon, pas de quoi en faire tout un plat. Bref, pour moi cette décision d'Enedis est assez logique, et pas du tout impactante pour les gens concernés. Espérons tout de même que l'hiver ne soit pas trop rude, et qu'on puisse éviter les coupures d'électricité (2 heures tournantes, comme pré-annoncé)... car là ça sera bien plus difficile, pour tout le monde. Et ne parlons même pas du blackout... PS : Tu parles de TIC, c'est à dire de "Télé-Information Client", mais celle-ci ne sera pas impactée, puisque c'est juste la remonté des informations vers un gestionnaire d'énergie (ex : Eco-Device) Justement non pour les scénarios domotiques rien à revoir, puisque on pilote déjà comme on veut (perso si le routeur solaire n'a pas suffit, alors petit coup de boost le matin juste avant les douches, simple, efficace, économique) Sauf si... dans l'autre sens : on veut justement utiliser la domotique pour participer à l'effort national de réduire sa consommation lors des pics de charge du réseau. C'est la raison pour laquelle j'avais imaginé l'autre jour utiliser l'API Ecowatt mise à disposition par Enedis... sauf qu'ils n'ont rien trouvé de plus intelligent que de protéger cette donnée publique et essentielle par une authentification OAuth 2.0.... on marche sur la tête parfois...

Oui je comprends bien que c'est une grosse galère... mais désolé je ne connais pas de solution miracle à ce niveau là. C'est peut être trop tard, mais peut être aurait-il fallu poser la question au support Fibaro, avec une prise en main à distance ils peuvent parfois dépanner simplement (mais pas toujours...)

Ah... étrange alors Je n'utilise pas le mode bloc, peut être un bug ? Mais sinon, dans le panneau de propriété de la prise, sur le graph de suivi de consommation, il n'y aurait pas un moment, même ultra bref, où la mesure de puissance passe en dessous de 4 W ? Sur l’icône de la prise en question, tu as bien une valeur de puissance supérieur à 4W ?

Ah... Sinon pour chaque device tu peux faire "Interroger cet appareil" ce qui va conserver les ID, mais tu es obligé de le faire pour chaque appareil. Ou alors il faudrait écrire un script LUA pour l'automatiser.

Sans certitude, mais tu peux peut être tenter de faire "Reconfigurer tous les appareils" dans les paramètres :

A ma connaissance il n'y a pas eu de mise à jour récente du firmware des modules FGR pour volets. Dans les Paramètres, Appareils, tu as un bouton Enlevez les appareils : Puis tu choisis Z-Wave : Puis Commencez à supprimer : Tu auras alors 5 minutes pour aller tripe-dliquer sur le bouton B du module pour l'exclure. Ensuite l'inclusion ça sera l'opération inverse :

Oui je confirme, j'ai remonté ce problème sur le forum officiel, ça a été confirmé par d'autres utilisateurs, et Fibaro a...... PAS réagit Donc patience, il faudra de longs mois pour résoudre ce bug....

Tu as sélectionné la mauvaise mesure, il y a 2 indices sur ta capture d'écran : Consommation d'énergie Unit : kWh Alors que tu tu veux faire ton test sur la puissance, en unité W. Je n'utilise pas le mode bloc, mais regarde ce qu'il te propose parmi les conditions de test, tu dois avoir un truc du genre "puissance instantanée" ou un truc similaire.

HC3 Lite can import any QuickApp containing LUA code, it's not limited as it was on fist generation HC Lite. But, there are some limitations, about the total number of QuickApp you can import. Furthermore, the CPU is limited and can't execute some advanced LUA code. We have already discovered that the Roborock QuickApp can't run on HC Lite, because of the cryptographic LUA library. I don't know for this Nuki QuickApp, but you may have some similar issues. You need some debug messages in the console window to be able to understand the problem.

Je n'ai plus de HC2, mais normalement tu devrais avoir un bouton pour lancer le calibrage dans les paramètres du module. Sinon c'est que tu l'as peut être configuré en mode sans positionnement, il y a un paramètre pour cela, du coup impossible de lancer une calibration. Du coup la vraie question, c'est quel est ton moteur de volet ? Car hormis les Somfy avec 3 fils (1 phase montée, 1 phase descente, et 1 neutre), les autres moteurs sont difficiles à calibrer, voire impossible.

Bienvenue sur le forum

Oui nickel Après sur la dangerosité relative du Wall Plug, vu qu'il est apparent, ça devrait normalement lever une alerte dans la tête de la personne qui s'apprête à brancher un appareil puissant dessus. Ce qui n'est pas le cas d'un module derrière une prise, car il est totalement invisible. Autre chose, même si on surcharge le Wall Plug, on devrait rapidement s'apercevoir, visuellement, de la présence de fumée/mauvaise odeur, et intervenir avant le début de l'incendie. Ce qui n'est encore une fois pas le cas d'un module encastré, car invisible... le feu peut être latent et se transformer en incendie plusieurs heures après. Du coup, je considère qu'un Wall Plug, ce n'est pas franchement dangereux, tandis qu'un module encastré peut potentiellement l'être.

Bienvenue sur le forum

Welcome to the forum

@flamalex du Jeedom non. Mais la plupart de mes QA sont architecturés de la même manière avec un regroupement dans différents fichiers : - main : gestion des interfaces du QA (webview, api, etc) - tools : librairie d'outils - xxx : fichier spécifique en fonction de l'appareil à interroger (c'est là en particulier que tu pourrais aller chercher des infos dans un Jeedom) Tu peux prendre mon QA PSA qui est le dernier que j'ai partagé, reprendre la structure. En plus il gère les modules enfants. Mais attention hein, si tu n'as jamais écris de QA, il y a une quantité de travail considérable pour comprendre le QA et l'adapter à ton usage. C'est loin d'être du copier/coller.

N'importe lequel de mes QA.... ils possèdent tous une boucle infinie permettant de faire du polling. Mais ça va pas être simple de reprendre mon code existant si tu débutes, car c'est déjà du code "étoffé" avec pas mal de lignes, plusieurs fichiers interdépendants, etc.