OpenHab & ipx800

Cartes Ethernet IPX800
1

Bonjour à tous,

D’abord une petite présentation comme je suis nouveau sur le forum.
Sébastien, bonne connaissance en informatique (dev linux C++, python, java), en électronique et électricité. On va dire que je passe pas mal de temps à bidouiller sur ordi, raspi ou autre…

Comme je fais construire une maison j’ai décidé d’intégrer de la domotique pour le confort, la sécurité et les économies d’énergies.
Pour résumer, l’ipx va gérer : les lumières, les volets, les BSO, le comptage des énergies, la distribution audio. L’installation va comprendre 2 IPX + 3 X800.

Pour piloter l’ensemble, je souhaite utiliser openhab qui me semble être un serveur vraiment très bien pensé.
Openhab est un serveur puissant basé sur la plate forme OSGI et permet de gérer l’ensemble d’une installation domotique avec des règles assez simple.
Il permet de réaliser facilement des suivi de consommation qui peuvent être stocké en base de données par exemple.

Je me suis donc lancé dans le développement d’un « binding » openhab pour l’ipx800.

Voici la liste des fonctionnalités qui sont/seront implémentés :

  • Prise en charge de plusieurs ipx800 connecté sur le port tcp
  • Prise en charge des extensions X880 et X400
  • Pilotage des sorties
  • Récupération de tout les états aux travers « d’item » openhab (couche de persistance d’openhab)
  • Types de configuration des items qui seront supportés
    • Comptage simple
    • Comptage moyennage (permet de mesurer des consommations en kw ou litre/m par exemple)
    • Appui court
    • Appui long
    • Simple clic
    • Double clic
    • Variateur virtuel (plus on reste appuyé sur le bouton plus la valeur du variateur augmente)

=> L’idée est de permettre de multiplier les cas d’usage d’un bouton poussoir simple, par exemple :
1 appui court allume ou éteint la lumière, 1 appui long fait augmenter la lumière (dimmer), et un double met l’ampoule dans un scénario programmé (couleur ou autre).
Ce cas d’usage nécessite bien sûr une ampoule spéciale (hue, milight…) !

Le développement est quasi terminé, il reste le variateur virtuel et quelques parties à fignoler.
Y a t-il des personnes intéressés pour tester ?

J’ai un petit problème sur l’IPX et l’interface tcp, lorsque deux événements arrivent très proche, l’IPX renvoi une trame tronqué. Exemple :

I=00000000000000000000000000000000&O=10000000000000000000000000000000&A0=0&A1=0&A2=0&A3=0&A4=0&A5=0&A6=0&A7=0&A8=0&A9=0&A10=0&A11=0&A12=0&A13=0&A14=0&A15=0&C1=431&C2=5&C3=0&C4=I=00000001000000000000000000000000&O=10000000000000000000000000000000&A0=0&A1=0&A2=0&A3=0&A4=0&A5=0&A6=0&A7=0&A8=0&A9=0&A10=0&A11=0&A12=0&A13=0&A14=0&A15=0&C1=432&C2=5&C3=0&C4=0&C5=0&C6=0&C7=0&C8=0

Cela peut vite devenir gênant si on commence a avoir beaucoup de périphérique de comptage branché sur l’IPX car on perd des événements.
Est-ce un bug ou une limitation du matériel ?

Voilà pour les premières questions, j’espère ne pas en rebuter trop avec ce post énorme…

Seb

1 « J'aime »
2

Bonjour Seb,

Bienvenu sur le forum.
Cela ressemble bien à un bug…On va regarder pourquoi le message est tronqué…

OpenHab est un très bon choix et c’est une solution qui est très utilisé par nos clients professionnels car elle offre une grande liberté.
N’hésitez pas a nous faire part de l’avancement de votre projet.

Patrick

1 « J'aime »
3

Bonjour !

Ahhhh ! voila le post que j’attendais ! J’utilise openhab depuis 2 mois et j’ai un IPX800 + X880 et un ecodevices. Pour l’instant, j’utilise le binding générique TCP pour récupérer les trames M2M que je retraite dans une règle et un script pour connaître l’état de l’IPX et de l’ecodevice et inscrire tout ca dans les items (voir le développement que quelqu’un avait été posté sur ce forum il y a qq mois).
Je commande les relais IPX en TCP et le X880 en http (bug de la 3.05.42, pas encore testé le nouveau firmware / voir mes posts précédents).
Je suis complètement partant pour tester un binding IPX ! Les fonctions pour les poussoirs sont super, j’en aurais besoin et je me demandais comment faire !
Pour ma part, je ne fais pas de comptage avec l’IPX, mais j’ai parfois des push M2M très proches (appui poussoir) et je n’ai pas noté de troncature dans les push M2M…

