RPI et Bus coupling unit KNX

[Kevlille]

Bonjour à tous,

Je ne sais pas si je suis dans la bonne section mais je ne savais pas trop ou mettre ce message.

Je suis actuellement sous superviseur Loxone pour mon installation KNX mais je n'en suis pas satisfait (support inexistant et je n'arrive pas à faire ce que je veux notamment pour les volets)

Je suis donc en train de me monter un RPI3 dans un module DIN afin de le placer dans le tableau electrique. Dessus je compte installer OpenHAB comme visu.

Par contre ce que je trouve bien sur le Loxone, c'est l'interface KNX pour communiquer directement avec le Bus et envoyer par exemple la date et l'heure sur le Bus.

Du coup je me posais la question d'integrer un Bus coupling unit sur le RPI: Apparemment c'est faisable par le port GPIO.

L'un d'entre vous à déjà fait cela?

J'ai tous le matos pour sauf le coupling unit, du coup avant d'acheter je souhaiterai avoir vos avis/retour.

Merci de vos retours.

[steph]

Bonjour,

Depuis OpenHAB sur ton Raspberry Pi, j'imagine que tu auras accès au bus KNX depuis ta passerelle IP/KNX.

Il est possible sous OpenHAB de récupérer la date/heure via NTP en configurant le binding adéquat, donc techniquement il est possible de rediriger l'information vers KNX via une "rule" OpenHAB.
Je comptais faire ceci prochainement sur mon installation et pourrais te donner plus de détails.

Donc à mon avis dans ce type de topologie une interface KNX physique sur le Raspberry Pi me semble superflue.

[Kevlille]

Salut Steph,

Oui surement mais c'etait plutôt dans l'optique pour ne plus utiliser la passerelle IP/KNX et de centraliser la communication avec le BUS sur le RPI.

En tout cas j'en suis qu'au debut de ce projet. Je vais déjà monter OpenHAB sur le RPI et essayer de configurer tout cela puis si ça roule, j'essayerai d'integrer une interface physique KNX.

Mais je me posai la question si quelqu'un avait déjà envisagé et fait cela

[nicop]

Bonjour,

De mon côté, j'avais regardé également ce type de solution et c'est faisable... Par contre, les niveaux électriques entre le raspberry et le BCU ne sont pas les mêmes et il faut ajouter un module isolateur (ADUM 1201), cf https://www.bauwas.eu/?p=984

Perso, j'ai déjà testé le raccordement d'un Arduino sur le bus KNX (avec un BCU Siemens) pour effectuer des fonctions basiques et ça fonctionne pas mal du tout.

Je suis moi aussi partisan de connecter directement le superviseur sur le KNX, le réseau c'est trop sujet à l'aléatoire pour gérer l'automatisation... C'est un projet qu'il faut que je développe mais j'ai bien envie de me faire un superviseur à base d'Arduino (c'est la solution low cost mais qui permet tout en contrepartie d'un certain temps à y consacrer...). L'avantage par rapport à raspberry c'est que tu crames pas des cartes SD...

nicop

[Kevlille]

Salut Nicop,

J'ai commandé le nécessaire pour brancher un BCU sur le RPI (avec carte adaptatrice): coût environ 80 euro (hors RPI et SSD).... j'attend ma commande.

Là j'ai déja fait l'install de openhab sur le RPI avec bascule du boot sur le SSD... par trop compliqué même si on est pas familier de Linux et co.

Par contre le paramètrage de OpenHAB est pour le moins.... austère et les tuto quasi inexistant (ou alors je ne sais pas chercher) si on veut l'utiliser dans un environnement knx.

Par exemple, un des trucs que j'ai du mal a comprendre:

Dans le configuration tools, dans le sous menu optional component, il y a KNXD. Et dans le menu Binding de Openhab, il y l'add-on "KNX BINDING".

Bon d'après Steph il semblerait que le BINDING seul est suffisant... Je vais tester ;-)

[nicop]

Salut,

J'ai aussi une install Openhab sur raspberry mais j'ai le binding KNX v1, pas encore passé à la v2. Et je passe par une interface IP/KNX

Openhab est pas forcément très simple à comprendre au début mais on finit par s'y faire. Je trouve par contre que les fichiers de conf en v1 sont plus simples que les fichiers en v2. Et oui, il me semble plus simple d'utiliser les fichiers que des interfaces graphiques sur lesquelles je n'arrivais jamais à faire ce que je voulais (en particulier sur d'autres bindings).

Maintenant sur knxd. En fait, tu peux voir un peu de doc ici : https://www.openhab.org/addons/bindings/knx/
Pour knxd, je pense que ça permet juste de l'installer pour utiliser ton installation openhab en tant que broker de connexion. Si tu connectes ton openhab sur un port USB à ton install KNX, comme ça, en cas de modification de programmation par ETS, t'as pas besoin de débrancher openhab ou d'installer une autre interface...

En attendant l'arrivée de ta commande, si tu as une interface IP/KNX, tu peux configurer complètement ton openhab. Tu n'auras qu'à modifier le "bridge" une fois le matériel arrivé.

