Show Posts
Pages: [1] 2 3 ... 28
1  International / Français / Re: Dimmer 220v on: August 18, 2014, 07:57:21 am
salut,

je n'ai pas encore de lien pour le proto mais voici quelques liens intéressants et qui nous ont aidés:


Comme tu pourras le constater, la partie puissance est un poil plus compliqué qu'un circuit à triac.

Romain
2  International / Français / Re: Dimmer 220v on: July 26, 2014, 05:08:31 am
bonjour ziuthre,

réponse un peu tardive...

Notre projet xPLduino permet de faire ce que tu recherches.
Le module gradateur est piloté par une carte type arduino, il suffit de lui envoyer les ordres via I2C. Un maximum de 8 de ces modules 4 voies peut être présent sur le bus I2C.

A noter que ce type de gradateur est à retard de phase (Triac) et donc ne peut dimmer que des lampes à incandescence ou halogène. Il peut quand même faire de la commande tout ou rien.
Pour pouvoir piloter également des LED ou des transfo électronique, on est en train de travailler sur une version à coupure de phase (powerMosfet). Le proto est opérationnel.

Gromain
3  International / Français / Re: Problème arduino et module Ethernet ENC28J60 on: October 27, 2013, 04:23:56 am
j'ai connu un cas qui ressemblait à ça.
Un arduino alimenté par un bloc secteur 230v-12v, qui commandait mes volets via des relais 12v. Parfois, le système rebootait pendant la commande des relais: j'avais l'alim qui s'effondrait suffisamment pour que le régulateur embarqué (un 7805) ne sorte plus de 5v.
Problème réglé en utilisant une alim pc (un peu encombrant), puis en remplacant le 7805 par une alim dc-dc et le bloc secteur.

Dans ton code, tu peux ajouter dans le setup une instruction pour t'afficher les causes du reboot (lecture du registre MCUSR):

Code:

    // read the cause of the reset
    mcusr=MCUSR;
    MCUSR=0;

    Serial.print(F("MCUSR="));
    Serial.println(mcusr,BIN);

    if(bitRead(mcusr,0))
        Serial.println(F("Power-on"));

    if(bitRead(mcusr,1))
        Serial.println(F("External"));

    if(bitRead(mcusr,2))
        Serial.println(F("brow-out"));

    if(bitRead(mcusr,3))
        Serial.println(F("Watchdog"));


Gromain
4  International / Français / Re: I2C : Fonction onReceive on: October 20, 2013, 07:18:48 am
salut,

c'est tout à fait normal.
Tu cherches à transférer un type integer (16 bits) alors que le transfert I2C est sur 8 bits (type byte). Donc tu ne transfères que les 8 premiers bits (bits de poids faibles)
Pour transférer un type int, il faut le couper en deux bytes et reconstituer côté slave l'integer.
Pour ça, tu peux poser un masque sur les 8 bits de poids fort pour extraire les 8 bits de poids faible et l'envoyer, puis faire un décalage de 8 bits vers la droite pour extraire les 8 bits de poids fort et l'envoyer.
Côté slave, c'est l'opération inverse.

Gromain
5  International / Français / Re: DOMO_CAN on: October 17, 2013, 02:00:43 pm
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
6  International / Français / Re: DOMO_CAN on: October 17, 2013, 09:59:53 am
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
7  International / Français / Re: I2C : Fonction onReceive on: October 14, 2013, 09:10:15 am
Salut,

bricoleau a été plus rapide, mais je poste quand même pour compléter sa réponse smiley-wink

L'explication est que ta fonction receiveEvent(int howMany) est appelé indirectement par l'interruption TWI (technique du callback).
Lorsqu'il y a de l'activité sur le bus I2C/TWI, une interruption est déclenchée. Et lorsqu'on est dans le cas d'une réception de données + signal de STOP (fin de transmission, twi.c, ligne 462), alors on fait appel à la routine twi_onSlaveReceive(twi_rxBuffer, twi_rxBufferIndex);
L'adresse du buffer et la quantité de données sont alors passés en paramètres. Cette routine dépend de la lib Wire, une petite mise en forme des données est faite et ta fonction receiveEvent(int howMany) est finalement appelée (Wire.c, ligne 265) avec, passé en paramètre, le nombre d'octet reçu dans le buffer.
Dans l'exemple cette information de quantité d'octets reçu n'est pas utilisé, mais on pourrait.

