MAM78

Oups !

Également tout ça sur ma box Apple TV. Mais effectivement j’ai la fibre

Hé ben, si j’avais su que mon histoire de batteries/piles allait déclencher un tel échange En tout cas merci @Steven pour tes explications qui répondent parfaitement à mes attentes. C’est exactement ce que j’attends de ce Forum. Que la bonne humeur subsiste et pour longtemps. Il en faut évidemment pour tout le monde, mais dans le respect des avis de chacun. Même dans ces débats contradictoires, il y a du bon pour fixer nos idées et nos recherches de solutions tout en ouvrans nos connaissances et expériences sur d'autres horizons.

Afin d’éviter de geler lorsque tu rentre chez-toi, je te suggère si ce n’est pas déjà fait d’intégrer une relance automatique de la scène en fonction du message d’erreur avec le Watchdog.

Hello Même question que pour les vannes Danfoss Live connect, savez-vous s’il est possible de savoir si les têtes Firaro sont en cours de chauffe (ouvertes) ou pas. Dans le cadre d’utilisation d’un radiateur mixte (eau et électrique), je souhaiterais détecter s’il est en chauffage eau pour éviter de mettre le chauffage en électrique afin d’éviter de griller le radiateur.

Hello Savez-vous s’il est possible de savoir si les têtes sont en cours de chauffe (ouvertes) ou pas. Dans le cadre d’utilisation d’un radiateur mixte (eau et électrique), je souhaiterais détecter s’il est en chauffage eau pour éviter de mettre le chauffage en électrique afin d’éviter de griller le radiateur.

Hello, Savez-vous pourquoi NetAtmo déconseille l’utilisation de batteries rechargeables et demande que ce soit des piles ?

@OJC merci pour les explication. Pourrais-tu me confirmer que la méthode par hystérésie est bien compatible avec le mode événementiel. Est-ce qu'en mode hystérie, je peux par exemple ajout un événement du type la fenêtre vient d'être ouverte je met le chauffage en mode arrêt (soit par exemple : en mode vacance, soit 7°) ?

@OJC il me semble que tu ne m'as pas répondu à la question ci-dessus ? Je ne comprend toujours pas pourquoi tu tests des tranches entre 1001 et 6500 et 1001 et 7500 et non pas les valeurs 7000 pour comfort et 6000 pour eco. comment des valeurs intermédiaires au-dessus de 1000 serait possible ?

Bonjour @OJC Pourrais-tu STP m'expliquer ce que signifie les lignes ci-dessous : if (event.setpoint > 1000 and event.setpoint <= 6500) then eventSetpoint = getThermostatSetpoint(room.idRoom, self.ln[self.HMCF.language].eco) - (eco - event.setpoint) elseif (event.setpoint > 1000 and event.setpoint <= 7500) then eventSetpoint = getThermostatSetpoint(room.idRoom, self.ln[self.HMCF.language].comfort) - (comfort - event.setpoint) else eventSetpoint = event.setpoint end Pourrais-tu m'expliquer comment fonctionne le mode automatique (en mode setProportionalMode) cf. le VD Thermostat. Est-ce cela ? En fonction de la valeur par défaut définit par le paramètre defaultSetpoint de la fonction setProportionalMode, soit comfort, soit eco : Sans aucun événement particulier est survenu la température de consigne est celle définit en fonction de la valeur par défaut ci-dessus avec sa valeur (nb °C) correspondante (confort ou eco) dans le VD Thermostat. Si événement survenu alors la température de consigne est celle opposé à celle définit (confort versus eco ou eco versus confort) en fonction de la valeur par défaut ci-dessus avec sa valeur (nb °C) correspondante (confort ou eco) dans le VD Thermostat. Mais alors pourquoi la valeur event.setpoint évoluerait dans le temps, pourquoi dans une tranche entre 1001 et 6500 et 1001 et 7500.

Yes, c'est bien ça

Hello, challenge terminé ! Comme dit l'adage "on n'est jamais mieux servie que par soi-même". J'ai tout simplement utilisé l'heure de dernière modification de la valeur des Label pour savoir depuis combien de temps il n'y pas eu d'actions sur le VD et donc du coup après 10 secondes sans modification je nettoie les Labels. Voici le VD modifié : Notification_Stop.vfib.json

