Aidez nous ! Projet - Gestion domotique

Et bien je vois que cela ne chaume pas. Noël est passé, je vais donc pouvoir commander mon arduino et contribuer plus activement avec vous. Malheureusement je ne vais pas être très présent prochainement car ma femme va accouché d'ici peu et je part en stage de mi-janvier a mi-février, mais je ne manquerais pas de vous suivre.

En tout cas je vous souhaite de bonne fête a tous

Skuzmitoo: Malheureusement je ne vais pas être très présent prochainement car ma femme va accouché d'ici peu

Félicitation :), tu vas pouvoir contribué lors de tes nombreuse nuits blanche. :grin:

Salut zoroastre et tous, je vous souhaite une très bonne année 2012, pleine de joies arduinesques et autre régulations.

Au sujet des SN75176, ils n'ont pas çà chez Cotubex (Bruxelles) ?

Pour les moyennes, j'ai du mal à comprendre pourquoi elles sont si "compliquées" ou "peu fiables" : la température d'une maison varie très peu ! Donc si on la mesure toute les x secondes, on peut encore faire une moyenne géométrique très large sans risque,, genre valeur_moyenne = 0.99 * valeur_moyenne + 0.01 * nouvelle _mesure

Dans le code, j'ai du mal à comprendre les ajustements de température "-0.06" ou "+0.2", pourquoi n'y-a-t'il pas plutôt un analogRead ou OneWire::read ?

De mon côté,j'en suis encore à l' "espionnage" de mon système de régulation existant (Sauter EY3600 avec des sondes NI1000 pulsées...), donc pas de trucs très probants à l'heure actuelle, mais même si ma commande est une pompe à chaleur (donc fonctionnement d'une heure sans arrêt recommandé), et j'ai une (vieille) expérience de fuzzy logic, j'envisage quand même plutôt le PID avec des moyennes mobiles ... Ma valeur de sortie principale n'est pas "brûleur ON/OFF", mais bien "minutes de chauffe/24h", à raffiner par la suite (p.ex. pour tenir compte de l'inertie thermique de la maison).

Je compte aussi installer certains DS18B20 pour raffiner les circuits de chauffe, tenir compte des heures où la cassette/les panneaux solaires fonctionnent, etc. mais c'est pour encore plus tard. Avant çà, j'ai d'autres chats à fouetter avec une alarme pour quand la PAC se met en sécurité, étalonner les sondes/évaluer les variations journalières, ... Ma priorité #1 est de ne pas "casser" ce qui marche (à moitié).

A bientôt.

Yep tochinet !

Désolé de te répondre à rebours.

J'ai proposé quelques courbes caractéristiques en page 14, dernier message.

Ce qui faut savoir avant tout est que les sondes DS18B20 ont une précision de +/-0.5° dans les plages de température courante. Pour une résolution de 12 bits, elles ont un pas d'environ 0.06°. Les valeurs de 0.06 et 0.2 sont donc des réferents à ces remarques, respectivement le pas et 4 fois le pas. (4x0.06=0.24°, donc supérieur à 0.2°)

Je possède des radiateurs en fonte et acier, mon chauffage central a un fonctionnement tout ou rien, et toute la problématique est de béneficier au maximum de l'inertie des radiateurs. Les moyennes et leur comparaison n'est pas une mauvaise methode en soi, cependant, dans certaines circonstances, suite à un relevage, par exemple le passage d'un mode éco à un mode confort, la moyenne ne fournit pas une information précise et sûr. La conséquence principale est un doublement consécutif du cycle de chauffe. Si les moyennes sont trop éloignées les unes des autres, il arrive que l'inertie dont on veut connaitre son image soit occulté, la perdition estimée du cycle précedent se répercute sur le cycle suivant. Le système manque de réactivité. Si, au contraire, les moyennes sont rapprochées, le système est trop réactif, outre les erreurs de lecture dûes à l'inhérence du materiel, l'image inertielle en retour est d'ordre impulsionnelle. donnons les valeurs -1, 0, 1 aux tendances de la courbe, nous aurons ainsi beaucoup de 0 et de temps en temps -1 (perdition), +1 (distribution). Dans ce cas, nous sommes obligés de pondérer les moyennes.

La régulation PID n'est pas possible dans mon cas, et ton experience et tes remarques interesserons certainement les maitres d'oeuvre de ce projet.

