Gazous

Bonjour, des retours sur ce nouveau module ? Est-ce que certains ont déjàeu l'occasion de le tester ? J'ai déjàrelevé une "régression" par rapport àl'ancienne version, àsavoir que le triple-clic sur S1 ne peut plus être utilisé dans les sceneActivation, ce que je trouve vraiment dommage. Le triple-clic sur S2 fonctionne. Selon FIbaro, cela n'est plus possible car le triple-clic sur S1 est réservé au passage en mode "apprentissage" Je comprends que cela active ce mode sur le module mais je ne vois pas en quoi cela les empêche de remonter aussi une sceneActivation.... Si vous avez des retours je suis preneur.

Bonjour, je reviens aujourd'hui sur ce post car ayant fait l'acquisition il y a quelques temps d'un IPX800V3, j'ai naturellement utilisé celui-ci pour le pilotage de mes radiateurs et également de mon chauffe-eau. Voici ci-dessous le script amélioré et adapté à l'IPX800. Il faut si vous avez activer l'authentification sur votre IPX, saisir vos crédentials et définir vos zones de chauffage. Je gère également une variable Globale "vacances" avec comme valeurs 0 ou 1 pour couper le chauffage et l'eau-chaude en cas d'absence prolongée. Espérant que cela puisse servir à d'autres. En ce qui me concerne, c'est du temporaire pour la partie chauffage puisque j'attends une autre solution Fil Pilote centralisée ou radiateur connecté puisque j'envisage prochainement de remplacer mes radiateurs. --[[ %% autostart %% properties %% globals --]] local sourceTrigger = fibaro:getSourceTrigger() local zones = {} local chauffeEau = {} local IPXIP = "192.168.1.11" local IPXAuthorizationKey = "" local IPXJsonState = nil --- Usefull Functions --- function debug(text, color) color = color or "white" fibaro:debug("<font color='"..color.."'>"..text.."</font>") end function arrayContains(array, val) for k,v in pairs(array) do if (v == val) then return true end end return false end function isWeekDay() return fibaro:getGlobalValue("JourChome") == "NON" end function isTimeBetween(startTime, endTime) -- Je stocke l'heure courante dans le format attendu pour comparaison now = tostring(os.date("%H:%M")) -- Je vérifie que l'heure courante est dans la plage horaire if (startTime < endTime and (now >= startTime and now <= endTime)) then return true elseif (startTime > endTime) then if (now >= startTime or now <= endTime) then return true end end return false end function checkTimeSlots(timeSlots, zoneName) for k,ts in ipairs(timeSlots) do if isTimeBetween(ts.startTime, ts.endTime) then return true elseif (ts.canDerogate and tonumber(fibaro:getGlobalValue("presence")) ~= 0) then fibaro:debug("Zone "..zoneName.." en CHAUFFE sur dérogation de présence") return true end end return false end function newTimeSlot(startTime, endTime, canDerogate) ts = {} ts.startTime = startTime ts.endTime = endTime ts.canDerogate = canDerogate or false return ts end function checkZonesAsync() if (IPXJsonState == nil) then debug("Erreur de récupération de l'état IPX", "red") else -- J'itère sur toutes les zones for k,z in ipairs(zones) do checkZoneState(z) end end debug("Vérification terminée !", "blue") -- Gestion de l'autostart et du timer toutes les 1 min if (sourceTrigger["type"] == "autostart") then setTimeout(checkZones, zones.checkEvery*1000) end end function refreshIPXState() IPXJsonState = nil local http = net.HTTPClient() http:request("http://"..IPXIP.."/api/xdevices.json?cmd=20", { options = { method = 'GET', headers = {["Authorization"] = 'BASIC '..IPXAuthorizationKey}, }, success = function(response) IPXJsonState = json.decode(response.data) checkZonesAsync() end, error = function(err) debug("Error: " ..err, "red") fibaro:sleep(1000) refreshIPXState() end }) end function switchIPXRelay(relayId, newState) local http = net.HTTPClient() http:request("http://"..IPXIP.."/preset.htm?set"..relayId.."="..newState, { options = { method = 'GET', headers = {["Authorization"] = 'BASIC '..IPXAuthorizationKey}, }, error = function(err) debug("Error: " ..err, "red") end }) end function checkZoneState(z) -- Selection du bon TimeSlot (Semaine ou WE) if isWeekDay() then timeSlots = z.weekSlots else timeSlots = z.weekendSlots end -- Gestion du mode inversé (exemple chauffe eau) local eco = 1 confort = 0 if (z.inverseState) then eco = 0 confort = 1 end -- Mode ECO if (vacances == 0 and checkTimeSlots(timeSlots, z.name)) then if (tonumber(IPXJsonState["OUT"..z.IPXRelayId]) == eco) then debug("Passage de la zone "..z.name.." en Mode CHAUFFE", "orange") switchIPXRelay(z.IPXRelayId, confort) end -- Mode CONFORT elseif (tonumber(IPXJsonState["OUT"..z.IPXRelayId]) == confort) then debug("Passage de la zone "..z.name.." en Mode ECO", "green") switchIPXRelay(z.IPXRelayId, eco) end end zones.add = function(IPXRelayId, name, weekSlots, weekendSlots, inverseState) z = {} z.IPXRelayId = IPXRelayId z.name = name z.weekSlots = weekSlots z.weekendSlots = weekendSlots z.inverseState = inverseState or false table.insert(zones, z) end ----------------------------------------------------------------------------- function checkZones() debug("Vérification Chauffe-eau et Chauffage...") vacances = tonumber(fibaro:getGlobalValue("vacances")) if vacances == 1 then debug("Mode vacances : toutes les zones sont en ECO", "red") end -- Je rafraichi l'état des relais de l'IPX qui terminera le traitement lors de la réponse refreshIPXState() end -- Initialisation des zones -- La syntaxe est simple, il suffit d'ajouter une zone avec -- - l'id du relais de l'IPX -- - le nom de la zone -- - les X timeSlots ECO de la semaine -- - les X timeSlots ECO du weekend -- - si les status du relais sont en mode inversé NO <> NF -- Le troisième paramètre optionnel tu timeSlot correspond à une autorisation de dérogation -- Il faudra pour l'autoriser le définir à true et positienner une variable globale nommée "presence" à 1 ou 0 -- Dans mon cas ci-dessous, seul le séjour a une possibilité de dérogation en cas de présence dans l'appartement en journée, dans ce cas, le chauffage restera en CONFORT zones.add(1, "Chauffe-Eau", {newTimeSlot("03:45", "06:55")}, -- newTimeSlot("14:10", "16:50")}, -- semaine {newTimeSlot("03:45", "06:55")}-- newTimeSlot("14:10", "16:50")} ,true) -- weekend et jour chomes zones.add(2, "Sejour", {newTimeSlot("06:00", "08:30"), newTimeSlot("16:30", "23:35", true)}, -- semaine {newTimeSlot("08:00", "12:00"), newTimeSlot("13:00", "23:35")}) -- weekend et jour chomes zones.add(3, "Chambres 1 et 3", {newTimeSlot("06:15", "07:45"), newTimeSlot("21:45", "23:50")}, -- semaine {newTimeSlot("07:00", "08:45"), newTimeSlot("22:45", "23:50")}) -- weekend et jour chomes zones.add(4, "Chambre Adam", {newTimeSlot("06:15", "08:15"), newTimeSlot("18:30", "21:00")}, -- semaine {newTimeSlot("06:45", "08:45"), newTimeSlot("18:30", "21:00")}) -- weekend et jour chomes zones.add(5, "SDB", {newTimeSlot("06:15", "08:15"), newTimeSlot("18:30", "21:00")}, -- semaine {newTimeSlot("06:45", "08:45"), newTimeSlot("18:30", "21:00")}) -- weekend et jour chomes -- Recurence de verification zones.checkEvery = 60 pcall(checkZones)

