Rechercher dans la communauté

Après le calendrier Google, je me suis attaqué maintenant à ma Zibase. En effet, j'ai commencé la domotique il y a quelques temps de ça, avec une Zibase. Depuis elle ne m'a jamais quitté. Même si aujourd'hui j'ai migré (pratiquement) tous mes modules zwave sous la Home center, j'utilise toujours ma Zibase pour les devices Oregon et EnOcean essentiellement. J'ai vu passer différentes solutions permettant de récupérer les infos/valeurs de ces modules au sein de la HC2. Ceci dit, rien de satisfaisant pour moi, car les solutions sur lesquelles je suis tombé font essentiellement du pooling vers la Zibase, or j'ai besoin de temps réel. Pas pour les relevés des sondes Oregon mais pour les détecteur d'ouverture EnOcean. Je me suis donc amusé à trouver une autre solution répondant à mon besoin. Le principe Le principe est assez simple : plutôt que d'aller voir de façon périodique l'état des devices de la Zibase, je me suis dit qu'il suffit en fait "d'écouter" ce que broadcast la Zibase et de chopper dans ce flux ce qui m'interesse. Il suffit alors de passer par l'api de Fibaro pour mettre à jour les variables correspondantes dans ma HC2. Dans le détail... Il s'agit d'un script PHP que j'ai hébergé sur mon syno (mais un RPI ou toute autre machine pouvant faire tourner du PHP 24h/24 suffit). Pas besoin de configurer un serveur web puisque le script PHP tourne en mode CLI (lancé automatiquement au démarrage du syno dans mon cas). Lors du lancement du script, ce dernier va s'abonner aux messages de la Zibase. Il va donc recevoir un flux de ce type a chaque fois qu'un device remonte une info vers la Zibase : Received radio ID (<rf>433Mhz Oregon</rf> Noise=<noise>2420</noise> Level=<lev>3.4</lev>/5 <dev>Temp-Hygro</dev> Ch=<ch>2</ch> T=<tem>+18.4</tem>C (+65.1F) Humidity=<hum>45</hum>% Batt=<bat>Ok</bat>): <id>OS439218434</id> On décode alors ces données pour pouvoir mettre à jour la ou les variables associées au niveau de la HC2. Un des points délicats concerne la configuration du fichier permettant de mettre en place ce décodage. Le fichier de configuration des messages de la Zibase Ce fichier est donc un des éléments essentiels de cette solution. Il s'agit d'un fichier json (pour la facilité de lecture et construction). Il y a 2 parties dans ce fichier : Un premier élément de configuration permettant de définir les différents protocoles radio qui seront reconnus par le script. On vient dire ici, par protocol (Oregon, EnOcean, ...) et par type de device (Détecteurs, sondes température, etc.) quelles sont les données qu'il faut récupérer dans le flux correspondant. Un second élément permet de définir pour chaque device reconnu (par son ID Radio) quelles sont les variables qui seront mise a jour avec quelles données. On indiquera également si cette mise a jour doit se faire à chaque remontée d'info (exemple du détecteur), ou seulement si la donnée à été modifiée depuis la dernière mise à jour (afin de ne pas saturer la HC2 de requêtes inutiles). Autant vous prévenir tout de suite, cette configuration est chiante à souhait à mettre en place, mais bon j'ai pas trouvé plus simple et/ou plus automatisé. Ceci dit, une fois au point, on y touche plus ! Le script PHP Ce dernier vient avec un script contenant les variables de configuration dont les valeurs sont à modifier en fonction de votre installation. C'est assez explicite, je ne vais pas m'attarder dessus. Côté Home center Alors ici, il y a quelques petites choses à faire. Le plus gros problème est que je passe par l'api HTTP pour mettre à jour les variables. Or par ce biais, même si la mise à jour fonctionne, elle ne permet pas de déclencher les scènes et autres scripts qui seraient basés sur ces dernières (limitation de Fibaro ... va comprendre pourquoi ...). Du coup, j'ai implémenté la solution proposée par Jojo dans un autre post qui consiste à passer par l'intermédiaire d'un bouton de module virtuel qui vient mettre à jour la variable avec sa valeur. Bon ne pouvant pas m'amuser à créer un bouton pour chaque valeur discrète possible et imaginable, le script PHP va mettre à jour 2 variables permettant de stocker le nom de la variable finale à mettre à jour et sa valeur(1). On va ensuite déclencher le module virtuel (2) qui va récupérer ces données (3) et mettre à jour à son tour la variable désirée avec la bonne valeur (4). Et voilà , les scènes basées sur cette variable fonctionnent du coup (5) ! Je ne sais pas si vous me suivez toujours dans mon raisonnement (un peu tordu), j'essaye de vous faire un p'tit dessin pour illustrer la chose : script PHP ---------+----(1)--->zibaze_variable = "anemometre" <-. +----(1)--->zibaze_value = "3.2" <-----------+ | (3) `----(2)--->VModuleID = 99, PushButton n°1 --+ | (4) | v anemometre = "3.2" | (5) | v scene "FermetureStore" start Installation Du coup l'installation de tout ce bordel s'effectue en plusieurs étapes : A/ Pour la partie PHP il faut 1) Poser les différents fichiers dans un espace sur votre serveur et connectez vous dessus (ssh, telnet, ...) 2) Modifiez le fichier zibaseGateway_config.php et zibaseGateway.php afin d'initialiser les variables avec les bonnes valeurs (partout ou il y a des XXXX vous devez configurer en fonction de votre installation) 3) Assurez vous que la variable verbose soit positionnée à LogType::CONSOLE dans un premier temps (une fois que tout sera au point vous la changerez comme bon vous semble) 4) Lancez le script à la main php zibaseGateway.php 5) Si tout va bien, les messages reçus de la Zibase devraient s'afficher à l'écran. A vous de jouer maintenant pour mettre à jour le fichier zibaseMessages.json en conséquence. 6) Arrêtez les script (CTRL+c) et relancez le pour vérifier que la configuration est bien prise en compte correctement. B/ On passe maintenant au niveau de la Home Center 7) Déclarez les différentes variables que vous avez déclaré au point 5) 8) Déclarez les 2 variables Zibase_variable et Zibase_value (cf. fichier de configuration zibaseGateway_config.php) 9) Importez le module virtuel C/ Le test final 10) Relancez le script et vérifiez que les variables de votre HC soient bien mises à jour. Si ce n'est pas le cas, reprenez depuis le point 2) : soit vous n'avez pas initialisé vos variables correctement, soit le fichier json ne reflète pas la réalité... D/ Mode automatique Etant nouveau dans le monde des syno, j'avoue avoir un poil galéré pour que mon script php se lance automatiquement au démarrage du NAS. En gros il faut transformer ce script en deamon. 11) Tout d'abord j'ai modifié la config PHP au niveau de l'interface d'admin du NAS : Panneau de configuration > Services web > Paramètres PHP : cliquez sur personnaliser PHP openbase_dir et rajouter les chemins vers vos repertoires d'installation. Sans cette config vous risquez d'avoir des warnings/erreurs PHP lors de l'exécution. 12) J'ai créé un script SH qui permet de "deamonsier" le script PHP. Il suffit de faire un lien de ce script dans le bon répertoire : ln -s S99zibase.sh /usr/syno/etc/rc.d/S99zibase.sh Et voilà , le script sera lancé ou arrêté automatiquement au startup/shutdown de votre NAS. Bien entendu, ces différents points sont à adapter en fonction de votre config... Maintenant que tout fonctionne, il ne vous reste plus qu'a redémarrer votre NAS et vérifier que les variables HC2 soient bien mises à jour. A vous de créer des modules virtuels pour afficher l'état de vos variables dans vos interfaces... Remerciements Un gros merci à Cmoi20, auteur du projet ZiHome dont je me suis très très fortement inspiré pour mettre en place le script PHP jojo pour sa solution de mise à jour d'une variable via un module virtuel Bejamin Garel pour son sdk PHP pour la Zibase Téléchargements package PHP : zibaseGateway.zip Module virtuel : Zibase.vfib Image pour module virtuel :

@flamalex a fait une modification au code car problèmes à partir du firmware v'.140ou v 4.145. Il l'a baptisée v2, mas comme on était déjà à v5.4, je l'ai rebaptisé v6.0. My_Batteries_v6.2.vfib My_Batteries_v6.1.vfib My_Batteries_v6.0.vfib --------------------------------------------------------------------------------------------------------------- My Batteries Ce virtual device permet de visualiser le niveau des batteries de l'ensembles de vos appareils sur batterie (max 10). Il est TRES largement inspiré du travail initial de Steven http://www.domotique-fibaro.fr/index.php/topic/1710-my-batteries/ Merci également à Moicphil qui m'a énormément aidé pour debugger la partie v4.x Les modifications que j'y ai apportées : modification de l'affichage, avec moment du dernier check automatique incorporation des supers icônes de @couillerot firmware 4.x push si batterie sous un certain niveau Voici la dernière version du VD : My_Batteries_v5.4.vfib Et les codes : MyBatteries.Batteries.lua MyBatteries.MainLoop.lua

Bonsoir, ma 1e contribution, soyez indulgents. Si cela peut servir à quelqu'un. Je veux programmer un réglage du chauffage via des têtes TH et une vanne électrique. Pour cela la HC2 a besoin de savoir si je suis là ou au travail, et si je suis au rdc ou à l'étage. Comme cela je peux régler le chauffage à 16 si je suis au boulot, et quand je rentre, à 19 en bas, 16 à l'étage, et l'inverse quand je dois aller me coucher. Donc j'ai créé cela : local presMaison=true -- présence dans la maison ? local presRDC=true -- présence au rdc ? local hlevSem=0620;local hlevWE=0830 -- heures lever en semaine et le weekend local hcouSem=2300;local hcouWE=2330 -- heures coucher en semaine et le weekend local hdepW=0730;local hretW=1630 -- heures départ et retour travail local day = string.lower(os.date("%A")) local hour = tonumber(os.date("%H")..os.date("%M")) local day="tuesday" -- var pour tester le script local hour=1100 -- idem if (( day == "monday" or day =="friday" ) and ( hour > hdepW and hour < hretW )) then presMaison=false;end if (( day == "tuesday" or day == "wednesday" or day == "thursday" ) and ( hour > hdepW and hour < 1230 )) then presMaison=false; end; -- car ces jours là je termine à 12h30 if ( (presMaison) and ( day == "saturday" or day == "sunday" ) and ( hour > hlevWE and hour < hcouWE ) ) then PresRDC = true; else presRDC = false;end if ( (presMaison) and ( day == "monday" or day == "tuesday" or day == "wednesday" or day == "thursday" or day == "friday" ) and ( hour > hlevSem and hour < hcouSem )) then presRDC = true;end -- bilan if presMaison then fibaro:debug("presMaison=oui") else fibaro:debug("presMaison=non") end if presRDC then fibaro:debug("presRDC=ok"); else fibaro:debug("presRDC=non"); end On peut aussi procéder ainsi, mais j'ai trouvé la 1e méthode plus simple à programmer pour ma gestion des horaires plus complexe local weekjob = {"monday","tuesday","wednesday","thursday","friday"} local weekend = {"saturday","sunday"} for k,v in pairs(weekJob) do if ( v == day ) then presMaison=false; end

