Toute l’activité

Hi @jojo, that is my plan to add notifications to all my QA or scenes. But before I add notifications I have to make Advanced Notification QA that will manage sending notifications not only to Fibaro native push and e-mail, but also to many other notification services like Pushover, Telegram, Group me, WhatsApp, Signal etc.

thank you for your explanations. In your next version, is it possible to introduce the possibility to recfeive an e-mail when connection is lost (for 30 min ?) and one when connection is regained ? Thank you.

Hi all, Just now noticed that Netatmo weather had problem with updating when last time cloud was updated. It was not updated properly. On my HC2 Weather stations reported warning that stations are not updated longer than 30 minutes and it was checking cloud every minute. My HC3 Netatmo QA is updating every 5 seconds if any of the weather stations cloud is not updated for that long. This caused QA to loose tokens. I'm working on new version and that bug will be corrected. Until this bug is corrected only workaround is to manually update cloud by touching top of the main module and wait for 10 minutes and then regenerate token on Netatmo developer site and paste it to the QA. NOTE - Netatmo mobile app didn't show this problem, so I guess that it uses another endpoints and not the ones provided to developers?

j'ai également le faire aujourd'hui

Hi @TitiXsi, I have reduced refresh time to 15 seconds and it still working without any failed calls, even I have another instance of my Envoy QA on another Fibaro gateway that refreshes every 30 seconds. Just for reminder, my Envoy is connected over the WiFi. I do not remember, but you should get inventory only when QA is restarted. All important information and measurement can be retrieved with only two calls, one to production of the system and one of the production of the inverters. Idea to show users status of the tokenvalidity is excellent, but I think it would be enough to show it on the label of the main QA instead of adding yet another child. What do you think?

Bug ce matin, j'ai du refaire un refresh des tokens pour retrouver les datas

et depuis que j'exploite Domochart et Grafana, je me disais que ce serait bien d'il y avait une catégorie supplémentaire dans Domochart : BinarySwitch, qui collecterait les états des FGBS (IN1/2,OUT1/2), FGS223/224, FGK, ...

C'est assez réactif en plus. Pour selon que ça va tapper la mémoire de la hc3... Et c'est pas si moche pour du qa. J'aimerais bien voir le code pour regarder ce qu'il utilise... Html ou autre chose...

Merci pour le partage, je ne serais pas tombé dessus par hasard vu que je ne pense jamais à aller sur le market Fibaro L'autre intérêt de ce QA aussi, c'est de pouvoir visualiser les graphiques simplement depuis l'application mobile, sur son smartphone. Car DomoCharts sur l'écran du smartphone, ce n'est pas prévu pour, c'est même vraiment nul

Oui c'est sur mais là c'est assez natif. J'ai testé et c'est pas mal dans le sens ou on peut en live choisir de regarder un capteur et voir sont graphique. Pour le moment, on ne peut voir qu'un graphique à la fois mais je ne m'attendait pas à autant avec une simple QA. Bravo au développeur.

avec Domochart et Grafana, tu as encore plus joli/ Mais c'est vrai que tu as alors besoin de toute une architecture, alors qu'ici juste la box HC3.

@Felig, pour faire suite à cette demande http://admin:LocalHc3!45@192.168.1.141/api/devices/ En résumé. Dans Domochart je serais très intéressé de recupérer la température de consigne. Pour cela (si j'ai bien compris à la lecture du json), il y a 2 propriétés : coolingThermostatSetpoint et heatingThermostatSetpoint et ton QA met à jour la propriété qu'il faut en fonction de la valeur de la variable HMCF.coolingDevice = false|true et le device regarde le bon setpoint en fonction de la propriété thermostatMode = Heat|Cool Donc, il n'yaurait qu'a mettre à jour les 2 setpoints du device (heatingThermostatSetpoint & coolingThermostatSetpoint) car de toute façon il ne tiendra compte que de celui qu'il faut en fonction de la propriété thermostatMode. Ainsi dans le code lua de domochart, je rajoute uniquement { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID Devices setpoints Celà rendrait le code plus simple ? Ou je suis complétement à côté de la plaque et j'ai une vision trop simpliste ?

Merci a tous les 2 pour vos suggestions. Mais je ne suis pas du style à changer le standard. En fait, je vais demander une modif du code du QA PID pour écrire les set points dans les 2 propriétés et ainsi dans domochat.lua je ne rajoute que la ligne pour le heating, et basta, ça devrait être bon

