razowski

Les deux dernières réponses sont contradictoires : scheduler vs trigger. Selon test en cours, si je start ma lampe maintenant, elle devrait s'éteindre, mais ce n'est pas le cas. Je pense que l'utilisation du scheduler est bien nécessaire, right ?

Merci

Merci pour le partage.... J'ai repris le script et adapté ce dernier à mon besoin. Par-contre, un point qui n'est pas clair pour moi : l'évaluation est réalisée tous les combien de temps ? Ne faudrait-il pas ajouter une notion de fréquence ? (vérifier chaque heure)

C'est bien ce que je pensais, va falloir dire au revoir aux détecteurs d'ouvertures EnOcean du coup... Merci pour la confirmation Envoyé de mon iPhone àl'aide de Tapatalk

Petit up sur mon post ;-) J'aimerais bien trouver une solution pour rendre un device virtuel "armable"...

Bonjour à tous, Savez-vous s'il est possible d'intégrer un device virtuel dans le panneau d'alarme proposé par Fibaro par défaut ? Je m'explique : je mets en place une passerelle EnOcean <-> Fibaro HC2 (selon excellent tutoriel de l'équipe domotique-info), notamment pour pouvoir utiliser le status de mes contacteurs de porte EnOcean. J'ai donc créé un device virtuel qui est mis à jour par FHEM via l'API de la HC2. Jusqu'ici tout va bien, le status remonte bien. Où je bloque : J'aimerais utiliser ce device virtuel dans mon système de détection d'intrusion et intégrer ce device virtuel au panneau Alarme proposé par Fibaro. Pourquoi me direz-vous? C'est relativement simple, sur les applications mobiles Fibaro, il n'est pas possible de retirer la section "Alarme". Du coup, si je bricole mon système de détection d'intrusion de manière complètement indépendante, je me retrouve avec deux pièces "Alarme" sur les applications mobiles et c'est pas terrible pour le end-user. Merci d'avance de vos idées / remarques / suggestions ;-) @+

Hello, De mon côté, la détection est très mauvaise. J'observe une latence importante par rapport aux autres détecteurs que je possède. Sur détection, le détecteur reste sur "alerte" pendant un long moment sur la Fibaro HC2. Je suis presque certain de ma configuration, ayant essayé différents réglages. Je pense que le matériel n'est pas de bonne qualité, je pense que le problème réside surtout là ... D'autres retours de quelqu'un?

Ne fonctionne pas correctement de mon côté sur un HC2, j'arrive àinclure le détecteur, mais la détection ne fonctionne vraiment pas bien. J'en ai 6, donc il ne s'agit pas d'un détecteur qui pose problème. Aucun problème sur une Eedomus...

Nickel, merci pour les précisions.

Sauf erreur de ma part, dans ce cas il y a du "cross-domaine", car le HC2 est sur le domaine "192.168.xx.xx" (exemple) et la requête "user:password@192.168.xx.xx", la policy XMLHttpRequest identifie cela comme deux domaines distincts. Ma première réaction était identique, on reste sur le même domaine, mais non... Le "inline" était car je n'ai pas réussi à passer le user/password via paramètre, pas faute d'avoir essayé ;-)

1) Mais si c'est un ping, pourquoi un maxRetryProcess? Je conçois que le process pourrait tourner indéfiniment, mais en même temps dans ce cas c'est pas ce qu'on cherche ? 2) Pourriez-vous être plus précis sur l'emplacement où introduire le figaro:sleep(xx) ?

Après différentes recherches, debugging et autre, j'ai trouvé la réponse. En fait, la requête n'est pas autorisée en "XMLHttpRequest" car considérée comme "Cross-Domain"... Je propose une autre alternative si d'autres personnes sont un jour confrontées à la même problématique: réaliser une requête ajax : $.ajax({ type: "GET", url: "http://user:password@xxx.xxx.xxx.xxx/api/callAction", dataType: "jsonp", contentType: "application/javascript", data: {deviceID: "XX", name: "turnOn"}, crossDomain: true, xhrFields: { withCredentials: true }, jsonp: 'jsonp_callback', success: jsonp_callback });

Tout d'abord, merci pour le script. J'ai fouillé les forums mais je ne trouve pas réponse à ma question : pourquoi un "_maxRetryProcess" ? Je souhaiterais que le ping tourne en boucle non-stop de tel sorte que sur changement d'état, je puisse actionner un scénario. Pour le moment, j'ai créé un device virtuel et utilisé ton code dans le main loop, l'idée étant de ne pas devoir cliquer sur un bouton pour lancer le ping. Mon main loop fonctionne. Mon routeur est allumé et ping. Je le reboot et mon device virtuel change de status, l'icône de mon device également. Par-contre, dès que le routeur a terminé son reboot et est à nouveau en ligne, le device virtuel ne se remet pas à jour. J'ai vu sur un de tes posts sur un autre forum qu'il semblait nécessaire de lancer un "FTcpSocket:disconnect();". Serais-tu en mesure d'apporter ton aide ?