ATTENTION Ce VD peux corrompre la DB de votre HC2, à n'utiliser qu'en connaissance de cause. Je ne puis être tenu pour responsable en cas de problème. Faire un backup de la DB avant de commencer à l'utiliser. Si vous cachez un device , notez bien son numéro, car il ne sera plus visible, et donc "impossible" à reconfigurer, ... (en tout cas si vous cachez le Main device et ses child devices) Merci : Merci à Steven pour son code "Double click pour confirmer" Merci à notre graphiste national (Couillerot) pour ses icônes Objectif : Ce VD permet de modifier une propriété d'un device. Je l'ai déjà utilisé dans les situations suivantes : dead : marquer manuellement un device sur pile comme mort, quand il n'a plus de pile ... disabled : afficher un "sous-device" qui était caché par erreur / cacher des child devices inutilisés (exple dans les binary sensors). "offset" : modifier l'offset d'une sonde de température (plutôt que d'utiliser le slider) Utilisation : avec l'URL suivante "<IP>/api/devices/" (suivi du # du device) vous pouvez voir dans votre browser les propriétés et leur nom précis (dépend du type de device) {"id":649,"name":"Tmp_Tisun","roomID":12,"type":"com.fibaro.temperatureSensor","baseType":"com.fibaro.multilevelSensor","enabled":true,"visible":true,"isPlugin":false,"parentId":634,"remoteGatewayId":0,"interfaces":["zwave"],"properties":{"parameters":[{"id":1,"lastReportedValue":0,"lastSetValue":0,"size":2,"value":0},{"id":2,"lastReportedValue":0,"lastSetValue":0,"size":2,"value":0},{"id":3,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":4,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":5,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":6,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":7,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":8,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":9,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":10,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":11,"lastReportedValue":200,"lastSetValue":200,"size":1,"value":200},{"id":12,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":13,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":14,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0}],"zwaveCompany":"Fibargroup","zwaveInfo":"3,3,52","zwaveVersion":"2.1","pollingTimeSec":0,"configured":"true","dead":"false","deviceControlType":"0","deviceIcon":"30","emailNotificationID":"0","emailNotificationType":"0","endPointId":"3","liliOffCommand":"","liliOnCommand":"","log":"","logTemp":"","manufacturer":"","markAsDead":"true","model":"","nodeId":"79","offset":"10.00","parametersTemplate":"85","productInfo":"1,15,5,1,16,2,2,1","pushNotificationID":"0","pushNotificationType":"0","remoteGatewayId":"0","saveLogs":"false","showFireAlarm":"false","showFreezeAlarm":"false","smsNotificationID":"0","smsNotificationType":"0","unit":"C","useTemplate":"true","userDescription":"","value":"70.87"},"actions":{"reconfigure":0},"created":1444553629,"modified":1444553629,"sortOrder":113} les propriétés concernées se trouvent dans : "properties":{...} {"parameters":[{"id":1,"lastReportedValue":0,"lastSetValue":0,"size":2,"value":0},{"id":2,"lastReportedValue":0,"lastSetValue":0,"size":2,"value":0},{"id":3,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":4,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":5,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":6,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":7,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":8,"lastReportedValue":255,"lastSetValue":255,"size":1,"value":255},{"id":9,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":10,"lastReportedValue":1,"lastSetValue":1,"size":1,"value":1},{"id":11,"lastReportedValue":200,"lastSetValue":200,"size":1,"value":200},{"id":12,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":13,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0},{"id":14,"lastReportedValue":0,"lastSetValue":0,"size":1,"value":0}],"zwaveCompany":"Fibargroup","zwaveInfo":"3,3,52","zwaveVersion":"2.1","pollingTimeSec":0,"configured":"true","dead":"false","deviceControlType":"0","deviceIcon":"30","emailNotificationID":"0","emailNotificationType":"0","endPointId":"3","liliOffCommand":"","liliOnCommand":"","log":"","logTemp":"","manufacturer":"","markAsDead":"true","model":"","nodeId":"79","offset":"10.00","parametersTemplate":"85","productInfo":"1,15,5,1,16,2,2,1","pushNotificationID":"0","pushNotificationType":"0","remoteGatewayId":"0","saveLogs":"false","showFireAlarm":"false","showFreezeAlarm":"false","smsNotificationID":"0","smsNotificationType":"0","unit":"C","useTemplate":"true","userDescription":"","value":"70.87"}ensuite adapter suivant vos désirs les lignes 4, 10 et 11 du VD local Property = "offset" -- vleurs possibles : cfr json local NewPropValue = "0.00" -- la valsur doit être entre " local deviceID = 649 Lorsque vous appuyez une première fois sur le bouton "Update device property", il vous affiche le device, la propriété à modifier, sa valeur actuelle, et la future valeur Appuyez une deuxième fois sur le bouton (dans les 5 sec) pour effectuer la modification Si le nom de la propriété introduit en ligne 4 n'existe pas, il affiche un message d'erreur. Cette v2 est compatible avec le firmware v4.x DeviceProperties_v2.0.vfib DeviceProperties_v1.0.vfib DeviceProperties._v2.0.vfib

Hello, Voici un petit module virtuel qui va interroger la HC2 et qui permet quand on est pas à la maison, de garder un oeil sur la mémoire utilisée par notre HC2, la charge CPU et l'espace disponible pour le système respectivement le recovery. Voici mon icône, si cela peut vous intéresser...: Voici le module virtuel : HC2_Diagnostics.vfib Pour que ça marche, importer le Virtual Device et c'est prêt. Bonne découverte. @+ Razowski

Bonjour la communauté, Je vous propose aujourd'hui mon module virtuel "SmartVMC". Ce dernier me permet de piloter de manière automatique ma VMC en fonction de la qualité de l'air de ma maison : On allume la VMC si le taux moyen d'humidité relative est supérieur à 60% OU si la concentration moyenne de CO2 est supérieure à 1000 ppm. Le traitement s'arrêtera si le taux moyen d'humidité relative est inférieur ou égal à 55% ET si la concentration moyenne de CO2 est inférieure ou égale à 900 ppm. Le but étant de ne pas allumer/éteindre la VMC dès que l'on atteint la limite de 60% ou de 1000 ppm. Les données sur la qualité de l'air (humidité relative et concentration de CO2) sont extraites de ma Netatmo par le biais du plugin idoine disponible dans la V4. Ma configuration matérielle est la suivante : VMC simple flux, hygroréglable, Aldès, MicroWatt. Home Center 2 en version v4.033. WallPlug Fibaro pour piloter la VMC. Station Netatmo avec modules additionnels. Le module virtuel se présente de la sorte : Un visuel des moyennes d'humidité relative et de concentration de CO2. Un bouton permettant d'analyser à l'instant "t" l'air de la maison. Un visuel de l'état actuel de la VMC. Un bouton de marche forcée de la VMC. Un bouton d'arrêt complet de la VMC. Un bouton pour basculer la VMC en mode automatique. La date de la dernière analyse de l'air. Les 4 états différents de la VMC sont les suivants : Marche Forcée Arrêt Complet Auto (En cours...) Auto (Pause) Il est nécessaire de créer 2 variables globales : Une première variable globale "VMC" est utilisée afin de savoir si la VMC est : en marche automatique, en pause, en marche forcée ou arrêtée (Auto, Pause, Forcée, Arrêtée). Une seconde variable globale "RecyclAir" est utilisée afin de savoir si la VMC est déjà en train d'assainir l'air, par le biais de ce traitement (Oui, Non). J'ai commenté le code afin d'en faciliter la compréhension. NB : Il peut être envisageable pour les personnes possédant une VMC à 2 vitesses que le mode "Auto (En cours...)" corresponde à la grande vitesse et que le mode "Auto (Pause)" corresponde à la petite vitesse. Voici les icônes (2 variantes) : Orange => Marche Forcée Rouge => Arrêt Complet Vert => Auto (En cours...) Bleu => Auto (Pause) Les originaux qui m'ont servi de base sont ici : http://www.domotique...zibase/?p=25155 Vous trouverez également de magnifiques icônes pour la Netatmo ici (merci Stef). ChangeLog => v1.0 : Création du module. v1.1 : Ajout du push lors du passage "En cours" <=> "Pause". Modification des conditions du passage au mode "Auto". Ajout d'un contrôle sur l'état du plugin Netatmo pour mode "Auto". SmartVMC.vfib

Je continue mon apprentissage de la HC2 et j'investigue les triggers (en français gâchette ou détente). Dans notre domaine c'est donc un évènement qui, lorsqu'il intervient, va déclencher une action. J'avais fait un petit script qui affiche les températures min et max à l'intérieur de la maison et à l'extérieur. http://www.domotique-fibaro.fr/index.php/topic/3438-temp%C3%A9rature-min-max/ Il est en fait très peu efficace du point de vue ressources machines puisqu'il est basé sur une boucle infinie qui, à interval régulier, va chercher les températures, même si elles n'ont pas changé. Je l'ai donc modifié en utilisant les triggers, et c'est maintenant un changement de température qui actionne la scène pour afficher les nouvelles valeurs. Dans l'entête sous "%% properties" il faut indiquer les IDs des devices concernés et exit le "while true do". --[[ %% autostart %% properties 35 value 42 value %% globals --]] Comme la scène ne tourne pas en continue, il faut enregistrer les valeurs min/max dans des variables globales. Vous devez créer GVTempE et GVTempI. également json.encode ne fonctionne pas dans les scènes (suis en 3.600) je le fais moi même. Voilà le code complet: --[[ %% autostart %% properties 35 value 42 value %% globals --]] local temp; local TempExtMin; local TempExtMax; local TempSalonMin; local TempSalonMax; local str; local id = {}; id.tempext = 35; id.tempint = 42; id.display = 83; -- GVTemp format 099.99/-99.99 GVTempE = fibaro:getGlobal("GVTempE"); GVTempI = fibaro:getGlobal("GVTempI"); -- fibaro:debug(GVTempE); -- fibaro:debug(GVTempI); TempExtMin = tonumber(string.sub(GVTempE,1,6)); TempExtMax = tonumber(string.sub(GVTempE,8,13)); TempSalonMin = tonumber(string.sub(GVTempI,1,6)); TempSalonMax = tonumber(string.sub(GVTempI,8,13)); -- Température extérieur temp = fibaro:getValue(id.tempext,"value"); -- fibaro:debug(temp); if (tonumber(temp) < TempExtMin) then TempExtMin = tonumber(temp); end if (tonumber(temp) > TempExtMax) then TempExtMax = tonumber(temp); end str = string.format("%3.1f",TempExtMin).." / "..string.format("%3.1f",TempExtMax); fibaro:call(id.display, "setProperty", "ui.Label1.value", str.." °C"); fibaro:call(id.display, "setProperty", "ui.Label7.value", temp.." °C"); str = string.format("%06.2f",TempExtMin).."/"..string.format("%06.2f",TempExtMax); -- fibaro:debug(str); fibaro:setGlobal("GVTempE",str); -- temérature intérieur temp = fibaro:getValue(id.tempint,"value"); -- fibaro:debug(temp); if (tonumber(temp) < TempSalonMin) then TempSalonMin = tonumber(temp); end if (tonumber(temp) > TempSalonMax) then TempSalonMax = tonumber(temp); end str = string.format("%3.1f",TempSalonMin).." / "..string.format("%3.1f",TempSalonMax); fibaro:call(id.display, "setProperty", "ui.Label11.value", str.." °C"); fibaro:call(id.display, "setProperty", "ui.Label13.value", temp.." °C"); str = string.format("%06.2f",TempSalonMin).."/"..string.format("%06.2f",TempSalonMax); -- fibaro:debug(str); fibaro:setGlobal("GVTempI",str); le code du bouton reset du VD est aussi changé. Il remet les variables globales à 099.99/-99.99 Changer le numéro de la scène (23) et du VD (83) ou mettre un getSelfId. fibaro:killScenes(23); fibaro:setGlobal("GVTempE","099.99/-99.99"); fibaro:setGlobal("GVTempI","099.99/-99.99"); fibaro:sleep(1000); fibaro:startScene(23); local Date = os.date("%d/%m/%y %H:%M"); fibaro:call(83, "setProperty", "ui.Label5.value",Date); Depuis que j'ai une HC2, je regarde avec plus d'attention les script LUA et je vois énormément de boucles infinies quand des triggers seraient beaucoup plus efficaces. Un petit clien d'oeil à Jojo qui semble aimer les VD. Il faut lire la petite phrase concernant la "Boucle principale". Dans ta version des températures, tu actives ce script toutes les secondes, alors que les températures changent en gros toutes les 20 à 30 minutes. (mes fgk sont réglés tous les 0.5°) Je pense également au tuto de sebcbien sur les dead nodes. Je n'ai pas fait le test, mais il semble qu'il est possible de faire un script avec sous %% properties des choses comme. 35 dead 42 dead 69 dead etc .... Et de faire une scène qui ne s'actionnera que s'il y a un dead node. Ces considérations me sont venues en lisant vos posts sur la température de vos HC2. Je me demande s'il n'y a pas trop de boucles qui tournent pour rien, ou pas grand chose, et surchauffent le CPU. PS: En me relisant, j'ai peur de passer pour un donneur de leçons, ce n'est certainement pas le cas, mais juste des pistes de réflexions.

Compatible uniquement 4.x (pour la 3.60 ... c'est ICI ... merci DMK2424) L'idée est de générer automatiquement le tableau d'ID utilisé dans GEA ou autres scripts. Ainsi, il sera possibile à chaque mise à jour de votre HC2, de simplement relancer le générateur, copier le résultat dans GEA et vos ID seront donc remis à jour. Voici le tableau dont je parle : local id = { --inconnu LUA_SNIPPETS = 141, --Garage OREGON = 128, SURPRESSEUR = 118, CAMERA = 123, PORTE_GARAGE = 238, DETECTEUR_PORTE = 112, PORTE_GARAGE_GARAGE = 64, --Jardin TEMPERATURE = 69, SEISMOMETRE = 71, HUMIDITE = 261, DETECTEUR = 68, NETATMO = 137, PLUVIOMETRE = 262, LUMINOSITE = 70, LAMPE_OUEST = 234, PLUIE = 139, COIN_REPAS = 14, PRESSION_ATMOSPHERIQ = 258, TERRASSE = 160, METEOALERTE = 150, ARROSAGE = 158, NETATMO_EXTERIEUR = 260, --Local Technique LIVEBOX = 251, IPX800_RELAIS = 106, PORTE_LOCAL = 56, VMC_DOUBLE_FLUX = 114, LAVE_LINGE = 120, PLAFONNIER = 54, PASSERELLE_NETATMO = 135, PASSERELLE_ZIBASE = 126, --Entrée CAMERA_ENTREE = 129, DETECTEUR_ENTREE = 5, LUMINOSITE_ENTREE = 7, SEISMOMETRE_ENTREE = 8, PLAFONNIER_ENTREE = 10, PORTE_ENTREE = 58, TEMPERATURE_ENTREE = 6, --Cuisine SIRENE = 200, BRITA__FILTRE_ = 131, CUISINE = 237, CAPTEUR_FUMEE = 46, ALARME_FUMEE = 48, FRIGO = 52, TEMPERATURE_CUISINE = 47, LAVE_VAISSELLE = 50, TABLETTE = 176, --Chambre parentale SECHE_SERVIETTE = 60, --Salon CHAUFFAGE = 104, HUMIDITE_SALON = 257, CO2 = 256, NETATMO_SALON = 255, SONOMETRE = 259, POELE = 34, OREGON_SALON = 127, TV = 39, HIFI = 42, BLUE_RAY = 41, OPENKAROTZ = 133, ROMBA = 43, LUMIERE_SALON = 107, PRISE_LIBRE = 44, BRISE_SOLEIL = 105, WI = 40, KAROTZ = 134, NETATMO_SALON_SALON = 136, --Chambres PLAFONNIER_KENDRA = 23, PLAFONNIER_NORA = 18, TEMPERATURE_CHAMBRES = 147, FENETRE_NORA = 143, FENETRE_KENDRA = 145, OREGON_CHAMBRES = 138, FENETRE_NOLAN = 149, PLAFONNIER_NOLAN = 21, --Couloir PORTE_TERRASSE = 153, APLIQUE_ESCALIER = 25, TEMPERATURE_AU_SOL = 155, SPOTS = 230, LEDS_ESCALIER = 27, --Divers ANDROID_FILES = 162, IMPERIHOME = 208, TYPE_DE_JOURNEE = 110, EVENEMENTS = 173, NETATMO_DIVERS = 253, CLOCK_SYNC = 252, UPDATE_NOTIFIER_1_0_6 = 206, AGENDA = 178, MY_BATTERIES = 130, VACANCES_SCOLAIRES = 151, } Ce générateur ce base sur les noms des modules et des pièces que vous avez déclarer. Il va donc parcourir tous vos modules, prendre leur nom et le transformer (majuscule, suppression caractères spéciaux, ...). Si le nom existe deux fois, il va le suffixer du nom de la pièces (ex : DETECTEUR_GARAGE). Donc, si comme moi, vous ne changer pas régulièrement le nom de vos modules, ce générateur va vous permettre de gagner quelques précieuses minutes. Usage ... simple, copier le code ci-dessous et lancer le script avec le bouton "start". Une fois le script terminé, il va vous affiché le tableau dans la fenêtre de debug, il ne vous suffira plus que de le copier dans vos scripts. Il est possible de spécifier les ID ou type de module que vous ne voulez pas prendre en compte. Vous pouvez aussi préciser si vous souhaiter prendre en compte les modules caché ou mort. Voici donc le script dans sa globalité : --[[ %% properties %% globals --]] local hidden = false --- true pour exporter les devices cachés local dead = false -- true pour exporter les devices morts local excludeType = {"com.fibaro.zwaveDevice", "weather", "HC_user", "iOS_device", "com.fibaro.voipUser"} local excludeID = {} local devicesJSon = api.get("/devices") local devices = {} local names = {} local rooms = {} function addName(name, roomname) if (type(names[name]) == "nil") then names[name] = true return name else return addName(name.."_"..roomname, roomname) end end function getRooms() local roomsJSon = api.get("/rooms") rooms[0] = "inconnu" for k, v in ipairs(roomsJSon) do rooms[v.id] = v.name end end function rename(name, roomname) local name = name:upper():gsub("[éêèà«]", "E"):gsub("EE", "E"):gsub("[à»à¼ù]", "U"):gsub("UU", "U"):gsub("[à âà¤]", "A"):gsub("AA", "A"):gsub("[à¶ô]", "O"):gsub("OO", "O"):gsub("[îà¯]", "I"):gsub("II", "I"):gsub("%W", "_") local roomname = roomname:upper():gsub("[éêèà«]", "E"):gsub("EE", "E"):gsub("[à»à¼ù]", "U"):gsub("UU", "U"):gsub("[à âà¤]", "A"):gsub("AA", "A"):gsub("[à¶ô]", "O"):gsub("OO", "O"):gsub("[îà¯]", "I"):gsub("II", "I"):gsub("%W", "_") return addName(name, roomname) end getRooms() for k, v in pairs(devicesJSon) do local doit = (hidden or v.visible) and (dead or not v.dead) if (doit) then for h, w in pairs(excludeType) do if (v.type == w) then doit = false end end if (doit) then for h, w in pairs(excludeID) do if (v.id == w) then doit = false end end end end if (doit) then table.insert(devices, v) end end table.sort(devices, function(a, return a.roomID<b.roomID end) local result = "<BR><BR>-- IDs générés le : " .. os.date("%d/%m/%y à %X") local room = -1 local lastinfo = ""; result = result .. "<BR><BR>local id = {" for k, v in ipairs(devices) do if (room ~= v.roomID) then room = v.roomID result = result .. "<BR>--"..rooms[v.roomID].."<BR>" end lastinfo = rename(v.name, rooms[v.roomID]) result = result .. lastinfo .. " = " .. v.id .. ", " end result = result .. "<BR>}" result = result .. "<BR>" result = result .. "<BR>-- usage :" result = result .. "<BR>-- fibaro:getValue(id[\""..lastinfo .."\"], \"value\")" result = result .. "<BR>-- GEA.add(id[\""..lastinfo .."\"], 30, \"\")" print(result) Il ne vous restera plus qu'à utiliser les ID ainsi fibaro:getValue(id["DETECTEUR_GARAGE"], "value") GEA.add(id["DETECTEUR_GARAGE"], -1, "La porte du garage est entrain de s'ouvrir") ATTENTION : Les déclencheurs doivent et devront toujours être changé par vos soins ATTENTION 2 : Si vous ne comprenez pas l'usage de ce script, c'est sà»rement parce que vous n'en avez pas l'utilité Icone by @Did (Merci)

Bon, ça casse pas une patte à un canard, mais pour apprendre LUA mieux vaut commencer simple. L'objet de cette petite chose est d'avoir un visu des températures min/max. Quand vous achetez un thermomètre à deux balles il a des options de mini/maxi, mais pas chez Fibaro. Il y a donc une scène qui tourne en continue et retient les min et max. L'affichage ce fait dans un device virtuel. Le bouton reset tue la scène et la redémarre. Il vous faudra changer les "id" de vos thermomètres et du virtual device. Rien ne vous empêche de rajouter les thermomètres de la chambre du petit dernier, du cellier de vos bonnes bouteilles (moi, c'est Saint Emilion - Merci ). Au printemps je mettrais la piscine. --[[ %% autostart %% properties %% globals --]] local temp; local TempExtMin = 100; local TempExtMax = -100; local TempSalonMin = 100; local TempSalonMax = -100; local temin = ""; local temax = ""; local tsmin = ""; local tsmax = ""; local id = {}; id.tempext = 35; id.tempint = 42; id.display = 74; while true do -- Température extérieur temp = fibaro:getValue(id.tempext,"value"); if (tonumber(temp) < TempExtMin) then TempExtMin = tonumber(temp); temin = string.format("%2.1f",TempExtMin); end if (tonumber(temp) > TempExtMax) then TempExtMax = tonumber(temp); temax = string.format("%2.1f",TempExtMax); end fibaro:call(id.display, "setProperty", "ui.Label1.value", temin.." / "..temax.." °C"); fibaro:call(id.display, "setProperty", "ui.Label7.value", temp.." °C"); -- temérature intérieur temp = fibaro:getValue(id.tempint,"value"); if (tonumber(temp) < TempSalonMin) then TempSalonMin = tonumber(temp); tsmin = string.format("%2.1f",TempSalonMin); end if (tonumber(temp) > TempSalonMax) then TempSalonMax = tonumber(temp); tsmax = string.format("%2.1f",TempSalonMax); end fibaro:call(id.display, "setProperty", "ui.Label11.value", tsmin.." / "..tsmax.." °C"); fibaro:call(id.display, "setProperty", "ui.Label13.value", temp.."°C"); fibaro:sleep(3*60*1000); end Temp_minmax.vfib PS: Cet outil est vraiment très pratique sur smartphone.

J'en ai marre de faire crever mes plantes une à une, tout ça parce que j’oublie de les arroser ! Comme j’ai pas envie de foutre entre 50 et 80 € par pot pour un koubachi ou un parrot flower power il me faut donc trouver une autre solution (autre que la plante en plastique !). Le besoin : J’aimerai être rappelé, à intervalle régulier, d’arroser les plantes. Bon pourquoi ne pas mettre tout simplement un rappel dans mon agenda alors ? Et bien parce que : 1) j’ai pas envie de blinder mon agenda avec des « arroser les plantes » toutes les semaines 2) je veux être rappelé tant que je n’ai pas arrosé les plantes et pas une seule fois. 3) je ne peux pas « acquitter » un rappel de mon agenda (justement pour arrêter d'être rappelé quand j'ai fait ce que je devais faire). 3) j’ai une box a 600 boules alors autant la faire bosser La solution envisagée : Pour en arriver a mes fins je suis passé par un petit module virtuel dont le principe est simple. 2 boutons : un qui permet d’acquitter le fait que j’ai arrosé les plantes et qui du coup calcul la prochaine échéance de l’arrosage. Un autre qui permet de me notifier sur mon téléphone via prowl, qu’il est temps d’arroser les plantes. C’est GEA (merci encore Steven) qui me sert de déclencheur pour la notification (j’avais pas envie de passer par le main loop du module ou par une autre scène pour faire ça alors que j’ai le GEA …) Installation : A/ Les variables globales : J’utilise 2 variables globales qui me permettent de stocker le moment ou j’ai arrosé les plantes et la prochaine échéance. Il s’agit respectivement des variables Arrose_Le et Date_Arrosage. B/ La notification : J’utilise prowl pour recevoir la notification par push sur mon téléphone. Prowl permettant d’envoyer des notification par le biais d’un email, j’ai donc créé un utilisateur dont l’adresse email est lié a ma Prowl API key. Il me suffit donc de notifier cet utilisateur par mail pour recevoir le push sur mon téléphone. Je suis passé par la car c’est super rapide a mettre en place, cette technique peut être utilisée aussi sur HCL et surtout parce que la notification via l’appli Fibaro me gonfle (ca marche …. ou pas, l’appli est longue a charger en roaming, etc.) C/ Le module virtuel : Je vous joint l’export de mon module. Sur le premier bouton, vous devez modifier la variable locale num_day comme bon vous semble. Il s’agit de la période entre deux arrosages. Dans mon cas je veux arroser mes plantes 1 fois par semaine (d’ou la valeur de 7). A chaque fois que ce bouton est déclenché, la date du prochain arrosage est calculée, sauvegardée dans la variable globale et les labels sont mis a jour pour afficher la date du dernier et du prochain arrosage. num_day = 7 arrose_le = os.time() prochain_arrosage = arrose_le + (num_day*24*60*60) selfId = fibaro:getSelfId() -- Sauvegarde de la dagte d'arrosage fibaro:setGlobal('Arrose_Le', arrose_le) -- Calcul de la prochaine date d'arrosage fibaro:setGlobal('Date_Arrosage',prochain_arrosage) -- Mise à jour des labels fibaro:call(selfId,"setProperty","ui.Label1.value", os.date("%d/%m/%Y",arrose_le)) fibaro:call(selfId,"setProperty","ui.Label2.value", os.date("%d/%m/%Y",prochain_arrosage)) Le second bouton permet d’envoyer la notification et de modifier l’icône du module afin d’attirer l’attention sur le fait qu’une action est en attente. Ici aussi il faudra modifier les identifiants correspondant a l'utilisateur et au message de notification (ou adaptez le code lua avec le mécanisme de notification qui vous convient). fibaro:call(88, "sendDefinedEmailNotification", "6"); Arrosage_Plantes.vfib D/ GEA : Pour GEA j’ai ajouté la ligne suivante : GEA.add({"Global-", "Date_Arrosage", os.time()}, 20*60, "", {{"VirtualDevice", id["VD_ARROSAGE_PLANTE"], "2"},{"Time", "19:00", "20:00"}}) Ca me permet d’être notifié toutes les 20min, entre 19h et 20h dès lors que la prochaine échéance d’arrosage est échue et que je n’ai toujours pas appuyé sur le bouton de mon module. Et voilà ,cette solution répond a mes attentes, et à la limite peut être déclinée pour d’autres besoins de rappels (sortir les poubelles, etc) …

Tout est dans le titre. Il s'agit d'un simple device virtuel permettant de rebooter ou arreter un serveur synology. L'idée est inspirée de la solution de Labomatik pour QNAP La solution est tres tres largement inspirée du module virtuel de lazer permettant de piloter la surveillance station ... effectivement, je n'ai pas inventé grand chose. Toute la mécanique d'authentification est issue du dev de Lazer (que je remercie au passage). Les fonctions que l'on exploite ici ne sont pas officiellement mise à dispo par l'API Synology, mais un peu de reverse engeneering permet de retrouver ce qui est fait par l'interface web du synology. La configuration est tres simple : - Paramétrer l'adresse IP et le port du device virtuel avec l'adresse ip et le port du synology ==> Il doit s'agir d'un port HTTP. La solution ne supporte pas l'HTTPS. Dans chaque bouton, remplacer les variables par un login / password existant sur votre synology. Attention : Il doit s'agir d'un utilisateur ayant des droits admin Ajouté au virtuel device de Lazer, nous voilà aussi bien équipé que les utilisateurs QNAP. Plus de jaloux! Une remarque pour ceux qui souhaitent égallement redémarrer leur synology via la HC2 : Tous les synology ne supportent pas le Wake On Lan. Plus d'info : https://www.synology.com/fr-fr/knowledgebase/faq/437 Synology.vfib Icone pour le device virtuel :

Bonjour à tous, Voici un petit tutoriel sur comment piloter son nas QNAP avec la HC2. Je ne suis pas dévelopeur LUA sous HC2 donc il y a surement moyen d'optimiser tout ça (notamment les variables login/pass). Les 3 exemples sont basés sur mes besoins actuels, j'arrête mon nas le soir avec l'armement de mon alarme et rallume avec le désarmement de mon alarme grace au WOL (plugin fibaro). Avec les nouvelles génération de nas X51, il est possible de lancer la commande sleep et non shutdown, ce qui permet au NAS d'être réveillé en 5 secondes (RAM sauvegardée) Configuration QNAP Vous devez autoriser la connexion sans SSL (la HC2 ne supporte pas le ssl) HC2 voici un exemple de quelques fonctions que j'ai utilisé pour commander mon NAS - arrêter le nas proprement - démarrer l'enregistrement des caméras de la station de surveillance - arrêter l'enregistrement des caméras de la station de surveillance si vous voulez obtenir l'API complet des fonctions des NAS qnap, envoyez un petit mail à developer@qnap.com (anglais) --> Je ne suis pas dévelopeur et/ou je ne veux pas comprendre Voici alors le virtuel device déjà prêt avec les 3 fonctions vous devez configurer l'IP et le port dans la configuration du virtuel device et adapter le login/pass dans le code des 3 boutons (remplacez LOGIN_NAS et PASSWORD_NAS) QNAP.vfib.zip --> Je suis dévelopeur et/ou je veux comprendre démarrer l'enregistrement: local ip_module = fibaro:get(fibaro:getSelfId(), "IPAddress") local port = fibaro:get(fibaro:getSelfId(), "TCPPort") surveillance_Station = Net.FHttp(ip_module, port) surveillance_Station:setBasicAuthentication("LOGIN_NAS", "PASSWORD_NAS") response = surveillance_Station:GET("/cgi-bin/mrec.cgi?ch=1&act=1") if (string.find(response, "OK")) then fibaro:log("Starting Recording") else fibaro:log("ERROR") end arrêter l'enregistrement local ip_module = fibaro:get(fibaro:getSelfId(), "IPAddress") local port = fibaro:get(fibaro:getSelfId(), "TCPPort") surveillance_Station = Net.FHttp(ip_module, port) surveillance_Station:setBasicAuthentication("LOGIN_NAS", "PASSWORD_NAS") response = surveillance_Station:GET("/cgi-bin/mrec.cgi?ch=1&act=0") if (string.find(response, "OK")) then fibaro:log("Stop Recording") else fibaro:log("ERROR") end la partie plus complexe qui nécessite un parseur XML, l'arret du NAS if (not QNAP) then QNAP = {} QNAP.qnap_ip = fibaro:get(fibaro:getSelfId(), "IPAddress"); QNAP.port = fibaro:get(fibaro:getSelfId(), "TCPPort"); QNAP.globalvariable = "" -- -------------------------------------------------------------------------------------------------------------- -- Obtient le XML et le retourne sous forme de table LUA -- -------------------------------------------------------------------------------------------------------------- QNAP.getTokenFromXml = function() local QNAP2URL = Net.FHttp(QNAP.qnap_ip,QNAP.port); response = QNAP2URL:GET("/cgi-bin/authLogin.cgi?user=LOGIN_NAS&plain_pwd=PASSWORD_NAS&remme=1"); xmlTable = QNAP.iif(response ~= nil, QNAP.newParser().ParseXmlText(response), ""); if (xmlTable.QDocRoot ~= nil) then qsidstr = xmlTable.QDocRoot.authSid:value(); if (string.len(qsidstr)>0) then fibaro:debug("Qtoken founded"); qsidstr = qsidstr:gsub("[".."<![CDATA[".."]", ''); qsidstr = qsidstr:gsub("[".."]".."]", ''); qsidstr = qsidstr:gsub("["..">".."]", ''); fibaro:debug(qsidstr); response = QNAP2URL:GET("/cgi-bin/sys/sysRequest.cgi?subfunc=power_mgmt&count=0.1234&sid="..qsidstr.."&apply=shutdown"); if (string.find(response, "OK")) then fibaro:log("Power Off Server") else fibaro:log("ERROR") end end end end -- ------------------------------------------------------------------------------------------------------------- -- Teste la condition et retourne la valeur true ou false -- ------------------------------------------------------------------------------------------------------------- QNAP.iif = function(condition, iftrue, iffalse) if (condition) then return iftrue end return iffalse end -- ------------------------------------------------------------------------------------------------------------- -- Ceci est une version modifiée par Steven de Corona-XML-Module par Jonathan Beebe qui a son tour -- est basée sur Alexander Makeev's Lua-only XML parser . -- see https://github.com/Cluain/Lua-Simple-XML-Parser -- ------------------------------------------------------------------------------------------------------------- QNAP.newParser = function() parseXml = {} parseXml.FromXmlString = function(value) value = string.gsub(value, "([%x]+)%;", function(h) return string.char(tonumber(h, 16)) end); value = string.gsub(value, "([0-9]+)%;", function(h) return string.char(tonumber(h, 10)) end); value = string.gsub(value, "'", "'"); value = string.gsub(value, ">", ">"); value = string.gsub(value, "<", "<"); value = string.gsub(value, "&", "&"); return value; end parseXml.ParseArgs = function(node, s) string.gsub(s, "(%w+)=([\"'])(.-)%2", function(w, _, a) node:addProperty(w, parseXml.FromXmlString(a)) end) end parseXml.ParseXmlText = function(xmlText) local stack = {} local top = parseXml.newNode() table.insert(stack, top) local ni, c, label, xarg, empty local i, j = 1, 1 while true do ni, j, c, label, xarg, empty = string.find(xmlText, "<(%/?)([%w_:]+)(.-)(%/?)>", i) if not ni then break end local text = string.sub(xmlText, i, ni - 1); if not string.find(text, "^%s*$") then local lVal = (top:value() or "") .. parseXml.FromXmlString(text) stack[#stack]:setValue(lVal) end if empty == "/" then -- empty element tag local lNode = parseXml.newNode(label) parseXml.ParseArgs(lNode, xarg) top:addChild(lNode) elseif c == "" then -- start tag local lNode = parseXml.newNode(label) parseXml.ParseArgs(lNode, xarg) table.insert(stack, lNode) top = lNode else -- end tag local toclose = table.remove(stack) -- remove top top = stack[#stack] if #stack < 1 then error("XmlParser: nothing to close with " .. label) end if toclose:name() ~= label then error("XmlParser: trying to close " .. toclose.name .. " with " .. label) end top:addChild(toclose) end i = j + 1 end local text = string.sub(xmlText, i); if #stack > 1 then error("XmlParser: unclosed " .. stack[#stack]:name()) end return top end parseXml.newNode = function(name) local node = {} node.___value = nil node.___name = name node.___children = {} node.___props = {} function node:value() return self.___value end function node:setValue(val) self.___value = val end function node:name() return self.___name end function node:setName(name) self.___name = name end function node:children() return self.___children end function node:numChildren() return #self.___children end function node:addChild(child) if self[child:name()] ~= nil then if type(self[child:name()].name) == "function" then local tempTable = {} table.insert(tempTable, self[child:name()]) self[child:name()] = tempTable end table.insert(self[child:name()], child) else self[child:name()] = child end table.insert(self.___children, child) end function node:properties() return self.___props end function node:numProperties() return #self.___props end function node:addProperty(name, value) local lName = "@" .. name if self[lName] ~= nil then if type(self[lName]) == "string" then local tempTable = {} table.insert(tempTable, self[lName]) self[lName] = tempTable end table.insert(self[lName], value) else self[lName] = value end table.insert(self.___props, { name = name, value = self[name] }) end return node end return parseXml; end end QNAP.getTokenFromXml();

