Bus domotique

Bonsoir le groupe !

Je voudrais un bus 'domotique' simple avec mon petit serveur sous Linux en tant que maître. j'aurais besoin de :

- envoyer des commandes simples a des périphériques (genre appareil truc, relais machin : colle !)

- lire des valeurs : (température, états ou autres, ça peut-être n'importe quoi..)

- qui marche simplement sous linux en ligne de commande (possibilité de programmer)

- logicielement, y'aura une fifo pour que deux ordres donnés en même temps soient bien traités (ce que ne fait pas mon programme en ligne de commande pour envoyer des trames 433MHz, d'ailleurs)

Exemple type : sous linux, scan du bluetooth, si mon portable est trouvé [1] alors ouvrir la porte de l'immeuble et quand je rentre, ça voit que le capteur de présence à été activé alors ça allume la lumière. si ça n'a pas vu de gsm dont la mac est reconnue, alors ça envoie un email, sans arrêter de relever la consommation électrique. Enfin, c'est un exemple !

Au pire, je pourrais essayer de tout recoder depuis le début, mais si y'a déjà quelque chose qui existe et utilisable, ça m'éviterai de me refaire une norme "maison" ;)

Merci d'avance ^^

-- cLx

[1]: (ce qui est peu probable dans l'immédiat, vu l'état dans lequel il est pour l'instant.)
Reply to
cLx
Loading thread data ...

Hello,

Tu as regardé tu côté du système "Domocan" de Bigonoff ?

formatting link
Son interface PC à été devellopée pour Windows, mais vu que le système est completement ouvert et entièrement documenté tu sauras le transposer à Linux, surtout si un simple truc à base de ligne de commande suffit.

"cLx"

Reply to
Adrien Gaudel

plein de trucs bien chez eux :

formatting link

le bus est de l'ethernet ca marche avec tout programmation en html depuis l'ordinateur

--

Jean-Yves.
Reply to
jeanyves

Si je dois me retaper la gestion du truc sous linux, et comme ce n'est pas une "vraie" norme, autant refaire un truc soi-même qui n'utilisera pas de composants introuvables et des micros moins chers que des 18F !

-- cLx

Reply to
cLx
[snip]

Hééé t'es relà ! Skool ^^

Ça a marché cette carte de conversion de niveaux de tension, ou tu veux que je te la fabriques ? ;p
Reply to
cLx

Si c'est l'approvisionnement en composant qui te poses problème je peux m'en charger. J'ai un compte chez Microchip (que tout le monde peut ouvrir) et là tu as toutes les references disponibles à des prix plus interessant que ce que l'on peut trouver chez les revendeurs. Enfin ce n'était qu'une idée, parce que justement pas mal de cartes ont déjà été devellopée par l'auteur, et quelque soit le système d'exploitation utilisée, elle fonctionneront tel-quel sans adaptation. Tu peux donc te concentrer uniquement sur le devellopement de l'application linux dont tu as besoin (que tu devras develloper de toutes manières). Le système peut de toutes façons fonctionner sans PC (c'est un système mixte que fonctionne aussi bien centralisé que décentralisé) J'aime bien la demarche de l'auteur qui a finalement la mentalité "open source". Plutôt que de develloper son truc dans son coin, puis d'essayer de le commercialisé d'une façon ou d'une autre, il met au contraire tout à disposition, avec en plus une documentation très fournie qui explique tout dans le détail. Même pas besoin d'essayer de comprendre comme ça marche, il s'est chargé de l'expliquer. Quelqu'un qui n'y connait strictement rien, peut avec un peu de courrage réaliser le système. Quelqu'un d'un peu plus formé pour s'en servir de base et l'ameliorer ou l'adapter à ses besoins. Si tu devellope tes propres cartes ou tes propres applications pour ce système, tu peux choisir de lui envoyer et il mettra tout à dispostion des autres. L'esprit Linux justement non ?

Après tu peux tout aussi bien te tourner vers des système "normalisés" : EIB, QNX, etc.. qui ne sont au final que des bus propriétaires que plusieurs constructeurs se sont entendu pour une utilisation communue. Là tu trouvera difficilement les documents pour faire toi même tes peripheriques, et si tu y arrive il faudra de toutes façons tout reinventer toi même. A moins d'acheter l'appareillage dans le commerce et ne te concentrer que sur le devellopement de la partie logiciel. Dans le même genre il y a les bus "industriels" : Profibus, Modbus, DeviceNet, CAN, ASi, etc... qui sont eux très bien documenté, mais alors même remarque que si dessus, ne compte pas sur les fabricant ni les organismes de normalisation pour te fournir schéma applicatif et exemple de firmware pour tes propres application. Il te faudra de farcir les normes et inventer tout toi même, à moins là encore d'acheter directement l'appareillage dans le commerce a un prix... industriel !

Mais c'est vrai que ça depend aussi de l'ampleur du système, ce que tu n'as pas précisé, et si c'est pour ce que j'imagine, alors peut-être que quelques cartes d'entrées/sorties sur un petit réseau RS485 seront suffisantes, le gros du travail étant alors fait du côté logiciel sur le pc sur lequel seront connectée ses cartes. Quand on parle de système domotique, je vois tout de suite le truc complexe capable de piloter et gerer absolument tout dans une maison de plusieurs centaine de m² mais ce n'est certainement pas ça que tu imaginais je pense.

Sinon en ce qui concerne la jauge, non je ne l'ai pas encore faite selon ton schéma. Pour l'instant j'en ai fait une version simplifiée qui n'utilise qu'un simple LM358, l'offset est deplorable mais je suis un peu pris par le temps alors ça suffira. J'aimerais integrer ton montage à une carte plus complexe qui se chargera aussi de la mesure du courant mais que je n'ai pas le temps de la develloper en ce moment. Et comme cette mesure de tension, même approximative, est quand même necessaire alors j'ai bricolé un truc vite fait avec ce que j'avais sous la main.

"cLx" une "vraie" norme, autant refaire un truc soi-même qui n'utilisera pas de

Reply to
Adrien Gaudel

ors

e de

et

Une approche simple est de partir sur du Modbus TCP. Le protocole est tr=E8s simple, la documentation suffisamment abondante et il existe de nombreux bouts de code sur le Net.

--

-Stan

Reply to
Stan

Si je ne me trompe pas, le modbus TCP est basé sur un cablage ethernet. en fait c'est une version encapsulée dans dans trames TCP-IP des trames du standard historique modbus (qui devait être en RS485 à l'origine) ça induit donc d'implementer une interface ethernet et une pile TCP-IP dans chaque peripherique connecté ?

"Stan" a écrit dans le message de news: snipped-for-privacy@h27g2000yqm.googlegroups.com...

Une approche simple est de partir sur du Modbus TCP. Le protocole est très simple, la documentation suffisamment abondante et il existe de nombreux bouts de code sur le Net.

--

-Stan

Reply to
Adrien Gaudel

en

dans

C'est ce qu'il y a de plus universel, certes pas le moins cher. Mais c'est dans une approche tout Ethernet =E9voqu=E9 par ailleurs dans ce fil. On peut se passer de TCP et utiliser Modbus en UDP, =E7a =E9vite la stack TCP/IP ;-) et c'est beaucoup moins lourd que de mettre des serveurs HTTP dans les =E9quipements...

--

-Stan

Reply to
Stan

Bonjour, pourquoi ne pas tout simplement utiliser le bus 1-wire qui est assez simple d'utilisation ( carte I/O minimale nécessitant quatre composants) et assez connu sous linux (digitemp et OWFS). Tu peux utiliser des composants qui s'occupent de lire la T°, d'autres qui se chargent de faire un ADC. D'autres qui sont servent I/O, etc... De plus, ce bus est pas très cher: (carte I/O à qqes ? et chaque composant à ~2?).

Cordialement

Reply to
Frank

il y a les mini serveurs web à puce avr pas cher et facile à programmer ...

formatting link

--

Jean-Yves.
Reply to
jeanyves

Non, les trucs ethernet c'est vraiment hors cahier des charges. Moi ce que je voulais, c'est un protocole qui va sur un bus en paire torsadée pour récupérer des données ou envoyer des ordres, et sur lequel j'aurais pas besoin de programmer un client sous linux pour l'utiliser et faire des automatismes.

-- cLx

Reply to
cLx

Voie intéressante ! Merci!

formatting link

Faudra que je teste tout ça... :)

-- cLx

Reply to
cLx

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.