DOMO_CAN

Vous avez peut être déjà entendu parlé de système domocan. Il s'agit d'un système de domotisation réalisé autour de microprocesseurs pic. Le principe consiste à faire un système décentralisé pour la gestion domotique d'une maison.Toutes les cartes de gestions sont interconnectées par un bus type canbus. Chaque carte possède des propriétés distinctes (gestion allumage lampe, gestion interrupteur, gestion sonde température...)
Le système de bus type can bus est utilisé dans les voitures pour gérer l'interconnexion entre les différents éléments.

Je vous propose donc d'appliquer ce principe avec nos petites cartes arduino.

Le but: contrôler sa maison de façon simple et efficace.

Pourquoi ce choix:
-Un système décentralisé évite le plantage totale de l’installation + changement facile des éléments défectueux.
-le bus can est un BUS très fiable, peu sensible aux interférence, pouvant avoir une porté de plus de 100m (suivant vitesse du bus).

Objectif:
1)développement des cartes principales (codes+câblages):
-carte gradateur:carte permetant d'allumer 8 lampes ou prises
-carte interrupteur: carte permettant la réception de boutons poussoirs
-carte horloge: carte donnant l'heure
-carte mémoire:carte permettant le stockage d'information;
-carte ip: carte permettant d'interagir avec internet

2)développement application android pour supervision.

  1. amélioration, développement de cartes complexe
  2. mise en place du système.

ça vous intéresse?

Avant de commencer jetez un coup d’œil pour réaliser une communication entre 2 arduinos à travers le bus can.

http://modelrail.otenko.com/arduino/arduino-controller-area-network-can

Ce tuto est très bien fait pour débuter. Vous trouverez une bibliothèque permettant l'envoi de donnée.

bonjour ludoboss7,

je me suis intéressé à Domocan il y a quelques années. C'est très bien documenté, en français, et avec une bonne communauté.
Malgré la qualité de la doc, j'ai été un rebuté à l'époque par le côté PIC/assembleur/toolchain (je n'y connaissais rien non plus en uC..)
Je trouvais aussi un peu dommage de refaire un Domocan bis à base d'Atmega, alors que le PIC intégre tout ce qu'il faut pour le gérer, alors que l'Atmega non (note: il existe des uC atmel intégrant le CAN)
C'est pour ça que, perso, je me suis orienté vers une solution à base d'Ethernet, ce qui manquait à Domocan.

Ceci dit, l'aspect CAN m'intéresse toujours car je cherche à implémenter un bus sur mon contrôleur. Les protos intégrent le RS485 pour le moment. Une extension CAN est envisageable.

Gromain

Fin bref!

Le RS485 fonctionne trés bien et sans utilisation d'un protocole spécifique, même si à terme il puisse y avoir une volonté de réunir les compétences et les spécificités de chacun.
Le temps dira qui a raison.

@+

Zoroastre.

on est d'accord, le RS485 c'est très bien de par sa simplicité. On peut le coupler à un protocole type Modbus pour un peu de robustesse.
Cependant, il faut quand même reconnaitre que dès qu'on commence à avoir du monde sur le bus, la gestion par le CAN est beaucoup plus adapté grâce à l'aspect multimaster/gestion collision implémenté de base dans le hardware. Mais la complexité est à l'avenant.

Gromain

Bonjour,
voila je viens de commencer mon projet.Pour l'instant j'ai réalisé 3 types de cartes:

1 cartes d'entrée ( arduino +mcp2515+mcp2551 + boutons poussoir) pour détecter l'appui sur un bouton poussoir et envoyer un ordre

1 carte type gradateur( arduino +mcp2515+mcp2551+ sorties variables) pour allumer des lampes.

1 carte type mémoire+clock (arduino+mcp251+mcp2551+ds2417+24lc256) pour avoir l'heure et stocker des données non volatiles.

ces cartes sont reliées sur un bus can à 100kbs/s. les trames envoyées sont toutes composées de la façon suivante:

4 bytes--> identifiant
byte 0--> type de carte ciblé (carte interupteur, carte gradateur, carte mémoire....)
byte 1--> commande demandée (exemple allumer lame)
byte 2-->numéro de la carte (permet de différencier 2cartes du même type)
byte 3 -->parametre (variable suivant la commande)

8 bytes -->bytes de données. (variable suivant la commande)

c'est clair? non!!!!

alors un petit exemple.soit la trame suivante:

identifiant donnée
[0x03,0x01,0x09,0b00000011] [0x00,0x00,0x00,0x00;0x00,0x00,0xFF,0xAA]

il faut lire la trame de la façon suivante:

on souhaite envoyer un ordre à une carte de type 0x03 (carte gradateur) une commande d'allumage de lampe (0x01) , la carte gradateur à qui l'ordre est adressé est la carte numéro 9 (0x09). dans le paramétré il est précisé lesquelles des huit lampes (un bit par lampe) doivent changer d'état ( ici bit=0 la lampe conserve son état bit=1 on change l'état de la lampe).
Les bytes de données précise la "luminosité" souhaitée: il faut lire:
les lampes 0-1-2-3-4-5-6 ne change pas d'état (non sélectionnée dans le byte paramètre) , la lampe 6 est allumé au maxi (0xFF), la lampe 7 à une valeur quelconque (0xAA)

