Remontée d'état via l'API

[kimagure]

Bonjour

Je suis en train de développer une interface graphique pour piloter mon installation depuis des tablettes réparties dans la maison.

Je souhaite avoir une remontée d'état des devices gérés par l'eedomus pour changer l'apparence des boutons et voyants sur l'interface en fonction de leur état, qu'ils aient été manipulées localement, via l'interface eedomus ou via mes tablettes.

Actuellement j'appelle de manière périodique (toutes les 10 secondes) l'API "get periph.caract" depuis mon serveur pour tous les devices que je veux tracker (prises, lampes), et je transmets les changements d'états à mes GUI via broadcast UDP.

Y'a-t-il une solution plus propre (et plus performante) que d'appeler de manière périodique l'api "get periph.caract", sachant que j'aimerais évidemment avoir un retour le plus rapide possible et que cette API met un certain temps à répondre, meme en local, et que je ne veux pas surcharger la box par des appels API inutiles...

Merci

K.

[DjMomo]

Y'a-t-il une solution plus propre (et plus performante) que d'appeler de manière périodique l'api "get periph.caract"

Pour l'instant non...

[Idefix-69]

Je ne connais pas l'eeDomus mais peut-on envoyer à partir d'une règle, une commande http
Exemple : changement d'état d'un périphérique = envoi d'une commande http
Cela pourrait résoudre le problème

[Nico33]

C'est en effet réalisable via des règles qui détectent le changement d'état et des actionneurs http qui vont appeler l'URL.
A tester.

[Idefix-69]

Ouf, heureux que cela puisse être fait de cette manière avec la eeDomus car c'est ce que je fais actuellement avec ma Zibase. (je vais bientôt changer mais plus de stock)
Ma box actuelle envoi donc une commande HTTP que je récupère sur une page PHP puis j'écris dans une BDD pour l'historique et j'envoie sur un socket UDP pour mes tablettes histoire d'avoir un changement d'état immédiat.

Peut-on faire la même chose avec la réception d'une température, hygrométrie et UV ? (Envoyer les valeurs reçues dans la commande http)
Peut-on faire la même chose avec une batterie faible ?

[Nico33]

Alors je ne sais pas répondre comme ça pour la batterie faible.
Pour ce qui est de la température, hydro ou autre du même genre, tu peux faire une règle toutes les minutes qui envoie la requête http avec la température (utilisation du champ LAST_VALUE PERIPH_ID=xxxxx qui donne donc la dernière valeur connue du periph spécifié)

Pour les lumières, tu fais une règle qui détecte le changement d'état et envoie de la même manière.

[Idefix-69]

Merci nico33 pour toutes ces précisions.
Désolé kimagure, j'ai pris un peu le pas sur ton post

Y'a plus qu'à acheter la box qui est toujours en rupture

[Nico33]

Avec plaisir.
J'ai déjà pensé à faire une interface avec le plan de maison et les icônes qui se mettent à jour dessus.
Mais pas le temps ni forcément les connaissances.
Par contre, il faudra nous montrer ce que vous arrivez à faire Et surtout le partager

[kimagure]

Merci pour les idées.

Dans les critères d'une règle, il n'y a pas "change de valeur" (sans indiquer de valeur). Il n'y a que "devient" qui nécessite de préciser la nouvelle valeur.

Pour une lampe avec variateur, qui a 6 valeurs possibles (de Off à 100%) par exemple, si je veux pouvoir recupérer tous les états, cela signifie-t-il que je dois faire une règle par valeur ?

A priori, je peux a minima faire
- 1 règle "devient différent de Off"
- 1 règle "devient égal à Off"
Puis dans mon actionneur HTTP, utiliser le paramètre "LAST_VALUE_PERIPH_ID" avec comme ID celui de ma lampe (donc avoir 1 valeur de mon actionneur HTTP par device).

Y'a plus simple ?

K.

[DjMomo]

A priori, je peux a minima faire
- 1 règle "devient différent de Off"
- 1 règle "devient égal à Off"
Puis dans mon actionneur HTTP, utiliser le paramètre "LAST_VALUE_PERIPH_ID" avec comme ID celui de ma lampe (donc avoir 1 valeur de mon actionneur HTTP par device).

Y'a plus simple ?

K.

Non

[Nico33]