Je vous fait un petit retour rapide sur mes avancées concernant Cozytouch. J'ai récupéré l'IPA de l'application iOS que j'ai décompilée ce qui m'a permis de découvrir pas mal de choses. J'ai aussi intercepté un appel (login) à leur cloud en détournant celui-ci via un proxy local qui déchiffre le SSL. J'ai donc pu tracer l'appel qui redirige vers je vous le donne en mille ? Une API JSON SSL publique dont voici l'l'URL : https://ha110-1.overkiz.com/enduser-mobile-web/externalAPI/json/ Ainsi, pour appeler la méthode login, il suffit d'appeler https://ha110-1.overkiz.com/enduser-mobile-web/externalAPI/json/login?userId=gazous&userPassword=gazous Le retour obtenu est : {"error":"Bad credentials"}, normal car je n'ai pas de compte et il faut un Bridge Cozytouch pour le créer. Cela commence donc plutôt pas mal car si l'API fonctionne ainsi pour tous les appels de l'application, ce qui est très probablement le cas, je suis capable de tracer et reproduire tous les appels et donc à priori de pouvoir simuler tout ce que fait l'application et ainsi : - piloter tous les équipements (radiateurs, ventilation, chauffe-eau) compatibles - récupérer les statistiques de consommations des équipements Maintenant pour avancer et valider la faisabilité de tout ça il me faudrait le fameux Bridge Cozytouch afin de créer un compte... C'est assez prometteur quand même et je pense que cette techno qui vient d'être lancée va être déclinée rapidement sur toute la gamme de ces fabricants et être maintenue pour pas mal d'années... Qu'en pensez-vous ?

