Lazer

c'est pas la faute de l'iPad pour le coup. Ca m'arrive régulièrement avec le HC2 que les modules que j'inclue soient mal reconnus. Solution : exclure et inclure ànouveau.

Pour l'iPad, je ne peux pas t'aider, c'est trop compliqué à utiliser (je parle en connaissance de cause, j'en ai un à la maison). Ca sert juste à surfer, jouer, et regarder des vidéos de chats. C'est même pas un troll tellement c'est vrai :/ . Ton module doit être ma reconnu, essaye de l'exclure, et de le réinclure à nouveau. Tu dois avoir ces infos là en en-tête de page :

Sur mes 2 FGRM-222 sur HC2 v3.590, j'ai bien le bouton Calibration, comme sur le screeshot de Did. Ah les mystères de Fibaro

Retour d'expérience sur la durée de vie des 2 piles AAA d'origine fournies avec ce thermostat. Elles ont tenu 11 mois : SRT321 installé début décembre, et piles changées début novembre. J'ai configuré les paramètres suivants qui ont une influence sur l'activité du thermostat,donc sur la durée des piles : Intervalle de réveil : 900 secondes (15 minutes) TPI : 6 cycles par heure Association : 1 module FGS-211 Et le graphique (qui ne commence pas au début, le temps que je mette le monitoring en place) : On constate que la chute s'est limitée à partir d'avril/mai quand on a arrêté de chauffer. Pour une raison inexpliqué, c'est reparti de plus belle en plein mois d'aoà»t. Vers la fin, en dessous de 40%, le niveau des batteries dans HC2 remontait de temps en temps à 0, ce qui explique les chutes brutales, puis ça revenait. J'ai reçu un paquet d'email d'avertissement durant 1 mois, jusqu'à ce que les piles soient effectivement mortes à 30% (en fait, ils leur reste du jus, mais pas assez pour le thermostat : l'écran fonctionnait, mais pas les communications radio Z-Wave). Bref, avec ce module, la mesure du niveau de batterie n'est pas très fiable. Maintenant il est banché sur des fausses piles en bois, donc 100% tout le temps et j'ai réduit l'intervalle de réveil Tip top

J'ai un gros doute pour les valeurs de thermostats, surtout depuis que je viens de découvrir qu'en v4 ils ont ajouté un nouveau type spécial pour Danfoss : com.fibaro.thermostatDanfoss Du coup, mon Secure SRT321, de quel type sera t'il en v4 ??? Demain soir en rentrant chez moi, j’inclurai le ZXT-120 sur la HC2 de Lionel afin de voir de quel type il est reconnu en v4 (c'est bête, on peut tout faire à distance sauf les recovery et les inclusions) Merci à Lionel de permettre de faire avancer la science EDIT : je viens aussi de découvrir une API que je ne connaissais pas : /api/devices?type=com.fibaro.temperatureSensor Donc dans la prochaine version de mon module virtuel, je ne parcourerai pas la liste complète des modules, mais ferai directement appel à l'API pour obtenir direct la bonne liste de modules, ce qui évitera de se faire piéger par la variable maxModuleID à 200.

ah oui forcément

Avec les butées d'arrêt ? Chez moi elle ne sont làqu'en fin de course, et c'est mécanique, donc je ne vois pas vraiment comment choper l'info avec des relais. Tu peux préciser ?

Je veux bien voir ta page. Mais ça ma saoule de devoir tout programmer, alors qu'on aura tout ça prochainement tout prêt, il n'y aura qu'à choisir les modules qu'on veut mettre sur chaque écran.

targetLevel n'est différent de value que durant l’intervalle de réveil. Le reste du temps il est identique. Cela permet juste de détecter la différence entre la consigne envoyée et la consigne perçue. Après on n'est pas obligé d'exploiter cette info non plus.