Romain
8  International / Français / Re: Reverse ingéniering de BUS ? on: September 14, 2013, 12:25:10 am
euh..
data+clck ce sont les caractéristiques d'un bus I2C. Il y en a peut-être d'autre.
MAIS vu la distance possible (50m), il y a forcement un système d'amplification type P82B96 derrière (http://ics.nxp.com/products/i2chubs/)
DONC ne pas te brancher directement sur la ligne tant que tu n'es pas sur des niveaux d'amplifications.

As-tu accès aux pcb ? il faut repérer de tels composants sur le circuit de chaque côté (centrale/clavier). Les signaux I2C sont nommés SDA et SCL, ça devrait être indiqué quelque part dessus.

Pour "espionner" les bus, il existe des petits modules polyvalent type "Bus Pirate"

Gromain
9  International / Français / Re: Reverse ingéniering ? on: September 13, 2013, 07:44:46 am
Salut,

Clavier n°1
Quote
Toutefois, comme ce système accepte un grand nombre de claviers, je suppose qu'ils sont esclaves de la mini-centrale et que probablement ils ne "causent" pas spontanément sur le bus quand on appuye sur les touches mais attendent que la mini-centrale leur donne la parole.
pas forcément. Généralement c'est comme ça, mais il est aussi possible, vu le contexte (probabilité pour que 2 claviers causent en même temps dans le tuyau), qu'un clavier esclave parle à la centrale sans attendre d'être interrogé.

Quote
Dans ce cas, je dois brancher la clavier , la centrale et l'arduino sur le bus RS485 et écouter tout ce qui s'y dit ? Est ce que l'arduino pourra tout "entendre" ? Comment est ce que je peux distinguer ce qui viendra de la centrale de ce qui viendra du clavier ? Il n'y a pas de miniswich sur le clavier. Tous les claviers du bus ont le même rôle.
l'identification de l'équipement se fera dans le message (probablement dans les premiers octets)

Quote
Est ce que j'ai des chances d'arriver a décoder le fonctionnement de l'ensemble pour récupérer le clavier pour le faire fonctionner directement sur l'arduino ?
avec de la patience oui.

Clavier n°2
Quote
bus 2 fils (clock+data (+ POS + NEG)), la distance max recommandée est 50m
clock+data... à part i2c je vois pas trop. Avec i2c il est possible de faire de la longue distance moyennant amplification.

Gromain
10  International / Réalisations et Projets Finis / [ en cours ] projet domotique xPLduino on: August 20, 2013, 07:05:29 am
Bonjour,

depuis le temps que je fréquente ce forum, certains doivent être au courant de mon projet.
Commencé il y a quelques années déjà, à partir de cartes arduino Duemilanove, puis Mega, et de shields ethernet Wiznet, je pense qu'il est désormais 'présentable', même s'il est loin d'être terminé.

L'idée était de partir de la plateforme matériel et logiciel Arduino pour aboutir à une solution domotique libre et accessible, et parfaitement intégrable dans un coffret électrique (boitier rail DIN)
J'ai fait pas mal de proto, de version, je vous présente les cartes les plus abouties à ce jour, résultat obtenu grâce à un vrai travail d'équipe où chacun a apporté ses compétences:

- la carte contrôleur, équivalent à un arduino/sanguino avec la partie Ethernet embarquée. Les caractéristiques principales sont:
  • 1. atmega1284 (128k flash, 16k de RAM), cadencé à 20 Mhz, 2 UART
  • 2. contrôleur Ethernet ENC28J60
  • 3. alimentation dc-dc 12v à 24v
  • 4. lecteur de carte uSD
  • 5. port RS485 half-duplex
  • 6. port OneWire hardware (DS2482)
  • 7. port I2C pour la connexion des cartes filles
  • 8. slot pour un module RTC
  • 9. slots pour un shield de personnalisation d'I/O disponible