Merci de me tenir informé

Jeblack

4

Merci Patrick, pour info mon ipx est en 3.05.42. Je vais tester si ça fait la même chose avec la version 3.05.46.
Je dois aussi recevoir mon deuxième ipx800 (en v3i) lundi prochain avec les extensions, je testerais aussi.

Bon voilà mon premier beta testeur !
Pas de soucis Jeblack, je pense pouvoir t’envoyer une première beta en fin de semaine prochaine.

5

Ok super. On se tient au courant par MP.

Bon WE !

Bernard

6

Concernant le problème de trame tronqué, après plusieurs test à l’instant :

  • Même problème avec la version 3.05.46
  • Même problème avec un autre ipx en v3i

Pour reproduire le problème facilement avec un ipx800, configuration vierge et option M2M > ‹ Send data on status change › activée :

#  for i in $(seq 0 100); do curl [http://192.168.1.250/leds.cgi](http://192.168.1.250/leds.cgi)\?led\=100; done

Le problème se reproduit aussi avec un simple BP connecté sur une entrée.

Avez vous des nouvelles sur ce problème ?

7

Salut,

Pour faire le test, tu mets quoi exactement dans le champ « path » de la config « send data on events » ?

Merci !
Jetblack

8

J’ai peut être été un peu court dans mon explication. Mon problème se situe au niveau des mise à jour d’état sur le protocole tcp (donc pas de push http).

Dans mon test j’utilise http juste pour mettre à jour des entrées.

Pour visualiser le problème il faut bien sûr voir ce qui se passe côté tcp.

Pour résumer :

  1. Ecouter sur le port tcp
# netcat 192.168.10.250 9870
  1. Lancer des changements d’états rapprochés (dans un autre terminal)
# for i in $(seq 0 100); do curl [http://192.168.1.250/leds.cgi](http://192.168.1.250/leds.cgi)\?led\=100; done
9

Le développement du binding avance bien. J’espère pouvoir arriver avec une première version rapidement.

J’ai une demande d’évolution qui pourrait être sympa pour tout ceux qui utilisent leur box ou serveur domotique pour centraliser l’ensemble de leurs paramètres domotique.

Je souhaiterais qu’en cas de plantage/extinction… du serveur domotique, l’ipx soit autonome et donc fonctionne normalement avec les affectations programmés.
En revanche quand le serveur/box répond correctement, c’est lui qui gère entièrement l’ipx, les affectations dans l’ipx sont donc désactivés.

Certains scénarios compliqués ne peuvent pas être géré avec l’ipx : double clic + simple, variateur, ou scénarios complexes (déclenchement en fonction de paramètres extérieurs…).
L’idée est donc de gérer ces scénarios avec le serveur domotique et de rebasculer sur l’ipx en cas de problème.

Pour la technique, je pense à plusieurs solutions :

  1. Une sorte de watchdog : une commande qui désactive les affectations normales doit être envoyé a intervalle régulier par le serveur à l’IPX.
    Si cette commande n’est pas reçue, l’ipx réactive les affectations.

  2. Pour chaque événement envoyés par l’IPX, si le serveur répond OK, l’IPX ne réalise pas les actions, si le serveur ne répond pas, l’IPX réalise les actions.

Vous en pensez quoi ?

10

Ah ok,

je n’avais jamais vu cette option du M2M sur port 9870 qui permet de renvoyer sur la communication TCP le changement d’état.
Moi j’utilise la configuration push du M2M sur port 25001 en TCP. Voir la figure jointe. Dans ce cas il faut indiquer les étiquettes des donées que l’on souhaite récupérer.
Dans ce mode, je n’ai jamais eu de messages tronqués, (mis à part les petits bug signalés qui expliquent pourquoi j’ai mis des ‹ dummy › dans le message à envoyer en plus des étiquettes)

Jetblack.

1004×567 33.7 KB

11

Salut,