Tiens pour une fois, je ne vais pas être d'accord avec DjMomo
Tu peux faire légèrement plus simple avec une seule règle pour une lumière avec 2 conditions en OU :
Lampe devient maintenant ON
OU
Lampe devient maintenant OFF
et tu envoies la requète avec le LAST_VALUE PERIPH_ID

Tu peux aussi faire une seule règle qui toutes les minutes envoies toutes les valeurs de température et d'hydro, etc ...

[DjMomo]

Tiens pour une fois, je ne vais pas être d'accord avec DjMomo
Tu peux faire légèrement plus simple avec une seule règle pour une lumière avec 2 conditions en OU :
Lampe devient maintenant ON
OU
Lampe devient maintenant OFF
et tu envoies la requète avec le LAST_VALUE PERIPH_ID

Bien joué

[kimagure]

Juste pour etre sur, sur un device multivalué (ex une lampe Off - 20% - 50% - 70% - 100%), une règle "devient ON" signifie "toute valeur différent de OFF" (donc pour ma lampe, allumée quel que soit le niveau de puissance ?)

[DjMomo]

Non, la valeur ON correspond à la valeur réelle 100%.

La valeur ON est la description affichée sur tes interfaces eedomus et disponible au travers des règles.
100 (ou 80 ou 35 ou 0 etc) est la valeur brute de ton périphérique (et que tu récupères via l'API).

valeur.png (17.5 Kio) Consulté 19417 fois

Ces 2 données sont visibles dans l'onglet "Valeurs" de ton périphérique.

Dans ton cas, il te faudra créer autant de conditions que de valeurs possibles de la lampe.

[milillicuti]

Mais avec cette méthode tu vas multiplier les règles par 1000, non ?
L'usage abusif (mais obligatoire) des états virtuels tend déjà à sur multiplier les règles dans tous les sens.
Je ne sais jusqu'à quelle limite la box peut tenir le coup ...

[kimagure]

Non, en combinant les remarques de DjMomo et Nico33 et mon idée de départ, il "suffit" donc :

1. De créer un actionneur HTTP avec une valeur pour chacun de mes périphériques, et qui passe en parametre l'ID du device et LAST_VALUE PERIPH_ID pour passer sa valeur.

2. De créer pour chaque device une règle
Lampe devient maintenant OFF
OU
Lampe devient maintenant différent de OFF
avec comme action, mon actionneur HTTP, et la valeur correspondant à mon device.

+> Du coup, 1 seule règle par device, et c'est bon

Idéalement, si on avait une variable "DEVICE" indiquant le périphérique source de l'action et utilisable dans les paramètres d'un actionneur HTTP, on pourrait tout faire avec une seule valeur de l'actionneur... Peut etre une évol à demander ?

Ce système permet de remonter à mon serveur HTTP chaque changement d'état, que je peux propager à mes interfaces via broadcast UDP.

Je garde une tâche de polling périodique pour rafraichir tous les devices d'un coup (+ mes capteurs de température), mais je peux diminuer sa fréquence (1 ou 2 minutes, ca me suffit)...

Merci pour les idées

K.

[milillicuti]

Ca ferait quand même chez moi plus de 50 actionneurs http + 50 règles en plus de tout ce que j'ai déjà ...

J'ai la même problématique que toi avec OpenRemote.

Savez-vous comment ImperiHome a été interfacée avec l'eedomus ?
Si c'est encore du polling, ça ne sert à rien

Il faudrait vraiment que l'on puisse intégrer cette fonction à l'eedomus. Je ne demande pas à l'équipe de sortir une interface graphique car les goûts et les couleurs sont toujours discutables, mais un moyen technique permettant derrière à chacun de créer une interface personnalisée.

[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/

[Nico33]

@kimagure : il faut dans ta règle avec les conditions en "OU", que tu mettes tous les états possibles du genre :
LAMPE à 0
LAMPE à 10%
LAMPE à 20%
...
LAMPE à ON (100%)

parce que sinon tu ne verras pas les changements de 20 à 50 % par ex mais seulement le passage de allumé à éteint.
Enfin si ta lampe est dimable.

@milillicuti : Pour Imperihome, je pense que le soft fait du polling car on voit le rafraîchissement se faire en haut toutes les 10 secondes je dirai.
Et quand on change l'état d'une lampe par ex, il faut un petit moment pour qu'il apparaisse dans le soft.

[Nico33]

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.