Pour ma part, je comptais travailler avec une seule sonde de temperature dans un premier temps. Que ce soit par la méthode des moyennes, de la logique floue, sommet de la courbe, je n'entrevois pas vraiment de solution logicielle parfaite. Finalement, je me dis que positionner une seconde sonde à proximité d'un radiateur "temoin" serait la methode la plus simple pour garantir une distribution passive réussie.

@+

Zoroastre.

Yop Yop,

Bribri disparut, Skusmi pouponne :grin: ?
Jute pour dire que j’ai bien avancé sur le bus rs-485, mpcm, mode 4 fils et sans maître et plein plein de testes différents, une mega de grillé et debug de mini(s) à la diode :grin:, problèmes de cas, etc, etc, mais j’arrive au bout :grin:.
Plus personne d’interessé ? =(

Yep!

Plus personne d'interessé ?

Si si toujours interessé ;)

Les maitres d'oeuvre sont effectivement absents depuis un moment déjà. J'espère qu'on les reverra bientôt, aprés leur période d'hibernation XD

Tes experimentations sur le bus Rs485 peuvent interessées du monde et moi le premier. Le rs485 comme bus de terrain, l'idée me plait et je l'utilise au quotidien ;)

Tu peux détailler tes experimentations ici, dans un autre topic et remettre un lien ici ou nous donner une url.

@+

Zoroastre.

De mon côté, urgence : la PAC refuse tout service pour cause de ... fuite ? Impossible de savoir où, mais impossible aussi de garder la pression dans le système. Donc la régulation est passée en priorité 2, on chauffe avec des radiateurs en direct. Heureusement que c'est une ossature bois ... et que l'hiver n'est pas (encore) rude.

Allez, j'y retourne. :-(

Bonjour à tous,

Non je n'ai pas disparu, j'ai fait marcher les différents éléments séparément, puis j'ai tout intégré, ça marche aussi. Même si je n'ai pas tout bien compris (programmation), je vais donc reprendre tous les programmes un à un en mettant un maximum de commentaires pour à la fois mieux maitriser et pouvoir optimiser. Ensuite seulement je ferai les adaptations par rapport à mes besoins, et là j’aurai certainement plein de questions à vous soumettre !

J’ai également monté un serveur (vieux PC), pour l’instant html, mais j’ai commencé à apprendre le php.

Cela fait beaucoup de choses à la fois !

Mais je continue à suivre avec grand intérêt vos échanges, je n'en suis pas encore à la liaison RS485, mais cela viendra en son temps.

zoroastre:
Tu peux détailler tes experimentations ici, dans un autre topic et remettre un lien ici ou nous donner une url.

Yop,
Je peux décrire brièvement mes expérimentations, je découvre, je teste, …
D’abord le bus rs-485 niveau hard rien de bien nouveau, mode 2 fils (half duplex) ou 4 fils (full duplex) dans les deux cas on dois toujours activé une sortie de l’arduino pour sélectionné (RE/DE) le mode de transmission ou réception .
Pour le mode 4 fils (full duplex) c’est simple on utilise 2 transceivers par module ou contrôleur, un pour rx l’autre pour tx pour lequel il faut toujours activé RE/DE et pas simultanément sinon ça capote (expérience inside :grin:) .
Pour lier la ligne réception à la ligne transmission une paire est mis en début ou fin de ligne ou autre. (rx/tx lié directement pour tester le bus sans maître)
Exemple rapide de mon montage actuel.

Niveau programmation utilisation du Multi-processor Communication Mode (mpcm) de l’atmega, le principe est assez simple il se base sur une transmission 9 bit, selon l’état de ce 9 ieme bit il s’agit soit d’un adressage si il est à 1, soit de simple données s’il est à 0 (pour celà il faut avoir été sélectionné au préalable via adressage).

ISR(USART_RX_vect) //vecteur d'interruption sur sur rx
{
  if((UCSR0B & (1<<RXB80))) //on lit l'état de ce 9ème bit (RXB8) dans le registre UCSRB
  {
    listener = UDR0; //s'il est à 1 on lit l'adresse dans le registre UDR et on l'enregistre

    if(listener == ADDRESS) //si il s'agit de ça propre adresse 
    {
      UCSR0A &= ~(1<<MPCM0); //on met le bit MPCM du registre UCSR0A à 0 ce qui aura pour 
                                             //  effet de laisser entrer toute données transmise
    }
    else
    {
      UCSR0A |= (1<<MPCM0); //dans le cas contraire toute transmission avec le 9 ème bit à 0 seront totalement ignoré, aucune interruption rien de rien jusqu'au prochain adressage.
    }
  }
  else
  {
    unsigned char c = UDR0; //lecture normale des données avec le 9ième bit à 0 si MPCM à 0.
    store_char(c, &rx_buffer); // mise en buffer lol ...
  }
}