Bonjour Pour mon premier tuto, je vous propose un Module Virtuel pour interfacer la Livebox d'Orange et je vais vous détailler la mise en Å“uvre de l'intégration avec la HC2. Le module rassemble les informations importantes sur l'état des interfaces, le débit, les statistiques et les différents compteurs d'erreurs. Il permet aussi d'exécuter des commandes simples comme l'activation du Wifi ou le redémarrage de la Livebox. Prérequis Une Livebox 2 (Sagem) DSL note: pas pu tester la fibre. J'aimerais bien mais dans moin coin c'est pas avant 2022 ). Une HC2 (code lua testé avec v3.600 et v4.031) Installation Télécharger et ajouter le VD (lien en bas de post) Sur la page de configuration du module, saisir l'adresse ip et le port (80) de la Livebox Ensuite, il faut paramtètrer le VD, editez le code en debut de page (pour chaque bouttons): -- Nom d'utilisateur et mot de passe de la livebox local USER ="admin" local PASSWORD = "admin" Le VD retourne trois états possibles: Inconnu, OK et Not OK. Editez les variables pour adapter l'ID des icones: -- ID des icônes icon_ok = 1004 icon_nok = 1005 icon_unknown = 1006 Par défault, l'execution du module toutes les 5 minutes est confié à la mainloop du VD qui simule un appui sur le bouton Rafraichir. Simple, mais pour plus de fléxibilité et surtout de plus stabilté je recommande d'utiliser l'excellent GEA avec la ligne ci-dessous (à adapter). Dans ce cas, noubliez pas de supprimer le code dans le mainloop du VD. -- Mise à jour état connexion Internet GEA.add(true , 5*60, "",{{"VirtualDevice", id["VD_LIVEBOX"], "1"},{"VirtualDevice", id["VD_LIVEBOX"], "7"},{"Repeat"}}) Le VD n'utilise pas de Variable Globale car je n'ai pas de scénario qui necessite un retour sur l'état de la connexion internet mais c'est juste une ligne de code à ajouter: fibaro:setGlobal('test', Livebox.WANStatus.LinkState) Comment ca marche ? c'est la section pour les geeks. Je partage ici le resultat de mes bidouilles (et saut d'humeur) à propos de l'API Livebox Fonctionnement de l'API Orange/Sagem: En regardant d'un peu plus près les paquets échangés dans une session d'admin avec la livebox on peut voir des réponses de POST en json . à‡a commence plutôt pas mal, la livebox a donc une API ! Comme souvent avec Orange, ça commence bien, c'est après que les choses se gâtent ! Impossible de mettre la main sur une doc publique de l'API. En fouillant un peu sur les forums d'Orange j'ai trouvé quelques pistes mais mes vrais amis ont été Wireshark et les dev tools InternetExplorer ou Chrome (F12) pour comprendre un peu comment l'appli mobile d'Orange (version IOS) utilisait l'API… En inspectant le déroulé d'un login, je manque de m'étrangler en constatant que le nom d'utilisateur et le mot de passe sont balancés en clair; ben voyons les gars faut pas se gêner hein… la requête login retourne un "ContextID" qui est utilisé comme identifiant pour les appels aux fonctions de l'API (X-Context dans les headers). Donc au menu nous avons des custom headers et une authentification super basique, fastoche! où est le problème? Bah ça marche pô! - > "permission denied" le voilà le problème Bah surement qu'ils ont été pris de remords chez Orange avec cette authentification de mickey avec password en clair et histoire de faire bonne figure (et pas se faire défoncer tous les mercredi par des pré-ados qui voudraient passer outre le contrôle parental) ils ont semble-t-il cherché à compliquer un peu les choses… mais en faisant du gros n'importe quoi! Pour aller à l'enssentiel, en plus d'un ContextID, le Login renvoie une autre clé mais planquée dans un cookie cette fois. La sécurité n'y a pas gagné grand chose mais en revanche c'est une vraie prise de tête à intégrer sur la hc2. Hmm.. Net.FHttp avec des custom headers et un cookie, ça va pas le faire… Pour contourner le problème et récupérer le cookie, je me suis servi du génialissime ToolKit v1.0.4 de Krikroff. Une toute petite modif de 4 lignes dans httpClient:request et nous voila prêts à nous goinfrer de cookies. J'ai modifié (à l'arrache, sorry Krikroff) la fonction request(...) dans le fichier Toolkit.net.lua (commence ligne 165). on cherche la chaine "cookie" dans les response headers renvoyés par le serveur et le cas échéant on extrait avec un string.sub() en partant du douzième char. la fonction retourne le cookie en plus des classiques response, status et err. request = (function(self, method, uri, headers, body) ... for k, v in pairs(__headers) do --Toolkit.Net.__trace("raw #"..k..":"..v) if (string.find(string.lower( v or ""), "chunked")) then self.__isChunked = true; Toolkit.Net.__trace("%s.%s::receive > Transfer-Encoding: chunked", Toolkit.Net.__header, Toolkit.Net.__Http.__header, string.len(result)); -- Modification pour récupérer le cookie. Ofwood Janvier 2015 elseif (string.find(string.lower( v or ""), "cookie")) then cookie = string.sub(v, 12) Toolkit.Net.__trace("%s.%s::receive > Cookie: %s", Toolkit.Net.__header, Toolkit.Net.__Http.__header, cookie); end end ... -- return budy response & cookie return response, status, err, cookie; Voyons maintenant avec un exemple comment tirer profit de cette modification et mangeons des cookies! La fonction login() authentifie l'utilisateur et retourne le contextID (dans la réponse json) et le cookie associé. function login() local httpClient = Toolkit.Net.HttpRequest(ip, port) httpClient:setReadTimeout(Livebox.commandTimeOut) local uri = string.format("/authenticate?username=%s&password=%s", utilisateur, mot_de_passe) local response, status, errorCode, cookie = httpClient:request("POST", uri, {"User-Agent: FibaroHC2/1.0", "Content-Type: application/json"}, "" ) if (errorCode == 0) and tonumber(status) == 200 then local jsonTable = json.decode(response); ContextID = jsonTable.data.contextID; return ContextID, cookie end end l'exemple suivant utilise le contextID et notre cookie pour une requête (l'état de l'interface WAN sur la LiveBox) function getWANStatus(contextID, cookie) local httpClient = Toolkit.Net.HttpRequest(ip, port) httpClient:setReadTimeout(Livebox.commandTimeOut) local uri = "/sysbus/NMC:getWANStatus" local params = [[ {"parameters":{}} ]]; -- Injection de X-Context et du Cookie dans les headers local response, status, errorCode, cookie = httpClient:request("POST", uri, {"User-Agent: FibaroHC2/1.0", "Content-Type: application/json", "X-Context: "..contextID, "Cookie: "..cookie }, params); if (errorCode == 0) and (status == 200) then local jsonTable = json.decode(response) Return jsonTable.result.data end end Voici la liste des fonctions implémentées dans la version 1.0 du module. Il en existe d'autres, je n'ai pas encore tout recensé. Livebox.login() Authentification session utilisateur Livebox.logout() Fermeture session Livebox.listTrunks() Information téléphonie IP Livebox.getIPTVStatus() Etat IP TV Livebox.getDSLStats() Stats DSL (Erreurs) Livebox.getMIBs() Information lien dsl Livebox.getWifiMIBs() Information Wifi Livebox.getWANStatus() Etat de la connexion WAN Livebox.reboot() Redémarrage la livebox Livebox.setwifi(mode) Active/désactive le Wifi Livebox.filtreMAC(flag) Active/Désactive filtrage MAC address Livebox.getWificomStatus() Information Wifi public Orange Voilà , ça donne l'idée générale et Orange n'ayant pas le monopole sur les APIs bien pourries, je me suis dit que ça pourrait peut-être en aider d'autres qui se prennent la tête sur des intégrations nécessitant le support des cookies. Enjoy! merci pour vos retours (et votre indulgence) Historique 13/01/2015 - v1.0 : version initiale Livebox_VD.zip

Voici une petite astuce sà»rement utilisée par beaucoup mais que je n'ai pas vue sur le forum (j'avoue j'ai pas lu tous les sujets) et qui pourra vous faire gagner beaucoup de temps notamment lors des changements de version et des recovery. En effet il peut arriver lors des recovery que l'identifiant de module change, cela implique donc de modifier l'ensemble de vos scripts Lua pour corriger les id de module, et lorsque vous avez beaucoup de scripts, ça peut prendre un temps fou. L'idée est donc de stocker l'ensemble de vos id dans une variable globale et de les restituer à chaque début de script. Dans le panneaux des variables, créez une nouvelle variable globale nommée "id". Ce premier bout de code à placer dans un bouton de module virtuel vous permet de sauvegarder les id dans la variable globale à chaque appui sur le bouton: -- Déclaration de la table des id id={}; -- Affectation des id de chaque device id.pcdavid=7; id.pcchristelle=11; id.freebox=6; id.diskstation=12; id.notification=12; -- Sauvegarde des id dans la variable globale fibaro:setGlobal('id',json.encode(id)); Pour restituer ces id à l'entrée de votre script et les utiliser dans un programme: -- Récupération de vos id en début de vos scripts id=json.decode((fibaro:getGlobal('id'))); -- Exemple d'utilisation fibaro:call(id.freebox, "pressButton", "12"); fibaro:debug(id.pcchristelle); Voilà , voilou, si ça peut aider quelque newbees comme moi

Salut à tous, pour mon premier petit tuto, je vais vous détailler la mise en place d'une passerelle SMS perso et autonome que je viens de mettre en place. Cette passerelle SMS va vous permettre d'envoyer depuis le HC2 vos propres SMS gratuitement sur n'importe quel numéro de portable. Pour ce faire vous avez besoin : -d'un abonnement GSM, j'utilise le forfait à 2 euro de free, gratuit pour les freenaute. -d'un vieux portable sous android, version 1.6 minimum -et d'un HC2, ou de n'importe qu'elle box domotique qui sait envoyer des requêtes HTTP. 1- Préparation du matériel : Il suffit de connecter en WIFI votre téléphone sur votre réseau, de préference avec une ip fixe ou une réservation dans le DHCP. Installer l'application SMS Gateway de l'éditeur APK Soft à télécharger sur le google play 2-Configuration du logiciel : Très simple d’utilisation il suffit de paramétrer SMS Gateway pour qu’elle crée un serveur HTTP au sein de votre téléphone en lui spécifiant un port (ou laisser celui par défaut). Votre serveur domotique communiquera avec la passerelle SMS en HTTP via ce serveur web embarqué. Un mot de passe peut être demandé afin de limiter les accès au serveur web. Ce mot de passe devra être spécifié dans la requête http voici le lien pour configurer l'application : http://www.abavala.com/2012/07/09/sms-gateway-une-passerelle-sms-a-la-maison/ Du coté du HC2, il faut créer un périphérique virtuel, en indiquant l'adresse IP du téléphone et son port TCP (9090 par defaut). Ensuite j'ai créer un bouton qui correspond à un message prédefini --Récupération de l'adresse IP et du Port inscrit sur le module virtuel. --fibaro:getSelfId() retourne l'ID du module virtuel en cours. local ip_module = fibaro:get(fibaro:getSelfId(),"IPAddress") local port = fibaro:get(fibaro:getSelfId(), "TCPPort") local id_module = fibaro:getSelfId() local status = "" local TelFred = "+3367*******" HC2 = Net.FHttp(ip_module,port) response ,status, errorCode = HC2:GET("/sendsms?phone=067*******&text=ceci%20est%20un%20test&password=*********") fibaro:debug("response = " .. response) fibaro:debug("status = " .. status) if response ~= nill and tonumber(status)==200 then fibaro:debug("Succes: SMS envoyé") else fibaro:debug("Error: Failed to SEND SMS") end Le SMS de votre serveur domotique sera envoyé directement par la passerelle dès qu’il s’adressera à elle via une URL de la forme: http://***.***.***.***:9090/sendsms?phone=xxxxxxxxxx&text=ceci%20est%20un%20test&password=yyyyy Vous pouvez créer autant de bouton que nécessaire En espérant avoir pu vous être utile.

Le but de ce tutoriel est de vous présenter 2 solutions pour remplacer l'antenne d'origine par une antenne avec gain. Cette nouvelle antenne "amplifiée" vous permettra d'augmenter la portée du signal Z-Wave et ainsi, de réduire les nÅ“uds morts. A ce stade, 2 solutions existent et dépendent de l’actuel emplacement de votre HC2 : Baie informatique Autre : placard, bureau... . Solution pour une baie informatique : Tout d'abord, il vous faudra vous procurer le matériel suivant : Adaptateur RP SMA femelle => SMA mâle (http://www.amazon.fr...8081_TE_3p_dp_1) Socle magnétique RP SMA (http://www.amazon.fr...0444391_TE_item) Antenne 868 Mhz (http://www.amazon.fr...8081_TE_3p_dp_1) Une fois le matériel en votre possession, il vous faudra réaliser les opérations suivantes: On stoppe proprement la HC2. On coupe les disjoncteurs sur lesquels se trouve vos modules. On démonte l'antenne d'origine. On visse l'adaptateur RP SMA femelle/mâle sur la sortie antenne de la HC2. On visse la nouvelle antenne sur le socle magnétique. On visse la rallonge du socle magnétique sur l'adaptateur vissé précédemment (étape 4). On redémarre la HC2. On patiente le temps que cette dernière réalise son redémarrage complet. On remet en tension tous les disjoncteurs coupés à l'étape 2. On patiente quelques minutes le temps que la HC2 réalise son nouveau maillage du réseau Z-Wave. Enjoy! Solution pour les autres emplacements : Tout d'abord, il vous faudra vous procurer le matériel suivant : Antenne coudée 868 Mhz (http://my-domotique.com/store/index.php?id_product=582&controller=product&id_lang=2)Une fois le matériel en votre possession, il vous faudra réaliser les opérations suivantes: On stoppe proprement la HC2. On coupe les disjoncteurs sur lesquels se trouve vos modules. On démonte l'antenne d'origine. On visse la nouvelle antenne sur la HC2. On redémarre la HC2. On patiente le temps que cette dernière réalise son redémarrage complet. On remet en tension tous les disjoncteurs coupés à l'étape 2. On patiente quelques minutes le temps que la HC2 réalise son nouveau maillage du réseau Z-Wave. Enjoy! Je remercie Nico, KriKroff, Lazer et BenjyNet pour leur aide apportée à mon problème de perte de réseau Z-Wave sur ma HC2. Ce tutoriel fait suite à ce dernier : http://www.domotique-fibaro.fr/index.php/topic/2475-perte-de-r%C3%A9seau-z-wave/

Suite à une demande d'aide par MP, voici une traduction de mon post sur le forum fibaro officiel. http://forum.fibaro.com/viewtopic.php?t=3477&postdays=0&postorder=asc&start=26 La Sonette EVERSPRING UTSE03A est maintenant compatible avec la HC2 Voici la procédure: PROCEDURE MISE A JOUR ICI: http://www.domotique-fibaro.fr/index.php/topic/2663-sonnette-everspring-inclusion-et-support-hc2/page-4#entry88244 1 - Inclure le carillon en pressant 3 fois le bouton IER 2 - Inclure le bouton de la sonnette en pressant une fois le bouton IR pendant 10 secondes 3 - Les deux devices sont inclus dans la HC2 4 - Maintenant il faut associer les deux ensembles 5 - Appuyez le bouton IR pendant 10 secondes sur le module bouton de sonnette (Le bouton clignote) 6 - Appuyez trois fois sur le bouton IR du module bouton de sonnette (le bouton clignote) 7 - Appuyez trois fois le bouton IER sur le carillon (les deux boutons vont arrêter de clignoter) Maintenant le carillon est configuré. Si ça ne fonctionne pas, vous devez faire un reset du carillon et du module bouton poussoir et refaire la procédure... Dans mon cas ça a fonctionné au deuxième essai mais d'autres ont été moins chanceux et on du le refaire plusieures fois. Sans doute à cause de la nature zwave sur piles qui est toujours plus difficile à inclure (réveil) Maintenant vous pouvez faire sonner le carillon avec le code ci-dessous: fibaro:call(<IDCarillon>, "setValue", "255") Vous pouvez détecter un appui sur le bouton avec la scène suivante: --[[ %% properties <IDCarillon> value %% globals --]] if(tonumber(fibaro:getValue(<IDCarillon>, "value"))>0) then fibaro:debug("Actif"); else fibaro:debug("Inactif"); end note: je possède la version 1.1 Notification via GEA et envoi des photos des caméras: GEA.add({"Value+", id["SONNETTE"], 1}, -1, "Sonnette actionnée à #time# le #date#", {{"Portable", 53}, {"Portable", 104}, {"VirtualDevice", id["VD_PHOTO_SENDER"], "10"},}) Et voilà le travail:

Bonjour, Suite à une conversation en MP avec un de nos admin chéri ;-), voici ma solution pour détecter la présence via smartphone. L'idée est de savoir quand ma femme ou moi même sommes à la maison afin de pouvoir lancer des scénarios ou en bloquer l’exécution. J'ai fait ça il y a longtemps, et bien sur je n'ai pas tout fait tout seul. Je me souviens avoir fait quelques modifications pour que ça tourne comme je le voulais, mais je ne sais plus lesquelles. Bref, voici le package complet, pour certains scripts, comme pour le ping par exemple la base est de Krikroff et j'ai laissé le copyright. J'ai mis le Virtual Device en attach et le code du bouton ci-dessous . IP Smartphone Presence Check V1.0.vfib !!! voir post plus loin dans le fil pour les V1.1 V1.2 V1.3 V2.0 et suivantes !!! V2.1 ici: https://www.domotique-fibaro.fr/topic/2613-detection-de-prã©sence/?do=findComment&comment=121355 V1.3 ici: http://www.domotique-fibaro.fr/index.php/topic/2613-detection-de-pr%C3%A9sence/page-3#entry35219 - il faut créer une variable globale (non prédéfinie) par device à surveiller (moi j'utilise "Phone_GG_Present" pour le tel de ma femme) et la déclarer en début de script du bouton. - il faut encoder l'adresse IP du téléphone dans les paramètres du Virtual device (pensez à déterminer une ip Wifi fixe pour votre smartphone) - il faut encoder le port ouvert sur votre téléphone dans les paramètres du Virtual device (3500 ou 3401) - Sur Androà¯d, il n'y a pas de port ouvert par défaut pour accepter le ping, le moyen le plus simple est d'installer l'application Sonos et a lancer, c'est tout (pas besoin d'avoir du matos sonos pour que ça fonctionne) - Sur iPhone idem, mais je n'ai pas testé personellement - si vous ne voulez pas utiliser le mainloop comme "scheduler" , créez simplement une scène qui va cliquer sur le bouton de demande de présence toutes les minutes... ou avec l'excellent GEA, avec la ligne ci-dessous (à adapter): -- Mise à jour des Présences par détection d'adresses IP toutes les minutes GEA.add(true , 1*60, "",{{"VirtualDevice", id["VD_PRESENCE_SEB"], "1"},{"VirtualDevice", id["VD_PRESENCE_GG"], "1"},{"Repeat"}}) Notification de présence en utilisant GEA, entre 8h et 21h: N'oubliez pas de mettre les VG dans l'entête. Ces exemple sont repris dans le post GEA de ma signature --------------DETECTION PRESENCE-------------- -- Signale GG at Home GEA peux se déclencher sur un changement de valeur d'une variable global GEA.add({"Global", "Phone_GG_Present", "1"}, -1, "Presence GG est maintenant à #value#", {{"Portable", 53}, {"Time", "08:00", "21:00"}}) GEA.add({"Global", "Phone_GG_Present", "0"}, -1, "Presence GG est maintenant à #value#", {{"Portable", 53}, {"Time", "08:00", "21:00"}}) Code bouton VD détect presence V1.0 (ancien code): -- IP Smartphone Presence Check V1.0 -- Copyright © 2014 Sébastien Jauquet. -- http://www.domotique-fibaro.fr/index.php/topic/2613-detection-de-pr%C3%A9sence/ --Using code from: -- Ping v 1.0.1 [05-2013] -- Copyright © 2013 Jean-christophe Vermandé -- http://www.domotique-fibaro.fr/index.php/topic/109-ping-dun-%C3%A9quipement-r%C3%A9seau/page-2 fibaro:log("Starting process"); local _deviceIp = "192.168.10.112"; local variable_globale_phone = "Phone_GG_Present"; local _devicePort = 3500; local _maxRetryProcess = 20; local time = tonumber(os.time()); local maxtime = 56; -- fibaro:setGlobal("Lock_Away","Unlocked") function SecondsToClock(sSeconds) local nSeconds = tonumber(sSeconds) if nSeconds == 0 then return "00:00:00"; else nHours = string.format("%02.f", math.floor(nSeconds/3600)); nMins = string.format("%02.f", math.floor(nSeconds/60 - (nHours*60))); nSecs = string.format("%02.f", math.floor(nSeconds - nHours*3600 - nMins *60)); return nHours..":"..nMins..":"..nSecs end end -- recursive function to ping device local function _ping(retry) retry = retry or 0; -- notify state local elapsed = os.difftime(os.time(), tonumber(time)); local msg = "Loop #".. retry .." since "..SecondsToClock(elapsed); fibaro:log(msg); -- check for no more than 30 seconds if elapsed > maxtime then return false; end --open the socket local tcpSocket = Net.FTcpSocket(_deviceIp, _devicePort); --set the read timeout tcpSocket:setReadTimeout(250); --send packet local bytes, errorCode = tcpSocket:write("test"); --check for error if errorCode == 0 then return true; else if retry < _maxRetryProcess then --fibaro:log("Retry process, please wait..."); fibaro:sleep(1*750); return _ping(retry + 1); end return false; end end --ping device, secure with pcall to catch errors. local f, result = pcall(_ping); local Lock_Away = fibaro:getGlobal("Lock_Away") if (f) then if (result == true) and (Lock_Away == "Unlocked") then fibaro:log("Device has been found."); fibaro:setGlobal(variable_globale_phone,"1") -- fibaro:setGlobal("Present_Phones",os.time()) else fibaro:log("Device was not found!"); fibaro:setGlobal(variable_globale_phone,"0") end else fibaro:log("Error: " .. f); end Code main loop du VD local thismodule = fibaro:getSelfId(); local status = fibaro:getGlobal("Phone_GG_Present") -- fibaro:debug(thismodule); if status == "0" then fibaro:call(thismodule, "setProperty", "currentIcon", 1037) end if status == "1" then fibaro:call(thismodule, "setProperty", "currentIcon", 1036) end fibaro:sleep(1000); Ce n'est certainement pas le code le plus "léché" mais je pense que ça en aidera quand même certains... et puis c'est "tout fait" ;-) Le script va détecter quasi instantanément lorsque le smartphone apparaît sur le réseau, mais pourra mettra jusqu'à une minute pour valider son absence Enjoy !