Hello bienvenue àtoi sur le forum et excellent choix de passer sur la HC2. Tu vas t'éclater. A bientôt !

Intéressant ! Je n'ai las encore de voiture électrique mais comme je viens de revoir mon installation en domotisant mes box avec un IPX800 j'ai installé 2 prises 20A en prévision... Tu as quoi comme voiture électrique et combien de temps dure la recharge complète ? Merci pour ton post, ça lenservira probablement dans quelques temps.

Pour ceux que ça intéresse, la solution corrigé postée dans le sujet référencé plus haut fonctionne parfaitement chez moi depuis plusieurs semaine. Cela le permet de contourner un blocage de MainLoop jusqu'alors inexplicable...

Moi je ne suis pas spécialiste en électronique mais j'ai un collègue qui l'est. Par contre, je peux sans problème travailler sur la partie soft et l'API REST JSON qui va bien. On monte une team ?

Pourquoi pas. Tant qu'àfaire j'ajouterais la gestion des 6 ordres fils pilotes. Sérieusement, tu es capable de faire tout ça ?

Merci c'est sympa ! Car si chaque radiateur consomme 10 ou 20W en veille on va oublier...

Oui effectivement j'avais vu passer ce projet et je n'y pensais plus non comme toi. Merci de l'avoir rappelé ! Ce qui m'avais gêné àl'époque, c'est le fait qu'il soit en Wifi uniquement et surtout le fait que le contrôle se fasse uniquement via le Cloud. Maintenant en relisant les commentaires, je vois qu'un projet open source permettant de faire tourner un serveur web pour héberger une API REST JSON sur le Spark Core afin de le piloter en local et s'affranchir du Cloud est disponible. On pourrait donc contrôler les 7 zones FP de la même manière qu'on le fait sur un IPX800. Je vais creuser un peu plus mais ça me tente bien de commander les pièces et de monter une carte complète. Premier souci le Spark Core est en rupture de stock... Si ça intéresse quelqu'un on peut faire une commande groupée ?

@Nico, dans tes bureau, il n'y a pas le Bridge Cozytouch ? Car que le IO Home Control soit totalement fermé, c'est normal. La question se pose pour la passerelle qui est forcément IP et communique en IP avec des serveurs dans un cloud ce qui peut ouvrir d'autres portes... Ca serait intéressant si tu avais aussi la possibilité de mesurer la consommation d'un radiateur en veille !

Did, tu n'a pas en tant que PRO des contacts avec Thermos/Atlantic pour en savoir plus sur les produits. En fait que le système soit ouvert ou fermé cela ne change rien puisque dans tous les cas si tu choisis d'acheter du Thermor tu devras quand même acheter le Bridge Cozytouch et acheter que des radiateurs compatibles donc chez eux. La seule différence ensuite c'est la manière dont tu les contrôles : avec leur application ou via la domotique. Je pense qu'au contraire une API locale permettant de discuter avec le Cozytouch serait un bon argument marketing !