Pour la doc de configuration, il faut regarder le lien que j'ai envoyé ci-dessus, tu y as la configuration générale. Le point le plus complexe, c'est la notation des GAs. Sur ce point, tu peux lire également la configuration du binding KNX 1.x qui s'étend un peu plus sur la question avec un exemple plus parlant.

Le plus compliqué, c'est le premier participant que tu vas configurer, après, c'est quasi du copier/coller !

nicop

[filou59]

Oui surement mais c'etait plutôt dans l'optique pour ne plus utiliser la passerelle IP/KNX et de centraliser la communication avec le BUS sur le RPI.

Je vois pas trop l'interet de ne plus utiliser la passerelle. Une passerelle une fois en place ca se laisse et on l'oublie, elle sert aux supervision ou a ETS.

Je suis moi aussi partisan de connecter directement le superviseur sur le KNX, le réseau c'est trop sujet à l'aléatoire pour gérer l'automatisation...

Faudrait que tu developpes car je ne vois pas en quoi le reseau serrait un inconvénient pour ce genre de tache.
A mon avi vous vous torturais l'esprit pour pas grand chose.

Question performance sur les grosses install les superviseur sont brancher coté IP, c'est bcp plus rapide. 
Imaginons 2 install avec 2 zone
La 1ere avec 2 ligne TP et une dorsale TP sur laquelle le superviseur est branché.
La 2nd avec 2 ligne TP aussi mais une dorsale IP sur laquelle le superviseur est branché.
D'un coté le superviseur est limité au 9600 du bus TP de la dorsale, on ne pourra pas saturer les 2 branches a la foi par exemple, et de l'autre il peut saturer les 2 branches TP puisque le reseau ne serra pas un frein

L'avantage par rapport à raspberry c'est que tu crames pas des cartes SD...

Perso je n'ai jamais cramé de carte SD, Il y a des solutions pour eviter tout ca, maintenant on trouve plein de tuto.


Sur Raspberry j'ai essayé knxd avec : 
-Interface USB
-Interface Busware (Un petit montage que l'on plug sur le Rpi)

Perso je trouve la solution bcp plus contraignante qu'une interface IP.
De mémoire j'ai réussi a paramétré le truc pour m'en servir avec ETS, mais parfois ca bug et il faut relancer 

J'avais dans l'idée d'utiliser l'interface Busware pour ensuite utiliser Codesys et pouvoir transformer le Rpi en automate KNX , comme mon wago mais bon pas assez de temps pour avancer la dessus.

Je vais probablement rester sur OpenHab sur Rpi via une interface KNX/IP. Je suis resté aussi sur le binding v1, j'ai simplement testé quelques fonction de base pour la syntaxe.

[nicop]

Je suis moi aussi partisan de connecter directement le superviseur sur le KNX, le réseau c'est trop sujet à l'aléatoire pour gérer l'automatisation...

Faudrait que tu developpes car je ne vois pas en quoi le reseau serrait un inconvénient pour ce genre de tache.
A mon avi vous vous torturais l'esprit pour pas grand chose.

L'intérêt que je vois à connecter directement en KNX, c'est d'éviter de passer par des intermédiaires qui peuvent potentiellement tomber en panne, perdre leur config... OK, ce sont des cas rares mais la philosophie KNX qui consiste à disposer d'un bus pour tout connecter me semble plus homogène que de devoir disposer de passerelles entre plusieurs technos

Question performance sur les grosses install les superviseur sont brancher coté IP, c'est bcp plus rapide. 
Imaginons 2 install avec 2 zone
La 1ere avec 2 ligne TP et une dorsale TP sur laquelle le superviseur est branché.
La 2nd avec 2 ligne TP aussi mais une dorsale IP sur laquelle le superviseur est branché.
D'un coté le superviseur est limité au 9600 du bus TP de la dorsale, on ne pourra pas saturer les 2 branches a la foi par exemple, et de l'autre il peut saturer les 2 branches TP puisque le reseau ne serra pas un frein

Je ne conteste pas cet argument. Mon install n'est pas si importante donc je n'ai pas ce recul.

L'avantage par rapport à raspberry c'est que tu crames pas des cartes SD...

Perso je n'ai jamais cramé de carte SD, Il y a des solutions pour eviter tout ca, maintenant on trouve plein de tuto.

Et ça dépend aussi de la marque et de la qualité de la carte SD. J'ai plusieurs raspberry dont 1 version 1B qui tourne encore avec la carte SD d'origine, ce n'est pas le cas d'un 3B qui a supporté quelques temps Jeedom...

[steph]

Je partage le même avis que Filou59. La passerelle IP est de toute façon présente pour accéder au bus pour ETS, et le RPi comme superviseur a forcément un lien Ethernet ou Wifi vers ce même réseau (à moins que vous fassiez un truc complètement autonome avec un écran LCD), donc autant passer par là.

Un superviseur ne doit pas être l'élément essentiel pour accéder à votre installation, et je pense que la fiabilité de la passerelle IP/KNX est bien supérieure à celle du rPI.

Après, un coupleur KNX physique m'intéresse aussi. Tout comme nicop je prévois de réaliser un module à base d'Arduino qui directement relié au bus NX grâce à un BCU Siemens.
Ca me servira comme monitoring du niveau d'eau de ma cuve d'eau de pluie.