Bonjour Jojo, Je ne garanti pas à 100% que ce qui suit va fonctionner pour toi, mon utilisation n'est pas 100% celle là... Il y a probablement une solution (au moins un début) en utilisant le champ "userDescription" qui est présent dans les properties de chaque device. C'est un champ libre ou chacun peut y écrire ce qu'il souhaite. Ce qui est intéressant c'est que domochart peut filtrer les devices qu'il cherche selon ce champ. Il y a 2 ou 3 chose à faire: dans domochart.lua modifier la définition des devices à récolter et installer ce filtre suplémentaire: -- là ou tu as ajouté tes définitions, ajouter un field 'userDescription' : { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="heat" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID HeatingDevices setpoints { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto", userDescription="cool" , visible = "true", dead = "false", property = "coolingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID CoolingDevices setpoints --autour des lignes 597 il y a la définition des filtres: -- Get datas from API local typeFilter = sensor.fibaroType and ("&type=" .. tools:urlencode(sensor.fibaroType) ) or "" local visibleFilter = sensor.visible and ("&visible=" .. tools:urlencode(sensor.visible) ) or "" local interfaceFilter = sensor.interface and ("&interface=" .. tools:urlencode(sensor.interface) ) or "" local parentFilter = sensor.parentId and ("&parentId=" .. tools:urlencode(sensor.parentId) ) or "" local unitFilter = sensor.unit and ("&property=[unit," .. tools:urlencode(sensor.unit) .. "]") or "" local deadFilter = sensor.dead and ("&property=[dead," .. tools:urlencode(sensor.dead) .. "]") or "" local energyFilter = type(sensor.showEnergy) == "boolean" and ("&property=[showEnergy," .. tostring(sensor.showEnergy) .. "]") or "" -- il faut y ajouter la ligne: local usrDscFilter = sensor.userDescription and ("&property=[userDescription," .. tools:urlencode(sensor.userDescription) .. "]") or "" -- et modifier la ligne 610 (à peu près 610...) local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter -- pour y intégrer ce nouveau filtre: local url = "/devices?enabled=true" .. typeFilter .. visibleFilter .. interfaceFilter .. parentFilter .. unitFilter .. deadFilter .. energyFilter .. usrDscFilter dans ton code de gestion/surveillance de la PAC Il ne reste plus qu'à lui faire écrire le mot cool ou heat dans le champ userDescription selon le mode de la PAC. Quelque chose du genre: if (CurModeHeatCool ~= LastModeHeatCool) then begin for CooltargetIds = ..... do begin fibaro.call(CooltargetIds, "setProperty", "userDescription",(CurModeHeatCool=="Cool") and "cool" or "heat") LastModeHeatCool = CurModeHeatCool end end En espérant que cela fonctionne pour toi

Pas de chance... Tu avais soudé les résistances ?

Bon mon installation m'a lâché après quelques mois d'utilisation. Je ne sais pas encore quel est le problème. Je communique bien en wifi avec mon esp32, mais les commandes n'ont plus l'air de passer avec la thermopompe. J'ai remplacé le esp32 avec le module officiel de Mitsubishi, et ça fonctionne, donc le problème est coté esp32. Vu que je communique par wifi, peu de chance que ce soit un problème firmware. Je vais vérifier mes soudures / connexions, mais c'est possible que le esp32 ne supporte pas les pull Up au 5v après un certain temps...

Non.. ce n'est pas prévu... j'avais identifié cette limitation dès le portage de DomoCharts pour HC3. Et je ne sais pas trop comment on pourrait adapter le code sans entrer dans des trucs ultra compliqués... car le souci n'est pas tant du coté du code LUA du QuickApp, que de la base de données SQL qui n'est pas prévue pour reconnaitre plusieurs propriétés pour un même type de device.

