Remontée d'état via l'API

[kimagure]

@kimagure : il faut dans ta règle avec les conditions en "OU", que tu mettes tous les états possibles
(...)
parce que sinon tu ne verras pas les changements de 20 à 50 % par ex mais seulement le passage de allumé à éteint.

Je n'ai effectivement pas fait le test hier, mais logiquement, la règle "devient maintenant différent de Off" devrait se déclencher dans ce cas, non ?

K.

[DjMomo]

En fait intégrer un maître xPL dans l'eedomus serait l'idéal. Le protocole est déjà disponible car elle est cliente. Elle possède donc normalement un hub xPL. Reste à implémenter les trois types de messages xPL et c'est tout.

On obtient alors une box ouverte permettant ainsi de communiquer avec d'autres systèmes xPL naturellement.

--> http://www.planete-domotique.com/blog/2 ... ocole-xpl/

Tu as donc fait la demande au support ?
Parce que ça me semble une excellente idée ta proposition.

Fait à l'instant.

[DjMomo]

@kimagure : il faut dans ta règle avec les conditions en "OU", que tu mettes tous les états possibles
(...)
parce que sinon tu ne verras pas les changements de 20 à 50 % par ex mais seulement le passage de allumé à éteint.

Je n'ai effectivement pas fait le test hier, mais logiquement, la règle "devient maintenant différent de Off" devrait se déclencher dans ce cas, non ?

K.

Il faut comprendre "Devient différent de XXX" comme "vient de quitter la valeur XXX". Du moins, c'est comme cela que je le comprends.

[kimagure]

Ca peut effectivement se comprendre comme ça aussi

Je regarderai ca ce soir...

[Nico33]

C'est une bonne question ...
Mais avec le devient différent tu vas avoir des dysfonctionnement je pense.
Par ex: tu passes de OFF à 20% => notif
Puis de 20 à 50 % => pas de notif
Puis de 50 à OFF => notif

Pour éviter cela, j'ai fait toutes les conditions avec "devient maintenant égal à" séparées par des OU :
devient maintenant égal à OFF
devient maintenant égal à 10%
devient maintenant égal à 20%
devient maintenant égal à 30%
devient maintenant égal à 40%
devient maintenant égal à 50%
devient maintenant égal à 60%
devient maintenant égal à 70%
devient maintenant égal à 80%
devient maintenant égal à 90%
devient maintenant égal à 100%

Comme ça aucun changement ne m'échappe.
Mais je ne dis pas que c'est le mieux, c'est juste tout ce que j'ai trouvé

[milillicuti]

C'est une bonne question ...
Mais avec le devient différent tu vas avoir des dysfonctionnement je pense.
Par ex: tu passes de OFF à 20% => notif
Puis de 20 à 50 % => pas de notif
Puis de 50 à OFF => notif

Pour éviter cela, j'ai fait toutes les conditions avec "devient maintenant égal à" séparées par des OU :
devient maintenant égal à OFF
devient maintenant égal à 10%
devient maintenant égal à 20%
devient maintenant égal à 30%
devient maintenant égal à 40%
devient maintenant égal à 50%
devient maintenant égal à 60%
devient maintenant égal à 70%
devient maintenant égal à 80%
devient maintenant égal à 90%
devient maintenant égal à 100%

Comme ça aucun changement ne m'échappe.
Mais je ne dis pas que c'est le mieux, c'est juste tout ce que j'ai trouvé

Punaise ! Multiplié par le nombre d'interrupteur etc...
Vivement que ce soit implémenté dans la box ...

[kimagure]

Bon, je viens de faire le test.

Je confirme les propos de Nico33

Par ex: tu passes de OFF à 20% => notif
Puis de 20 à 50 % => pas de notif
Puis de 50 à OFF => notif

Si on veut que ca marche avec ce système de règle, il faut avoir une ligne pour chaque valeur possible...

Dommage

Reste à attendre une éventuelle évolution pour gérer ce type de notification (via xPL, un callback quelconque...)

K.

[Tinto]

Salut ...

Je lis ton message et je me dit que c'est ce que j'ai fait, faire remonter la valeur a chaque changement d'état ... sauf que j'ai pas fait du tout comme ça, et je l'ai fait en une seule règle

En fait au changement d'état, je compare a une valeur référence ( que j'ai mis a 10000 ).

Si le nouvel état est inférieur à la valeur référence, j’exécute ma règle ( critère "Périphérique" "Est" "Inférieur au périphérique" "Valeur référence" ) ... en gros dès que ton périphérique devient inférieur à 10000 il y a exécution de la règle, soit à chaque fois ...

Je n'ai testé qu'avec un capteur d'ouverture ( 0 ou 100 ) mais ça doit fonctionner à chaque fois en théorie ...

[DjMomo]

Et non justement. Vu que ton périphérique reste forcément en dessous de ta valeur de référence, ta règle n'est exécutée qu'une seule fois.

Dans ton cas, ton critère de comparaison est "est" et non "devient". Ce qui signifie que ta règle est appelée non pas à chaque changement d'état de ton périphérique mais selon la valeur que tu as mis dans "Autoriser le redéclenchement" (ou selon un critère horaire). Plus cette valeur de redéclenchement est basse, plus tu fais bosser ta box pour rien...

[Tinto]

Euh non justement ... enfin je crois pas

Ma regle ne s'execute qu'au changement d'etat ... genre la il y a 51 minutes, quand j'ai ouvert mon detecteur

[DjMomo]