Pour ma part, j’ai quelques affectations simples et qui doivent s’executer rapidement, qui sont programmées directement dans l’IPX, du genre : appui sur un bouton poussoir déclenche un relais pendant un temps donné.
En parallèle de ca, le système domotique gère des fonctions complexes, par exemple les stratégie de chauffage et de chauffage de l’eau chaude en fonction des jours tempos et de l’occupation de la maison, ou alors l’éclairage extérieure de la maison en fonction de l’ouverture du portail et de l’heure de lever et de coucher du soleil…

Bref, pour mes applis, il est important de conserver en parallèle les 2 modes de fonctionnement : fonctions internes de l’IPX + contrôle par des scénarios extéreurs.
Ca fait 2 ans que j’utilise l’IPX et il n’a jamais planté. Ca fait plus d’un an que j’ai un système domotique sur raspberry qui pilote le même IPX et je n’ai jamais eu de plantage non plus (multicardipx 800 et maintenant openhab).

Personnellement et pour ces raisons, je ne suis pas favorable à un comportement différent de l’IPX selon que le serveur domotique soit en fonctionnement ou défaillant.

Jetblack

12

Je n’avais pas encore essayé ce mode. D’après ce que je vois, c’est bien un push http :

GET mac=00:1E:C0:smiley:5:angry:x:angry:x&in=00000000000000000000000000000000&out=00000000000000000000000000000000 HTTP/1.1
Host: 192.168.10.10
Connection: close

Au moment de la création du binding je suis parti sur une connexion TCP depuis le serveur domotique vers l’IPX car c’est ce qui permet d’avoir le moins d’overhead
(pas de nouvelle connexion à chaque événement) et de gérer en même temps l’envoi de commande et la réception d’événements sur le même port.

13

Oui en effet c est du push http, voilà ce que je reçois sous openhab :

IPX_PUSH state updated to GET /I00000000000001100000000000000000dummydummy /O01111000000000000000000000000000ydummy /C0&0&0&0&0&0&0&0 /dummy /A0&0&0&0000000000000 /END HTTP/1.1

14

bonjour je souhaite également utiliser le binding. Où peut on le trouver?

merci

15

encore merci seebag pour ton boulot et ta disponibilité. L’install d’openhab n’a pas été simple mais ça a valu le coup de persévérer :slight_smile:

16

Bonjour,
Je viens de m’inscrire sur ce forum ce matin.
Je me renseigne sur la domotique.
J’ai découvert openhab il y a 3 semaines et je l’ai installé sur raspberrypi
J’envisage un ipx800.
J’arrive 3 ans après la bataille. … mais cette solution de binding est elle toujours d’actualité ? Où peut-on la trouver ?
Merci

17

Bonjour,

Le binding sortie il y a plusieurs années est toujours disponible.

Il est compatible avec openhab V2. Je ne l’ai pas testé avec la toute dernière version 2.2 car je n’ai pas mis à jour mon installation mais il n’y a pas de raison que cela ne fonctionne pas.

Voici la documentation du binding : https://docs.openhab.org/addons/bindings/ipx8001/readme.html, avec la liste des fonctionnalités et des limitations.

Attention cependant, il n’est compatible qu’avec la version 3 de l’ipx800.

Il est en production chez moi depuis 2015, avec maintenant 3 ipx800 + 4 extensions. Ces ipx gèrent couplés à openhab :

  • 2BSO + 7 volets roulant + 1 portail de garage
  • 20 points lumineux + entrée pour 3 lampes pilotés (milight + zwave)
  • Plusieurs thermostat/tête thermostatiques
  • La distribution audio dans 4 pièces en stéréo
  • Le comptage de l’eau et de l’électricité (4 compteurs à impulsions séparés)

Voilà !

1 « J'aime »
18

Merci pour votre réponse.

En parlant de compatibilité avec ipx v3, excluez vous la v4 (j’ai cru comprendre que c’était la version actuellement distribuée) ?

J’ai des volets Bubendorff filaires et de fait il me faudra préciser une version du software particulière. J’ai 11 volets roulants donc j’aurais besoin de x4vr. Est ce que tout est compatible ?

Olivier

19

Oui, ne possédant pas de V4, je n’ai pas pu développer la compatibilité avec le binding. Je viens de regarder la documentation, le protocole parait relativement proche et donc facilement adaptable.

Les deux versions (V3 et V4) sont toujours distribués par gce.

Pour piloter les volets, les ipxv3 sont utilisable directement.

3 « J'aime »
20

Petit message pour remercier Seebag pour son boulot, ça fait 3ans que ça tourne nickel chez moi :slight_smile:

1 « J'aime »