Ces nouveaux système affichent des économies de 30% mais il serait intéressant de savoir combien consomme le Bridge Cozytouch et chaque radiateur en veille car àl'année pour un utilisateur qui ne coupe pas les disjoncteurs sur son tableau hors hivers ça peut faire cher...

Oui, j'ai eu la même réflexion et les seuls à pouvoir proposer un produit comme ça c'est GCE. Ils travaillent sortent en ce moment l'IPX800 V4 qui sera suivi d'une nouvelle extension fil pilote mais il ne donnent pas trop d'informations dessus pour le moment. C'est vraiment dommage que personne ne propose un équipement ethernet ou zwave capable de gérer un certain nombre de zones en FP. Les modules Qubino c'est très bien pour de la rénovation quand on a pas une installation avec FP dans une centrale mais pour des installation plus récente, c'est un peu con d'aller mettre 10 modules à 60 euros dans le tableau...

Oui je sais mais ça mérite quand même de s'y intéresser J'ai installé l'application pour voir comment c'était fait et sans surprise, il semble que le tout passe par un Cloud puisque la première chose demandée est de créer un compte avec un ID qui figure sur le Bridge. Je pense donc que c'est une architecture classique dans laquelle le Bridge se connecté àla PFS pour recevoir les ordres qui sont saisis via l'application elle-même connectée au Cloud. Il est donc fort probable que ce soit déjàun peu mort d'espérer piloter le Bridge en local mais il y a peut-être un espoir en passant par le Cloud.

Oui c'est sà»r qu'il y a beaucoup d'incertitudes. Etant donné qu'il y a des versions iOs et Android de l'application, on peut espérer qu'ils aient fait au plus simple avec du REST. Même si les échanges sont chiffrés en SSL, j'ai une technique très efficace pour récupérer les échanges avec un proxy et un iPhone jailbreaké... Mais bon comment déjà obtenir des informations là dessus ? Autre point important. il serait intéressant de connaître la consommation en veille de ces radiateurs. En effet, il y a des chances que même lorsqu'ils ne chauffent pas ces radiateurs consomment quelques W résiduels ne serai-ce que pour être à l'écoute des ordres entrants. Did me disait récemment qu'il avait eu une mauvaise surprise avec des radiateurs qui consommaient je crois plus de 20W en veille. Pour celui qui a 8 radiateurs et qui ne coupe pas l'alimentation en été pensant qu'il ne consomment rien a dans ce cas une consommation constante de 160W, ça commence à faire pas mal... C'est un peu pareil pour les enceintes Sonos qui je croient consomment presque 20W en permanence.

Hello, Je poste ce sujet car étant toujours à la recherche de bons radiateurs électriques pour mon installation, je regardes régulièrement ce qui se faite de nouveau et depuis l'an dernier, les fabricants commencent à proposer des radiateurs connectés. Ainsi, depuis quelques jours, 3 fabricants connus pour sortir des produits très similaires (Atlantic, Thermos et Sauter) viennent de lancer leur nouvelle gamme de radiateurs connectés qui utilisent tous le protocole IO Home Control associé à une passerelle qu'ils appellent "Bridge Cozytouch" (exemple sur ce site) En plus le design des radiateurs est plutôt réussi par rapport à ce que l'on a pu voir dans les générations précédentes : Ces nouveaux systèmes m'amènent à la réflection suivante : plutôt que d'acheter des radiateurs classiques et de les pilotes en FP 6 ordres, pourquoi ne pas acheter ce type de radiateurs qui ne sont pas forcément beaucoup plus chers et qui permettent probablement un contrôle plus fin que les 6 ordres FP et offrent en plus la possibilité de connaître la consommation ? Le calcul que j'ai fait est simple, pour mes 7 radiateurs, il me faut 7 modules FP soit environ 400 euros. Le Bridge Cozytouch est vendu moins de 140 euros... La question est donc : est-ce que ce bridge Cosytouch dispose d'une API ouverte qui permettrait de le contrôler depuis la HC2 ? Là c'est déjà moins évident MAIS, vu qu'il existe une application iOS et Adroà¯d, il y a forcément au pire la possibilité de tracer les appels faits depuis l'application pour les simuler depuis la HC2. Ce type d'architecture simplifierait grandement la programmation et apporterait en plus la possibilité de suivre la consommation de chaque radiateur sans avoir à investir dans des modules de mesure de consommation supplémentaire ? Qu'en pensez-vous ? J'ai essayé de trouver des contacts chez ces fabricants mais ce n'est pas évident, leur site revoit à chaque fois vers des installateurs. Si quelqu'un a la possibilité d'avoir un contact, ça serait intéressant. On pourrait envisager le futur développement d'un Plugin Fibaro Cozytouch

