Lazer

OK je comprends.... dans mon cas c'est l'inverse, puisque j'ai justement profité du passage à la fibre pour résilier mes hébergements chez OVH (je n'ai conservé que les noms de domaines), et j'auto-héberge tout. Le cout devient nul, puisque mon NAS serait allumé quoi qu'il arrive à domicile. Je fais donc d'une pierre 2 coups. Mais pour que cela soit viable, il faut que l'accès fibre soit fiable, ce qui est le cas chez Orange. En plus j'ai gratuitement (enfin dans le prix de l'abonnement) une puce Orange 4G pour faire du failover. Il me semble que Free n'offre pas ce service (à moins de payer un abonnement séparé) Du coup, la légende est vérifiée.... personne n'a la fibre Free

Bienvenue sur le forum

VPN c'est hors de question de faire transiter mon flux par des serveurs russes/chinois/whatever non contrôlés. Du coup la vraie question c'est est ce que les problèmes de peering sont toujours d'actualités ? Tu as constaté ? En fibre j'entends, parce que les débits ridicules du xDSL ne permettent pas vraiment de savoir si ça coince en amont.

Rien ne te dis que le contact de réveil se fasse réellement. Après je ne suis pas spécialiste du protocole, mais peut être que le réveil ré-envoie réellement les trames 15 fois jusqu'à ce que la communication passe, ce qui ne serait pas le cas pour la signalisation de fin de mouvement (voir mes 3 hypothèses données plus tôt)

Oui voilà, c'est cela même C'est ce que je disais juste au dessus, mais c'est peut être plus clair avec tes mots. Pour pinailler un peu, ce n'est pas un "ping", mais c'est un peu plus évolué. Lors du réveil, le module se signale au contrôleur Z-Wave en lui disant : "Hey toi, je suis réveillé, et je vais t'écouter pendant quelques secondes, juste au cas où tu aurais quelque chose d'intéressant à me dire, avant de me rendormir". C'est à ce moment là que la HC2 peut envoyer des nouveaux paramètres au module. C'est la raison pour laquelle, après avoir modifié les paramètres d'un module depuis la box, il faut aller réveiller le module. Le réveil est la seule façon de transmettre les nouveaux paramètres au module.

Hum, c'est nouveau, maintenant je me tâte : En plus je suis tout juste en limite de couverture, ça ne s'invente pas Qui a la la fibre Free, et en est content ? Débit vraiment au top tout le temps et sur tous les sites ? Je suis chez Orange, alors même si le réseau est au top et je n'ai eu quasiment aucune panne et un débit toujours au top du maximum (1Gbps théorique, 950 Mbps mesurés), le prix est prohibitif. Du coup je me tâte à changer, Free n'a pas bonne réputation sur le respect des peerings avec les gros réseaux (Youtube, Netflix, etc) Et encore ce test date de l'installation de ma ligne, depuis Orange a poussé l'upload à 300 Mbps. Vous en pensez quoi ?

Bienvenue sur le forum

Tu devrais relire le petit topo que j'avais fait à ce sujet dans la section pour les nuls. Car là tu mélanges le polling et le réveil, qui sont 2 choses qui n'ont rien à voir, puisqu'ils concernent des devices différents (polling pour les devices sur secteur, réveil pour les devices sur batterie) La phrase "le device ne répond pas aux intervalles de réveils" n'a pas de sens, puisque par définition un device sur batterie (donc avec un intervalle de réveil), ne répondra jamais aux sollicitations de la box. En effet, le réveil se fait toujours à l'initiative du module sur batterie. Pour déterminer un module comme mort, la box procède comme suit : - module sur secteur : interrogation (pollling) régulière du module, paramétré dans les propriétés générales de la box (plus on a de modules, plus on élargi l’intervalle afin de ne pas saturer le réseau en "pings" inutiles), sous réserver que le polling n'est pas été désactivé dans les propriétés d'un module en particulier. Si le module ne répond pas suite à la tentative de polling, ou suite à la tentative d'envoi d'un ordre (on, off, dimmer, etc), alors la box le marque comme mort. - module sur batterie : comme dit, la box n'a aucun moyen de joindre le module, donc elle attend. Elle connait l'intervalle théorique de réveil du module, puisque qu'il est stocké dans ses propriétés (visible dans l'onglet adhoc) lorsque l'utilisateur l'a paramétré. Statistiquement, si le module n'a pas contacté la box depuis plus longtemps que l'intervalle de réveil, alors elle part du principe qu'il est théoriquement mort (plus de piles, etc...). C'est amusant pour un module tel que le Fibaro Button pour lequel on peut désactiver l'intervalle de réveil (pour préserver les piles, c'est d'ailleurs une très bonne idée). Dans ce cas le module ne passera jamais en noeud mort.

En fait la HC2 n'a aucun moyen de savoir si le capteur est dans la portée ou hors de portée.... car il s'agit d'un capteur sur pile, donc "endormi", c'est à dire qu'il n'écoute pas le réseau. La box ne peux pas le joindre à intervalle régulier (polling) pour interroger son état. Donc c'est bien le capteur qui envoie en statut en cas de changement d'état (mouvement début/fin), ou de température, luminosité, etc. Seulement si tu es en limite de portée, le capteur a des chances de ne pas pouvoir joindre la box, et les trames Z-Wave se perdent dans le réseau. Normalement le mécanisme de retour d'état est censé éviter ce genre de situation, car selon la norme il peut faire jusqu'à 15 tentatives d'émissions pour joindre sa cible. Cependant je soupçonne : - que certains modules, notamment ceux sur pile, limitent la ré-émission de trames pour économiser la batterie - envoie leurs trames avec une priorité faible, si bien qu'en cas de congestion du réseau à ce moment là, la trame se perd et n'arrive jamais à la cible (je sais que c'est le cas des rapports de puissance des Wall Plugs) - ne respectent pas parfaitement le protocole Z-Wave Je ne dispose pas des outils pour confirmer ou infirmer mes hypothèses....