Hello, j'ai un petit chalenge à vous soumettre. Qui va le relever J'entreprends d'apporter quelques modifications à mon VD de désactivation de certaines notifications présenté au début du Post. En toute transparence, je me suis inspiré du principe du VD de gestion d'un thermostat de @OJC présenté ici : https://www.domotique-fibaro.fr/topic/11224-heating-manager/ Je cherche à mettre en oeuvre une méthode de modification des différents labels (1 label = un type de notification) pour pouvoir les modifier en utilisant 5 boutons : Le 1er permet de sélectionner le label à modifier en affichant un pointeur (un index qui pointe son doigt) à gauche de la valeur courante Le 2ème au 5ème qui permettent de modifier la valeur du label actuellement sélectionné selon les 4 états, pour rappel : On = Notification activée en permanence Tmp = Notification suspendue pour une durée que vous déterminerez dans GEA Day = Notification suspendue pour la journée entière Off = Notification arrêtée jusqu'à la prochaine activation faite manuellement via le VD ou par GEA (selon n'importe qu'elle conditions à votre convenance) L'idée est également de pouvoir ajouter autant de label que l'on veux sans modifier le principe de fonctionnement général. Soit une seule ligne de boutons pour effectuer les modifications. Mon problème c'est qu'une fois les modifications effectuée, je veux que la valeur du label ne contienne plus le pointeur et donc ne contient que la valeur de son état afin que celui-ci soit plus simple à exploiter dans GEA ou autre VD ou Scènes. J'ai bien pensé à mettre une boucle qui nettoie les labels dans la boucle principale du VD. Mais le problème c'est de trouver le bon timing pour le faire (une fois qu'il n'y à plus de modifications après un certain temps). Le problème de la boucle c'est qu'elle peut démarrer ou se terminer à n'importe quel moment et pas forcement au moment opportun (lorsque je n'effectue plus de modifications). Est-ce que l'un de vous aurait une idée à me soumettre. Bien évidement, je souhaiterais donc ne pas ajouter (ce serait trop simple et pas très esthétique) : un label qui contiendrait par exemple un timer depuis le dernière modification une variable globale Voici un image de mon VD actuel pour que vous compreniez mieux ma demande : Voici le source dans son état de développement actuel : Notification_Stop.vfib.json Merci d'avance pour vos suggestions

Je suis maitenant en 135 pour le module principal interieur et currieusement par rapport à toi je suis en version 44 pour les autres modules. Mais précédement, je ne sais pas quelle était la version du module principal interieur. La MAJ c'est lancé automatiquement dès que j'ai tenté de me reconnecter sur le module via mon téléphone. La scène controle déjà la durée depuis laquelle il n'y a plus eu de remontées de températures de la pièce. Ce devrait être donc assez facile de déclancher une condition qui irait rechercher la valeur d'un module de secours. Cela pourrait se faire de la façon suivante : En modifiant la fonction de déclaration des radiateurs : self:addHeater(idRoom, idHeater, idSonde, localkP, localkT) En modifiant la syntaxe du paramètre idSonde : {ID du module, nom de la propriété contenant la température} Par la syntaxe suivante : {ID du module principal, nom de la propriété contenant la température, ID du module de secours, nom de la propriété contenant la température} La désignation de l'ID de secours ainsi que sa propriété pourrait être elle optionnelle afin de rester compatible avec la situation précédente. Bien évidement, il faudra en conséquence adapter le code de la scène pour que cette évolution soit prise en compte : Détection de la bascule sur les paramètres de l'ID de recours, Retour sur l'ID principal lorsqu'il redevient disponible, Notification lors des bascules dans la LOG et le push sur les téléphones. ... CQFD