Une remarque, j’ai dus retiré hardwareSerial du core arduino afin d’adapter son code, conflits entre les fonctions d’interruption comme elles sont pré instancié par défaut.

Pour l’adressage ou la transmission de données pas grand chose de différent hormis TXB8 à 1 pour signifié une adresse.
Entre () ,j’ai du également ajouté un delay (_wait) de 7.2 millis sec (valeur trouvé sur le net) entre chaque transmission et fermeture du signal ( PORTD &= ~(4); ) , apparemment pour permettre le temps au donnée de circulé sur le bus, c’est là qu’on vois la différence de traitement entre une écriture directe et le traitement effectuer via print et println.

uint8_t writeAddress(uint8_t address)
{
  while (!((UCSR0A) & (1 << UDRE0)))
	;
  PORTD |= 4;
  UCSR0B |= (1<<TXB80); //adressage
  UDR0 = address;
  _wait
  PORTD &= ~(4);
}

uint8_t writeData(uint8_t c)
{
  uint8_t i = (tx_buffer.head + 1) % SERIAL_BUFFER_SIZE;
	
  while (i == tx_buffer.tail)
    ;
	
  tx_buffer.buffer[tx_buffer.head] = c;
  tx_buffer.head = i;
	
  sbi(UCSR0B, UDRIE0);
  
  return 1;
}

ISR(USART_UDRE_vect)
{
  if (tx_buffer.head == tx_buffer.tail)
  {
	cbi(UCSR0B, UDRIE0);
  }
  else
  {
    unsigned char c = tx_buffer.buffer[tx_buffer.tail];
    tx_buffer.tail = (tx_buffer.tail + 1) % SERIAL_BUFFER_SIZE;
	
    PORTD |= 4;
    UCSR0B &= ~(1<<TXB80);
    UDR0 = c;
    _wait
    PORTD &= ~(4);
  }
}

Maintenant concernant la gestion entre modules sur le bus, je suis parti sur une formule simple, si la dernière adresse reçue est 0 c’est que le bus est libre, sinon on attend.
Le principe globalement:

  • si listener = 0, le bus est libre.
  • On active l’écouteur (listener) de destination en mettant le 9ième bit à 1 ( UCSR0B |= (1<<TXB80); ) et on spécifie son adresse, il sera le seul à écouter.
  • L’écouteur retourne son adresse avec son 8ième bit (msb) à 1 pour signifier qu’il écoute bien (ce qui limette les adresse à 7 bit donc de 1 à 127, 0 libère, 128 pour broadcast) .
  • On envoie les données à transmettre.
  • en fin de transmission on libère le bus en envoyant l’adresse 0.

Le protocole en lui même c’est le plus simple, pas besoin de s’y attarder. :stuck_out_tongue:
Il faut ajouter à tout ça quelques sécurités comme mettre listener à 0 automatiquement après un délais max (un peux comme un watchdog sur le bus lui même) en cas de problème lors de la transmission ou l’émetteur n’aurait pus libéré le bus, etc, tec, …
Donc après divers testes , bizarreries, plantage, … , je pense être tout proche d’une solution satisfaisante ou du moin intéressante :grin:.

Brisebee:
j’ai fait marcher les différents éléments séparément

Mais je continue à suivre avec grand intérêt vos échanges, je n’en suis pas encore à la liaison RS485, mais cela viendra en son temps.

Ollé Bribri, quelques détails de tes différents montages ? XD

Yep!

Osaka, J'éspère que tu n'as pas suivi ton schema à la lettre ;)

Il y a deux fils rouge mal positionnés...

Heu !!! Petite question concernant les resistances de ligne, 120 ohms au plus proche des tranceivers, elles sont où ??? Pour de longue distance, faudra peut être prévoir les lignes de pull up avec resistances de 570 ohms (5v sur A & Gnd sur B)