j'espère être plus clair. :astonished:

J'ai développé mon application de la façon suivante suivante:

un ensemble d'ordres (donc de trame de 12bytes (identifiant 4+8 données)) est stocké en mémoire eeprom sur le 24lc256 de la carte clock+mémoire. des ordres pourront être ajouté ou supprimé dynamiquement (à finir de développer).

Les cartes d'entré (boutons poussoir) sont configurées de la façon suivante: à chaque appui sur un bouton est associé le numéro des ordres préenregistré à exécuter.

exemple de communication pour l'allumage d'une lampe à partir d'un bouton poussoir.

  1. l'ordre correspondant à l’allumage de la lampe est enregistré dans l'eeprom de la carte mémoire-clock sous l'ordre numéro 1
  2. le bouton poussoir est configuré pour demandé le lancement de l'odre1 (allumage lampe)

ensuite ce qui ce passe.

j’appuie sur le bouton poussoir-->une trame est envoyée à la carte mémoire-clock qui indique qu'il faut exécuter l'ordre 1
--> la carte mémoire envoie la trame (ordre1) sur le bus permettant l''alumage de la lampe--> le message est reçu par la carte gradateur qui allume la lampe--> un message de retour d'état est retourner pour connaitre l'état des lampes.

Bon pour être plus clair je vous laisse mes bout de code que j'ai commencé à faire:
vous y trouverez les codes pour chaque cartes,

La library can bus que j'utilise ainsi que des fichier texte expliquant les différentes commandes de chaque carte.

ce serait sympa que vous me donniez vos avis sur ce début. Si vous avez des idées améliorations. :wink:

Gromain j'ai vu ton projet qui est super intéressant. j'avais songé à faire le même principe. j'ai été rebouté du fait que la transmission par udp n'est pas sur (risque de perte de message qui peut être génant).
Je me rend compte qu'un avantage de ma solution est que les programmes sont assez light.

version beta.zip (21.6 KB)

retour sur expérience:
ci joint code +lib:

avec ça on peut allumer des lampes à partir d'une connexion udp.
envoie trame par udp--->tranfert sur le bus--->allumage lampe

on peut aussi définir l'heure sur le bus (utilisation du ds1357).
voilà

canbus.zip (20.8 KB)

pas de retour?

Bonjour,

Je connais assez bien le bus CAN, je l'utilise sur mon réseau de train miniature. Une remarque sur ce que j'ai lu : il n'y a pas de complexité à la charge du programmeur puisque justement cette complexité est gérée par le hard. C'est plutôt dans le RS485 que se trouverait la complexité puisque, dès que l'on a un système un peu complexe, il faut tout faire en soft.

Concernant son emploi en domotique. Pourquoi pas. Je bricole moi même sur un projet mais tirer une paire torsadée partout dans la maison me décourage et me rebute. Ça sera donc du sans fil.

bonjours j'ais besoins de vous aide , j'ai un problème sur limitation nombre de fois de rotations d'un mini servomoteur, j'ais fais un petit programme sur l'arduino c'est que le servo tourne 45 degrés vers -45 degrés mais il reste toujours fonctionner es que il ya une boucle pour limiter le nombre de fois et merci d'avance j'atends vous réponse .