En fait, ta règle n'est déclenchée que lorsque la condition est vraie (on est d'accord sur ce point, je m'étais mal exprimé sur mon post précédent), mais en arrière plan, ta box tourne en permanence pour vérifier si la condition est vrai (qui plus est, tu as un redéclenchement immédiat). Alors que si tu utilises la condition "devient" la box comparera ta condition uniquement lors du changement d'état de ton périphérique, la laissant libre pour faire autre chose quand la valeur de ton périphérique ne change pas.
Il s'agit là d'optimisation. Si tu n'as qu'un seul périphérique avec une seule règle, les performances n'en seront pas améliorées. Par contre, 50 périphériques avec chacun 50 règles, et tu mets à genoux ta box avec ta méthode. Les temps d'exécution et de réponse seront énormément rallongés.

[Tinto]

Je m'étais bien douté de cela ...

Mais je pensais que la règle n'etait vérifiée qu'au changement de valeur ... pourquoi ma règle ne s'éxécute pas constamment alors ? ... parce qu'en sémantique, je suis toujours "est" inférieur ... et donc ma condition toujours vérifiée ...

Tu es sûr qu'il y a une surveillance constante ? je me demande alors pourquoi il n'y a pas d'éxécution indésirée ...

Mon problème avec le devient, c'est que ça ne "devient" jamais inférieur, ça passe de 0 à 100, c' "est" toujours inférieur :-/

[DjMomo]

Ajoute une notification sur le portail à ta règle pour voir exactement quand elle s'exécute. Car je vois plus là. ..

[Tinto]

Salut

Je viens de tester, je n'ai une notification que lors de mes manipulations du detecteur d'ouverture ...

Les trente secondes peuvent porter a confusion, mais ce n'est que pur hasard, j'ai ouvert et refermé a 30 secondes d'écart

[Tinto]

D'un autre coté,

Quel pourrait être l'interet de ce ce "Est" ... quand pourrait on avoir besoin d'éxécuter une règle constamment, voir avec un délai de redéclenchement toutes les 5 minutes ... pendant tout le temps qu'un périphérique est dans un certain état ? la règle fera de toute façon la même chose à chaque fois ... je ne trouve pas d'exemple pour lesquels c'est pertinent ...

Si on veut déclencher quelques chose toutes les 5 minutes ( genre un karotz qui dit "Ta porte du fin fond du garage est ouverte, tu vas l'oublier, va vite la fermer ..." ) on applique une macro qui se rappelle toutes les 5 minutes tant que la porte est ouverte non ?

[milillicuti]

J'ai un peu la même idée en tête avec OpenRemote mais les compétences me font défaut ...

L'idée :
Chaque changement d'état lance une requête http qui inscrit cet état dans une BDD (comme toi).
Là je suppose qu'il faut appeler un fichier php en passant des variables dans l'url.
Ensuite OpenRemote poll toutes les secondes un autre fichier php qui renvoie le statut de tous les modules renseignés dans la BDD pour mettre à jours les capteurs de l'interface.

A moins qu'il n'y ait une autre solution côté OpenRemote (je sais qu'il peut écouter des ports UDP mais là ça me dépasse...) ? Je ne crois pas qu'OpenRemote puisse interroger directement une BDD.

En fait j'aime bien le designer d'OpenRemote. Et comme mon boulot c'est quand même plus le design que la programmation ...

[Tinto]

Salut milillicuti,

Tout d'abord laisse moi te féliciter pour ton site, de toute beauté ... être designer ça aide

Open Remote je ne connais que de ce que j'ai vu sur ton site ... mais, mon problème c'est que je suis développeur de formation, reconverti depuis mais ça laisse des traces ... ça n'a pas l'air d'être un problème à priori mais si on a une idée, on essaye de la créer, sans vouloir réinventer la roue, mais là, vu que ce n'est pas très compliqué, autant tout coder dès le départ, on est sûr qu'à la fin on aura quelque chose qui répond a nos besoins, et il n'y a pas de meilleur moyen de visiter les entrailles de notre eedomus ...

En fait, oui, j'alimente une base avec tous mes changements d'états, ça me créé un historique qui pourra servir plus tard ( stats, caractéristiques habituelles, etc ... ) mais pour l'instant, j'ai juste à consulter le dernier état pour afficher ma visu ...

J'ai presque fini cette partie d'ailleurs mais la rendre multi-utilisateurs demande la création de pages de gestions que je n'aurais pas eu à faire pour moi seul ( accès direct à la base pour modifier ce que je veux )

Pour résumer : je crois avoir trop d'idées pour trouver une appli qui fasse tout ce que je veux, donc je la fais moi-même, et je la rend multi-utilisateurs parce que ça à l'air d'interesser du monde. Viendra bientôt aussi une phase de demande de souhaits, parce qu'une fois que j'ai l'historique valorisé des périphériques, on se rend bien compte que l'on peut faire pleins de choses ...

[milillicuti]

Merci pour le compliment ! C'est un thème WordPress avec quelques touches persos
Félicitations à toi pour ton boulot !
L'idéal serait, bien sûr, qu'une fois tout le tard codé, on ai à faire à un simple éditeur graphique. Justement à la OpenRemote

[Nico33]

Ca marche bien avec Openremote ? Sur android ?
Ca a l'air très joli en tout cas.

Et en effet, ton site est vraiment une réussite graphique.

[milillicuti]

Merci merci. Je répète, c'est un thème Wordpress avec quelques aménagements

OpenRemote marche très bien. J'avais une interface très réactive avec ma Vera Lite.
Par contre là je galère avec l'eedomus qui n'est pas pratique à interfacer facilement et, surtout, pour que les commandes et remontées d'état soient réactives. C'était quasi instantané sur la Vera.