Spécification KNX - KnxIP/Net Tunneling et Routing
Christophe
Souhaitant réaliser un tracker de paquets sur le bus KNX via une
passerrelle IP en tunneling type N148/22 (puis routing), je suis à la
recherche de toutes documentations décrivant ceci.
Merci
marc.assin
> Souhaitant réaliser un tracker de paquets sur le bus KNX via une
> passerrelle IP en tunneling type N148/22
> (puis routing),
Tu veux dire qu'il y a un routeur KNX-IP en plus du N148 ?
> je suis à la
> recherche de toutes documentations décrivant ceci.
As-tu déjà jeté un oeil sur le site ?
https://sites.google.com/site/domotiqueeib/
puis tapé N148 dans la boîte de dialogue, çà donne quelques pointeurs
supplémentaires et peut-être utile ?
Christophe
> Je ne suis pas sûr de comprendre, mais ... connais-tu WireShark ?
de le porter sur des iDevices par la suite. Et si possible (en
fonction de mon temps), créer une supervision KNX couplée à différents
autres protocoles.
>
> > (puis routing),
Non je veux simplement parler des différents moyens de connexion à ne
passerrelle KNXnet/IP. Tunneling, Routing (Core et management)
> > je suis à la
> > recherche de toutes documentations décrivant ceci.
>
Les spécifications KNX coutant un bras par rapport à l'utilisation que
je veux en faire, je recherche toutes doc décrivant les différents
specs.
Core
Management
Tunnelling
Routing
Après si je trouve 9 personnes souhaitant les specs, on peut
partager :). Je ne sais pas si c'est légal vis à vis de Knx, mais bon
pour un protocole ouvert vendre les specs 1000€ je trouve cela un peu
contradictoire.
Anthony PENHARD
> Oui je le connais, mais je souhaiterai créer mon propre programme afin
> de le porter sur des iDevices par la suite. Et si possible (en
> fonction de mon temps), créer une supervision KNX couplée à différents
> autres protocoles.
il y a déjà plus d'une solution libre qui fait ce genre de "connexion"
avec le KNX
pour n'en cité qu'un EIBD
il serait peut-être plus simple de reprendre tout ou partie du code de
EIBD dans ton projet
pour les applications iDevice gérant le knx et d'autres protocole il y
a par exemple iRule (si pas encore géré je crois que c'est en projet),
IRidium
amha le mieux serait peut-être de contribuer à un ou des projets libre
existant plutôt que d'en créer un nouveau
perso je ne vois pas bien l'intérêt d'une appli complète "mobile" car
pour avoir les feedback il faut envoyer une lecture sur toute les GAs
à la connexion
ce qui peut se faire sur c'est un "ipad" (ou tablette autre ) par
exemple et que celui-ci reste connecté en permanence dans la maison
mais de se connecter a distance le "flux" va être important entre le
"device" et la maison et donc ralentir l'appli voir même si grosse
install "surcharger" le bus knx de lecture
(si mal configurer ...)
Ce genre d'appli n'est "qu'une IHM" une "télécommande améliorée" et
pas un superviseur
si un superviseur est installé il est plus cohérent de passer par lui
pour ce "connecter" à l'installation
(permet notamment de protéger plus facilement sont installation plutôt
que d'avoir le KNX dispo directement via IP sur internet)
je me suis un peu écarté du sujet ...
@+
Anthony.
Multimedia
On Feb 7, 10:22 am, Anthony PENHARD <a.penh...@gmail.com> wrote:
> mais de se connecter a distance le "flux" va être important entre le
> "device" et la maison et donc ralentir l'appli voir même si grosse
> install "surcharger" le bus knx de lecture
> (si mal configurer ...)
Très bonne observation!
Par contre il y a aussi un module de communication type BAOS.
Celui ci évite justement les lectures sur toutes les GAs comme il
propose des objets de communication comme tout autre produit KNX.
Ces objets sont toujours "à l'écoute" et dès qu'un appareil sans fil
se connecte, il charge les états actuels par IP sans passer par le
bus.
Et ben, il y a aussi une visu "proknx" qui pose là dessus.
A bientôt
Christian
Christophe
Merci pour vos commentaires, cependant je désire trouver de la
documentation KNXNet/IP car la solution Eibd ne me satisfait pas car
je suis anti-linux. Et oui, il y en a :)
Donc please, malgré vos bonnes intentions, je recherche toujours de
la documentation sur le protocole KNXnet. Malgré qu'avec mes
recherches j'ai tout de même fait le tour de pas mal de choses mais
j'ai peur d'en oublier.
@Multimedia, je connais les solutions BAOS et proKNX et cela s'avère
une bonne solution mais je désire créer une solution tierce via un
simple Tunneling.
La maîtrise de la solution m'apportant la possibilité d'étendre les
fonctionnalités à n'importe quel processus.
@Anthony, j'ai répondu dans ton message.
> il serait peut-être plus simple de reprendre tout ou partie du code de
> EIBD dans ton projet
pour ce que je veux en faire et sans documentation sur le protocole
KNXnet ceci n'est pas évident de l’interpréter correctement afin
d'extraire le besoin tout en gardant une complète compréhension.
>
> pour les applications iDevice gérant le knx et d'autres protocole il y
> a par exemple iRule (si pas encore géré je crois que c'est en projet),
> IRidium
> amha le mieux serait peut-être de contribuer à un ou des projets libre
> existant plutôt que d'en créer un nouveau
On pourrait citer également l'excellent ayControl.
> perso je ne vois pas bien l'intérêt d'une appli complète "mobile" car
> pour avoir les feedback il faut envoyer une lecture sur toute les GAs
> à la connexion
> ce qui peut se faire sur c'est un "ipad" (ou tablette autre ) par
> exemple et que celui-ci reste connecté en permanence dans la maison
>
> mais de se connecter a distance le "flux" va être important entre le
> "device" et la maison et donc ralentir l'appli voir même si grosse
> install "surcharger" le bus knx de lecture
> (si mal configurer ...)
Tout ne nécessite pas forcément des feedbacks.
Et une lecture intelligente des GA, par exemple uniquement lorsque la
page affichée en à besoin et un refresh en tâche de fond des autres GA
(seulement en cas de perte de connexion).
> Ce genre d'appli n'est "qu'une IHM" une "télécommande améliorée" et
> pas un superviseur
> si un superviseur est installé il est plus cohérent de passer par lui
> pour ce "connecter" à l'installation
> (permet notamment de protéger plus facilement sont installation plutôt
> que d'avoir le KNX dispo directement via IP sur internet)
l'affichage et le contrôle de la domotique ( = automatique dans le
monde industriel) c'est un superviseur.
def wiki: "La supervision est une technique industrielle de suivi et
de pilotage informatique de procédés de fabrication automatisés. La
supervision concerne l'acquisition de données (mesures, alarmes,
retour d'état de fonctionnement) et des paramètres de commande des
processus généralement confiés à des automates programmables.
Dans l'informatique, la supervision est la surveillance du bon
fonctionnement d’un système ou d’une activité.
"
Christophe
Anthony PENHARD
> Donc please, malgré vos bonnes intentions, je recherche toujours de
> la documentation sur le protocole KNXnet. Malgré qu'avec mes
> recherches j'ai tout de même fait le tour de pas mal de choses mais
> j'ai peur d'en oublier.
l'association knx à acheter comme tu as indiqué mais sinon
http://www.knx.org/knx-standard/knx-specifications/
en bas de page
"If you need more information regarding to the KNX Specifications,
please contact: Mr. De Bruyne."
as-tu essayer de poser la question ? on sais jamais ...
> Tout ne nécessite pas forcément des feedbacks.
c'est quand même très très rare
> Et une lecture intelligente des GA, par exemple uniquement lorsque la
> page affichée en à besoin et un refresh en tâche de fond des autres GA
> (seulement en cas de perte de connexion).
en effet vu la taille des écrans mobile le nombre de GA a lire reste "limité"
ce qui est moins le cas pour les tablettes oui il est possible
d'afficher plus de choses
sans "serveur" cela impose donc un relecture périodique des GA sur le
bus pour rester à jour
la lecture sur le bus impose un respect "strict" de la config ets si
on a mal définit les flags une lecture sur une GA peut faire actionner
la sortie ...
>> Ce genre d'appli n'est "qu'une IHM" une "télécommande améliorée" et
>> pas un superviseur
>
> Si en s'en tient à la définition d'un superviseur, une "IHM" contenant
> l'affichage et le contrôle de la domotique ( = automatique dans le
> monde industriel) c'est un superviseur.
ok pour la définition de superviseur merci
j'aurais du préciser que "pour moi" un superviseur ce n'ai pas que
l'IHM loin de là ...
mais donc si superviseur "évolué" (exemple linknx/lifedomus/domovea ou
autres ) connecté sur le bus à la maison
je ne vois toujours pas l'intérêt de ne pas passer par lui pour la visu mobile
il permet notamment de gérer des fonctions plus évoluées
et si on a un smartphone pour gérer ça domotique je pense que l'on a
aussi un superviseur "évolué" à la maison (ou c'est en projet) ...
@+
Anthony
fred
séparé de l'IHM - et le cache des GAs n'en est pas un :)
Le premier ce sont les tâches de fond, comme envoyer l'heure sur le
bus, les fonctions logiques, alarmes, intégration entre produits. Sur
un iDevice, tu ne peux pas actuellement garantir ces fonctions, et il
faut les réaliser ailleurs. Ce qui ne veux pas nécessairement dire que
le iDevice doit accéder à cette "supervision" (qui peut d'ailleurs
être réalisée avec plusieurs sous appareils KNX, genre horloge, etc) -
c'est juste peut-être plus efficace.
La deuxième raison est simplement que la configuration d'une
installation d'une certaine taille sur le iDevice est juste pénible.
Si tu as 30 dimmers, se taper sur le iDevice la configuration des 90
GAs que ça représente est juste laborieuse - surtout quand on a une
jolie systématique dans les dites GAs. Copy/paste/find/replace dans un
joli fichier texte sur le PC qui fait tourner la supervision est bien
plus efficace (la dite supervision auto configurant l'iDevice ensuite
pour afficher ces points de contrôle).
iKNX règle ce deuxième problème avec un import/export via Google docs.
Ca marche mais c'est quand même maxi laborieux.
Fred
Christophe
je conviens parfaitement que la solution à base d'un serveur étend les
possibilités de manière importante. Aussi bien d'un point de vu
fonctionnalité, évolutivité, commodité et performance.
C'est d'ailleurs ma solution préférée.
Ce qui pour moi sont des inconvénients aujourd'hui et qui me gène :
- Ajout de Hardware
- Impossible de trouver un serveur sous windows XP, W7 ou autres
(supportant le framework 4.0+) consommant moins de 20W (j'ai peut être
mal cherché) et sans fan
- Coût supplémentaire pour l'acquisition du serveur.
- Plantage, bug, ...
Après si vous connaissez un serveur sous windows de moins de 20W et à
moins de 150€. Je changerais surement d'avis.
L'idée de faire une appli SmartPhone (iDevices et / ou Android) c'est
de pouvoir proposer une solution certes moins évoluée mais surtout
moins chère. Avec mise en place du design sur un PC ou MAC, import du
fichier ETS4, ...
Projet certainement trop ambitieux par rapport au temps que j'ai, mais
qui me tient à coeur. Je prend comme référence ayControl que je trouve
bien fait mais beaucoup trop cher à mon goût pour une simple
application.
Christophe