Domaci automatizace
Marek Pavlu
marekpavlu@mybox.cz
Středa Květen 11 01:09:51 CEST 2005
Zdravim,
Tim, ze vyradite rodinu PIC, ale i AVR, eZ8 a dalsi se vystavujete znacnemu
nebezpeci, ze mnoho lidi od toho da ruce pryc:((((.
Naopak by se melo postupovat naproasto opacne.
1. komunikacni protokol, nejlepe dnes asi RS485.
2.Definovat pozadavky na sitovou komunikaci
-pozadavek bezpecnosti(CRC paketu)
-- je mozna vhodne definovat formu paketu i pro data, kde neni dulezita
bezpecnost(omezeny prenos zvuku)
-delka adresy
-delka paketu(a tedy delka dat)
--konstantni
--variabilni
-zpusob potvrzovani mezi kumunikujicimi partnery
-reseni kolizi na siti
(site predavajici prava k vysilani"token" jsou zde neprakticke pro velky
pocet prvku site)
--moznost zavest prioritu do paketu pro nasledne reseni kolizi a akteri se
stejneou prioritou si musi hodit minci, kdo driv:))).
-definovat upgrade FW primo do zakladu protokolu a to co nejobecneji, aby to
prezilo i nove typy svabu, urcite nikdo nehodla kvuli titerne zmene
vykuchat svaba ze zdi. Ani modularni architektura, kdy se navrhne vymena za
jiny kus(modul) z duvodu SW chyby nebo nutnosti zmeny FW je neprijatelna!
-definovat spojovani subsiti
(kde subsit je jedno fyzicke vedeni s omezenym poctem clenu na RS485)
--bud jen hloupe spojky, ktere jen vse zopakuji
(zatez site roste s jeji velikosti)
--nebo se vydat cestou "chytre" spojky, zarizeni, ktere bude spojovat jednu
subsit(maximalni pocet zarizeni na jedne lince RS485) do jine subsite.
--kombinace vyse uvedeneho
3.Najit univerzalni zastupce(tridy) z jednotlivych rodin procesoru:
a) pro cleny plnici funkce sitovych spojek
b) cleny s vyssim vypocetnim pozadavkem
(meteostanice, ridici cleny slozitych prvku, ...)
c) cleny s nizzsimi pozadavky na vypocetni vykon, tedy ridici cleny nebo
snimace jednoduchych velicin bez nutnsti narocneho zpracovani dat(snimace
osvetleni, PIR snimace, tlacitka, rizeni SERV nebo krokovych motoru atd)
d) a v neposledni rade cleny plnici funkci napojeni do standardni
site(Ethernet,WiFi) nebo prostredku, ktery to umozni(PC)..
4.Definovat univerzalni programovaci jazyk pro vsechny cleny
-jak pro bod 3., tak pro systemy navazujici(PC) popripade tolerovat jen
jazyky pribuzne (zde bych ja osobne uprednostnil C/C++) nebo takove, ktere
lze vyuzit k tvorbe DLL(Object Pascal,...) nebo jineho druhu kompatibilniho
propojeni do jazyku(C/C++ popripade C#,Obj.P., VB atd).
-moznost vytvoeni portu do dalsich jazyku muze byt na urovni DLL knihoven
nebo jinych technologii a obecne na samem zacatku neni tak dulezita
-distancovat se interpetovacich jazyku, desim se toho, ze mi bude ridit
teplotu v byte nebo něco nebezpecnejsiho napriklad Perl, Java nebo
VisualBasicScript!!!!
5.Dohodnout se na centralizovane/decentralizovanem systemu
-centralizovany je jednoduchy pro par clenu, ale pro veti pocet roste
slozitost, vypocetni zatez a klesa rychlost obsluhy jednotlivych clenu.
(urcite tam hned tak nekdo nevrazi P4).
Dalsim problemem je reseni vypadku centra, nutnost sekundarniho(stejne
vykonnneho) systemu.
Znacna spotreba takoveho centra a reseni jeho nechutnych naroku na spotrebu!
-decentralizovany system je slozity na navrh od pocatku, ale je bezpecnejsi
neni nutno se bat vypadku cele site
6.Pro kazdeho zastupce z bodu 3.:
- vytvorit knihovnu funkci pro podporu sitoveho protokolu a upgrade FW.
-- tedy dopredu vyresit celou komunikacni vrstvu tak, aby ten, kdo si vezme
dany zakladni modul jen s podporou site mohl zacit pracovat na
inteligenci daneho modulu a neresit to same dokola jako dalsi
vyvojari(sitovy protokol).
- musi byt pamatovano na moznost prechodu na novejsi typ stejneho razeni,
takze se vystrihat specialitkam daneho kousku procesoru!
- napsat zakladni(jednoduche) priklady pouziti sitove knihovny
Kdyz vyrazite tak nejak touto cestou(třeba i se znacnymy odchylkami od zde
uvedeneho), tak se dostanete k otevrene platforme pro tri-ctyri typy rodin
procesoru, ktere spolecne dokazou komunikovat, kde muzete vzit kod, resici
inteligenci nejakeho prvku site a s drobnymi upravami prenest jej na jiny
typ procesoru stejne vykonnostni tridy a schopnosti...
Pritom si staci uvedomit, ze jednotlive procesory lze resit jako moduly, kde
by mohla byt definovana jista kompatibilita dana vyberem v jednotlivych
rodinach s prihlednutim k bodu 3. a definici trid...
Znamenalo by to nekde potlaceni jistych schopnosti jednotlivych procesoru,
ale v zasade by to slo uskutecnit.
Samozrejme nema smysl se venovat takove rodine, kterou v soucasnosti nelze
pokryt dostatecnym poctem zajemcu z rad vyvojaru ochotnych na takovem
projektu spolupracovat:))).
Tot muj prosty nazor, ale stojim si za nim:).
Nicmene me casove moznosti jsou nyni znacne omezene, ale takovy projekt se
mi libi a urcite bych se i nejak v prubehu zapojil. Bylo by to jak splneni
detskeho snu:(.
S pozdravem,
Marek Pavlu
// -----Original Message-----
// From: hw-list-bounces@hw.cz [mailto:hw-list-bounces@hw.cz] On Behalf Of
// Pavel Novotny
// Sent: Tuesday, May 10, 2005 1:29 PM
// To: 'HW-news'
// Subject: RE: Domaci automatizace
//
// Jak se zda z ohlasu v konferenci a ohlasu na muj email, zajem o domaci
// automatizaci (DAtm)je relativne velky, otazkou je zda se lze shodnout na
// nejakem dostatecne konkretnim a pritom dostatecne univerzalnim reseni :-
// ).
// O problematice DAtm premyslim pomerne dlouho a neco na tento zpusob jsem
// jiz
// realizoval, muj soucasny "svetovy" nazor je:
// HW zakladem by mely byt dva typy modulu "velke" moduly pro umisteni na
// DIN
// listu do rozvadece, "male" moduly pro umisteni do krabicky pod omitku ,
// ktere se hodi tam, kde neni ucelne veskere ridici a ovladane vodice
// svadet
// do rozvadece.
// Moduly musi byt schopne zakladni funkce bez ohledu na nadrizeny ridici
// system, byt snadno vymenitelne a nahraditelne i za x desitek let bez
// nutnosti "bourat" dum.
// Vyssi stupen rizeni a spolupraci jednotlivych modulu + komunikaci s
// uzivateli by mel zajistovat co nejotevrenejsi system tj. asi PC (Via epia
// nebo jine nizko prikonove zarizeni). Nenasel jsem jinou tak "levnou",
// univerzalni, snadno rozsiritelnou a prubezne upgadovatelnou hw a sw
// platformu.
//
// Jake moduly prichazi pro DAut v uvahu ?
//
// - modul rizeni osvetleni
// - modul rizeni vytapeni
// - modul rizeni vetrani
// - modul rizeni bazenu (TUV)
// - modul EZU
// - meteo modul
// - zavlazovani zahrady
// - modul rizeni spotrebicu (zasuvek)
// - modul rizeni kameroveho systemu
// - audio modul
// - takove drobnosti jako dverni vratny apod.
// - ???
//
// Jako priklad si rozeberme modul rizeni svetel:
//
// Navrhuji resit ho jako velky modul na DIN listu pro rizeni 8 vykonovych
// vystupu a tomu odpovidajici pocet logickych vstupu (vypinacu v
// mistnostech)
// vykonovy vystup triak s moznosti rizeni On/Off , rizeni uhlu otevreni
// (stmivani). Pri instalaci se v modulu definuje (EEPROM)
// - jaky typ spotrebice je pripojen na kazdy vystup (klasicka zarovka,
// uspora,
// zarivka, halogen,..
// - spotreba
// - vstupum se priradi prislusne vystupy a definuje se reakce na vstup.
// Modul loguje provoz na jednotlivych vystupech a pocita "motohodiny"
// Tolik zakladni funkcionalita bez komunikace s nadrizenym ridicim
// systemem.
// Nadrizeny ridici system muze vyuzivat udaje
// - o pritomnosti osob v mistnosti (infa cidla alarmu) (lze vyuzit
// napriklad pro rozsviceni na chodbe apod..)
// - udaje z meteo modulu o intenzite svetla
// - samotny ridici system muze z astronomickych a casovych udaju
// pocitat
// dobu soumraku , ovladat svetla v zavislosti na predpripravenych pevne
// nebo
// nahodne danych tabulkach a programech.
// - takove drobnosti jako ze system pri uvedeni alarmu do stavu armed
// zkontroluje zda jsme nekde nezapomneli zhasnout nebo sleep funkce u
// svetel v
// loznici a podobne drobnosti snad netreba zduraznovat .
// - nadrizeny ridici system muze prijimat povely od uzivatele pres
// dalsi
// interface napada me Bluetooth, infa, web rozhrani atd.
// Podobne muze byt resen maly modul rizeni svetel, ktery by se umistoval
// pod
// vypinac a umoznil rizeni 1 (2-3) svetel
//
// Proc je lepsi spojit sily:
//
// - hromadna profi vyroba DPS pro jednotlive moduly vyjde vyrazne
// levneji , obecne moznost stahnout si predlohy pro DPS setri cas
// - existence otevreneho a zdokumentovaneho komunikacniho protokolu
// umoznuje dodelat si vlastni moduly
// - vyhody spolecne tvorby software jak pro ridici system tak pro
// moduly
// jsou nasnade.
//
//
// Na cem je treba se dohodnout ?
//
// - designu modulu (pouzity MCU) nechci nikterak podcenovat PIC od
// Microchips, ale jako vhodnejsi mi pripada pouzit radu x51, nejde o
// proprietarni reseni od jednoho vyrobce a tak je relativne vetsi
// predpoklad
// lepsi dostupnosti v case a zamenitelnost jednotlivych out of time typu
// MCU.
// ?
// - komunikacnim mediu, exoticka reseni typu bezdratove komunikace nebo
// ethernet bych nechal do rise snu a sahl bych po stare a overene RS485 ?
// - komunikacni protokol, zde nemam zadneho favorita, ale melo by ji o
// neco relativne standardniho, jednoducheho s CRC zabezpecenim. ?
// - OS pro ridici PC, neni az tak dulezity, idealni je platforme
// nezavisle reseni , ale kdyz ma byt neco Open tak asi Linux :-)
// - v cem psat ridici sw pro ridici PC , tezko rici, srdce Veckare rika
// v C nebo C++, ale faktem je , ze pokud ma byt system co nejuniverzalnejsi
// modularni apod. tak nejsou k zahozeni ani reseni zalozena na vyssim
// interpretovanem jazyku. Neco jako reseni postavene na Perlu
// http://w3.misterhouse.net:81/
//
//
// Tolik na uvod, nyni ocekavam vase pripominky a namety. Kdyz nic jineho
// tak
// uvidime, ze se nelze na nicem dohodnout a muzeme si kazdy dale bastlit tu
// svoji nej automatizaci :- )
//
// _______________________________________________
// HW-list mailing list - sponsored by www.HW.cz
// Hw-list@list.hw.cz
// http://list.hw.cz/mailman/listinfo/hw-list
---
avast! Antivirus: Odchozi zprava cista.
Virova databaze (VPS): 0519-1, 10/05/2005
Testovano: 10.5.2005 23:23:50
avast! (c) copyright 2000-2003 ALWIL Software.
http://www.avast.com
Další informace o konferenci Hw-list