Domaci automatizace - zhrnutie variant

Pátek Květen 20 21:35:30 CEST 2005

Zdravim,

Jen jsem chtel ukazat prinosy/vyhody/nevyhody jednotlivych reseni, kde jsem
ocekval, ze to nekdo doplni o dalsi klady/zapory a srovanim se da nalezt
reseni, jako rozumna volba nezalozena na predsudku, ale to je asi muj
nejvetsi omyl, ktereho se nelze u jedincu typu clovek nijak strepat, to je
proste asi jako jeden nerozlozitelny balik:)).

ale kdyz to chcete takto, tak Ok:).

Mne se zasadne libi navrh v bode prvnim, ale ma to dosti much a je videt, ze
to bylo psano trosku zaujate, to byl duvod, poc jsem se do hlasovani
nezapojil:).

Jestlize vsak vyjdu ze zakladu bodu prveho a prijmu nasledujici predpoklady:

___
1.Jsme chudi, fyzicka vrstva pro samotnou sit musí byt levna:
-tak z toho vyleze RS485.
___
2.Jestlize prijmeme fakt, ze decentralizace neni o moc slozitejsi nebo
drazsi a trebas muze byt i levnejsi(spotreba dvojice CMS, narocnst na udrzbu
dvojjice CMS)
___
3.Jestlize prijmeme fakt, ze sit rozdelena na subsite je bezpecnejsi:
-subsite jsou samostatne jednotky a primo se dovnitr neda bez posveceni
nejakou logikou, trebas jen kontrola checksumy, nic vyslat
-kdyz se nekdo na jedne subsiti zblbne, tak to nezasahne celou sit
-kdyz se preskubne drat, tak preziji navazujici subsite
--pokud mají spojeni, tak jako celek
--pokud jiz zadne namaji, tak zustane zakladni funkcnost v subsiti zachovana
___
4.Pokud prijmeme pozadavek, ze jedna subsit = jedna mistnost
-není to však uplne dogma, jen pocatecni pozadavek, který se muze v prubehu
zivota domu v nekterych mistnostech zmenit...
- pri prebudovani pokoje se muze stat, ze bud je treba v jedne subisti
dvojice pokoju(pokud se nepresahne pocet pripojitelnych modulu, tak zadny
problem), ale v tom horsim se muze stat, ze svetlo je v jine subsiti nez
spinac(ale treba i jiny prvek, fyzicke rozdeleni svetlo spinac neni dogma),
tedy problem nastane, pokud vypadne sit, ale porad pojede topeni a takto
prebudovavat urcite nebudete cely dům, takze plno pokoju si muze zachovat
zakladni funkcnost neautomatizovaneho domu
-takz muzeme zachovat jeji funkcnost i v pripade vypadku spojeni s
navazujicimi subsitemi
--sice nebude ventyl topeni rizen zcela efektivne, ale porad muze byt v
mistnosti teplo
--porad muzeme svitit
--porad zasuvky pobezi
v takovem pripade jen ajen zhebnou vyssi funkce mozkove, ale porad dychame a
na nejake zakladni urovni i zijeme
-vypadek takto ochromi hlavne bezpecnostni prvky(zabezpeceni, pozar,...) a
dále prvky, ktere jsou v DA jakymsi strazcem efektivnosti domu...
___

Pritom poznamenavam, ze antikolize neni stastna a tim padem, vzhledem k tomu
k bodu 3. nic nebrani tomu, aby funkci spravy tokenu v subsiti ridil ten
samy prvek site, ktery ji napojuje do vedlejsi subsite avsak v teto externi
subsiti musi sam cekat na token stejne jako kazdy jiny prvek na subsiti.
Takze nazvete ho jak chcete(ja tomu rikam spojka nebo brana). Ale bude to
resit funkci subsiti, jejich propojeni a predavani zprav. Hlavnim problemy
vidim tyto:
a) Jak resit adresaci v subsitich
b) Jak resit pridavani prvku do subsite.
c) Jak resit komunikaci v subsitich(treba Broadcast zpravy, ale i adresne
zpravy)
d) Jak resit komunikaci mezi subsitemi

Vse ostatni, rozumne, co tu bylo od funkci site pozadovano si dovedu
predstavi realizovane nad takto koncipovanou siti...

Odpovedi na reseni mam v kapse, ale reknu jen, pokud nekdo tyto ctyri body
muze/chce akceptovat:). V opacnem pripade jsem ztratil několik dni nad
debatou, ktera casto, nikam nevedla, která často byla jen pristipkarska s
pridavky osobnich urazek, ac ne sprostych:))).