Je regarde mais n'ai rien trouvé jusqu'ici... Merci tout de même pour les pistes.

Je suis navré mais je ne te suis pas dans l'explication. Je comprends qu'il s'agit d'un problème d'authentification àpriori. Selon les informations que tu m'indiques, j'ai modifié en cela : //Fonction permettant de retourner le status du périphérique function getDeviceValue() { var req = new XMLHttpRequest(); var credentials = btoa("admin:pass"); req.open("GET", 'http://192.168.12.151/api/devices?id=44', true); req.setRequestHeader("Authorization", "Basic " + credentials); req.onreadystatechange = function () { if (req.readyState == 4 && req.status==200) { var doc = eval("(" + req.responseText + ")"); var val = doc.properties.value; alert(val); } }; req.send(null); } Mais cela ne semble pas fonctionner. Mon "alert(val);" ne me retourne rien alors que je devrais obtenir la valeur du device...

Bonjour, Merci pour les exemples, cela fonctionne en PHP ainsi. J'essaie de le faire au travers d'une requête AJAX. Je me suis inspiré de ce que j'ai réalisé sur ma box eedomus, mais avec la Fibaro, cela ne passe pas. J'ai tout mis en dure dans la requête (user, password et id du device). Lorsque j'appelle le JS via mon browser, j'obtiens une pop-up pour l'authentification. Je pense que cela ne passe pas au niveau de l'authentification mais je n'en suis pas certain.... //Fonction permettant de retourner le status du périphérique function getDeviceValue() { var req = new XMLHttpRequest(); req.open("GET", "http://admin:password@192.168.12.151/api/devices?id=44", true); req.onreadystatechange = function () { var doc = eval("(" + req.responseText + ")"); var val = doc.properties.value; alert(val); //Je n'obtiens rien hormis une popup qui demande user/password et même en saisissant ces derniers, rien ne se passe }; req.send(null); }

Exactement, le syno est une pièce maîtresse dans l'infrastructure ;-) Ca comporte un avantage: j'ai la main sur le tout ET un désavantage: en cas de problème, généralement, je suis le seul responsable ;-)

Elle est en cours, j'ai fait des allez-retour pour faire certains choix, voir si je développais en natif sur iOS ou Android, faire de l'hybrid ou un site responsive design. Après plusieurs essais, tests, j'ai opté pour un site responsive design àbase de JQuery Mobile. Voici 2 pages sur lesquelles je travaille, simple, mais efficace pour mon quotidien :

Bonjour, J'ai parcouru le forum mais ne trouve pas réponse à mon problème. Je tente d'utiliser l'API proposée par Fibaro pour interfacer ma propre interface graphique. Je suis capable de lancer un ordre sur un device via un browser (safari, chrome, ...) mais je ne m'en sors pas en PHP pour exécuté cette même requête. D'après ce que je comprends à ce stade, cela doit être l'authentification qui ne passe pas. Ma requête est de la forme : http://admin:password@IP_DE_MA_BOX_FIBARO/api/callAction?deviceID=59&name=turnOn Dans un navigateur web, j'obtiens une alerte de phising mais en validant, la requête s'exécute et j'obtiens le résultat désiré. Est-ce quelqu'un est en mesure de m'indiquer comment lancer cette même requête via un simple script PHP ou JS? Cela semble pour tant tout simple, mais en vain, je sèche après bien des essais. Merci de votre aide, ouvert à toutes questions / échanges.

La migration s'est bien déroulées vu que j'ai une majorité de modules Fibaro. Néanmoins, après quelques temps d'utilisation : Avantages HC2 : - rapidité de traitement des ordres Z-Wave est top - interface graphique très sympa - possibilité de scripting LUA est un vrai plus Inconvénients HC2: - clairement en retard par rapport à la eedomus, par exemple : pas de parser XML, pas de capteur HTTP, pas de support de EnOcean, documentation pas à jour ou pas proposée en anglais - accès remote via applications mobiles fonctionnent une fois sur deux - impression générale que fibaro pose des limites à l'ouverture de son système Au final, je développe ma propre interface utilisateur (site web responsive design) qui vient accéder à l'API de la Fibaro pour la gestion des modules de base (luminaires, stores, prises et capteurs d'ouvertures, alarme) et à l'API de la Eedomus pour les modules complémentaires (EnOcean pour les ouvertures secondaires, capteur de température, parser XML, ...) et un NAS Synology pour la gestion des caméras de surveillance (Synology Surveillance Station).

Bonjour à tous, Je me permets de me présenter en quelques mots. J'ai 30 ans, ingénieur en informatique, nouveau propriétaire d'une box HC2. Je viens de terminer ma migration depuis une box eedomus vers la HC2. Mon installation domotique comptabilise une cinquantaine de modules Fibaro pour la gestion des luminaires, des stores et des prises électriques de la maison. J'espère pouvoir apporter mon expérience et obtenir de l'aide sur des sujets où je bloque. A bientôt.