Ce matin j'ai eu la mauvaise surprise de constater que la température ne remontait plus depuis mon Plugin NetAtmo. Du coup plus de chauffage d'autant qu'il gèle dehors. Du coup le côté WAF n'était plus là j'ai eu droit à quelques remarques Après quelques recherches pour comprendre ce qui se passait, j'ai trouvé qu'il s'agissait de la sonde NetAtmo elle-même. Il fallait lui installer une mise à jour de son logiciel interne. Peut-être que c'est un effet de bord de la fusion avec Legrand Du coup je me demande, s'il ne faudrait pas prévoir en cas d'absence de remontés d'info de la sonde de la pièce d'avoir la possibilité de désigner une sonde de secours. Par exemple : oeil de sauron, même si la mesure sera faussée puisqu'au plafond. Ce sera toujours mieux que se le geler au réveil ou lorsque l'on rentre chez soit et que la WAF se manifeste

Depuis que j'ai mis à jour mon système en version 4.512 je n'arrive plus à modifier les VD dans lesquels il y a des boutons désactivés. Ce qui est le cas du VD Thermostat. Du coup j'ai entrepris de le modifier pour y intégrer un mode vacance (c'est @pepite qui va être contant). J'ai également retravaillé légèrement l'ergonomie du VD pour limiter le nombre de ligne. J'ai également modifié les emoji pour qu'ils soient visibles à la fois sur les systems windows, samsung et iOS/Mac. Certains emoji précédents ne l'étaient pas sur iOS/Mac. En attendant la scène qui prend en compte le mode vacance, vous trouverez ci-dessous un aperçu de ma version du VD Thermostat : Source de ma version du VD : Thermostat MAM78 New.vfib.json Pour ce que ça intéresse, vous trouverez ci-dessous un aperçu de la version qui reste compatible avec la scène officielle que j'affiche à côté pour voir les différences (et notamment les emoji qui bug) : Source de la version du VD qui reste compatible avec la scène officielle : Thermostat MAM78 Compatible.vfib.json A tester évidement

Comme l'indique @pepite tu ne peux pas modifier l'adresse. Mais si tu veux quelque chose de plus parlant : Tu ajoutes cette adresse à un nouveau contact et tu le nommes comme tu veux. Du coup, c'est ce nom qui s'affichera sur ton gestionnaire de messagerie (smartphone ou PC) Ce n'est probablement pas ce que tu imaginais, mais bon comme ça tu pourras lui donner un petit nom à ta HC2

Au sujet de ce VD. Avez-vous eu également le mail ci-dessous signifiant l'arrêt de du service Weather Underground The WU API has been around since 2010 to help you develop apps and websites as well as manage your Personal Weather Station data. During that time, we’ve watched you build amazing products and visualize weather data with creativity and purpose. Over the years, our infrastructure has been unable to keep up with the growing numbers of users coming to us for API data. This has led to higher costs as we worked to keep the service stable and dependable. Eventually, we realized we’d need to make drastic changes or risk serious problems for our API. As a result, we’ve made the difficult decision to retire the Weather Underground API. The Weather Company, which acquired WU back in 2012, offers a powerful suite of enterprise-grade APIs that might be better suited to meet your scale and performance needs while offering a broader range of weather data. You can see these products here . Here’s what you need to know going forward: Your subscriptions, and therefore access, will continue to work through 12/31/2018 . If you are a paying WU API customer , you will receive a call from a representative from The Weather Company, and IBM business, to discuss transition options to other API services. If you’d like to have these conversations sooner, contact us . If you are a Personal Weather Station owner , you will receive more information about our plan to offer free access to the data you provide to Weather Underground. We’ll reach out once that plan has been finalized. For developers who use WU API data for non-commercial purposes , you will have access to a new plan for a personal use, low call volume API. Stay tuned for more details as we build this out. The WU Forum will continue to be the best place to connect, keep you informed, share your feedback and get your questions answered as we go through this process. We are grateful for your commitment to Weather Underground and appreciate your understanding and support as we work through this process. These changes will allow us to continually improve our services and develop new features to keep WU a thriving place for you for many years to come. Thanks for being part of the community! Sincerely, The WU Team