Jo a abych nezapomnel, je velice zajimave, jak se tu resi pady site(pritom
jsem ukazal, ze s pomoci deleni na subsite LZE resit jeji vyoadky), ale pak
se tam nakonec vrazi CMS, ktere je mnohem citlivejsim clankem retezce. Navic
mi reknete, jak chcete resit pripad, ze CMS zblbne, ale bude to vypadat, ze
stale bezi??? V navrhu kazdeho modulu tak s touto eventualitou musite
pocitat. Stejne tak musite tuto ulohu resit v nahradnim CMS atd...
O to horsi to je v pripade, ze mate MultiMaster s tim, ze se moduly zbrchaji
do jakehosi decentralizovaneho rezimu(kdopak to vsechno otestuje ve vsech
rezimech). Pokud mate MasterSlave, tak je to jen a jen otazka toho, jak
dokazete dobre zdetekovat v CMS II, ze neco s CMS I je spatne. Musi bezet
obe, musi se tedy provadet prubezna analyza, ja bych to psat nechtel,
protoze se musi resit plno dosti protichudnych eventualit:).

Takze ja volim bod jedna se sadou pripominek danych tim, ze o
decentraliozvanem systemu uvazujim narozdil od osoby, ktera tu tabulku
vyrobila:))). Samozrejmosti je, a to uznavam, ze pro super jednoduchost, kdy
nechci resit subsite nebo jejich inteligentni spojky(brany), je idealem CMS
a Master-Slave at zu na RS485 nebo necem jinem, ale ja bych si to do domu
nedal. Pred peti lety bych se tomu asi nebranil, ale tenkrat byly ceny
procesoru taky nekde uplne jinde:))).

S pozdravem,
		Marek Pavlu