Avec le Secure SRT321, c'est différent : type : "thermostat_setpoint" (en V3) targetLevel : "20.00" => consigne envoyée par HC2 value : "20.00" => consigne effectivement reçue par le thermostat en fonction du délai de réveil valueSensor : "20.30" => sonde de température interne

Voilà pourquoi je n'utilise pas cette application. Jolie, mais pas pratique. Vivement la compatibilité de Imperihome avec Fibaro, afin qu'on puisse se créer ses propres écrans en 2 temps 3 mouvements

Logiquement la remonté de Luminosité et de Thermostat ne devaient pas fonctionner non plus. Tu peux essayer avec ça, ce code devrait être compatible en v3 ET v4 : Bouton n°1 : local updatechart = Net.FHttp("server_name_or_ip_address") local i = 0 local maxNodeID = 200 for i = 0, maxNodeID do local deviceType = fibaro:getType(i) local deviceType2 = "" if deviceType == "temperature_sensor" or deviceType == "com.fibaro.temperatureSensor" then deviceType2 = "temperature" elseif deviceType == "humidity_sensor" or deviceType == "com.fibaro.humiditySensor" then deviceType2 = "humidity" elseif deviceType == "thermostat_setpoint" or deviceType == "com.fibaro.thermostatSetpoint" then deviceType2 = "temperature" elseif deviceType == "light_sensor" or deviceType == "com.fibaro.lightSensor" then deviceType2 = "light" end if deviceType2 ~= "" then payload = "/graph/data_post_" .. deviceType2 .. ".php?id=" .. i .. "&value=" .. fibaro:getValue(i, "value") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) deviceType2 = "" end end payload = "/graph/data_post_temperature.php?id=3&value=" .. fibaro:getValue(3, "Temperature") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) payload = "/graph/data_post_humidity.php?id=3&value=" .. fibaro:getValue(3, "Humidity") --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) fibaro:log("Environmental uploaded") Bouton n°4 : local updatechart = Net.FHttp("server_name_or_ip_address") local i = 0 local maxNodeID = 200 for i = 0, maxNodeID do local deviceType = fibaro:getType(i) local deviceType2 = "" if deviceType == "temperature_sensor" or deviceType == "com.fibaro.temperatureSensor" then deviceType2 = "temperature" elseif deviceType == "humidity_sensor" or deviceType == "com.fibaro.humiditySensor" then deviceType2 = "humidity" elseif deviceType == "thermostat_setpoint" or deviceType == "com.fibaro.thermostatSetpoint" then deviceType2 = "temperature" elseif deviceType == "light_sensor" or deviceType == "com.fibaro.lightSensor" then deviceType2 = "light" end if deviceType2 ~= "" then local roomID = fibaro:getRoomID(i) local deviceName = string.gsub(fibaro:getName(i), "%s+", "%%20") local roomName = string.gsub(fibaro:getRoomNameByDeviceID(i), "%s+", "%%20") payload = "/graph/device_post.php?id=" .. i .. "&type=" .. deviceType2 .. "&name=" .. deviceName .. "&roomid=" .. roomID .. "&roomname=" .. roomName --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) end x , y = string.find(fibaro:get(i, 'unitSensor'), "W") or string.find(fibaro:get(i, 'unit'), "W") if x ~= nil or y ~= nil then local roomID = fibaro:getRoomID(i) local deviceName = string.gsub(fibaro:getName(i), "%s+", "%%20") local roomName = string.gsub(fibaro:getRoomNameByDeviceID(i), "%s+", "%%20") payload = "/graph/device_post.php?id=" .. i .. "&type=power&name=" .. deviceName .. "&roomid=" .. roomID .. "&roomname=" .. roomName --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload); end if fibaro:getValue(i, "parentID") == "1" and fibaro:get(i, 'isBatteryOperated') == "1" then local roomID = fibaro:getRoomID(i) local deviceName = string.gsub(fibaro:getName(i), "%s+", "%%20") local roomName = string.gsub(fibaro:getRoomNameByDeviceID(i), "%s+", "%%20") payload = "/graph/device_post.php?id=" .. i .. "&type=battery&name=" .. deviceName .. "&roomid=" .. roomID .. "&roomname=" .. roomName --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) end end local deviceName = fibaro:getName(3) payload = "/graph/device_post.php?id=3&type=temperature&name=" .. deviceName .. "&roomid=0&roomname=Météo" --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) payload = "/graph/device_post.php?id=3&type=humidity&name=" .. deviceName .. "&roomid=0&roomname=Météo" --fibaro:debug(payload) response, status, errorCode = updatechart:GET(payload) --if response ~= nil then fibaro:debug(response) end --if status ~= nil then fibaro:debug(status) end --if errorCode ~= nil then fibaro:debug(errorCode) end fibaro:log("Devices uploaded")