Après quelques tests. c'était le bonne correction à apporter pour l'histérésie. Cf. la LOG de la scène. [DEBUG] 19:50:10: HEATING MANAGER v. 3.1.2 - Copyright 2017 Olivier Meyer [DEBUG] 19:50:10: [REGULATION] Mode Hysteresis sélectionné [DEBUG] 20:42:32: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique) Temp. à 18.7 °C et consigne à 19 °C, Hysteresis à 0.2 [DEBUG] 21:07:57: [ACTION] Salle de Bain Parent : Arrêt de chauffe (Radiateur Electrique) Temp. à 19.3 °C et consigne à 19 °C, Hysteresis à 0.2 Mais attention par rapport au code original, il faut juste replace la ligne "else" par la ligne ci-dessus. Dans ma scène modifié j'ai intégrer d'autres modification pour ajouter des infos dans la LOG. Ou sinon reprendre ma version de la scène présente dans mon précédent post. elseif (room.refinedSetpoint - current <= -tonumber(self.HMCF.hysteresis)) then

V 4.512 en place. A suivre je croise les doigts

Hello, après avoir modifié le code de la scène pour obtenir dans la LOG les infos température courante, temp. de consigne, et paramètre hysteresis lors des démarrages et arrêts, je constate que le fonctionnement de l'hystérésis n'est pas le bon. Voir trace ci-dessous. [DEBUG] 01:29:03: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique) Temp. à 18.5 °C et consigne à 19 °C, Hysteresis à 0.5 [DEBUG] 01:59:25: [ACTION] Salle de Bain Parent : Arrêt de chauffe (Radiateur Electrique) Temp. à 18.6 °C et consigne à 19 °C, Hysteresis à 0.5 [DEBUG] 02:30:32: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique) Temp. à 18.5 °C et consigne à 19 °C, Hysteresis à 0.5 [DEBUG] 02:59:38: [ACTION] Salle de Bain Parent : Arrêt de chauffe (Radiateur Electrique) Temp. à 18.6 °C et consigne à 19 °C, Hysteresis à 0.5 [DEBUG] 03:19:43: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique) Temp. à 18.5 °C et consigne à 19 °C, Hysteresis à 0.5 [DEBUG] 03:49:49: [ACTION] Salle de Bain Parent : Arrêt de chauffe (Radiateur Electrique) Temp. à 18.6 °C et consigne à 19 °C, Hysteresis à 0.5 Sauf à ce que je me trompe totalement le fonctionnement de l'hystérésis devrait être le suivant : Lors la temp. actuelle est inférieur à la température de consigne (dans l'ex: 19°) moins la valeur de l'hystérésis (0,5°), soit 18,5°, le chauffage doit s'allumer Lors la temp. actuelle est supérieurs de la température de consigne (dans l'ex: 19°) plus la valeur de l'hystérésis (0,5°), soit 19,5°, le chauffage doit s'éteindre Cela permet d'éviter de faire le chauffage se met en route à la moindre variation du chauffage, soit 0,1 °. Ce qui est pourtant le cas actuellement. Cf. ma LOG ci-dessus. L'arrêt du chauffage ne respecte pas le principe de l'hystérésis. Je pense avoir trouvé la correction à apporter, je fais le test et je vous dis ce qu'il en est. Il s'agit des lignes ci-dessous : if (room.refinedSetpoint - current >= tonumber(self.HMCF.hysteresis)) then self:startHeater(item, room.nameRoom, room.refinedSetpoint, self.HMCF.hysteresis) else self:stopHeater(item, room.nameRoom, self:getTemperatures(item, room.nameRoom), room.refinedSetpoint, self.HMCF.hysteresis) end Qui je pense devrait être corrigé comme ça : if (room.refinedSetpoint - current >= tonumber(self.HMCF.hysteresis)) then self:startHeater(item, room.nameRoom, room.refinedSetpoint, self.HMCF.hysteresis) elseif (room.refinedSetpoint - current <= -tonumber(self.HMCF.hysteresis)) then self:stopHeater(item, room.nameRoom, self:getTemperatures(item, room.nameRoom), room.refinedSetpoint, self.HMCF.hysteresis) end Vous trouverez ci-dessous ma dernière version du code de la scène : Heating Manager - Scene.lua

Pourrais-tu STP préciser ce que tu entends par là ? Tu veux dire qu'il ne doit pas être utilisé en mode Hysteresis ?

Toujours dans un souci de lisibilité du contenu de la LOG j'ai ajuster la fonction suivante pour afficher dans message de la ligne d'ACTION la température courant de la pièce (utile lorsque l'on désactive les LOG détaillés). function HM:startHeater(item, nameRoom, hC) --if (isnotnil(hC)) then hC = self:getReadableTime(hC) end local current = self:getTemperatures(item, nameRoom) if (item.VD) then self:notify(self:log(iif(isnotnil(hC), "startHeatingTime", "startHeating"), nameRoom, item.nameHeater, iif(isnotnil(hC), current, hC)), self.colors.action) item.startTime = os.time() _f:call(item.heater, "pressButton", item.actions[1]) else if (tostring(_f:getValue(item.idHeater, "value")) == tostring(item.offValue)) then self:notify(self:log(iif(isnotnil(hC), "startHeatingTime", "startHeating"), nameRoom, item.nameHeater, iif(isnotnil(hC), current, hC)), self.colors.action) if (type(item.actions[1]) == "string") then item.startTime = os.time() _f:call(item.idHeater, item.actions[1]) elseif (type(item.actions[1]) == "number") then item.startTime = os.time() _f:call(item.idHeater, "setValue", item.actions[1]) else self:notify(self:log("badHeaterAction", nameRoom, item.nameHeater, item.actions[1]), self.colors.error) end end end end Pour pouvoir ajouter cette température courante j'ai également modifié les lignes ci-dessous : startHeatingTime = "[ACTION] %s : Start heating (%s) Temp. is %s °C and setpoint is %s °C", startHeatingTime = "[ACTION] %s : Début de chauffe (%s) Temp. à %s °C et consigne à %s °C", J'ai également remarqué que la fonction "getReadableTime" retourne la valeur de la température du panneau de chauffage mais avec les caractères " s", soit pour une température de 21° cela done "21 s". Ce qui n'est pas terrible ;). Après analyse du code je l'impression que la ligne ci-dessous n'a rien faire ici. Je l'ai donc mise en en remarque. A confirmer par le créateur Heating Manager. if (isnotnil(hC)) then hC = self:getReadableTime(hC) end

Suite à mon message précédent, j'ai également modifié la fonction ci-dessous pour ne recevoir la trace dans la LOG uniquement lorsque l'actionneur est en état "Off" et qu'il doit basculé à "On". Histoire de ne pas saturer la LOG d'informations inutiles. Nota : Cette restriction de volume de messages dans la LOG ne marchera pas si l'actionneur correspond à VD avec un appui sur un bouton de celui-ci. function HM:startHeater(item, nameRoom, hC) if (isnotnil(hC)) then hC = self:getReadableTime(hC) end if (item.VD) then self:notify(self:log(iif(isnotnil(hC), "startHeatingTime", "startHeating"), nameRoom, item.nameHeater, hC), self.colors.action) item.startTime = os.time() _f:call(item.heater, "pressButton", item.actions[1]) else if (tostring(_f:getValue(item.idHeater, "value")) == tostring(item.offValue)) then self:notify(self:log(iif(isnotnil(hC), "startHeatingTime", "startHeating"), nameRoom, item.nameHeater, hC), self.colors.action) if (type(item.actions[1]) == "string") then item.startTime = os.time() _f:call(item.idHeater, item.actions[1]) elseif (type(item.actions[1]) == "number") then item.startTime = os.time() _f:call(item.idHeater, "setValue", item.actions[1]) else self:notify(self:log("badHeaterAction", nameRoom, item.nameHeater, item.actions[1]), self.colors.error) end end end end

Est-il normal d'avoir dans la LOG des messages tous les 15 secondes blog que le paramètre logInfo est à false ?. Voir ci-dessous. [DEBUG] 00:39:39: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique)[DEBUG] 00:39:54: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique)[DEBUG] 00:40:09: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique)[DEBUG] 00:40:24: [ACTION] Salle de Bain Parent : Début de chauffe (Radiateur Electrique)