tout à fait Bon après ce genre de plaques doit représenter une très faible partie de leurs ventes. Partout où je vais je vois la finition plastique classique, seule la couleur change. J'avais pris quelques finitions bois et alu chez moi, mais c'est relativement hors de prix....

Ils n'ont pas voulu s'embêter.... Et puis comme ils disent, il y a tellement de plaques de finitions différentes, que ça doit être un casse tête pour trouver une solution universelle. Perso je trouve déjà excellent qu'ils aient penser à prévoir une compatibilité avec d'autres finitions plutôt que d'imposer leur style. Sinon faut prendre le problème à l'envers, demander à Legrand de sortir une gamme de plaques de finitions avec des zones translucides correspondant aux diodes Fibaro. Aller, on peut rêver....

Hum... oui recommence. Et comme je disais à Nico, ne pas oublier d'activer ONVIF sur la caméra.

Cela sera aussi le cas pour le Switch, c'est assez logique en fin de compte. Après si tu as fait le choix du Celiane, c'est à priori que tu aimes bien le coté sobre, donc ça ne devrait pas trop gêner de ne pas avoir de diode multicolore flashy !

C'est clairement une réponse générique du gars qui n'a rien compris, ou plutôt n'a rien cherché à comprendre. Pour moi ce problème est clair : problème de signal Z-Wave. J'ai typiquement eu ce problème avec différents capteurs (pas forcément des FGMS) qui étaient en limite de portée. Le premier changement d'état passe bien (la détection de mouvement), mais le second passe 1 fois sur 2 (la remise à 0 du mouvement). Bref, je préconise d'améliorer le maillage du réseau en ajoutant des modules relais (= sur secteur) dans les environs des capteurs qui posent soucis.