Pour un fonctionnement par maitre, pas besoin de 2 tranceivers/arduino, non ???

Sinon ton schema est super pour une compréhension du full-duplex en rs485 et effectivement le passage à l'etat haut de RE/DE met le tranceiver en mode Tx, à l'etat bas en mode Rx.

@+

Zoroastre.

zoroastre: Osaka, J'éspère que tu n'as pas suivi ton schema à la lettre ;)

Il y a deux fils rouge mal positionnés...

Non non évidement :sweat_smile:, c'était juste du vite fais pour présenté rapidement, c'est corrigé. :grin:

zoroastre: Heu !!! Petite question concernant les resistances de ligne, 120 ohms au plus proche des tranceivers, elles sont où ??? Pour de longue distance, faudra peut être prévoir les lignes de pull up avec resistances de 570 ohms (5v sur A & Gnd sur B)

Je pas mis les 120 ohms sur le schéma mais elles y sont bien, pour le moment comme c'est là c'est juste pour tester donc petite distance :..

zoroastre: Pour un fonctionnement par maitre, pas besoin de 2 tranceivers/arduino, non ???

Non pas obligatoire le fonctionnement par paire c'est juste pour le côté full duplex avec ou sans maître et vu le prix des sn75176 à 4,5€ les 5 j'en ai pris 10 (pieces pas 10 de 5) :grin:. (commandé sur ebay chez un français -> pseudo: andr8400 , ça boutique: Rimtron_Destock vous la trouverez directement dans google) En fait dans mes premier testes j'utilisais un maître en half ou full duplex histoire de tester un peux de tout, j'utilisais une mega comme maître pour le debug grâce à ses 4 ports series. Mais un mauvais branchement et du 15v ont eu raison de lui apparemment (j'en ai un nouveau en commande made in china qui devrait pas tarder) et c'est là que je me suis dit qu'il suffisait de relier rx/tx directement à ça place pour que les autres puissent continué à communiqué, d'où mes essais sans maître :open_mouth:. Un avantage d'une solution sans maître c'est en cas de pépins sur un modules le bus est toujours fonctionnel pour les autres, tandis que si le maître défaille ... Je suis pas arrêté sur cette solution 4 fils full duplex c'est juste que c'était déjà branché lol, parce que le plus compliqué c'est bien le code: risque de collisions, une fois libre qui qui parle en premier , prévoir tout les éventualités, etc, etc, ... =( XD

zoroastre: Sinon ton schema est super pour une compréhension du full-duplex en rs485

C'est toujours plus facile à expliqué avec un schéma. :grin:

Rebonjour a tous, mon stage d'un mois est fini et je retrouve ma petite famille. Je viens de jeter un œil sur vos derniers commentaires je vois que vous n'avez pas abandonner c'est cool.

Pendant mon stage je me suis familiariser avec l'arduino sur une guirlande de 25 leds adressables avec la librairies FastSPI . Je termine la semaine prochaine car j'ai reçu mes darlingtons pour mes dioders ikea, je vais donc souder tout cela et je reprend le projet domotique avec vous. En attendant si vous pouvez publiez vos codes et le sujet sur lequel il porte cela serait cool, certains on déjà posté du code très intéressant. Merci a tous et content d'être de retour parmi vous.

Yop Skuz, J'ai raté ton passage, content de te revoir. Pour mon code dès que j'aurais abouti et nettoyé je posterais. Moi c'est le travail de Bribri que j'aimerais voir. :grin:

Bonjour à tous,

Je viens de remettre le nez dans ce projet, après quasiment deux mois de standby : ce n'était pas de l'hibernation, j'ai travaillé sur d'autres projets (sans arduino, si si ça existe !).

En fait comme je l’avais prévu, j’ai testé les différents éléments matériels, j’ai réussi à tout mettre en œuvre. Je récapitule : Arduino Méga 2560 avec : - Horloge temps réel DS1307 => OK, reste à voir le recalage de l’heure sur Internet : j’ai vu que Jean-François a posté un tuto à ce sujet, lorsque j’aurai réglé la question de la communication de l’Arduino avec le serveur web, je reverrai cette question. - Afficheur LCD 4x16 => OK - Capteur de température et d’humidité DHT11 => OK (j’en utiliserai à priori 3) - Capteur de température DS1820 => OK (j’en utiliserai au moins un à l’extérieur car le DHT11 est limité de 0 à 50°C => il ne mesure donc pas les températures négatives) - Ethernet shield W5100 => OK , mais je n’arrive pas encore à travailler de manière satisfaisante dans les deux sens, il faut que je m’intéresse très sérieusement à deux projets l’un d’Osaka sur les websockets et celui de Stantor, mais les deux ne sont pas encore à ma portée, il faut que j’en apprenne encore un peu plus sur les technologies web, (j’ai déjà un peu progressé !).

Voilà, ce que j’ai prévu de faire maintenant c’est : - Réécrire mon cahier des charges en détaillant les différentes fonctionnalités attendues et en mettant en face les solutions techniques retenues. - Réécrire tous les bouts de sketchs que j’ai glanés et utilisés pour mes essais pour en faire des éléments modulaires, que je pourrai facilement assembler dans mon application finale. - Puis viendra la grande question de la communication avec le serveur web et le stockage de données (plages horaires, historiques …), j’aurai certainement besoin de votre aide.

Je vous soumettrai les éléments au fur et à mesure pour que vous puissiez réagir et éventuellement prendre ce qui vous intéresse (si cela présente un intérêt pour vous !). Bon, aller au boulot !!!

Yop Bribri content d'avoir de tes nouvelles. :open_mouth: Je vois que tu progresses bien , si tu as besoin d'un coup de main niveau web n'hésite pas. ;) J'attend également tes résultats et solutions niveau hard et gestion du 220, volets, etc . :grin: Je posterais bientôt le gros brouillons de mes résultat avec le bus rs-485.

Merci Osaka pour ta proposition d’aide pour le web, pour le moment je n’en suis pas encore là. Mais je ne manquerai pas d’appeler au secours lorsque je serai coincé, et probablement même avant pour demander des conseils pour le choix de solutions à mettre en oeuvre.

Je suis entrain de rédiger un cahier des charges très détaillé, dans lequel je vais décrire les fonctionnements attendus et les solutions techniques matérielles retenus avec schémas (testés et fonctionnels). Si au cours de ma rédaction (qui va prendre plusieurs jours, car je le fais à temps perdu) j’ai des questions (faisabilité, choix de solutions, …) je posterai sur le forum, sinon je vous livrerai mon cahier des charges une fois terminé.

Ensuite je câblerai mon système complet avant de passer à la programmation à proprement parler.
Pour la première version je n’aurai probablement pas besoin de la liaison RS 485, mais dans une version ultérieure et notamment pour gérer mes volets électriques (j’en ai 16 en plus du volet de garage) je vais surement utiliser un Arduino par étage, il va donc falloir les faire communiquer, mais ça ce sera beaucoup plus tard.

@+

Voilà, j’ai fini la première version du cahier des charges détaillé, je vous le soumets pour critiques, si vous avez le courage de le lire.
Je ne l’ai relu que très rapidement, si vous trouvez des incongruités, des incohérences ou des erreurs n’hésitez pas, c’est ainsi que j’avance.
La prochaine étape :
Câbler l’unité de gestion, puis la tester.
Je vous enverrai des schémas, des photos et les résultats de mes essais.
@+

Cahier des charges détaillé du système domotique avec interface web.pdf (437 KB)

Même si je pars sur une base 1 arduino par fonctions (contrôleur, I/O 220v, chauffage, volets, alarme, ...) ça me semble parfait et dans la même optique que moi. Étant très amateur dans le domaine de l'électronique, concernant triac ou optotriac et 220v j'allais partir sur cette base http://www.sonelec-musique.com/electronique_realisations_interfaces_230v_001.html. Qu'en penses-tu (vous) ?

J'ai rapidement regardé le lien concernant le montage de commande par triac, c'est un montage de base qui doit très bien fonctionner. Après il faut voir au cas par cas en fonction de la puissance à commander et du type de commande TOR ou progressif. Mais n'hésiste pas Osaka (on se tutoie) à me solliciter pour toute question liée au hard. @+

Yep!

Ok pour les triacs, mais ce serait plus mieux de dimensionner le circuit de puissance en fonction des disjoncteurs, 10 A et 16 A pour les plus courants. En cas de pépin ou de surchauffe, on risque de griller le recepteur et le triac sans que les appareils de sécurité aient réagis…L’autre option est de claquer un fusible 8 A sur chaque organe de commande.

@+

Zoroastre.