@Krikroff : ah j'avais loupé la ligne du path pour la batterie. Bon et bien c'est super ça. /mode boulet

Il sert àquoi le paramètre "Notify when battery low via e-mail" dans le plugin ? Car on ne peut pas avoir de type Battery ? Ou alors c'est une future feature ?

Je ne sais pas, je ne touche plus du tout àl'iPad.... mais àl'époque, l'appli iPad avait bcp d'avance

ah oui tout àfait c'est bon de le préciser

J'ai un peu de temps ce soir, tu vas d'écrire ton problème sur le topic adéquat et je regarde.

Mprinfo, oui je pense qu'on parle de la même chose au sujet du bail Dhcp statique, permettant de fixer une IP en fonction de la MAC.

Fin de la bêta ? Super ! Par contre le panneau d'énergie que en v4... Donc bêta :/

Cool Le mieux c'est de déclarer un bail Dhcp statique dans ta box, comme ça même si la box perd son IP statique, elle reprend la même via Dhcp.

En effet, SQLite est transactionnelle, c'est un bon point. Donc elle devrait résister aux coupures de courant. Le système de fichier journalisé ext4 également. Malgré cela, il y a des cas (la box de Lionel), ou la corruption finit par arriver. Indépendamment de la "solidité" individuelle de chaque composant, c'est la gestion qui en est faite par Fibaro qui peut laisser à désirer parfois. Si ils mettent les mauvaises donnée dans la base, cette dernière a beau être cohérente d"un point de vue système, les données ne le sont pas forcément d'un point de vue applicatif. Un autre truc tout con, c'est le nom de certaines tables choisi à l'arrache.... ça fait peur. @Nvince76 : tu as les diodes qui clignotent à l'envers ? Mais tu n'arrives pas à accéder à la page Web ? Vérifie les logs de ton serveur DHCP (box ADSL ?), car la box prend une IP via DHCP en mode Recovery. Ou alors tu branches un écran, tu verras l'IP au boot.

ah oui ok, bien pensé. Je note, merci pour l'astuce

Je ne comprends pas bien cette histoire de multithread qui a été annoncé en v4. Car àpriori c'est déjàle cas en v3. Les scènes dans des threads, et les main loop de MV dans des processus enfants. Les accès àla BD se font avec SQLite, qui je pense n'est pas transactionnelle; Donc faut pas que 2 thread y accèdent en même temps. Apparemment, il y a un seul process indépendant des autres responsable de cette activité, ce qui devrait résoudre le problème, si il est bien codé...

C'est de la gaine thermo le truc blanc que tu as mis autour ? Du coup tu as utilisé quoi pour les 3 fils afin que ça passe ? Du câble téléphonique/réseau dégainé ?

Génial tout ça ! J'ai remarqué que parfois le FGBS appréciait moyennement de perdre la communication avec les sondes. SI tu as suivi, j'ai cramé 2 sondes (sur 4), et l'étage d'alimentation 3,3V du FGBS. Certainement à cause d'un court circuit temporaire sur l'une des pâtes quand j'ai bougé les fils. Donc bon, il vaut mieux l'éteindre temporairement quand on touche aux sondes.