jjacques68

Je ne pourrais pas te dire... je sais pas... Moi la latence dont je parle est avec un FGMS est d'une seconde environ qui est acceptable je pense. Par contre lorsque j'actionne des lumières connectées avec un IPX ça passe à 1 voir 2 secondes... mais ça je pense que c'est normal, vu que l'on passe par des requêtes HTTP pour piloter l'IPX... et c'est bien dommage...

Alors chez moi le flux est nul de chez nul, le refresh se fait toutes les 2 secondes... donc c'est peut être normal... pour visionner les caméras, je passe par une appli tierce, et le flux est très bon...

Mais c'est pas bête ça... mais bon ... ça va commencer faire chère la commission

rigoles pas mais OUI !!!

pas de soucis

OOOOKKKKK je vais faire... Mais vous avez intérêts à y apporter des améliorations justement et je posterai ça où ?

bon suis en congé, vais essayé de faire ça ce weekend... Mais c'est un sacré boulo... du moins surtout d'expliquer la logique qui est derrière justement... (en plus ma logique à moi qui ne l'est pas toujours...)

ah bonne remarque ! dans mon cas oui l'utilisateur est admin de la caméra...

je sais pas faire les tutos mais je peux poster les codes si vous voulez...

j'en ai 2 des FI9853EP, j'ai les même paramètre que @pepite, avec comme différence : le modèle sélectionné est bien FOSCAM J'ai aussi mis le login et password dans les champs correspondant, même s'il est remis dans les URL... URL des mouvements : mouvement gauche = /cgi-bin/CGIProxy.fcgi?cmd=ptzMoveLeft&usr=user&pwd=pwd mouvement droite= /cgi-bin/CGIProxy.fcgi?cmd=ptzMoveRight&usr=user&pwd=pwd mouvement haut = /cgi-bin/CGIProxy.fcgi?cmd=ptzMoveUp&usr=user&pwd=pwd mouvement bas = /cgi-bin/CGIProxy.fcgi?cmd=ptzMoveDown&usr=user&pwd=pwd envoyé stop après la commande = coché JPG = désactivé MPEG = activé tu renseigne bien l'IP et le port de ta caméra ? Le port est ouvert sur le routeur ?

Moi j'ai mis une WillTec DQ220 et un compteur Gioanola 1 pulse/0.25l. compteur branché sur l'IPX. plusieurs scènes qui me permettent : - de couper automatiquement l'eau si ça consomme plus de 15 min. - une scène qui me calcul la conso - une scène qui me calcul le débit (pas super précis à cause de l'IPX/compteur) - une scène me détecte les petites fuites genre goutte à goutte, mais marche pas pour la goutte qui,tombe toutes les heures - un VD qui m'affiche la conso du jour/semaine/mois/année Et la dernière conso effectuée. - un VD qui me permet de piloter manuellement la vanne d'arrêt (au cas où ) les infos mesurées sont très proches de la réalité (quelques litres près). donc je suis plutôt satisfait de l'ensemble... et je conseille ce matos...

Ah je sais pas, moi j'aime bien Envoyé de mon iPhone en utilisant Tapatalk Pro