Je "commance" à apprivoiser Grafana, et du coup je veux faire des graphes qui comparent mes consignes de température avec la température mesurée. Evidemment, la collecte des données avec Domochart est la base. Pour mes régulations, j'utilise ce développement : il crée des devices de type : com.fibaro.hvacSystemAuto Qui contient les DEUX propriétés suivantes : coolingThermostatSetpoint & heatingThermostatSetpoint En fonction que le QA est en mode AirCo ou chauffage, il va lire la valeur d'une des 2 propriétés. Et évidemment, c'est cette propriété qui est mise à jour. Dans le programme Domochart, j'ai adapté la table deviceSensors (en début de code), en y ajoutant ces entrées : { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto" , visible = "true", dead = "false", property = "heatingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID HeatingDevices setpoints { dbType = "temperature", fibaroType = "com.fibaro.hvacSystemAuto" , visible = "true", dead = "false", property = "coolingThermostatSetpoint", }, -- added by Jojo on 18/01/2025 to include PID CoolingDevices setpoints les entrées sont bien créées dans les tables. Mais, les résultats ne sont pas cohérents En fait c'est logique, Domochart ne sait pas si le device est en mode Cooling ou Heating. Y a-t-il un moyen de le lui dire ?

en effet grafana c'est super puissant, je commence à "mâitriser"(eque) : je n'en suis pas encore à ton niveau, mais j'ai déjà trouver comment faire 2 axes Y différents (ne pas rire sVP) Grafana, c'est fun, mais chronophage ... Maintenant le mode bloc des requêtes SQL ne fonctionne pas, il faut absolument faire un "SELECT UNIX_TIMESTAMP(time)*1000 as time, ..." sinon les heures sont décalées.

Hello, Quelques nouvelles du côté des qa. Fibaro sort une qa qui permet d'avoir un mini graph pour un device sélectionné. Je n'ai pas encore essayé n'étant pas dispo pour administrer. L'idée est sympa et à minima c'est toujours intéressant bien que très loin de ce que fait nativement jeedom .... https://marketplace.fibaro.com/items/quick-charts-for-fibaro-yubii Ps: peut-être que ce fil existe déjà, n'ayant rien trouvé, je le poste ici.

Hello, Idée d'amélioration : Ma sonde de temp remonte un chiffre à 10 digit. Ca sert à rien mais c'est comme ca ... J'ai donc modifié ton code pour avoir ceci sur la fonction HM:updateLabelTemp(item) function HM:updateLabelTemp(item) table.insert(self.iwashere, "updateLabelTemp") item.power = item.power or 0 -- not needed local device = iif(self.HMCF.coolingDevice, "❄️ ", "🔥 ") local percent = iif(self.isOff, "Off", string.format("%.0f%%", item.power)) local power = device..percent.." | "..iif(item.state == ON, "⚡", "💤") local tempe = item.temp or "N/A " if type(tempe) == "number" then tempe = math.floor(item.temp * 10) / 10 end if self.outdoor then self:updateLabel("lbTemp", "🌙 "..self.outdoor.."°C | 🌡️ "..tempe.."°C | "..power) else self:updateLabel("lbTemp", "🌡️ "..tempe.."°C | "..power) end table.remove(self.iwashere) end ajout de : if type(tempe) == "number" then tempe = math.floor(item.temp * 10) / 10 end

************************************************************** GCE Electronics IPX800 V5 Firmware - Software ************************************************************** *** Version 5.6.1 (06/01/2024) ## Changed * MQTT : Correctif permettant de stabiliser l'IPX *** Version 5.6.0 (12/12/2024) ## Changed * FONCTION : Refonte complète du process de calcul pour gérer tous les cas * MODBUS : Ajout de la fonction IEEE 754 et du complément à deux * X-DISPLAY_V2 : Ajout du nouvel écran météo * X-GSM_V2 : Ajout d'une liste de destinataire pour le XGSM (paramètre en config) * X-4VR : Maj de la consigne en fonction du retour d'état * X-DIMMER_V2 : Ajout de la possibilité de le mettre à jour ## Fixed * THERMOSTAT : Correctif sur le FRONT sur l'unité du temps de défaut * CLOCK : Correctif lié au GMT négatif * METEO : Prise en compte du GMT pour les timestamp lever et coucher du soleil * MQTT : Correctif sur le SSL MQTT * SNTP et SMTP : Correctif sur la validation des modales

Hello, @Sankotronique , I think you're right to avoid an issue, we need to send only one request with the ID and the token. My envoy is sometimes busy... Probably it as to much think to do and lost some request... I have added a check on the token validity on my QA, with notification in couple of days before the deadline. Let see in 302 days

Juste que cette doc est complètement insuffisante... déjà pour un humain, il faut pas mal se creuser la tête, expérimenter, et demander de l'aide sur les forums (ici et l'officiel) pour arriver à sortir un QA potable. C'est pas une IA, en tout cas pas les algos existants, qui pourront en faire quelque chose. Par ailleurs, même si une belle doc existait, dans ce cas, pourquoi ne pas simplement la lire, augmenter ses connaissances, et être autonome sur le développement des QA ? Quel intérêt de se reposer entièrement sur une IA pour écrire un QA, sans rien y comprendre ? Avec comme tu le soulignes, ses erreurs qu'elle peut faire et qu'on ne saura pas corriger si on se repose entièrement dessus. Dans cette situation, à part rendre les gens encore plus bêtes qu'ils ne le sont déjà, les IA ne vont pas nous emmener bien loin... Comme tu le dis, la bonne approche, c'est de l'utiliser pour nous aider sur des besoins bien précis, C'est un complément, pas un substitut.

Bonne question... je n'ai pas l'expérience nécessaire pour de tels projets...