Merci Jojo, ça fonctionne bien pour moi aussi ! Impec. Petite idée d'amélioration : il serait bien de conserver la date/heure du dernier changement d'état de façon àpouvoir améliorer le status qui donnerait "Eteint depuis 1h 3min" ou "Allumé depuis 3 jours". Qu'en penses-tu ?

Bonjour àtous. Le sujet est vraiment intéressant car depuis que j'ai domotisé mon ballon de 300L je me pose la question de trouver la meilleure manière de programmer les heures de chauffes sachant que nous sommes 2 adultes et 1 bébé. Je suis en HC/HP 14h-17h 2h-7h. J'avais mis en place un script qui gère la mise en chauffe du ballon durant les heures creuses avec une petite marge de quelques minutes pour ne pas déborder et la gestion du mode vacances. J'ai pu observé sur une période d'un mois des consommations journalières en HC entre 5000 W et 7000 W selon les jours. Je n'ai pas forcément le détail précis du ballon car il y a parfois une machine qui tourne durant les heures creuses mais ça donne déjàune idée. Depuis quelques jours je fais le test suivant : je retire la période de chauffe entre 14h et 17h pour que la ballon chauffe uniquement la nuit (2h-7h) et j'observe la conséquence sur la consommation. J'attends d'avoir un peu plus de recul mais j'observe que la consommation n'est pas forcément inférieure mais plutôt supérieure, ce qui m'étonne un peu. Mon ballon est dans un placard fermé àl'intérieur de l'appartement. Qu'en pensez-vous ? Je n'ai pas encore tenté le coup de ne chauffer qu'un jour sur 2 mais tous les 4 jours comme ce que fait CaptainIgloo ça me semble beaucoup ! Le 3ième jour la température de l'eau en sortie du ballon a du perdre pas mal j'imagine !

Hello Jojo. Tout d'abord merci pour le VD. J'ai voulu le tester mais je ne comprends pas dans le Zip il y a le VD Surveillance Station et pas ton VD. Erreur de fichier ?

Ha je ne connaissais pas les ACI... C'est récent ? Il y a aussi ce tuto : http://www.myipx800.com/index.php?post/2012/09/13/Commander-son-ballon-d-eau-chaude qui correspond à ce que j'ai actuellement.

Hello, en ce qui me concerne j'ai domotisé le cumulus en utilisant le contacteur J/N que j'avais dans mon tableau. Je me suis substitué au compteur EDF qui déclenché la chauffe via un contact qui se fait sur une sortie 220V 2A. Au départ j'utilisais un FGS et àprésent je l'ai branché sur mon IPX.

Merci Jojo, c'est peut-être une piste mais je n'utilise pas ses fonctions dans la scène en question.

Bonjour, J'ai une scène assez simple qui tourne en permanence et qui a pour but de récupérer la trame JSON d'un IPX pour stocker le résultat dans une VG. Cela fonctionne très bien sauf que dans certains cas, j'ai une erreur que je n'arrive pas à contourner et qui plante ma scène. Voici l'erreur en question : [ERROR] 12:48:06: LUA error: /usr/share/lua/5.2/json/decode/util.lua:35: unexpected character @ character: 1 0:1 [d] line: [ERROR] 12:48:06: d Cela se produit de manière aléatoire, peut-être une fois par mois et cela m'oblige à relancer la scène manuellement. Est-ce que quelqu'un a déjà rencontrer ce genre de souci et trouvé un contournement. Ce que je ne comprends pas c'est que je n'appelles pas de méthode decode sur le json dans cette scène... Merci d'avance pour votre aide.

Merci pour l'article ! Il serait peut-être intéressant de dédier un sujet aux bonnes idées d'intégration entre la HC2 et IFTTT. Certains pourraient contribuer en tant en apportant des idées et d'autres en les intégrant dans les scènes qui vont bien.