Les manipulations présentées dans ce sujet de discussion sont destinés à des utilisateurs avancés disposant des compétences nécessaires, et je décline tout responsabilité en cas de fausse manipulation rendant votre clé USB Recovery inopérante, voire même votre Home Center 2. Introduction Voir : Sauvegarde, Restauration, Et Recovery Sur Home Center 2 Clonage de la clé USB de Recovery Présentation de la clé La clé USB fournie avec la box Fibaro Home Center 2 est un élément critique, car sans elle la box ne peut fonctionner. Elle sert pour les sauvegardes de la configuration (en vue de leur restauration éventuelle), notamment avant chaque mise à jour de firmware, mais également pour le Recovery, c'est à dire le retour à une configuration usine en cas de crash de la box. Pour rappel, cette clé est connectée sur un port USB situé derrière la plaque métallique vissée sur le coté gauche de la box. Avant de retirer la clé USB Recovery de la box, s'assurer que celle-ci soit bien éteinte. Dans un premier temps, nous connectons la clé USB sur un PC sous Windows. Dans l'explorateur, nous voyons apparaître une partition d'environ 2 Go : Contenant 3 répertoires et 1 fichier : 24/10/2014 07:44 <REP> backups 02/09/2013 15:40 <REP> system 30/08/2013 12:15 10 network.conf 13/11/2013 22:48 <REP> logs Il est inutile à ce stade là de vouloir copier l'arborescence de cette partition, car le Gestionnaire des disques de Windows nous montre 2 partitions inconnues supplémentaires, ainsi que de l'espace libre : La clé a en réalité une taille de 8 Go, mais seuls 4 Go sont utilisés. Il faut donc monter la clé USB sur un système Linux, qui est capable de lire (presque) tous les formats de partitions existants. J'ai utilisé pour cela une VM sous ESXi sur mon serveur HP Proliant G7 N54L, voici les captures d'écran des fenêtres de modifications des paramètres de la machine virtuelle : On remarque que la clé fournie par Fibaro est de marque Kingston, on n'est donc pas en présence d'une clé chinoise premier prix : Dans ma VM, il s'agit d'un Linux RedHat Enterprise Server, mais n'importe quel Linux peut faire l'affaire, en particulier Debian qui est la distribution utilisée par FIbaro. Il est évidemment possible de monter cette clé sur n'importe quelle machine Linux, dont voici une liste non exhaustive : - Linux natif sur PC - Linux sur Raspberry PI - Linux dans une VM sous VMware Player sous Windows ou MacOS - LiveCD bootable sur CD ou clé USB - etc... Je ne détaille pas ces procédures, de nombreux tutoriels existent sur Internet, et je répète que si vous voulez tenter les manipulations décrites ici cela nécessite d'être suffisamment à l'aise avec Linux (ce qui implique de savoir l'installer). Une fois la clé connectée sur la machine Linux, on la voit apparaître dans les messages du noyau avec la commande dmesg : [root@redhat ~]# dmesg | tail -21 usb 1-2: new high speed USB device number 3 using ehci_hcd usb 1-2: New USB device found, idVendor=13fe, idProduct=4100 usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 1-2: Product: FIBARO RECOVERY usb 1-2: Manufacturer: FIBARO usb 1-2: SerialNumber: ...................... usb 1-2: configuration #1 chosen from 1 choice scsi4 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 3 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 4:0:0:0: Direct-Access FIBARO FIBARO RECOVERY PMAP PQ: 0 ANSI: 6 sd 4:0:0:0: Attached scsi generic sg3 type 0 sd 4:0:0:0: [sdc] 15646720 512-byte logical blocks: (8.01 GB/7.46 GiB) sd 4:0:0:0: [sdc] Write Protect is off sd 4:0:0:0: [sdc] Mode Sense: 23 00 00 00 sd 4:0:0:0: [sdc] Assuming drive cache: write through sd 4:0:0:0: [sdc] Assuming drive cache: write through sdc: sdc1 sdc2 sdc3 sd 4:0:0:0: [sdc] Assuming drive cache: write through sd 4:0:0:0: [sdc] Attached SCSI removable disk Dans cet exemple, le device utilisé est /dev/sdc Par curiosité, avec lsusb on peut obtenir des informations sur cette clé Kingston : [root@redhat ~]# lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 196d:f100 Bus 002 Device 002: ID 0e0f:0003 VMware, Inc. Virtual Mouse Bus 002 Device 003: ID 0e0f:0002 VMware, Inc. Virtual USB Hub Bus 001 Device 003: ID 13fe:4100 Kingston Technology Company Inc. [root@redhat ~]# lsusb -s 001:003 -vvv Bus 001 Device 003: ID 13fe:4100 Kingston Technology Company Inc. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x13fe Kingston Technology Company Inc. idProduct 0x4100 bcdDevice 1.00 iManufacturer 1 FIBARO iProduct 2 FIBARO RECOVERY iSerial 3 ...................... bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 32 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 200mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 8 Mass Storage bInterfaceSubClass 6 SCSI bInterfaceProtocol 80 Bulk-Only iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Device Qualifier (for other device speed): bLength 10 bDescriptorType 6 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 bNumConfigurations 1 Device Status: 0x0000 (Bus Powered) Avec la commande parted, on découvre plus en détail la structure des partitions de cette clé : [root@redhat ~]# parted /dev/sdc GNU Parted 2.1 Using /dev/sdc Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) print Model: FIBARO FIBARO RECOVERY (scsi) Disk /dev/sdc: 8011MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 2000MB 1999MB primary fat32 2 2000MB 2255MB 256MB primary linux-swap(v1) 3 2255MB 3817MB 1561MB primary ext4 boot (parted) quit La taille de 8 Go est confirmée. On trouve les partitions suivantes : FAT32 (la partition visible sous Windows) Linux Swap (l'espace de paging space du système Linux) ext4 (le format de fichier standard d'une partition Linux, et qui se trouve en plus être bootable) Sauvegarde de la clé Sans plus attendre, on procède immédiatement à la sauvegarde cette clé, ce qui est l'étape la plus importante de cette étude. On utilise pour cela la commande dd qui permet de réaliser une copie bit-à -bit de l'intégralité de la clé. [root@redhat ~]# dd if=/dev/sdc of=/tmp/usb.img bs=1M 7640+0 records in 7640+0 records out 8011120640 bytes (8.0 GB) copied, 812.817 s, 9.9 MB/s Débit moyen de lecture de 10 Mo/s, ce n'est pas terrible (le débit max du bus l'USB-2 étant d'environ 25 Mo/s), mais pour l'usage très occasionnel qui est fait de cette clé, ce n'est pas un souci. On obtient un fichier de 8 Go sur le disque dur, qui est l'image exacte de la clé : [root@redhat ~]# ls -l /tmp/usb.img -rw-r--r--. 1 root root 8011120640 Oct 24 10:35 /tmp/usb.img Ce fichier contient donc le MBR (Master Boot Record) de la clé, l'intégralité des 3 partitions, ainsi que l'espace vide, comme le confirme la commande file : [root@redhat ~]# file /tmp/usb.img /tmp/usb.img: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 3903488 sectors; partition 2: ID=0x82, starthead 27, startsector 3905536, 499712 sectors; partition 3: ID=0x83, active, starthead 54, startsector 4405248, 3049472 sectors, code offset 0x63 Note : il aurait été possible de réaliser une sauvegarde de façon plus optimisée, en sauvegardant indépendamment le MBR et les 3 partitions, afin de ne conserver que les 4 Go utile. Néanmoins dans ce tutoriel la procédure se voulait simple afin de cloner intégralement la clé USB fournie par FIbaro afin de conserver une copie de secours. Nous verrons peut-être ultérieurement qu'il est possible d'aller beaucoup plus loin dans les manipulations de cette clé. Restauration de la clé On connecte une nouvelle clé USB vierge sur le système Linux. Si cette clé n'est pas vierge, elle sera écrasée. La restauration de la clé de Recovery utilise toujours la même commande dd, mais en sens inverse, c'est à dire qu'on lit le fichier pour écrire sur le périphérique USB. Dans mon exemple il s'agit de /dev/sdd : [root@redhat tmp]# dd if=/tmp/usb.img of=/dev/sdd bs=1M dd: writing `/dev/sdd': No space left on device 7553+0 records in 7552+0 records out 7918845952 bytes (7.9 GB) copied, 703.889 s, 11.3 MB/s On note une erreur car l'espace disponible sur ma nouvelle clé est insuffisant. En effet, j'ai utilisé une clé qui fait un peu moins de 8 Go, donc la commande n'a pas pu écrire la fin des octets. Ce n'est nullement gênant car comme on l'a vu précédemment, seuls 4 Go sont utilisés et la fin de la clé est inutilisé. Dans l'exemple ci-dessus, 7,9 Go ont été écrits, ce qui est plus que suffisant. Test de la clé clonée On insère la clé USB dans la box HC2, on branche l'alimentation, et la box boot comme si de rien n'était. On l'arrête à nouveau, on rebranche la clé d'origine, et on redémarre la box en production. On conserve la nouvelle clé générée bien à l'abri, ou pas, puisque avec l'image binaire présente sur le disque dur il est toujours possible de regénérer autant de clés qu'on le souhaite. Notes complémentaires Cette procédure permet de cloner une clé devant être utilisé sur la même box. L'étude pour cloner une clé sur une box différente sera menée ultérieurement (sans garantie de succès) Le clonage de la clé aurait pu se faire directement avec la commande suivante, sans passer par le disque dur (non testé) : dd if=/dev/sdc of=/dev/sdd bs=1M . Analyse détaillée de la clé A partir de ce chapitre, on commence l'étude approfondie de la clé de Recovery. Par sécurité afin de ne pas tout casser en cas de fausse manipulation, on travaille sur l'image générée précédemment sur disque. Le fichier usb.img est une image en mode "raw" de la clé, et a donc conservé la structure initiale avec les 3 partitions : [root@redhat tmp]# parted usb.img print Model: (file) Disk /tmp/usb.img: 8011MB Sector size (logical/physical): 512B/512B Partition Table: msdos Number Start End Size Type File system Flags 1 1049kB 2000MB 1999MB primary fat32 2 2000MB 2255MB 256MB primary linux-swap(v1) 3 2255MB 3817MB 1561MB primary ext4 boot On crée les devices dans le noyau permettant de monter les partitions : [root@redhat tmp]# kpartx -v -a usb.img add map loop0p1 (253:2): 0 3903488 linear /dev/loop0 2048 add map loop0p2 (253:3): 0 499712 linear /dev/loop0 3905536 add map loop0p3 (253:4): 0 3049472 linear /dev/loop0 4405248 On crée les points de montages (il est inutile de monter la partition de swap) : [root@redhat ~]# mkdir /mnt/sdc1 [root@redhat ~]# mkdir /mnt/sdc3 On monte les 2 partitions intéressantes : [root@redhat tmp]# mount /dev/mapper/loop0p1 /mnt/sdc1 -o ro [root@redhat tmp]# mount /dev/mapper/loop0p3 /mnt/sdc3 -o ro Dans la partition n°1, on retrouve les fichiers qui étaient visibles sous Windows : [root@redhat tmp]# cd /mnt/sdc1 [root@redhat sdc1]# ls -l total 16 drwxr-xr-x. 7 root root 4096 Oct 24 07:44 backups drwxr-xr-x. 2 root root 4096 Nov 13 2013 logs -rwxr-xr-x. 1 root root 10 Aug 30 2013 network.conf drwxr-xr-x. 2 root root 4096 Sep 2 2013 system Vérification de l'espace occupé/libre : [root@redhat sdc1]# df -m . Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/loop0p1 1903 487 1416 26% /mnt/sdc1 Les tailles de Mo de chaque fichier/répertoire : [root@redhat sdc1]# du -sm * 63 backups 1 logs 1 network.conf 424 system On en déduit que sur les 2 Go de cette partition, 424 Mo sont utilisés par l'image système de recovery, et seulement 63 Mo (dans mon cas) pour les sauvegardes de la configuration. Donc les 1416 Mo libres sont plus que suffisants pour réaliser un grand nombre de sauvegardes. Dans mon cas, j'ai seulement 5 sauvegardes, et on remarque que la plus grosse d'entre elle est ma dernière sauvegarde du 24/10/2014 : [root@redhat sdc1]# du -sm backups/* 6 backups/backup16_01_14-2032 6 backups/backup16_01_14-2037 41 backups/backup24_10_14-0944 11 backups/backup28_02_14-1428 2 backups/backup29_11_13-0019 Le fichier network.conf contient seulement l'info permettant au réseau de fonctionner en DHCP lorsqu'on boot en recovery : [root@redhat sdc1]# cat network.conf type=dhcp Etudions maintenant le contenu de ma dernière sauvegarde : [root@redhat sdc1]# cd backups/backup24_10_14-0944/ [root@redhat backup24_10_14-0944]# ls -l total 40812 -rwxr-xr-x. 1 root root 117 Oct 24 07:44 checksum -rwxr-xr-x. 1 root root 131 Oct 24 07:44 info drwxr-xr-x. 2 root root 4096 Oct 24 07:44 scenes -rwxr-xr-x. 1 root root 41757696 Oct 24 07:44 sql -rwxr-xr-x. 1 root root 16528 Oct 24 07:44 zwave Il y a quelques fichiers textes, une base de données SQLite, et un fichier binaire : [root@redhat backup24_10_14-0944]# file * checksum: ASCII text info: ASCII text scenes: directory sql: SQLite 3.x database zwave: data Le fichier checksum contient des sommes de contrôles permettant de s'assurer de la cohérence des fichiers stockés sur la clé avant la restauration éventuelle : [root@redhat backup24_10_14-0944]# cat checksum 82a0e8acacb02838248ff032dfb16a7e sql 96d7a2aac279dc2be1abd77bb1f37196 zwave c9bf3777d6c6990e37a59aa3cfac49af info Vérification, tout est OK : [root@redhat backup24_10_14-0944]# md5sum sql 82a0e8acacb02838248ff032dfb16a7e sql [root@redhat backup24_10_14-0944]# md5sum zwave 96d7a2aac279dc2be1abd77bb1f37196 zwave [root@redhat backup24_10_14-0944]# md5sum info c9bf3777d6c6990e37a59aa3cfac49af info Le fichier info contient quelques informations génériques qui sont affichées par l'interface Web lorsqu'on boote la box en recovery : [root@redhat backup24_10_14-0944]# cat info devices=90 rooms=12 scenes=22 hour=09 minute=44 day=24 month=10 year=2014 timestamp=1414136694 description=24/10/2014 v3.590 stable Le fichier sql contient toute la configuration, dont voici un extrait : [root@redhat backup24_10_14-0944]# sqlite3 sql ".tables" Alarm_Fibaro_Scene Alarm_Zone Alarm_Zone_PIN Backups Borrowed_Devices Cooling_Zone Cooling_Zone_Room Dashboard Device_Association_Group [...] Par exemple : [root@redhat backup24_10_14-0944]# sqlite3 sql 'select * from Room;' 1|1|Salon|room_kominek|999|96|97|0|0 2|1|Entrée|room_kapelusz|999|0|0|0|0 3|1|Salle à manger|room_jadalnia|999|0|0|0|0 [...] Dans le sous-répertoire scenes, on y trouve des pages html et des scritps LUA : [root@redhat backup24_10_14-0944]# cd scenes/ [root@redhat scenes]# ls -l total 484 -rwxr-xr-x. 1 root root 17288 Oct 24 07:44 10.html -rwxr-xr-x. 1 root root 828 Oct 24 07:44 10.lua -rwxr-xr-x. 1 root root 17346 Oct 24 07:44 11.html -rwxr-xr-x. 1 root root 947 Oct 24 07:44 11.lua -rwxr-xr-x. 1 root root 19930 Oct 24 07:44 12.html -rwxr-xr-x. 1 root root 1047 Oct 24 07:44 12.lua -rwxr-xr-x. 1 root root 17756 Oct 24 07:44 13.html -rwxr-xr-x. 1 root root 923 Oct 24 07:44 13.lua -rwxr-xr-x. 1 root root 26374 Oct 24 07:44 14.html -rwxr-xr-x. 1 root root 1112 Oct 24 07:44 14.lua [...] Au hasard, prenons la plus grosse scène, et ô surprise (oui je sais j'utilise encore une veille version de GEA) : [root@redhat scenes]# head -22 22.lua --[[ %% autostart %% properties 46 value %% globals --]] -- ------------------------------------------------------------ -- GEA : Gestionnaire d'Evénements Automatique -- Scénario permettant de contrôler si une périphérique est -- activé depuis trop longtemps ou lancer -- un push d'avertissement -- L'état du périphérique est contrôlé toutes les X secondes -- si passer le délai souhaité le périphérique est toujours -- activé, le système envoi une notification -- -- Auteur : Steven P. with modification of Hansolo -- Version : 3.50 -- Special Thanks to : -- Fredric, Diuck, Domodial, moicphil, lolomail, byackee, -- JossAlf, Did and all other guy from Domotique-fibaro.fr -- ------------------------------------------------------------ . On retourne maintenant à la racine de la partition n°1, afin d'étudier rapidement le répertoire system : [root@redhat scenes]# cd /mnt/sdc1 [root@redhat sdc1]# cd system [root@redhat system]# ls -l total 433920 -rwxr-xr-x. 1 root root 33 Sep 2 2013 checksum -rwxr-xr-x. 1 root root 444328464 Sep 2 2013 image.gz -rwxr-xr-x. 1 root root 0 Jul 17 2012 version3 -rwxr-xr-x. 1 root root 0 Aug 23 2013 version4 Comme pour les sauvegardes, une somme de contrôle permet de s'assurer de l'intégrité de l'image à restaurer : [root@redhat system]# cat checksum c496e1fe5e3095b73e2f376b35ae5307 [root@redhat system]# md5sum image.gz c496e1fe5e3095b73e2f376b35ae5307 image.gz Ce fichier image.gz est une archive compressée d'une image raw d'un disque : [root@redhat system]# file image.gz image.gz: gzip compressed data, was "image", from Unix, last modified: Mon Sep 2 15:27:19 2013 [root@redhat system]# gzip -dc image.gz | file - /dev/stdin: x86 boot sector; partition 1: ID=0x83, active, starthead 32, startsector 2048, 1951744 sectors; partition 2: ID=0x82, starthead 157, startsector 1953792, 499712 sectors; partition 3: ID=0x83, starthead 184, startsector 2453504, 1368064 sectors, code offset 0x63 On décompresse cette archive dans un répertoire temporaire : [root@redhat system]# cd /tmp [root@redhat tmp]# gzip -cd /mnt/sdc1/system/image.gz > image [root@redhat tmp]# ls -l image -rw-r--r--. 1 root root 2002780160 Oct 25 18:26 image Il s'agit de l'image du disque système interne de la HC2 (clé USB SLC de 2 Go) : [root@redhat tmp]# parted image print Model: (file) Disk /tmp/image: 2003MB Sector size (logical/physical): 512B/512B Partition Table: msdosNumber Start End Size Type File system Flags 1 1049kB 1000MB 999MB primary ext4 boot 2 1000MB 1256MB 256MB primary linux-swap(v1) 3 1256MB 1957MB 700MB primary ext4 En cas de recovery de la box, c'est donc cette image qui est restaurée sur la mémoire interne de la box, puis la dernière sauvegarde peut être restaurée. Je ne détaille pas plus le contenu de ces partitions systèmes, mais il est tout à fait possible de les monter et d'accéder à leur contenu. Je précise néanmoins que la première partition est la racine du système (/), tandis que la troisième partition est montée dans /var (contient les journaux, les pages Web, etc...). La première partition (FAT32) de la clé de Recovery est montée dans /home/fghc2-recovery/recovery On étudie maintenant la partition n°3 de la clé de Recovery : [root@redhat mnt]# cd /mnt/sdc3 [root@redhat sdc3]# ls -l total 96 drwxr-xr-x. 2 root root 4096 Dec 8 2011 bin drwxr-xr-x. 3 root root 4096 Dec 8 2011 boot drwxr-xr-x. 5 root root 4096 Dec 8 2011 dev drwxrwxr-x. 74 root root 4096 Aug 30 2013 etc drwxr-xr-x. 3 root root 4096 Oct 3 2011 home lrwxrwxrwx. 1 root root 28 Dec 8 2011 initrd.img -> boot/initrd.img-2.6.32-5-686 drwxr-xr-x. 12 root root 12288 Dec 22 2011 lib drwx------. 2 root root 16384 Dec 8 2011 lost+found drwxr-xr-x. 6 root root 4096 Dec 8 2011 media drwxr-xr-x. 2 root root 4096 Oct 3 2011 mnt drwxr-xr-x. 3 root root 4096 Dec 11 2011 opt drwxr-xr-x. 2 root root 4096 Oct 3 2011 proc drwx------. 4 root root 4096 Sep 12 2012 root drwxr-xr-x. 2 root root 4096 Dec 12 2011 sbin drwxr-xr-x. 2 root root 4096 Jul 21 2010 selinux drwxr-xr-x. 2 root root 4096 Dec 8 2011 srv drwxr-xr-x. 2 root root 4096 Jan 1 2011 sys drwxrwxrwt. 2 root root 4096 Aug 30 2013 tmp drwxrwxr-x. 10 root root 4096 Dec 8 2011 usr drwxrwxr-x. 14 root root 4096 Sep 11 2012 var lrwxrwxrwx. 1 root root 25 Dec 8 2011 vmlinuz -> boot/vmlinuz-2.6.32-5-686 Il s'agit du système Linux sur lequel la box boot en mode Recovery. [root@redhat sdc3]# df -m . Filesystem 1M-blocks Used Available Use% Mounted on /dev/mapper/loop0p3 1467 769 624 56% /mnt/sdc3 . Conclusion Après un certains nombres d'expériences non décrites ci-dessus : La restauration du dump sur la même clé fonctionne, j'ai pu rebooter et faire un recovery. En revanche, la restauration du dump sur une autre clé ne fonctionne pas complètement (certaines fonctionnalités ne fonctionneront pas, comme les sauvegardes, la réinitialisation de la puce Z-Wave, l'exclusion de modules, ... particulièrement en v4 où la sécurité a été renforcée) En effet, Fibaro utilise cette clé comme un dongle de protection. Les informations utilisées sont situées dans le firmware de la clé, et non sur les cellules flash. Par conséquent, elle ne sont pas prises en compte par la commande "dd". Donc si la clé est défectueuse (read only, secteurs défectueux, etc...), la méthode officielle est de se rapprocher du revendeur ou de Fibaro pour procéder à un échange. A noter que dans la mesure où la génération d'une nouvelle clé expose une partie des protections mises en place par Fibaro, ils refusent l'intervention à distance et imposent jusqu'à présent un retour complet de la box. Cependant, dans le cas où les données de la clé USB sont corrompues, mais que la clé n'est pas physiquement endommagée, il est tout à fait envisageable de reconstruire une clé de recovery from scratch pour les utilisateurs qui n'auraient pas fait de clone préalable. Il faut simplement les éléments suivants : - MBR (512 octets) - archive du répertoire system de la première partition - image de la seconde partition Cette expérience a été validée avec succès dans ce topic.

