Aidez nous ! Projet - Gestion domotique

Merci, je vois mieux la différence entre les deux maintenant.

zoroastre:

osaka:
J'aimerai connaître le résultat de tes expérimentations , compte rendu obligatoire

Pas de souci, par contre faudra être patient, j'ai un truc sur le feu pour l'instant XD

Pour détailler un peu, je compte mettre un afficheur tactile et l'ethernet sur un chip mega644 (taches lentes), quant au second 644, les tâches courantes, gestion des évenements capteurs et envoie des commandes asservies. Le tout en intercommunication.
J'espère avec cette configuration obtenir plus de réactivité sur les interfaces IHM.

figure toi que si j'ai bien compris, c'est exactement ce à quoi je pense, séparé contrôleur IHM (affichage, eth, ...) et contrôleur événementiel (temp, lum, horaire, ...)
(C'est pour celà que j'ai une adresse spécifique contrôleurs" 0x80" pour les retour et ack des modules, si cette adresse spécifiée, tout les contrôleur écoute c'est qu'il s'agit d'un retour d'état que la commande soit distante ou locale au module).

zoroastre:
Je n'ai pas encore fixé mon choix sur le chip des modules de commandes, l'attiny2313 a ma préference pour l'instant, mais il va falloir que je m'affranchisse de l'analogique et que je palie ce problème.

Je suis plutôt satisfait de ma solution actuelle à base de mega1280 + afficheur tactile + ds18b20 + relais piloté en rs485.
Je crains pourtant en ajoutant l'ethernet et des sondes supplémentaires d'être rapidement saturé en i/o et en vitesse de calcul.
Les avantages que j'entrevois dans ma solution est d'obtenir théoriquement deux fois plus d'entrée/sortie avec la même taille mémoire. (robotique ???)
Le plus chaud sera de partager les tâches équitablement. (l'option du clustering n'est pas loin!)

L'idée de déporter les modules de commandes me plait de plus en plus :wink:

La conception modulaire me conforte dans l'idée de n'avoir presque aucune limites. :open_mouth:

Yep!

osaka:
figure toi que si j'ai bien compris, c'est exactement ce à quoi je pense, séparé contrôleur IHM (affichage, eth, ...) et contrôleur événementiel (temp, lum, horaire, ...)

Ouép, on travaille dans la même direction.
C'est aussi une des raisons pour lesquels, je m'interesse beaucoup à tes dernières experimentations :wink:

Le protocole I2C est donné pour être plus rapide (100 à 400 khz) que le rs485, certes sur une distance beaucoup beaucoup moins importante. Mais l'essentiel est que ce sont tout deux des protocoles solides avec chacun une mission, celle au voisinage, celle au lointain.

Le proto que je dessine en ce moment réunit la puissance de 2 atmega644 afin de résoudre la séquentialisation des données.
En effet, comment donner la priorité à tel ou tel tâche si le cerveau est unique, l'algorithme devient complexe.
Si on décuple les cerveaux et on leur attribuent des tâches spécifiques mais conjointent, on commence à parler buffer de process, pipe et on aboutit à un système neuronal proche du clustering, avec un algorithme plus simple, un algorithme de fourmie travailleuse. :wink:

@+

Zoroastre.

Yop yop,
J'avais pensé à l'I2C (même au spi, can, ...), mais quelque chose me dérangeais c'est la communication maitre esclaves, pour laisser la parole à chaque esclave il est obligé de les interrogé l'un à la suite de l'autre, c'est un peux faire du "token ring" ?
J'ai vu qu'il y avait moyen de faire du multi-maître et d'entamé une conversation et transaction à la libération de la ligne sur sdl et sca ?
Enfin finalement je me suis dit que j'allais le réservé pour d'autre choses (par ex: le module rtc 1307, ...), que le rs485 permettait la longue distance, le "Multi-processor Communication Mode" que j'avais envie de testouiller, etc , donc j'ai pas approfondi le bus i2c. (et donc ça tombe bien que tu t'y intéresses :grin:).
Concernant la vitesse tout dépend également de ses exigences (à 4ms la transaction ça me donne quand même 250 transaction par sec ) et du code qui traine derrière , comme j'ai eu le cas avec l'ethernet (pourtant à 10Mbps théorique) et les sockets, on pourrais ce dire que ça rox, be finalement les différents chipotages,traitements (byte->json, etc) et intermédiaires (php qui clôture la transaction à la simple vue d'un 0 ]:slight_smile: ) donnent un résultat catastrophique comparé à ce que j’espérais pour une tel vitesse. (enfin ici c'est les différents chipotage pour rendre le tout compatible qui fout le boxon, faudrait que je remette mon shield, j'ai quelques idée pour pallier ça qui me trotte en tête). =(
Dans tout les cas la seule façon d'avoir le meilleur choix c'est de testé et comparé (je compte sur toi :grin:).
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?

zoroastre:
Le proto que je dessine en ce moment réunit la puissance de 2 atmega644 afin de résoudre la séquentialisation des données.
En effet, comment donner la priorité à tel ou tel tâche si le cerveau est unique, l'algorithme devient complexe.
Si on décuple les cerveaux et on leur attribuent des tâches spécifiques mais conjointent, on commence à parler buffer de process, pipe et on aboutit à un système neuronal proche du clustering, avec un algorithme plus simple, un algorithme de fourmie travailleuse. :wink:

On peux ajouter que la mort ou destruction d'un neurone n'empêche pas le cerveau de fonctionné (Je n'y vois que des avantages quand je lis ta description). :open_mouth:

zoroastre:
un algorithme de fourmie travailleuse

Tien ça me donne idée de nom (s'il faut le nommé :P) au système, "antsDomo" la fourmilière au service de votre maison. XD

Premier post pour vous dire...
...
..
.
que vous êtes de grands malades! XD

Continuez, personnellement je suis vos avancées avec attention! :wink:

Yep!

osaka:
J'avais pensé à l'I2C (même au spi, can, ...), ...
J'ai vu qu'il y avait moyen de faire du multi-maître et d'entamé une conversation et transaction à la libération de la ligne sur sdl et sca ?

Je suis passé par ces étapes de reflexion également, et effectivement le mode multi-maitre fait partie du protocole I2C. Lors de mes recherches, j'ai entrevus quelques solutions arduino et je pense sincèrement que cela est possible.
Les ressources ne sont pourtant pas trés nombreuses et plutôt légères. Il n'y aura, bien sûr, que la pratique qui pourra valider ou pas mes hypothèses. L'experience me tente fortement.

osaka:
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?

Je m'attendais à ce que le crc soit plus lourd en fait. J'avais regardé les differents algo de contrôle et certain me semblait fort alambiqué. Il faut effectivement voir ce qu'il apporte réellement.

osaka:
"antsDomo"

:grin:

Pour le proto, la mise en place des composants ne sera pas trop compliqué, j'ai surtout des problèmes d'esthétique en fait, je travaille sur une seule couche (compo dips uniquement) et j'essaie d'eviter autant que possible les straps.
Je suis déjà à mon second shema, le premier sur un seul plan, le second sur deux (principe du shield).
Je vais encore tatillonner quelques jours/semaines avant de choisir une solution. J'ai déjà l'essentiel des composants, et j'aimerais autant que possible que le proto soit plus qu'un proto, donc une plateforme pre et/ou définitive.
Le processeur IHM sera donc pourvu de l'ethernet de facto (ENC28J), d'un bus rs232 et rs485. Le processeur evenementiel sera doté de deux bus rs485. Une liaison I2C liera les deux processeurs, une eeprom au milieu.

Je travaille depuis peu avec les registres, cette méthode me parle plus en fait, je suis technicien de maintenance et l'automatisme est mon dada. J'ai par contre tout à apprendre du c++, mais je voyage depuis quelques années d'un language à un autre au grés de mes besoins.

Levaillant:
vous êtes de grands malades!

Et c'est que le début XD

@+

Zoroastre.

zoroastre:

osaka:
Ca me fait pensé qu'il faudrait testé ma solution sans la gestion du crc voir si ça en vaut la peine ?

Je m'attendais à ce que le crc soit plus lourd en fait. J'avais regardé les differents algo de contrôle et certain me semblait fort alambiqué. Il faut effectivement voir ce qu'il apporte réellement.

Je m'attendais également à une certaine lourdeur, jusqu'a ce que je tombe lors d'une de mes explorations sur le crc16.h de la lib avr.

static __inline__ uint16_t
_crc16_update(uint16_t __crc, uint8_t __data)
{
	uint8_t __tmp;
	uint16_t __ret;

	__asm__ __volatile__ (
		"eor %A0,%2" "\n\t"
		"mov %1,%A0" "\n\t"
		"swap %1" "\n\t"
		"eor %1,%A0" "\n\t"
		"mov __tmp_reg__,%1" "\n\t"
		"lsr %1" "\n\t"
		"lsr %1" "\n\t"
		"eor %1,__tmp_reg__" "\n\t"
		"mov __tmp_reg__,%1" "\n\t"
		"lsr %1" "\n\t"
		"eor %1,__tmp_reg__" "\n\t"
		"andi %1,0x07" "\n\t"
		"mov __tmp_reg__,%A0" "\n\t"
		"mov %A0,%B0" "\n\t"
		"lsr %1" "\n\t"
		"ror __tmp_reg__" "\n\t"
		"ror %1" "\n\t"
		"mov %B0,__tmp_reg__" "\n\t"
		"eor %A0,%1" "\n\t"
		"lsr __tmp_reg__" "\n\t"
		"ror %1" "\n\t"
		"eor %B0,__tmp_reg__" "\n\t"
		"eor %A0,%1"
		: "=r" (__ret), "=d" (__tmp)
		: "r" (__data), "0" (__crc)
		: "r0"
	);
	return __ret;
}

Ca m'étonne d'ailleurs que ce code ne soit pas plus utilisé, pour le 1wire par exemple ... alors que ...

_crc_ibutton_update(uint8_t __crc, uint8_t __data)

zoroastre:
Pour le proto, la mise en place des composants ne sera pas trop compliqué, j'ai surtout des problèmes d'esthétique en fait, je travaille sur une seule couche (compo dips uniquement) et j'essaie d'eviter autant que possible les straps.
Je suis déjà à mon second shema, le premier sur un seul plan, le second sur deux (principe du shield).

Pour le module I/O (8/8) je partais sur le principe du 2 couche (shield mais avec mini qui vient ce "broché" par dessus) vu ça taille (30X17) , sinon pour les autre où le mini ne serait pas adapté ça sera comme toi simple couche et dip ,pas question de uno, mega, ... ou la place est loin d'être optimisé à l'utilisation qu'on en ferais (je suppose que c'est également ton but, d'ailleurs il y a des chance que je te copie :grin:) .

zoroastre:
Je travaille depuis peu avec les registres, cette méthode me parle plus en fait, je suis technicien de maintenance et l'automatisme est mon dada. J'ai par contre tout à apprendre du c++, mais je voyage depuis quelques années d'un language à un autre au grés de mes besoins.

En effet la logique semble plus intuitive pour quelqu'un ayant l'habitude de l'automatisme, l'electropneumatique, hydrau, etc, industrielle.
Mes premières études (secondaire = college/lycees) étaient dans l'électromécanique (tout du moin avant que je me fasse mettre à la porte de l'école :.), puis la construction mécanique et métallique et mon meilleur amis qui étais avec moi au cours est technicien de maintenance maintenant (kraft be).
Finalement je regrette d'avoir choisie la voie de l'informatique (dev) ...
Enfin cette voie je l'ai pas vraiment choisie , c'est suite à une reconversion (graduat= bac+3) après une accident de tuture qui ma foutu les bras en l'air.
Maintenant j'hésite à faire une "petite" formation d'automaticien ou électromécanicien pour quitté le monde des fauteuils de bureau qui ne veulent pas de moi de toute façons. :grin:
Pour l'instant je me réfugie sur les µc et la domo des fourmis.

Levaillant:
vous êtes de grands malades!

C'est pas le début de la fin, c'est la fin du commencement (vers la follie). :grin:

Je suis également vos échanges que je trouve très intéressants, mais pour le moment mes préoccupations sont bien plus basiques.

J’espère seulement être en mesure de suivre et contribuer à vos échanges un de ces jours (même lointain).

L’idée d’utiliser plusieurs processeurs pour diverses tâches, peut-être très intéressante, et peut apporter un niveau de sécurité supplémentaire, car un processeur peut de temps en temps surveiller l’autre et réagir en cas de dysfonctionnement.

Yop bribri,

Brisebee:
J’espère seulement être en mesure de suivre et contribuer à vos échanges un de ces jours (même lointain).

Be tu contribues déjà pas mal, rien qu'avec ton doc très détaillés sur ton cahier des charges et schématisation que j'ai relus plusieurs fois (dans mon fauteuil au coin du feu avec un cigare et un vieux whisky XD) car je le trouve intéressant.
Il y a des chose que je ne connais pas,schémas, etc.
:wink:

J'ai câblé au propre et testé la plus grande partie de la carte unité de gestion UC.
Elle comporte :

  • La carte Arduino Mega 2560
  • La carte Ethenet Shield W5100
  • La petite carte RTC-DS 1307
  • Un afficheur LCD 4x16 caractères
  • La connectique pour raccorder la carte d’interfaçage et les interfaces des unités de gestion (chauffage et arrosage)
  • Un watchdog (pas encore câblé au propre)

Tous les tests de fonctionnement du matériel sont OK.

J’ai rajouté un watchdog matériel qui se déclenche et remet à zéro la carte Arduino Mega 2560 au bout d’une seconde environ, s’il n’est pas lui-même remis à zéro par le programme.

Je ne sais pas si c’est bien utile, je n’ai pas encore regardé de près le watchdog interne du microcontrôleur (qui doit avoir la même fonction) mais je me suis dit que ce sera une sécurité supplémentaire (et comme j’ai de la place sur la carte et que cela met en œuvre des composants standards que j’avais en stock !)

Que pensez-vous de cette option ?

Je vous joins le schéma de ma carte unité de gestion UC.

J’ai baptisé mon système DOMOWEB 2012

J’attends vos critiques.

Unité de gestion carte UC.pdf (59.8 KB)

Yep!

First, tu es sur de ne pas avoir besoin de pwm, parce que là tu les a tous mangé XD
L'afficheur peut être piloté avec un shift register ??? (tu ne gagnerais pas grand chose, c'est une question pour la forme)

Le 4060 est bienvenu, en effet le watchdog interne se contente de faire uniquement un reset software, il reprend au setup() si il ne reçoit pas le signal life à temps.
Un watchdog hardware te permettra un reboot complet de la carte en cas de défaillance, c'est une bien meilleur option et tout le monde apportera son crédit à cette solution :wink:

(En aparté, Il faut juste faire gaffe à certain péripherique qui ont une option reset propre, mon afficheur tactile par exemple freeze si je lance un reset de l'arduino, un second reset et tout est ok...il faut être prudent avec le timing de certain peripherique.)

EDIT 1 : J'envisage également un watchdog hardware à base de 555.
Je ne connais pas trop le 4060, alors avantages/inconvénients, gestion arduino ???

@+

Zoroastre.

zoroastre:

zoroastre:
tu es sur de ne pas avoir besoin de pwm, parce que là tu les a tous mangé

Non à priori je n'en ai pas besoin => j'en ai gardé une (la 9).

De toute manière j'ai fait mon câblage en wrapping, je pourrais donc modifier si je suis coincé.

Je vais avoir besoin de pas mal d'entrées sorties digitales, car j'ai décidé de reboucler les sorties (signaux directement prélévé sur les actionneurs et adaptés donc 230 VAC en 5 VDC et 24 VAC en 5 VDC) pour pouvoir contrôler l'état des actionneurs même en mode manuel.

zoroastre:
Un watchdog hardware te permettra un reboot complet de la carte en cas de défaillance, c'est une bien meilleur option et tout le monde apportera son crédit à cette solution :wink:

Cela conforte mon idée, je vais donc le câbler au propre.

Merci
@+

Yep!

Je vais avoir besoin de pas mal d'entrées sorties digitales

Si tu as besoin de pas mal de sorties digitales, les registres à décalage sont interessants, le 74HC595 (le plus documenté) ou les TPIC595 (TPIC6B595, etc) sont des chip série vers parallèle/série.
Uniquement 3 sorties arduino sont nécesaires pour piloter ces composants (8 sorties) par communication SPI, tu peux, qui plus est, chainer les chip les uns derrière les autres jusqu'à "je ne sais plus combien :grin: ".

Tu réduis ainsi ton nombre de sortie digital tout en gagnant en nombre d'entré :wink:

Le 74HC595 tolère max 70mA, (1x25 + 7x35 mA) par sortie.
Le TPIC6B596 tolère max 0.5A/50v, 150 mA par sortie (au nombre de 8). Une option interessante pour piloter de nombreux relais par exemple.
Le TPIC6595 tolère max 1.5A/45v, 250 mA par sortie.

Pour réduire le nombre d'entrée, je n'ai pas de solution qui me vienne en tête à par les ADC, CD4021...dans ce cas là, il faut être à l'ecoute des données entrantes, ce peut être interessant dans certain type de montage/programme...

@+

Zoroastre.

Merci zoroastre pour ces infos.

J'ai prévu de mettre en oeuvre la configuration décrite dans le fichier joint : (je n'arrive pas à mettre des images directement dans le post)

Ainsi j'étends le nombre d'E/S avec des PCF 8574 (I2C I/O expander) ce qui me permet de me "rapprocher", en simplifiant le câblage des liaisons avec mes unités de commande :

  • l'unité de commande arrosage ( 10 E, 10 S) se trouve à environ 50cm de mon unité de gestion;
  • l'unité de commande chauffage 5 zones ( 5 E, 5 S) se trouve à environ 1m de mon unité de gestion.

J'ai lu par ci, par là, que le bus I2C permettait de créer sans problème des liaisons jusqu'à quelques mètres.

Je vais câbler cela dans les prochains jours et faire des essais en ce sens.

Je vous tiendrai au courant.

Si vous avez des expériences et/ou des infos sur le sujet n'hésitez pas à m'en faire part pour que je puisse en tenir compte.

Principe unité de gestion.bmp (727 KB)

Yop Bribri,
C'est une véritable machine de guerre que tu nous fais là. :grin:
Sur l'utilité du watchdog pour moi il est surtout justifié dans le cas de code à risque et surtout au niveau des boucles que je sécurise via délais maximum d’exécution par exemple, mais au temps que possible j'évite d'en avoir dans mon code (j'utilise le fait que loop soit déjà bouclé en permanence).
Tiens sur le fait que Bribri n'utilise pas le pwm me fait pensé qu'on peux désactivé pas mal de fonctionnalité de l'avr, faudrait que je reregarde (Power Management and Sleep Modes) une fois à ça vu que pour mon module I/O par exemple il y a pas mal de chose dont je n'ai pas besoin, pwm, timer, i2c, ...

Bonjour,

Bravo pour ton projet, cela m’intéresse, je commence à me documenter pour faire à peu près la même chose, dans un premier temps surtout pour gérer mes chauffages électrique.
Je débute, je vais peut-être poser des questions bête...

As-tu finis et testé ton module 6 ordres ? Il fonctionne bien ? Il te revient à combien ? il tient dans l'emplacement cassette du chauffage ?

Sinon, pour un simple module 2 ordres (qui permettrait déjà le Normal / Confort), As-tu réfléchi/testé la solution de prendre un interrupteur commercial RF 220v/433mhz, comme décrit dans le projet

(Il n'y a pas de fils pilote entre mes différents chauffages, il me faudra un module par chauffage)

Yep!

J'ai lu par ci, par là, que le bus I2C permettait de créer sans problème des liaisons jusqu'à quelques mètres.

A la base, l'i2c est prévu pour quelques dizaines de centimètre.
Il est effectivement possible d'aller au delà en utilisant des répetiteurs, mais faut pas espérer aller au delà de 3 mètres.
Déjà, 1 mètre je trouve que cela fait beaucoup !!!

Il faut voir si ton 8574 fera un tampon correcte.

@+

Zoroastre.

cedric2:
Bravo pour ton projet, cela m’intéresse,

Merci, n'hésite pas à poser des questions. Nous sommes plusieurs sur ce forum à travailler dans le même esprit, sur des projets similaires.

cedric2:
As-tu finis et testé ton module 6 ordres ? Il fonctionne bien ? Il te revient à combien ? il tient dans l'emplacement cassette du chauffage ?

Non je n'ai pas testé ce module, je n'ai pas encore décidé si je vaiment mettre en oeuvre les 6 ordres.
Je crois que Skuzmitoo l'a simulé et peut-être même testé en vrai, tu trouveras des infos à ce sujet dans ce sujet vers les pages 9 ou 10, pour ce qui concerne le coût il suffit de voir sur un site comme sélectronic, conrad ou autre mais cela ne va pas chercher bien loin, le plus cher et aussi le plus encombrant sera le transfo.

cedric2:
As-tu réfléchi/testé la solution de prendre un interrupteur commercial RF 220v/433mhz

Non, je n'utilise pas de liason RF, mais il me semble que d'autres ont publié à ce sujet.

zoroastre:
A la base, l'i2c est prévu pour quelques dizaines de centimètre.
Il est effectivement possible d'aller au delà en utilisant des répetiteurs, mais faut pas espérer aller au delà de 3 mètres.
Déjà, 1 mètre je trouve que cela fait beaucoup !!!

Merci pour ton avis.
Je vais faire des essais (peut-être ce weeck-end), en augmentant la longueur de la liaison et en tentant de simuler un milieu relativement perturbé.

@+

osaka:
C'est une véritable machine de guerre que tu nous fais là.

Je vais essayer de faire un sorte que le système soit le plus fiable possible, même si ce ne sera pas le plus économique => je ne compte pas en faire des séries : je vais en faire 2 un qui sera fonctionnel et un second pour faire des essais et qui servira pour dépannage en cas de panne.

Je joins un autre schéma de principe des laisons entre les différentes unités : gestion / interface / commande

(je n'ai toujours pas trouvé comment insérer directement une image dans le message)

@+

Yop yop,

Brisebee:
(je n'ai toujours pas trouvé comment insérer directement une image dans le message)

2 ème icone à partir de la gauche au dessus des smileys : [img ] url [/img ] (sans l'espace avant ']' )