Log in Register

Login to your account

Username
Password *
Remember Me

Create an account

Fields marked with an asterisk (*) are required.
Name
Username
Password *
Verify password *
Email *
Verify email *
Captcha *
Welcome, Guest
Username: Password: Remember me

TOPIC: BUS multimaitres : le bus CAN

BUS multimaitres : le bus CAN 23 Jul 2013 07:44 #1

Dans ma vision de la domotique, le bus RS485 n'est pas celui que je retiendrais.
Et pour cause : chaque noeud du réseau est maître de ses fonctions et doit pouvoir émettre un message à tout moment sans attendre qu'un maître le lui demande.
gromain m'a mis sur la voie d'un projet intéressant : DomoCAN (français). Sur le forum de ce dernier j'ai été mis sur la piste d'un autre projet : HAPCAN (Polonais).
Les 2 projets suffixés "CAN" offrent une interface à un bus CAN et l'exploitent presque de la même façon. Il n'y a pas de protocole commun à ces 2 projets et donc chaque projet a développe ses propres logiciels de configuration et de supervision.
Il y a pas mal de similitudes entre les 2 projets malgré tout. Par exemple
Le bus de ces 2 projets est composé d'une paire torsadée pour le bus CAN et une paire torsadée pour le transport de l'énergie 12V pour DomoCAN et 24V pour HAPCAN.
L'autre point commun est l'utilisation de microcontrôleur PIC18Fxxx80 intégrant un contrôleur CAN.

Et xPLduino ?
Selon moi xPL est un protocole qui ne doit pas être de bas niveau car il n'est pas assez efficace si on considère le rapport (taille données utiles)/(taille données transmises).
C'est qui doit servir à développer des interfaces de commande, contrôle, supervision et configuration. Configuration par l'intermédiaire de passerelles.
Et c'est là que la fusion de projets : HAPCAN + xPLduino voire HAPCAN+DomoCAN+xPLduino

HAPCAN propose déjà des composants à la vente pour pas cher et l'infrastructure reste assez souple. Jacek, le développeur est assez disponible et très réactif. Seul hic, le forum est en polonais. Le projet évolue encore et assez rapidement.

DomoCAN a une communauté française, mais la gestion du hardware est assez anarchique je trouve. Le vrai plus est le protocole très bien pensé et qui est de mon point de vue meilleur que celui de HAPCAN.

xPLduino servirait de passerelle entre le hardware et le software.

J'ai fait l'acquisition il y a quelques mois d'une carte Arduino Due modifiée : TAIJIUINO Arduino Due Pro. Le µC intègre 2 contrôleurs CAN, mais seul 1 contrôleur est configuré de base je crois. Il intègre aussi un port ethernet.

Ainsi avec tout cela on dispose d'un réseau domotique robuste avec les différents intervenants connectés à un bus où le seul point de faiblesse de l'installation est l'alimentation du bus pour les fonctions basiques. On recourt à l'ethernet et au réseau IP qu'au moment où on fait appel à des fonctionnalités qui ne peuvent pas être embarquées dans un module CAN : configuration des modules, interfaces de supervision et de commande du style application Android ou iOS, etc.

Voilà mon projet !
  • engee974
  • Nophoto
  • OFFLINE
  • Fresh Boarder
  • Rank0
  • Posts: 17
  • Karma: 0
Last Edit: 23 Jul 2013 07:48 by engee974.
The administrator has disabled public write access.

BUS multimaitres : le bus CAN 25 Jul 2013 05:33 #2

Bonjour Engee974,

merci d'avoir exposer clairement ta vision de la domotique idéale. En ce qui me concerne, car je ne peux parler pour les autres, je ne la voit pas tout à fait de la même manière.

En effet je suis assez réticent à baser l'ensemble de l'installation sur une topologie de bus. En effet, je préfère garder les commandes "en dur" (bouton poussoirs, actionneurs...) qui eux sont cablés aux modules en coffret. De la, l'interconnexion entre les modules doit exister.

Concernant par exemple les fonctions "de confort" ( sonde t°, luminosité,..) là j'ai moins de problème et pensait partir sur un réseau 1Wire.

Chacun voit midi à sa porte, et je pense que xPLduino est tout à fait adaptable à chacun suivant ces besoins tellement les possibilités sont nombreuses .

Attention tout de même à ne pas tomber dans un système "usine à gaz" avec des couches multiples imbriquées et les différentes bidouille pour faire fonctionner le tout.

N'hésite pas à nous faire part de tes recherches, et pourquoi pas un Shield CAN pour la SMB ? Smile
  • chestroled
  • Avatar
  • OFFLINE
  • Administrateur
  • Administrateur
  • Posts: 58
  • Thank you received: 2
  • Karma: 1
The administrator has disabled public write access.

BUS multimaitres : le bus CAN 25 Jul 2013 05:52 #3

chestroled wrote:
En effet je suis assez réticent à baser l'ensemble de l'installation sur une topologie de bus. En effet, je préfère garder les commandes "en dur" (bouton poussoirs, actionneurs...) qui eux sont cablés aux modules en coffret. De la, l'interconnexion entre les modules doit exister.
C'est la topologie retenue. Un bouton poussoir n'a pas besoin d'embarquer d'intelligence et sera donc câblé au module de contrôle qui va bien.
Ce qui me gêne dans xPLduino c'est le recours à un switch ethernet pour interconnecter tous les modules entre eux où un bus. Le choix du switch est important et il devra être dimensionné en fonction du nombre de modules à connecter. avec un bus RS485 il faut 1 maître et les autres seront esclaves. C'est le bus multimaître qui est la meilleure solution selon moi.
Attention tout de même à ne pas tomber dans un système "usine à gaz" avec des couches multiples imbriquées et les différentes bidouille pour faire fonctionner le tout.

N'hésite pas à nous faire part de tes recherches, et pourquoi pas un Shield CAN pour la SMB ? Smile
Je me rends de plus en plus compte que je ne mettrai pas en oeuvre de hardware xPLduino dans mon projet. L'aspect économique je le retrouve aussi dans les 2 autres projets.
Le shield CAN ne sert que si on développe un protocole d'échange par dessus. Utiliser un protocole existant ou en développer un nouveau ?
Je vais sans doute moins contribuer à xPLduino car je n'adhère finalement pas à la philosophie du projet.
  • engee974
  • Nophoto
  • OFFLINE
  • Fresh Boarder
  • Rank0
  • Posts: 17
  • Karma: 0
The administrator has disabled public write access.
Moderators: nats
Backtotop