Maintenant on va configurer la détection de mouvement par analyse d'image de la caméra (à la place de laisser faire le travail par le Syno), donc là on aura beaucoup de faux positifs (mais on s'en moque, au pire ça enregistre des choses inutiles sur le disque dur) Cela se passe dans "Evénement", puisque pour rappel, les "événements intelligents" ne sont pas gérés par Surveillance Station (on en a parlé il n'y a pas longtemps) : Il faut toujours activer les options suivantes : La suite de la config est identique sans Surveillance Station. Donc là on va déclencher l'enregistrement basé sur l'analyse d'image de la caméra, ce qui a pour avantage de décharger le CPU du NAS, surtout utile quand on a plusieurs caméras. A noter qu'on peut activer simultanément la détection de mouvement par analyse d'image et le PIR si la caméra en est activé. C'est le cas sur ma caméra dont j'ai parlé au post précédent.

Alors, reprenons. Configuration du capteur PIR sur les caméras type "Cube", avec pour exemple mon modèle DS-2CD2432F-IW Dans mon cas, le capteur PIR : - active la sortie d'alarme sur laquelle est relié un IPX800 v4 via un câble - déclenche le démarrage automatique de l'enregistrement sur le NAS Synology Surveillance Station. Précision : je suis sur un relativement vieux firmware v5.4.41, cela a peut être changé sur les modèles récents. (c'est une caméra chinoise que j'ai "transformé" en caméra internationale multilingual grâce à une faille, j'en avais parlé sur le topic) On commence par Activer le capteur PIR et définir une programmation 24/7 : On active les méthodes de liaisons désirées : - Avertir centre de surveillance => Synology - A->1 => pour activer la sortie physique vers l'IPX800 - A1=> je ne me souviens plus trop mais je pense qu'il faut le cocher Je vous suggère d'activer l'avertissement audio pour les tests, même si ça casse assez vite les oreilles. Pour mon IPX800 il faut que je configure la sortie d'alarme avec un planning 24/7, j'ai mis un délai de 5s qui correspond à la "durée" du mouvement, c'est à dire le temps pendant lequel la sortie restera active dès la détection du mouvement : Dans Synology Surveillance Station, on configure la caméra en ONVIF : On active le pré-enregistrement pour être certain de ne rien manquer dès la détection de mouvement : La planification "Personnaliser 1" en 24/7 avec les détections : - Détection de mouvement - Falsification de la détection (optionnel, il faut activer l'anti-sabotage sur la caméra... personnellement j'ai eu beaucoup de faux positifs, donc j'ai désactivé) Et ça devrait fonctionner. Au final cette caméra avec détecteur PIR intégré est installée dans mon garage, et je n'ai quasiment aucun loupé, c'est très très fiable. Par contre ce simple détecteur PIR en extérieur ne serait à mon avis pas fiable, beaucoup de faux positifs (chats, oiseaux, nuages, végétation, etc....)

Hum, dommage, comme dit dans mon message précédent, cette API est la dernière connue. Cela a peut être encore changé, je n'ai pas essayé récemment. Remarque, je ne sais pas si ça fonctionne sur localhost, essaye avec l'IP de la box plutôt, juste au cas où.

Non tu n'auras pas de retour d'état de la TV avec ce code, ce que tu auras c'est juste un retour de la commande que tu as passé... en gros est-ce que la TV a bien reçu l'ordre que tu lui as donné. Mais tu ne sauras pas si elle s'est réellement éteinte, et encore moins si quelqu'un l'a rallumé juste après (avec la télécommande, etc) A toi de voir si ça te convient ainsi ou pas. Perso tous mes équipements multimedias sont sur Wall Plug ou Powernode. Mais scénarios sont basés sur leur consommation pour savoir si chaque appareil est réellement allumé ou non. C'est le retour d'état le plus fiable possible.

OK tu as surement raison. Sinon en alternative à la prise HDMI (qui obligé à laisser tourner un RPI qui va consommer 5 watts en permanence), tu peux regarder du coté des télécommandes infrarouge. Je pense que les lignes fournies par Pepite ne te seront pas trop utile, il te proposait juste cela pour obtenir la liste des actions que permettent ce plugin. Tu peux le faire plus simplement en tapant l'URL dans ton navigateur avec l'ID de ton plugin. http://IP_de_ta_box/devices/ID_de_ton_plugin

j'ai la DS-2CD2432F-IW exactement, et chez moi ça marche : le détecteur PIR déclenche bien l'enregistrement sur le Syno. J'essaierai de poster une copie de toute ma config ultérieurement.

Oui et non.... depuis le firmware v4.500, la HC2 est intégralement reformatée à chaque mise à jour. Donc même si tu root la box, toutes les modifs que tu fais seront perdues.... il ne me semble pas viable d'avoir un script qu'il faut sans cesse réinstaller. Du coup je pense qu'il est mieux d'avoir un script qui tourne sur un autre support.... comme le NAS. Par contre depuis 3 ans, les API pour redémarrer les services ou rebooter la box ont changé :

Le Wall Plug ne te servira pas à allumer la TV, mais juste à remonter le statut de la TV (allumé/éteint) en se basant sur sa consommation. Car le plugin de Fibaro, me semble t'il, n'offre pas de retour d'état. Donc le plugin pour piloter la TV, et le Wall Plug pour le retour d'état. Par contre, si Samsung ne permet pas d'éteindre/allumer, il faut acheter une vraie marque, alors ton idée de passer par HDMI est bonne. Ce point a déjà été traité :

Ce qui peut faire la différence aussi, c'est si tu te connectes à la caméra avec ONVIF ou le package Hikvision. Perso j'utilise ONVIF car c'est universel et que j'ai une vieille version de SS sans les devices packs récent. Il y avait une page sur le site de Synology qui donnait les compatibilité entre les différentes fonctionnalité (PIR, détection mouvement, enregistrement local, etc etc....) en fonction du mode de connexion retenu, mais je ne la retrouve pas.

En complément, voici ce que j'ai pour la sortie d'alarme : On voit qu'il faut aussi cocher "Avertir le centre de surveillance"

Avec "personnaliser 1" justement, on en parle au dessus. @Did Tu as cet écran ? Je suppose qu'il faut juste définir un planning sur toutes les tranches horaires et ça devrait fonctionner.