[Plugin Tiers] Plugin Protocole In One By Legrand (IOBL)

[alx68]

Oui je fait sa ce soir.
Merci

Envoyé de mon TREKKER-X3 en utilisant Tapatalk

[alx68]

Salut @apages
Je te joint l'imprim écran de l'équipement pilote par mon 67215 en faite c'est un 67202 . Je n'ai rien d'autre dessus il ne me sert que pour mon couloir la nuit.

equipements pilotes.png (656.06 Kio) Consulté 1561 fois

J'oublie tu devrais bientôt avoir les modules hs qui arrivent.
Je te félicite encore pour ton super taf.

[apages]

@alx68

Salut, Une nouvelle version demain qui implemente l'action for time (pour le 67215) et l'action in time

J'ai fait un gros menage sur les update des lumieres, si tu peux aussi retester le 67214 !!!!

Par contre pour le 67215, je n'ai implémenté pour l'instant que l'allumage pendant un temps, A priori, on peut faire aussi la meme chose avec une lumiere toujours allumé et qu'on eteint pendant un temps sur detection. ca vaudrait le coup de le tester

Bye

[alx68]

Salut @apages

Tous est est ok pour les 67214 ,pour le 67215 les action in time ok en fonction du temps du slide ou implémenté en dur dans le module les équipements pilotés se mettent a on et au bout du temps déterminé a off le seul (hic) c'est que le status n'apparrait pas dans les trames de boxio mais bon tous fonctionnent nickel .
Bon boulot franchement tu assures.
Je vais essayer ce week-end les action for time.

[Gugus1er]

Salut,

J’étais en déplacement début de semaine donc j'ai pas trop suivi le fil.
J'ai quand même pas résister a installer la mise a jour ce matin...
J'ai testé le statut du l'inter VMC 67451 ce matin en prenant ma douche ... il est bien mis a jour après retour a la vitesse normale.
La variation sur les 67214 marche aussi très bien, le % dans Jeedom est bien mise a jour après appui physique sur l'inter.
Super boulot ! Merci mille fois !
Je teste ce week-end mes problèmes de préréglages +/- .
Bonne journée et encore merci ...

[alx68]

C'est ok pour le status du 67215 on ve vois pas la commande de mise a jour du status dans les logs boxio mais dans la partie scenario on voie bien qu'il change d'état avec le testeur d'expression donc tout est ok !!!!!!.Je suis aller un peu vite sur mes tests.

Merci

[apages]

Salut alx68.

Je ne comprend pas ce que tu entends par : on ve vois pas la commande de mise a jour du status dans les logs boxio

Il faut savoir que pour le retour d'un etat apres un timer, je m'appuie sur les fonctions de base de jeedom. Celle-ci s'appel valeur de retour d'etat et durée avant retour d'etat et se trouve dans les commandes de type Info. c'est donc pour cela que tu ne les voit peux etre pas dans les logs boxio la mise a jour est faite via un cron depuis le core jeedom

Par contre, la limite est que ces mises a jour ne se font que par modulo d'une minute. Donc si ton timer est de 30 secondes, jeedom ne se mettra a jour qu'au bout d'une minute (voir 1minute 50), mais la je ne peux pas faire mieux car c'est une limite de jeedom

Sinon pourrais-tu tester le second mode de ton inter 67215 (lumiere eteinte pendant X secondes) voir les trames que celui-ci envoi ?

Bye

[apages]

@alx68

Autre chose, Il me semble que l'inter auto utilise des trames ACTION-FOR-TIME et non ACTION-IN-TIME (en tout cas c'est les trames que tu m'avait envoyé). n'y a t'il pas une inversion dans ton messages de ce matin ?

[alx68]

Oui je pensais qu'il fallait voir les trames sur le log de boxio pour pouvoir récupéré le status et l 'implémente dans un scénario .Mais en faite sa marche j'ai essayer dans un scénario et le retour d'état est presque instantanée​ par rapport au changement d état .En tout cas sa fonctionne super .
Et oui je me suis trompé de matin c'est bien des trames action for Time. Désolé je suis aller un peu vite.

Envoyé de mon TREKKER-X3 en utilisant Tapatalk

[apages]

Pas de soucis, mais du coup j'étais un peu perdu

Du coup je clôture l'issue sur le git


Envoyé de mon iPhone en utilisant Tapatalk

[alx68]

Et une issue encore en moin

Envoyé de mon TREKKER-X3 en utilisant Tapatalk

[apages]

Pas de soucis, mais du coup j'étais un peu perdu

Du coup je clôture l'issue sur le git


Envoyé de mon iPhone en utilisant Tapatalk

[alx68]

Salut @apages

Tu peux même en fermer deux ,le problème de log aussi a disparu !!!

[apages]

Bonjour a tous,

En faisant des modifications dans le code du plugin pour integrer les 67214 et 67215, je me suis apercu qu'il y avait des modifications de comportements dans le core de jeedom.

Du coup, le retour de statut des VR n'a pas l'air de fonctionner. Quelqu'un parmis vous a t'il aussi constaté que les status des VR ne fonctonne plus?

[alx68]

Pas de soucis de mon coter local ou jeedom, scenario ca a l'air ok.

[apages]

et si tu arretes le volet en plein milieu, t'as le niveau d'ouverture correct ?

[alx68]

Oui pas de soucis la dessus.

Envoyé de mon TREKKER-X3 en utilisant Tapatalk

[Gugus1er]

Pas de soucis avec les VR a priori chez moi non plus ...
Status bien mis à jour.

[Gugus1er]

Juste une remarque concernant le status des volets.
Pour le moment, le status numérique donne le % d'ouverture et pas de fermeture. Par exemple, si le volet est ouvert on est à 100% et pas à 0% ...
L'inverse serait plus logique ou c'est moi qui ne suis pas logique

J'ai essayé le volet 67251 en mode inversé mais ça donne le même résultat. Quelle est la différence entre les 2 ?
Merci et bonne soirée.

[apages]

Bonjour gugus1er.

La raison du 100% Ouvert est simple, c'est le fonctionnement de Jeedom. Sur l'appli mobile ou sur les widget, une valeur a 100% affiche un volet complètement ouvert. Si j'inverse dans le plugin, le rendu visuel dans le dashboard et dans l'appli mobile ne sera pas correct

le volet en mode inversé permet de prendre en compte un interrupteur qui serait monté a l'envers. En gros le bouton descendre vers le haut et le bouton monter vers le bas

Cordialement