// -----Original Message-----
// From: hw-list-bounces@hw.cz [mailto:hw-list-bounces@hw.cz] On Behalf Of
// Mala Kobyla
// Sent: Friday, May 20, 2005 1:04 PM
// To: HW-news
// Subject: Re: Domaci automatizace - zhrnutie variant
// 
// Cetli jsem to nekolikrat. Zavedl jste nekolik pojmu a pomoci nich popsal
// nekolik variant. To se vracite na zacatek, to uz zde vsechno bylo. Nyni
// jsme
// ve fazi jestli variantu 1,2,3 nebo 4. Pokud vam ani jedna nevyhovuje
// popiste
// klidne 5. Pokud vam nevyhovuje 1-4 a nedokazete popsat variantu 5,
// neunavujte se vytvarenim definic ;) Neberte si to spatne, jen si myslim,
// ze
// cas se da stravit lepe.
// 
// Na stole je nekolik variant a hledaji se priznivci jednotlivych reseni.
// Pak
// muzeme zkusit najit spolecne body na HW nebo SW urovni.
// 
// MK2
// 
// 
// ----- Original Message -----
// From: "Marek Pavlu" <marekpavlu@mybox.cz>
// To: "'HW-news'" <hw-list@hw.cz>
// Sent: Thursday, May 19, 2005 7:04 PM
// Subject: RE: Domaci automatizace - zhrnutie variant
// 
// 
// Zdravim,
// 
// Uz opravdu nechapu, co tu porad resime!!!
// Tak zkusim par prikladu reseni, panove a damo:).
// Myslim, ze se nize zas tak moc neodchyluji od reality:))).
// 
// A prosim, netahejte me za usi, když budete mit poznamky k relativystickym
// pojetim tam, kde jsem nebyl presny. To jde vyresit rozumne a ne
// kamenovanim,
// sadou nepresnych analogii nebo v horsim pripade resenim nemsysly typu:
// -Jak zajistit 100% funkcnost(to neumi ani v Temelinu s Hermelinem:))).
// -Pozadovat za všech okolnosti při padu svetla(ustrihnou Vam pupecni snuru
// na
// Temelin nez reknete 100%-funkcnost:))))...
// -...
// 
// Dale je třeba si uvedomit, ze Vas dům neni chirurgicky sal, takze vypadek
// svetla Vas, mili odpurci, nazabije, chorofyl si vyrobite proste az
// rano:))).
// 
// Nize je ukazano, ze decentralizovany system rozsekany na subiste muze
// fungovat jako jakesi zakaldni stavebnice deleny trebas na jednotky v
// baraku==pokoje nebo kdo nechce moc subsiti, tak teba patra...
// 
// 
// 
// 
// 
// Definice[ChytraSpojka - CHS]:
// -Oddeluje pouze dve subsite
// -ma vlastni buffer
// -je aschopna najit chybu v paketu a zahazovat je(pokud se nejaky Modul
// zblaznil, treba:)
// - je asymetricka, ma dva UARTy, ale jeden je dovnitr vlastni, rizene,
// subsite a ten druhy do navazujicí subsite
// -- ve vlastni rizene siti je i zdrojem pridelovani tokenu(tohle zajisti,
// ze
// se co nejdrive dostane k prenosu a nebudou se hromadit dada v buffru moc
// dlouho)
// -- v cizi, pripojovane subsiti musi pockat na prideleni
// ciziho_tokenu,pokud
// ceka na prideleni ciziho_tokenu a ma v buffru paket k odeslani do cizi
// subsite, tak ve vlastni subsiti muze predat vlastni_token nekomu jinemu a
// vzit si ho zpet pro sebe(potrebuje-li)), az je ji pridelem v cizi subsiti
// cizi_token jinou spojkou. Takze odesle paket do cizi subsite...
// <uvaha>
// -CHS by slo upravit tak, aby bylo schopno vytvaret slozitejsi sitove
// struktury, ale obecne tak, aby se vzdy spojovaly vzdy jen dve subsite.
// Pak
// by nevlastnila zadnou cast subsite a oba dva UARTy by byly napojeny do
// dvojice subsiti, CHS by pak muselo resit cekani na prideleni tokenu a
// take
// by muselo monitorovat, jestli paket, ktery prijal neni do dane subsite
// jiz
// vysilan. Znamenalo by to i dynamicke vytvareni tabulky adres jaksi
// pasivne
// oproti zakladni CHS. Takto by slo resit struktury jako kruh, hvezda
// atd...
// <\uvaha>
// 
// 
// Definice[BlbaSpojka - BS]:
// -Oddeluje pouze dve subsite
// -je to v podstate jak kus dratu, jen oddeleni budici atd..
// -neni aschopna najit chybu v paketu a zahazovat je(pokud se nejaky Modul
// zblaznil, treba:).
// -prenese vse a tim padem potencialni zdroj zavaznych chyb od jedineho
// modulu
// se bude sirit celou siti, pak si uz pres ni nikdo nepokeca!!!
// 
// Definice[Modul - M]:
// -zarizeni, ktere plni nejaky druh funkce nad sitovou vrstvou
// -jedn modul = jedno pripojeni do site
// 
// Definice[Subsit - S]
// 
// Definice[FyzickaVrstva]:
//  - s RS485(zakaldni predpoklad)
//  -- asi nejlevneji/nejznamejsi
//  -- netreba homologovat
//  -- bezpecna napeti
//  -- overena
//  -- nejspis nas prezije :))).
// 
//  - EIB
//  -- zajimave vlastnosti jejich svabu
//  -- nestastne s ohledem na cenu
//  -- perspekticni??? Asi ano...
// 
//  - Ethernet
//  -- zatim spis pro firmy a nebo Donalda Trumpa ci skrcka Gatese :))).
//  -- problematycnost slozitych siti
// 
//  - PowerLine
//  -- potreba homologace
//  -- problem snadneho ruseni cimkoliv a kdykoliv
//  -- bezpecnost práce
// 
//  - Radio
//  -- homologace
//  -- ruseni
//  -- dlouhodobe nejiste vyuziti kmitoctu
// 
//  - Optika
//  -- vyssi liga, firmy, a ti, kteri nevim, kam s penezma:).
// 
// 
// 
// 1 decentralizovany system
//  - nutne multimaster...
//  - nejlepe asi nejaky system s tokenem
// (myslim, ze panuje jakasi minimalni nutna shoda na tokenu[M.P.]  )
// 1.1 dec. se subsitemi
//  - vhodne reseni(co pokoj, to subsit)
// 1.1.1 Spojeni - ChytrouSpojkou
//  - automaticke odstaveni blbnoucich subsiti
//  - funkce subsite budou zachovany ikdyz vypadne spojeni s navazujicimi
// subsitemi a tim treba i nadrizenym systemem pro rizeni uspor energie nebo
// pro rizeni spinani kotle
// -- kazdy ventyl se muze ridit jen z teplomeru v mistnosti a dle toho
// ridit
// otevreni ventylu.
// -- každý vypinac muze zapnout sve svetlo
// -- atd...
// 
// - Pokud vypadne primo subsit, tak ventyl nebude mit pristup k teplomeru,
// to,
// ze nemá spojeni se subsystemem spinani kotle pozna podle toho, ze se po
// nejake dobe neozval. Pokud se neozval, tak se pokusi komunikovat s cidlem
// teploty mistnosti. Pokud to do trebas deseti minut nupujde(za tu dobu
// nikdo
// jeste neumrzl), tak se nastavi na topeni v nouzovem rezimu, kdy otevre
// ventyl na nejakou vseobecne prijatelnou hodnotu
// -- stejne tak rizeni kotle vi, ze se nemuze na dany ventyl dostat, muze
// to
// hlasit, a vesele topit dal, doku ma nejake teplotni cidlo a ventyl k
// dispozici. Pri nejhorsim muze topit podle mistnosti(kotelna trebas) a
// jedno
// teplotni cidlo(zalozni) mit sam na sobe, takze porad bude podle podle
// ceho
// topit! Neumrznete:))).
// 
// No a když to kikxne vsechno, tak je to v prdeli stejne, jak kdyz Vam
// vypnou
// elektrinu nebo umre cely termostat, stejne musite roztopit uhlak nebo
// klasiku na drevo. V horsim pripade tak, jak to udelali studenti na
// Ukrajine(nebo kde to), rovnou uprostred v pokoji:)))))....
// 
// Svetla jsou z meho pohledu jaxi postradatelna.
// Na to, ze nebude svitit urcite nezemrete a sance, ze spadne cela sit je
// při
// dobrem navrhu a pouziti subsitiminimalizovana na jednotlive pokoje a tedy
// vypadky jednotlivych subsiti...
// 
//  - kratke delky kabelaze(nizsi ruseni na siti)
//  - male pocty zarizeni na siti, umozni rychlejsi komunikaci a tim i pro
// velke  pocty zarizeni kratke reakcni casy
//  - možno rychle komunikovat jen v ramci subsite
// 1.1.2 Spojeni - BlbouSpojkou
//  - nachylne na problemy pri zblbnuti jednoho modulu  nekde v zapadle
// casti
// site, pak je to v ha**lu!!!
// - kratke delky kabelaze(nizsi ruseni na siti)
//  - male pocty zarizeni na siti, umozni rychlejsi komunikaci a tim i pro
// velke  pocty zarizeni kratke reakcni casy1.2 dec. bez subsiti
// 
// 2 centralizovany system
// 2.1 Master/Slave
//  - spadne CMS, spadne cela sit!!!
//  - zalozni CMS muze prebrat praci site, ale musí nejak odpojit puvodni
// CMS
//  - zalozni CMS musi nejak vubec poznat, ze CMS je v loji
//  - zalozni CMS musi poslouchat a komunikovat s hlavnim CMS, aby nebyklo
// uplne tupe a vedelo, co dostat odkud a dat kam...
//  - nutna sprava dvou CMS soucasnem, odstranene chyby v CMS se mohou
// zapomenout opravit v nahradnim CMS!!!
//  - nepotrebuje ChytrouSpojku:).
//  - muze vyuzit BlbouSpojku, ale když spadne CMS, je to stejne putna, jen
// je
// sance na vetsi rychlosti a mensi problemy s kabelazi...
//  - nemoznost predat zpravu, dokud si o ni CMS nerekne
//  - muze vytvaret subsite, ale když vypadne neco na ceste, tak je stejne
// Amen!
// 
// 2.2 Multimaster
// 2.2.1 subsite
// - reseni, ktere obchazi pad CMS nebo useku site tim, ze Slave moduly jsou
// znacne univerzalni, delaji skoro vcechno(Svetlo, Spinac, Teplomer, Rizeni
// ventilu topne hlavnice,...) neobstoji v takovych ulohach, jako je rizeni
// teploty v celem dome a tim i rizeni kotle.
//  - roste dost znacne slozitost jednoho modulu a tim i jeho mozna
// poruchovost
// a taky cena pri jeho nahrade/vymene...
//  - v tomto rezimu se muze sit zbrchat a stat se decentralizovanou, ale
// pak
// je otazka, proc by to nemohle delat rovnou, když i v decentralizovanem
// systemu lze ridit věci jaksi z centra???:))). Znamnena to vytvaret dvoji
// rezim v SW, roste slozitost a sance na chyby, kdo dokonale otestuje
// akceschopnost v nouzovem rezimu???
// 2.2.1.1 Spojeni - ChytrouSpojkou
//  - vyhody jak o decentralizovaneho systemu, jen odpada tokenovani, tedy
// pokud nechceme prechazet z duvodu nouze do decentralizovaneho systemu
//  - kdo vyzkousi všechny oba rezimy daneho SW???
// 2.2.1.2 Spojeni - BlbouSpojkou
//  - vyhodou je jen nizsi ruseni a moznost dodat vetsi pocet zarizeni bez
// snizeni rychlosti
// 
// 
// 
// 
// 
// S pozdravem,
// Marek Pavlu
// 
// ---
// avast! Antivirus: Odchozi zprava cista.
// Virova databaze (VPS): 0520-3, 19/05/2005
// Testovano: 19.5.2005 18:46:01
// avast! (c) copyright 2000-2003 ALWIL Software.
// http://www.avast.com
// 
// 
// 
// 
// _______________________________________________
// HW-list mailing list  -  sponsored by www.HW.cz
// Hw-list@list.hw.cz
// http://list.hw.cz/mailman/listinfo/hw-list
// 
// _______________________________________________
// 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): 0520-3, 19/05/2005
Testovano: 20.5.2005 21:26:18
avast! (c) copyright 2000-2003 ALWIL Software.
http://www.avast.com