Comment piloter IMPERIHOME depuis sa HC2 et pourquoi ? Imperihome fournit, depuis le 26 janvier 2014, une api qui permet : De faire du TTS (faire parler votre tablette/smartphone) De faire de la reconnaissance vocale (utile que sur certain périphérique) De changer les pages Pourquoi faire : Personnellement, le matin il m’intéresse de connaitre la température extérieur, m'assurez que les enfants ont bien éteint leur lampe, ouvrir le porte du garage, voir s'il pleut, .. Alors que le soir, cela ne m’intéresse plus du tout. Ce que je veux, le soir, c'est allumer la TV, tamiser les lumières, ... J'ai donc créer mes "pages" Imperihome selon mes besoin dans la journée (une page : Matin, une page : Soir, ...) et par rapport à l'heure, ma HC2 change de page automatiquement Sur détection de mouvement dans le jardin, Imperihome affiche automatiquement la page avec la vue de la caméra du jardin. ... A vous de faire fonctionner votre imagination que je sais très fertile. Comment : Simplement en important ce module virtuel et en remplaçant l'adresse IP et le port par celui de votre tablette/smartphone hébergeant Imperihome (je vous conseil d'indiquer une IP fixe). Si vous nécessitez de plus de page, il vous suffit de copier un bouton et de simplement indiquer l'indice de la page souhaitée (la numérotation commence à 0. Le pageIdx 4 affiche donc la page 5, pageIdx 0 affiche la page 1, .... status, response = HC2:GET("/api/rest/dashboard/gotopage?pageIdx=4") IMPORTANT : Par défaut, les API d'Imperihome sont désactivé. Vous devez allez les activer dans les "Préférences générales" d'Imperihome et "Activé le serveur HTTP API" (tout à la fin). Notez par la même occasion le port "8080" par défaut. Have fun Spéciale dédicace à @Moicphil et @Yohan : "aucun support pour vous 2 ... vous êtes trop méchant" Cliquer sur l'icone avant de la sauver sur votre poste sinon, elle n'aura pas la bonne taille et ne fonctionnera pas. Imperihome.vfib

Voici un tuto pour récupérer les valeurs des capteurs connectés à un serveur Owserver L'Owserver est un boitier raccordé sur le réseau permettant d'y connecter des sondes 1wire et de voir les valeurs en l’interrogeant depuis un navigateur. Je l'ai depuis 5 ans maintenant et il me permet de remonter les données de sondes de température DS18B20 de ma piscine. Je précise que le code a été développé par Steven et qu'il ne remonte pour l'instant que les sondes de température mais moyennant peu de changement dans le code il doit être possible de récupérer les valeurs d'autres sondes (Hygro, luminosité etc) Le virtuel Device remonte les données de 4 capteurs. Un bouton mise à jour permet de forcer la récupération des valeurs. Les valeurs sont remontées toutes les minutes. Il faut bien entendu indiquer votre adresse IP local OwserverURL = Net.FHttp("192.168.0.3"); local xml = OwserverURL:GET("/details.xml"); Fichier icone de l'owserver et le fichier du Virtual Device Owserver.vfib

Ce module permet de piloter l'arrêt, la petite et la grande vitesse à l'aide d'un FGS-221. La VMC n'est pas prévue pour être à l'arrêt initialement mais je trouve ridicule de la faire tourner les jours rouges (je suis en Tempo) qui sont généralement les plus froids. Une conso électrique pour en plus mettre de la chaleur dehors, plus jamais même si les radiateurs à chaleur douce sont en appoint d'un insert. La salle de bain à l'étage est en pignon et assez éloignée de la trémie de l'escalier donc pas réellement chauffée par l'insert. . Voici le schéma sur lequel je suis partit. Ayant un doute sur la possibilité de ma VMC à lui raccorder la grande vitesse en même temps que la petite, j'ai préféré ajouter un relais inverseur pour suivre le même câblage que le va-et-vient d'origine. L'astuce est de faire le pont entre la phase et O1 (marche-arrêt) puis d'alimenter le contact inverseur du relais en In et enfin sortir de O2 pour alimenter la bobine du relais (PV-GV). J'ai choisi des poussoirs à voyant Mosaïc pour les commandes et pour l'état un voyant vert pour la marche en petite vitesse et un voyant rouge sur le second poussoir pour la grande vitesse. Il me manquait des fils entre la VMC et une boîte à l'étage (au dessus du plan de travail). Je vous précise cela car ça ne voulait pas passer et j'ai été obligé de débrancher les fils existants dans la gaîne (circuit PC + circuit 20A + alim. d'un éclairage + 3 fils VMC), d'y accrocher une aiguille et ressortir les 7 mètres pour y ajouter mon neutre + d'autres en réserve pour ensuite les repasser tous ensemble (c'était chaud mais pas impossible). Pour les commandes des boutons, rien de compliqué La main loop pour le retour des 3 états. Un grand MERCI à Steven qui, une fois de plus à répondu présent pour me dépatouiller de Lua. --[[ %% properties %% globals --]] local id_vmc_lent = 236 local id_vmc_rapide = 238 local id_module_virtuel = fibaro:getSelfId() local lentAllumer = tonumber(fibaro:getValue(id_vmc_lent, "value")) == 1 local rapideAllumer = tonumber(fibaro:getValue(id_vmc_rapide, "value")) == 1 local icon = fibaro:getValue(id_module_virtuel, "currentIcon") if (lentAllumer and rapideAllumer) then -- icone rapide icon = 1097 elseif (lentAllumer) then -- icone lent icon = 1096 else -- icone éteint icon = 1091 end fibaro:call(235, "setProperty", "currentIcon", icon) Et enfin, les icônes au cas où vous ne les auriez pas déjà trouver dans le topic de Steh (Banque Icônes Hc2 & Hcl). Bien sûr, je n'ai pas fait ce module juste pour pouvoir m'amuser avec la VMC de la tablette mais je compte bien la faire taire complètement les jours rouges et peut-être aussi lui faire forcer la grande vitesse quand le taux d'humidité dans la gaîne de la salle de bain sera trop élevé mais encore faudrait-il trouver une sonde adéquate.

Notification Center Le centre de notifications à pour objectif de centraliser au mieux les besoins en communication en mettant à disposition une interface (lua) permettant d’accéder à divers services (HC2 Push & Mail, Pushover, passerelle personnalisée etc.) afin de pousser des messages dynamiques et informations diverses vers l’ extérieur. Version: 1.0.1 Phase du projet : Bêta Actuellement « Notification Center » est capable de gérer de manière automatique des demandes de notifications (concurrentes ou non) en utilisant les services suivants : HC2 Push (Mobile ID) HC2 Email (User ID) Pushover: Simple Notifications for Android, iOS, and Desktop (https://pushover.net/) Pushingbox (http://www.pushingbox.com) Prowl (http://www.prowlapp.com/) En cours d' intégration: Passerelle personnalisée (Ex : script php free sms, etc.) LiveNotifier (http://www.livenotifier.net) Roadmap: SMS Gateway & PAW Notification XBMC (Popup) TTS (support tiers) Messages prédéfinis (avec "template" ou non) Périphérique virtuel avec retour visuel : Nombre d’envois (Jours/mois), état du moteur de notification etc. Table de correspondance Mobile ID / User ID <-> Périphérique / Utilisateur par réflexion de l’API Panic Mode: routage automatique de tous les messages (prioritaires) vers une passerelle GSM (PAW, SMS Gateway) en cas de défaillance de fourniture Internet (ADSL/Fibre/Etc) En cours d'enrichissement...

Evénements Module virtuel pour afficher les derniers événements Lorsque l'on fait des tests, il est parfois pratique d'avoir la liste des derniers événements ayant eu lieu sur notre HC2. Voici donc mon dernier module virtuel avant les vacances :-) Comme vous pouvez le voir, ce module affiche les 10 événements en oubliant volontairement les modules de températures. Si vous voulez voir plus d'événements, il vous faudra rajouter vous-même des labels en faisant juste attention que leur ID suivent la numérotation Label11, Label12, Label13, ... et modifier la position du bouton rafraîchir dans le Main Loop. J'ai volontairement ajouté la pièce pour certaine personne qui se reconnaîtrons Ce dernier affiche donc : Le nom du module concerné La pièce dans laquelle il se trouve Son ancienne valeur Sa nouvelle valeur L'heure de l'événement Ce module se rafraîchi automatiquement toutes les 3 secondes . . . Installation Il vous suffit juste d'importer le module virtuel ci-joint puis de modifier votre pseudonyme et mot de passe qui se trouve dans le bouton Rafraichir local user = "admin" local pwd = "password" HC2 = Net.FHttp("127.0.0.1",80) HC2:setBasicAuthentication(user, pwd) ... Cordialement Evenements.vfib

My Batteries (sujet clos) Module virtuel pour afficher l'état de vos batteries ATTENTION : Jojo a repris ce module virtuel pour l'améliorer et le rendre compatible 3.x et 4.x, ce topic n'a donc plus de raison d'être. Je ne peux que vous conseiller d'aller voir son travail ICI. Personnellement, j'aime bien avoir un visuel de l'état des batteries de mes modules. Habituellement, je lançais un simple scénario qui me retournait l'état de ces derniers.J'ai décidé de modifier mon code pour le transformer en module virtuel afin que tout le monde puisse en profiter Comme vous pouvez le voir, ce module affiche les 10 modules ayant les piles les plus faibles et trier par ordre du plus petit au plus grand. Si vous avez plus de module, il vous faudra rajouter vous-même des labels en faisant juste attention que leur ID suivent la numérotation Label11, Label12, Label13, ... Ce module se rafraîchi automatiquement toutes les 12 heures (paramétrable dans le Main Loop) local nbHeure = 12 . . . Installation Il vous suffit juste d'importer le module virtuel ci-joint Cordialement Historique : 28.08.2014 : Ajout détection des piles à l'état critique My_Batteries.vfib