Aller au contenu

Dgille

Membres confirmés
  • Compteur de contenus

    240
  • Inscription

  • Dernière visite

Tout ce qui a été posté par Dgille

  1. Dgille

    Remplacement thermostat

    Bonsoir, le sujet a été abordé plusieurs fois sur le forum, et il y a plein de solution possibles, mais en résumé, tu peux utiliser (en autre) le thermostats + récepteur SRT (https://www.domotique-store.fr/domotique/modules-domotiques/thermostats/887-nouveau-secure-srt322-pack-thermostat-mural-z-wave-srt321-5-recepteur-z-wave-contact-sec-pour-chaudiere-ssr303.html?search_query=srt&results=5 ), l'avantage et de pouvoir déplacer le thermostat au meilleur endroit, ou un simple MCO https://www.domotique-store.fr/recherche?controller=search&orderby=position&orderway=desc&search_query=mco&submit_search= et prévoir une sonde dans l'appartement (un FGMS par exemple) ,et/ou dans la maison, ou effectivement un FGS (à voir comment l'alimenter au mur), sauf à la déplacer prêt de la chaudière. A voir finalement le budget que tu veux consacrer à l'opération...
  2. Dgille

    Philips HUE Manager

    Bonjour, si c est sur le même circuit électrique, je pense que cela pose problème. Le dim des Hue se fait de manière logicielle, pas sur qu elles acceptent des baisses d intensité. Par contre, ta box peut regarder le niveau de dim de tes Gu 10 et allumer tes Hue au même niveau par une scene ou via GEA, mais alimentation électrique séparée pour les Hue, cad pas derrière l inter des GU10.
  3. Bonsoir, @Lazer, effectivement, les Hue sont vues comme des RGB, cela passe avec la syntaxe GEA.add( {CONDITIONS}, 30, "", {"RGB", 21, 100, 0, 100, 100} ). Oui, elle est géniale, et oui, on se complique la vie alors que les QA font le boulot....
  4. oui, j'avais compris, c'était pour bien préciser c'est c'était une propriété non gérée ici. Je teste cela demain...
  5. en complément, un fibaro.call(23, 'value',0) ne fait rien.
  6. Bon, je suis passé d'un scène bloc vers lua. setColor prend bien 4 paramètres (R+G+B)+ ?, le quatrième n'a pas l'air d'influer énormément, mais je pense que c'est la saturation. fibaro.call(23, 'setColor', 255,0,0,0) fibaro.call(23, 'setValue',50) le setValue correspond à la luminosité et fait l'objet d'une règle de trois, les 50 % demandés ici , deviennent 128 "brightness": 128, L'espace colorimétrique est recalculé, le rouge demandé ci dessus devient "color": "1,27,255,0", D'ailleurs, le child est bizarre, il est en deux parties, une première on/off avec couleur et luminosité, une seconde avec la saturation en plus, qui réagit avec retard (le polling du pont ?). il y a d'autres possibilités, dont fibaro.call(23, 'toggle') fibaro.call(23, 'startLevelIncrease') mais pas super utile. donc si on sait positionner setColor et setValue avec 4 et 1 paramètres, on doit pouvoir s'en sortir.
  7. J'ai reçu ma box lundi, je peux juste dire qu'elle tient au moins 48h depuis son dernier reboot.... mais 0 plantage pour le moment, elle me fait bonne impression sur ce point (et sur d'autres). Si l'on passe en direct, on perdra XY et CT, je n'ai pas trouvé l'équivalent sur le child. En testant des changements d'état via l'app IOS Hue, je constate une latence de 1 à 3s max pour la prise en compte sur l'IHM de la HC3, elle doit faire du polling aussi à son niveau. On pourrait tester sous forme d'une option/plugin GEA, type "HueDirect", avec moins d'option, mais qui éviterait de supprimer le code existant, le temps d'avoir un peu de recul sur tout cela.
  8. Oui, sur HC2, le plugin Hue était instable (au moins dans les premières V4, cela dit, toute la box était instable). Je ne suis pas sur qu'il proposait toutes les propriétés (xy et ct en particulier). Je pense que Steven a préféré attaquer le pont pour stabiliser le fonctionnement et avoir la maitrise totale de l'écosystème Hue. Avec 2 calculatrices, j'arrive à faire une règle de trois, mais un pourcentage, c'est plus facile à maintenir :). La syntaxe que tu proposes me parait bien, et surtout lisible. On a ainsi la même échelle que celle proposée par les sliders des childs Hue. Pas de problème pour tester bien sur....
  9. Bonsoir, j'ai résolu mon problème, un problème entre la chaise et le clavier, le copier/collé est mal passé, en remettant tout sur une ligne, cela passe au niveau syntaxe. Le second problème est subtil, mais GEA envoi directement les ordres HUE au pont, et donc la luminosité n'est pas en pourcentage, mais sur la valeur décimale d'un octet, 100%=254 . D'ailleurs, on ne pourrait pas passer par le child device créé par le QA Hue ? à creuser. Désolé pour le bruit.
  10. Pas de problème, je suis offline également
  11. Merci pour ton aide, voici { "id": 21, "name": "Lampe", "roomID": 229, "view": [ { "assetsPath": "/dynamic-plugins/com.fibaro.rgbwController/assets", "jsPath": "/dynamic-plugins/com.fibaro.rgbwController", "name": "com.fibaro.rgbwController", "translatesPath": "/dynamic-plugins/com.fibaro.rgbwController/i18n", "type": "ts" }, { "type": "json" } ], "type": "com.fibaro.philipsHueLight", "baseType": "com.fibaro.colorController", "enabled": true, "visible": true, "isPlugin": true, "parentId": 20, "viewXml": true, "configXml": false, "interfaces": [ "levelChange", "light" ], "properties": { "alert": 0, "brightness": 1, "categories": [ "lights" ], "color": "255,255,255,0", "colormode": "", "currentProgram": 0, "dead": false, "deadReason": "", "deviceControlType": 23, "deviceIcon": 15, "effect": 0, "emailNotificationID": 0, "emailNotificationType": 0, "hue": 0, "isLight": true, "lightId": 1, "log": "", "logTemp": "", "manufacturer": "", "model": "", "on": false, "pushNotificationID": 0, "pushNotificationType": 0, "reachable": true, "saturation": 0, "saveLogs": true, "smsNotificationID": 0, "smsNotificationType": 0, "state": false, "userDescription": "", "value": 0 }, "actions": { "setColor": 1, "setValue": 1, "startLevelDecrease": 0, "startLevelIncrease": 0, "stopLevelChange": 0, "toggle": 0, "turnOff": 0, "turnOn": 0 }, "created": 1605644899, "modified": 1605644899, "sortOrder": 13 }
  12. Bonjour, j'ai un souci sur GEA 7 sur ma toute fraiche HC3. J'ai intégré mes ampoules HUE sans problème. J'allume bêtement une ampoule sur détection de mouvement. GEA.add( {51, {"Value-",53,150}} , -1, "", { {"Time","Sunset-30","23:00"}, {"Time","19:30","23:00"}, {"Time","07:00","09:00"}, {"turnOn",21,5*60}, {"Repeat"} }) Cela fonctionne, mais l'ampoule n'est pas 100% de luminosité par défaut. J'ai essayé GEA.add( {51, {"Value-",53,150}} , -1, "", { {"Time","Sunset-30","23:00"}, {"Time","19:30","23:00"}, {"Time","07:00","09:00"}, {{"turnOn",21,5*60},{"Hue", 21, "bri", 100}}, {"Repeat"} }) Mais j'ai une erreur [18.11.2020] [20:31:33] [ERROR] [QUICKAPP28]: main.lua:2382: attempt to call a nil value (method 'lower') La ligne en question est if type(a[i]) == "table" and a[i][1]:lower()=="if" then a[1] = vaut nil Une idée ? PS: pour le reste , la box est juste TOP !!!! (hormis les petits défauts de jeunesse :)))
  13. Dgille

    Quick App - HC2 Devices

    Effectivement, on pourrait imaginer une scène côté HC2 qui déclencherait un refresh du QA quand on a besoin de réactivité ?
  14. Dgille

    Heating Manager

    Pour les intéressés, voici une version de la scène avec régulation PID et anticipation des périodes de chauffe. Enjoy ! https://www.domotique-fibaro.fr/topic/14655-heating-manager-pid-and-more/
  15. Dgille

    Heating Manager - PID and more

    Winter is coming ! Cela fait un moment que jalouse les thermostats connectés NetAtmo et Nest, mais le coté connecté me gène. Les beaux thermostats MCO ne gèrent la régulation que par hystérisis, bref, il fallait une solution pour nos box préférées. En y réfléchissant, l'excellent Heating Manager de @OJC fourni déjà presque tout le nécessaire, voici donc une version 3.2 qui intègre une gestion de la régulation par PID, en plus des autres modes déjà présents. Le fonctionnement de l'ensemble reste le même, donc si vous êtes nouveaux sur le sujet, commencez par : J'en ai profité pour intégrer quelques corrections remontées par les autres membres du forum et d'autres que j'ai découverte. Pour activer le mode PID, il suffit de remplacer les directives setHysteresisMode ou setProportionalMode par setPIDMode(default_Kp, default_Ki, default_Kpd, cycle, minCycle). La partie la plus difficile est de fixer les coefficients. Il y a pléthore d'articles sur le sujet, donc interrogez Google ! Je vous en propose par défaut, mais pour faire simple : - la partie proportionnelle peut être fixée autour de 50 à 60 % - la partie intégrale peut être fixée à 20 % de la partie proportionnelle - la partie dérivée aux 2/3 de la partie intégrale. Tout cela est à ajuster à votre installation et dépend des caractéristiques de celle-ci, de votre isolation, du type de chauffage et de son inertie, etc.... Ayez à l'esprit que le mode PID n'est pas adapté à de brusques variations de consigne, donc si vos règles font de votre thermostat un yoyo, oubliez le PID et utilisez les autres modes ! La régulation PID peut générer des temps d'activation très court quand le système est stable, j'ai donc introduit un nouveau paramètre global minP (fixé à 2%), pour ne pas activer chaudières et convecteurs sur de très courtes durées, ce qui est inutile voire néfaste pour l'installation. Amusez vous bien ! Voici le code de la scène : Heating-manager-scene with PID-3.2.lua Anticipation de chauffe : Un peu de théorie: En fouillant sur internet, je n'ai pas trouvé beaucoup de littérature sur l'anticipation de chauffe, je n'ai pas beaucoup cherché non plus... L'algo imaginé consiste à effectuer une approximation linéaire de la montée en température de la pièce à chauffer lors des cycles de chauffe de Heating Manager. Pour ce faire, une fonction d'apprentissage alimente une matrice creuse dont les couples {température de départ, température d'arrivée) donnent une durée pour y parvenir, généralement, la durée du cycle. Pour déterminer la durée d'anticipation, une fonction récursive va chercher un chemin dans cette matrice pour déterminer la durée nécessaire pour aller de la température actuelle à la température de la consigne. La courbe résultant de la régulation PID ou UBat de Heating manager est en fait découpée en petits morceaux de droite si on en faisant une représentation géométrique. On compare ensuite la durée nécessaire pour arriver à la consigne cible à l'heure H à l'heure actuelle. Passons à la pratique: Cette version de Heating Manager, réalise un apprentissage basé sur les cycles de chauffe, en permanence, même lorsque la fonctionnalité est désactivée (par défaut). Pour avoir une anticipation fiable, il est conseillé de laisser tourner ainsi quelques jours pour constituer la matrice, stockée dans une table Lua, sauvegardée dans la VG HeatingManagerAA. L'apprentissage moyenne les températures de fin de cycle, pour compenser les périodes de chauffe rapide en demi saison et les périodes de chauffe lente en hiver. En cas de brusque changement des conditions climatiques, l'anticipation pourra ne pas être optimale pendant quelques jours, le temps que la matrice s'adapte. Il faut prévoir dans ce cas une marge de sécurité sur vos panneaux, j'intègrerai peut être celle-ci dans une prochaine version. Pour activer la fonctionnalité, il suffit d'activer la ligne self:setAutoAdapt(true) dans la section configuration de la scène. Par contre, pour anticiper les cycles, il faut un planning, vous devez donc vous appuyer, soit sur le Heating Provider, soit sur les panneaux de chauffage de la HC2. Les horaires indiquée deviennent ceux ou la température doit être atteinte. Si vous utilisez les panneaux de chauffage et si une température de vacance ou une dérogation de consigne est en cours, la scène en tient compte et désactive l'anticipation de chauffe. La scène vérifie que le temps d'anticipation ne dépasse pas 3h par défaut. Si vous devez chauffer 6h à l'avance pour obtenir votre consigne, c'est que vous avez un problème de chauffage ou de porte ouverte.... J'ai ajouté également une version du VD Heating Provider intègrant la fonctionnalité AutoAdapt. Il aura besoin, en plus du planning, de connaitre la sonde de température de la zone et de l'ID déclaré dans la scène pour identifier le dispositif de chauffe. Deux fonctions pour cela : HeatingManager:addheater("lblZoneJour", "id du qubino ou du FGS" ) HeatingManager:addprobe("lblZoneJour", {id de la sonde,"value"} ) Je pense que l'algo peut encore être amélioré, mais je partage cette première version avant de passer à la HC3... Amusez vous bien.... heating-manager-scene with PID and AutoAdapt.lua-3.4.lua Heating_Provider with AutoAdapt 3.4.vfib
  16. Dgille

    Heating Manager - PID and more

    Et voila, publication de la version 3.4 avec anticipation des cycles de chauffage...
  17. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Elle démarre au moins ?
  18. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Oui, et moi pas
  19. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    La mienne est en chemin.... validée ce matin sur le site, c'est à la tête du client de toute évidence...
  20. Dgille

    Vente de QuickApp pour Home Center 3

    J espére qu il a demandé l autorisation....
  21. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Merci, oui, tu dois avoir des actions, c'est clair Je connaissais l'histoire du créateur qui se verrait bien sur mars, mais pas dans le détail les avantages de la solution.. Bon, j'ai un compte maintenant. J'attends juste mon HC3.....
  22. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Non, pas contre, juste que je n en voyais pas trop l utilité, mais comme cela devient le mode de paiement unique sur certains sites, pas le choix...
  23. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Oui, mais pas de HC3 d occasion...c est dommage..
  24. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    Bon, j'ai ouvert un compte Paypal au final, la domotique impose des sacrifices.... et pas que financiers.
  25. Dgille

    Fibaro Z-Wave Home Center 3 a 435.99 euros

    peux être uniquement en Allemagne.... Moi, j'aimerai juste pouvoir la payer :).
×