Pour le plantage de la box, ok avec toi... Cette installation est pour la SDB. pour la VMC, elle est déjà sur le relai 2, Et est pilotée via une scène différente de celle de l'éclairage avec le relai 1. et oui je m'en fiche effectivement de la latence de la VMC. actuellement la VMC s'allume sur détection du FGMS (marche forcée possible avec inter) avec une condition supplémentaire, elle ne s'allume que si je consomme de l'eau. Car j'en avais mare d'avoir la VMC qui s'enclenche dès que je cherche qqch. et oui elle se coupe 1 min après la fin de détection du FGMS je sais c'est un peu nul. j'ai la même installation pour les WC mais sans VMC. ensuite pour ma marche forcée (gérée par scène), ce qui me pose problème, c'est que si j'enclenche l'inter alors que la lumière a été allumé par le FGMS, elle n'est pas prise en compte. voici le code de la scène (assez simple): --[[ %% properties 313 value %% events %% globals --]] --313 = FGSM --311 = FGS local LightOn = false if fibaro:countScenes() > 1 then fibaro:abort() end if tonumber(fibaro:getValue(313, "value")) == 1 then --si pir ON if tonumber(fibaro:getValue(311, "value")) == 0 then --si la lumière est éteinte print("allumage automatique") LightOn = false fibaro:call(311, "turnOn") else --sinon c'est qu'on est en marche forcée print("marche forcée en cours...") LightOn = true end while tonumber(fibaro:getValue(313, "value")) == 1 do end --boucle tant que PIR = ON if LightOn == false then --si pas marche forcée print("Extinction automatique") fibaro:call(311, "turnOff") else --si marche forcée, on laisse allumé print("Extinction annulée car marche forcée...") end end

Pour revenir à mon histoire de latence, Marche forcé et association directe, ... si je fait un allumage du relais 1 par association directe (donc pas de latence) ainsi qu'une extinction par scène, le risque c'est que si la HC2 plante, ma lumière ne s'éteindra jamais !!!! j'ai juste dans mon raisonnement ? Si je fait le off du relais 1 par l'association directe, comment se comporte la marche forcée avec l'interrupteur (pas de auto-off sur le relais 1) ? Là ou ça va se compliquer, c'est que la VMC tourne encore 1 minute après l'extinction (actuellement programmé dans scène) !

ça chauffe sur le fofo fibaro j'ai arrêté de lire la fin de la première page... je comprends les utilisateurs "pessimistes" tout en restant fidèle à fibaro...

Oh punaise j'ai une idée, je vous tiens au jus Envoyé de mon iPhone en utilisant Tapatalk Pro

@Nico Oui je suis entrain de comprendre qu'il faut faire un mix des 2... mais là ça chauffe dans la tête... Envoyé de mon iPhone en utilisant Tapatalk Pro

@pepite, faut que je cogite la dessus, c'est pas naturel comme algorithme

@Nico : dis comme ça oui ! Et pour la marche forcée ?

@Nico je commence à m'embrouiller moi-même... (2 soucis sont évoqués : la marche forcée et la latence d'allumage en passant par une scène) on parle bien de la même chose, mais je ne peux pas utiliser l'association directe avec ta méthode car j'utilise les 2 sorties du relais FGS. Et je ne veux/peux pas mettre 2 FGS... Donc je suis obligé de passer par une scène (voir plusieurs d'après la solution proposé par @pepite). Mais allumer qqch via un FGMS et une scène créé de la latence... Chose que j'ai constaté également avec un FGMS et l'action d'une sortie d'un IPX (mais ça semble plus logique et hors sujet ) Donc je trouve pas vraiment de solution à mon problème... même avec vos propositions. Et le fait de chercher à savoir si l'inter est actionné ou non me permettrai de résoudre mon soucis de marché forcé (mais pas celui de la latence). oula j'ose pas me relire

Oui mais ! impossible de savoir si la lumière à été allumé par le fgms, ou pas l'inter !!!!! donc obligé de passer pas une scène, voir 2, si pas trois... et une variable... bonjour le retard d'allumage. un retard que je constate aussi lorsqu'un éclairage, branché sur les output d'un IPX, est allumé par détection du FGMS... en passant car un VD...

Faut que je réfléchisse... En plus on perd en réactivité avec la scène... Envoyé de mon iPhone en utilisant Tapatalk Pro

Ok mais c'est mort ta solution@Nico, j'utilise les 2 relais du FGS... et puis il me semble qu'il y a des soucis avec l'association directe et les relais 1 ou 2 d'un FGS... nan ? Envoyé de mon iPhone en utilisant Tapatalk Pro