- la carte 8 entrées/8 sorties relais. Les caractéristiques principales sont:
  • attiny44
  • 8 entrées optoisolées (9-24v)
  • 8 relais 230v/10A à bobine 12v ou 24v (choix à faire au montage)
  • alimentation par le port I2C ou externe (au choix)
  • 2x port I2C pour la connexion à la carte contrôleur ou à une autre carte fille


Nous avons fait le choix du CMS (version 'grande' taille) pour une question de compacité, disponibilité des composants, et facilité de soudage. Un simple fer à panne fine, une pince à CMS et une loupe d'atelier suffisent.

Au niveau software, on travaille à un soft générique qui prend en charge les fonctions de base (gestion communication avec cartes filles, gestion sonde de température OneWire, horloge, communication XPL...) Il y a encore pas mal de boulot, mais les bases sont là. L'objectif est de n'avoir qu'une petite partie du programme à customiser (les scénarios). Un logiciel de configuration est en cours d'étude pour rendre tout ça user-friendly.

N'hésitez pas à venir nous rendre visite sur notre site dédié http://www.xplduino.org/fr/ et sur IRC smiley

Gromain
11  Topics / Home Automation and Networked Objects / Re: Drive a 230VAC Lamp from a TRIAC with Arduino on: July 10, 2013, 08:26:11 am
Hi,

you have to isolate your arduino from the triac by using an optocoupler like MOC3020.
I made some 230vAC lamp controls, but always with a zero detection circuit (TLP620 AC optocoupler): http://forum.arduino.cc/index.php/topic,33490.0.html (sorry, in french)

Gromain
12  International / Français / Re: variateur de lumière 230v avec ARduino on: June 03, 2013, 03:07:13 am
pour le circuit de détection du zéro, prend un équivalent à l'opto TLP620 (équipé de deux leds tête bèche) et supprimer la diode en parallèle. Ca te permettra de détecter tous les passages à zéro de la sinusoide.
13  International / Français / Re: Encore un projet domotique on: January 26, 2013, 05:32:07 am
Je pense que le X10 est une technologie dépassée, à cause de son manque de fiabilité et de l'absence de retour d'état.
14  International / Français / Re: Encore un projet domotique on: January 05, 2013, 04:38:36 pm
salut,

tiens, on parle de moi ?
j'en profite pour donner des nouvelles de mon projet.

La famille xPLduino est désormais composé:
  • d'un nouveau contrôleur à base d'atmega1284 + ethernet ENC28J60 + alim dc-dc + lecteur de uSD,
  • d'une carte 8 relais i2c,
  • d'une carte 16 entrées DC i2c
  • d'une carte 4 dimmer/4 entrées i2c

il reste du boulot, mais ça avance smiley-wink

Gromain

en PJ une photo de famille
15  International / Français / Re: Envoie de données en UDP on: December 03, 2012, 09:10:58 am
il va falloir que tu te mettes au C pour comprendre un minimum ce que tu codes et t'en sortir seul smiley-wink

Code:
Udp.endPacket();
ne fait pas ce que tu penses qu'il fait (http://arduino.cc/en/Reference/Ethernet)

Il faut simplement que tu mémorises que tu as envoyé le message, et tu reset le flag une fois le bouton relaché. Si le flag est vrai, alors tu n'envoies pas le message.

Code:
boolean memo = false; // variable globale, à placer en tete du code
IPAddress remoteIP(192, 168, 1, 26); // ip du serveur, tu peux le placer en tete du code également

void loop() {

 
// read the state of the pushbutton value:
buttonState = digitalRead(buttonPin);

// check if the pushbutton is pressed et que la commande n'est pas envoyée
if (buttonState == HIGH &! memo ){

Udp.beginPacket(remoteIP, 9999);
Udp.write("label: debut");
Udp.endPacket();

memo=true; // on memorise que la commande a été envoyée
}

if (buttonState == LOW){
memo=false; // on remet à zéro le flag
};

il est possible que sur appui il envoie plusieurs fois le message à cause de possible rebonds du contact. Dans ce cas temporise un peu avant de relire l'entrée (100ms)
Pages: [1] 2 3 ... 28