Jak stworzyć inteligentne urządzenia w Home Automation z odpowiednimi interfejsami?
Re: Protokol transmisji dla Home Automation
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Protokol transmisji dla Home Automation
Date: Thu, 02 Apr 1998 09:17:56 GMT
On Tue, 31 Mar 1998 23:57:40 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
wrote:
Poniewaz nasze urzadzenia domowego uzytku nie sa przystosowane do
zdalnego sterowania, nalezy kazde z nich (tzn. te ktorymi chcemy sterowac - niekoniecznie
akurat wszystkie :-))) wyposazyc w odp. interfejs umozliwiajacy to
zadanie.
Oczywiscie mozna to robic stopniowo.
Interesujace mogloby byc skonstruowanie odpowiednich: oprawki do
punktow swietlnych, wylacznikow swiatla, gniazdek na scianie itp.
z wbudowanym intefrejsem. Tak nawet bardziej skomlikowane urzadzenia
jak pralka, ekspres do kawy czy telewizor moglyby byc sterowane bez
ingerencji w ich budowe.
Nalezaloby tez skonstruowac odpowiednie czujniki (dymu, teperatury,
ruchu, dzwieku itp) z takim interfejsem.
Ogolnie mamy do czynienia z "punktami" wejsciowymi jak i wyjsciowymi
(ze wzgledu na sygnal), oraz analogowymi jak i cyfrowymi (takze ze
wzgledu na sygnal).
Po tym zabiegu kazde takie urzadzenie - czy bedzie to wylacznik swiatla,
gniazdko na scianie, telewizor, telefon, pralka, czujnik temperatury,
itp... - stanie sie czescia systemu - sieci domowej - i moze dzieki
Tak wlasnie, zdarzenia moga byc okreslone poprzez warunki czasowe,
ale takze poprzez inne zadrzenia oraz inteligencje zaszyta w programie
stertujacym.
Oczywiscie tutaj potrzebna jest ergonomiczna aplikacja, tak aby
uzytkownik mogl w latwy sposob sterowa i dokonywac zmian w algorytmie
sterowania nie bedac programista a moze nawet nie majacy zbyt wielkiej
wiedzy w tym zakresie.
Do wyboru mamy nastepujace nosniki : siec zasilajaca 220V (tzw. Power
Line - PL), fale radiowe (RF), podczerwien (IRED) i zwykly kabel. (np. skretka).
Zapomniales jeszcze o mozliwosc przenoszenia informacji poprzez
drgania np. scian czy rur. Chco moze to byc rozwiazanie zbyt kosztowne
i chyba niepotrzebne, ale warto pamietac o nim gdy inne zawioda.
Odpowiednie rozwiazania mozna stosowac juz na etapie budowania nowego
budynku, ale wykorzystanie takich nosnikow jak opisano wyzej, pozwala
na automatyzowanie domu, mieszkania juz zbudowanego bez solidnego
rozkuwania scian, remontu itp.
Dla kazdego rodzaju nosnika musimy wykonac stosowny interfejs-modem
umozliwiajacy przesylanie danych cyfrowych z komputera sterujacego do urzadzen
wykonawczych.
Z niektorych takze spowrotem (konieczne potwierdzenie) jak i odwrotnie
w przypadku czujnikow.
To zadanie dla elektronikow konstruktorow wlasnie - idea jest nastepujaca:
po stronie nadawczej wystawiamy 1 log (lub 0 w zaleznosci od konwencji),
po stronie obiorczej otrzymujemy ta 1 log.
Co z urzadzeniami analogowymi? Otwarcie jakiejs bramy, zaworu itp. na
wedlug ustalonej wielkosci? Wydaje mi sie ze takie urzadzenia tez
musza byc rozpatrywane.
Tak wiec elektornicy konstruktorzy dadza cialo, a progamisci
informatycy tchna w nie ducha ;-)))).
Tomek
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 00:05:10 +0100
Czesc!
Ok...to kontynuujmy...
Chcialem sprecyzowac troche (no bo wszystkiego na raz nie da sie rady)
zalozenia co do
systemu HA (przynajmniej tak jak ja to widze w tej chwili).
Po pierwsze: Kazdy "klocek" ma mozliwosc sterowania zdalnego jak i
lokalnego (klawiaturka) - na wypadek awarii systemu - zawsze mozemy
recznie wlaczyc/wylaczyc, etc...
Zreszta niekoniecznie przeciez musimy zawsze sterowac zdalnie, czasem
latwiej bedzie przechodzac cos wlaczyc lokalnie niz isc specjalnie do
komputera, odpalac program, szukac
urzadzenia i zmieniac jego stan - to byloby bez sensu.
Jednakze kazda zmiana stanu urzadzenia spowodowana przez nas lokalnie,
powinna byc
odnotowana w systemie (jesli np. przechodzac wlaczylismy swiatlo, to
poprzez siec informacja
o tym fakcie dostaje sie do komputera sterujacego i system ma "na
biezaco" aktualny stan).
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia,
a PC'tem - trzymanie tego ostatniego wlaczonego non stop 24h na dobe nie
jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki (tzw.
Master Controller), posiadalby pamiec wszystkich zdarzen (events), jakie
ustawilismy za pomoca PC'ta i sam sterowalby systemem przesylajac odp.
rozkazy do klockow o odpowiednich godzinach, czy przy wystapieniu odp.
zdarzen. Informacje o events ladowane bylyby z PC'ta, ktory w tym
wypadku
spelnialby role posrednika miedzy uzytkownikiem a systemem.
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Po trzecie: Dobrze byloby dla ulatwienia sterowania zrobic cos w rodzaju
inteligentnego pilota
o dwukierunkowej komunikacji (odbiera i nadaje), z wyswietlaczem
alfarnumerycznym LCD,
za pomoca ktorego moglibysmy w prosty sposob bezposrednio sterowac
systemem. Tutaj jest wlasnie miejsce na tzw. sceny - wcisniecie jednego
klawisza powoduje iles tam dzialan...
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et, z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Po czwarte: Komunikacja w sieci powinna byc dwukierunkowa tzn. ze
inicjatorem transmisji moze byc zarowno Master Controller, PC'et, jak i
dowolny z klockow (bo np. czujnik ruchu wykryl obiekt i informacja o tym
musi byc natychmiast przekazana).
Tu wlasnie jest miejsce na odpowiedni protokol transmisji - wykrywanie
kolizji (CSMA),
poprawnosc transmisji (CRC), etc. etc....
Po piate: Jasne jest, ze dla obslugi tego typu dzialan, kazdy z klockow
musi byc wyposazony w
odp. mikroprocesorek, ktory bedzie w stanie obsluzyc transmisje z jednej
strony, a z drugiej
moc sterowac funkcjami urzadzenia. Jak dla mnie bedzie to Atmel
89C2051 - w wersji SMD jest dosc maly, ogolnie dostepny, dobrze znany.
Rodzi sie pytanie: Czy damy rade pomiescic w jednym procesorku obie w/w
funkcje (transmisja i sterowanie). Czy potrzebny bedzie jeszcze jeden
procesorek "dedykowany" tylko do obslugi transmisji. (51'ka podoba mi
sie jeszcze z tego wzgledu, ze ma sprzetowy port szeregowy - czekajacy
tylko na wykorzystanie :-))) - samo "wprowadzanie i wyprowadzanie"
danych mielibysmy juz z glowy - pozostalaby tylko ich interpretacja.)
No i na razie tyle jesli chodzi o zalozenia. (na ten raz)
Aha...dla informacji podam, ze juz pewne elementy systemu mam opracowane
sprzetowej raczej niz programowej.
Po pierwsze jest juz modem sieciowy PL - transmisja danych cyfrowych
przez siec 220V idzie
z szybkoscia 1200 bodow. Nie jest to duzo w porownaniu z LonWorks, ale
chyba do sterowania wystarczy. W kazdym razie szybciej niz X-10 :-)))
Po drugie mam juz projekt sciemniacza swiatla - elementem sterujacym
jest oczywiscie mikroprocesor... Plynne wlaczanie/wylaczanie,
sciemnianie, etc. bajery dzialaja - niestety na razie lokalnie (tj. po
nacisnieciu klawiszy na klawiaturce), brak protokolu i calej reszty.
Klocki typu czujnik ruchu, temperatury, wylacznik zasilania 220V nie
beda zadnym problemem i tak najtrudniejsza czescia programu ich
procesorka bedzie obsluga transmisji.
Zastanawiam sie czy jeszcze pozostac na tej liscie, czy tez juz powoli
zaczac przechodzic na
multi-priva, ze sie tak wyraze - sa spore opoznienia miedzy serwerami
newsow (sam np. przekonalem sie ze nie widze wszystkich listow ciagnac z
news.icm.edu.pl, a np. na news.nask.org.pl juz ich bylo wiecej) - moze
dac jeszcze z tydzien na "ustabilizowanie sie sytuacji"? :-)))
Dobra....koncze na razie...
Jacek.
From: "Grzegorz Gajewski" <gajos_at_nospam_bobo.ds5.agh.edu.pl>
Subject: Re: Home Automation - opis c.d.
Date: Fri, 3 Apr 1998 16:20:07 +0200
[...]
Po pierwsze jest juz modem sieciowy PL - transmisja danych cyfrowych
przez siec 220V idzie
z szybkoscia 1200 bodow. Nie jest to duzo w porownaniu z LonWorks, ale
chyba do sterowania wystarczy. W kazdym razie szybciej niz X-10 :-)))
[...]
Jacek.
Bardzo mnie interesuje taki modem, jezeli masz schemat (w postaci
cyfrowej), to prosilbym o przeslanie na priv, jakkolwiek rowniez opis
slowny bylby bardzo przydatny.
No i podstawowe pytanie (obok transferu) - jaki zasieg transmisji?
Co to jest Lon Works? (niestety nie mam pojecia...)
-----------------------------------------------
GaYos
gajos_at_nospam_bobo.ds5.agh.edu.pl
-----------------------------------------------
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 17:49:47 GMT
On Fri, 3 Apr 1998 16:20:07 +0200, "Grzegorz Gajewski"
<gajos_at_nospam_bobo.ds5.agh.edu.pl> wrote:
Co to jest Lon Works? (niestety nie mam pojecia...)
Najkrocej mowiac jedna z magistrali a zarazem protokolow stosowanych w
automatyce. Znam zrodla ktore podaj, ze maja 34.4% rynku, ale nie wiem
czy to prawda. Duze upowszechnienie za sprawa TAC.
Tomek
From: marek.krzyszton_at_nospam_hsj.com.pl (Marek Krzyszton)
Subject: Re: Home Automation - opis c.d.
Date: Mon, 06 Apr 1998 10:36:14 GMT
=46ri, 03 Apr 1998 17:49:47 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisal(a):
On Fri, 3 Apr 1998 16:20:07 +0200, "Grzegorz Gajewski"
<gajos_at_nospam_bobo.ds5.agh.edu.pl> wrote:
Co to jest Lon Works? (niestety nie mam pojecia...)
Najkrocej mowiac jedna z magistrali a zarazem protokolow stosowanych w
automatyce. Znam zrodla ktore podaj, ze maja 34.4% rynku, ale nie wiem
czy to prawda. Duze upowszechnienie za sprawa TAC.
Czuje sie w obowiazku troche sprostowac wypowiedz kolegi.
LonWorks to nie jest ani magistrala ani protokol, to jest TECHNOLOGIA,
opracowana przez firme Echelon.
Zawiera wszystkie elementy potrzebne do zaprojektowania, stworzenia,
uruchomienia i obs=B3ugi systemu sterowania rozproszonego. Na ta
technologie skladaja sie takie elementy jak:
- Uk=B3ady NeuronChip z oprogramowaniem, obslugujace protokol LonTalk
- Transceiver'y, umozliwiajace polaczenie ukladow NeuronChip z
dowolnym medium transmisyjnym
- zintegrowane moduly zawierajace to wszystko co powyzej w jednym
- routery do komunikacji pomiedzy urzadzeniami znajdujacymi na roznych
sieciach (np. roznych mediach transmisyjnych)
- interfejsy, do przylaczania innych systemow mikroprocesorowych=20
- narzedzia do instalacji, konfiguracji, diagnostyki, obslugi,
sterowania i monitorowania sieci
- narzedzia wspomagajace projektowanie sieci (emulatory, symulatory,
debuggery, dokumentacja, itp).
Uklady NeuronChip, bedace sercem tego systemu, charakteryzuja sie:
wersja 1 wersja 2
mikroprocesory 8-bit. 3 3
EEPROM 512b-2048b 512b
RAM 1024b 2048b
PROM 10k 0
zewnetrzna pamiec nie tak
16-bitowe liczniki/timery 2 2
pinow ukladu 32 64
montaz powierzchniowy
zasilanie 5V=20
pobor pradu
uspienie 2mA =09
max 200mA
praca (bez obciazenia) 15mA
wymiary 11x23mm 14x14mm
11 programowalnych pinow we/wy (34 w 5 grupach zaimplementowane tryby
operacji, np. we/wy binarne, matryca 4x4, port rownolegly-
dwukierunkowy, rejestr przesuwny, szyna I2C, we/wy szeregowe we/wy
ukladu sterowania IR, generator-modulator impulsu (ow), dekoder Graya,
dzielnik czestotliwosci, sterowanie triakiem, zliczanie impulsow, itp,
itd)
obciazenie - 20mA
mikroprocesory - kazdy odpowiedzialny za inna dzialke:
1 - aplikacja (sterowanie), programowanie przez uzytkownika
2 - komunikacja-adresowanie, transakcje, pakiety, diagnostyka,
liczniki programowe
3 - komunikacja-fizycznie, dopasowanie sygnalow, obsluga
sieci - protokol sprzetowo i programowo
wszystkie komunikuja sie ze soba po wewnetrznej szynie
zegar - 0.625MHz do 10 MHz
Programowanie - Neuron C (taki przystosowany C) -> kompilator ->pamiec
chipa
Port komunikacji - 4 piny, 610 bitow/s do 1.25 Mbitow/s, wybierane
programowo
Wbudowane oprogramowanie -
protokol LonTalk, zgodny z 7-poziomowym modelem OSI
sterowanie I/O
obsluga zdarzen
kazdy chip ma unikalny, 48-bitowy numer identyfikacyjny
Protokol - LonTalk - umozliwia komunikacje poprzez dowolne medium
transmisyjne (jest niezalezny od medium), laczenie poprzez routery na
inne sieci, budowanie grup, podsieci, max. liczba wezlow w 1 sieci -
32385, zmienne sieciowe, wysylanie/odbieranie danych (z potwierdzeniem
lub bez, wielokrotne, na rzadanie)
media - siec energetyczna - 1200bitow/s (w USA 2400),
modulacja czestotliwosci, niestety pierwsze trafo
odcina, ale przechodzi miedzy fazami, sam testowalem=20
skretka I - 78kbitow/s
skretka II - 1.25Mbitow/s
swiatlowod - 1.25Mbitow/s
radio - 4.5kbitow/s
... i to wszystko a nawet jeszcze wiecej mozna zrobic z jednym chipem.
Producent - Motorola i Toshiba (wylacznie)
Opracowanie technologii - Echelon
Cena - o ile cena samych chipow jest niska (w zaleznosci od ilosci
zamowionej od 10$ do 3$ za sztuke), o tyle cena wszelkich narzedzi do
projektowania, debugowania, emulowania jest horendalnie wysoka
(dziesiatki tysiecy $).
Uff, moglbym tak pisac i pisac, ale mysle ze to wystarczy aby uchylic
troche rabka informacji o tej technologii. Mialem z nia do czynienia
przez ponad rok czasu i mysle ze poznalem ja raczej dobrze.=20
Jak to w sterowaniu rozproszonym, nie musi istniec jakas centralna
jednostka sterujaca, aczkolwiek mozna wykorzystac PC do monitorowania,
sterowania czy tez zbierania danych (potrzebna jest karta-interfejs do
sieci, ok. 100$).
=09
info: www.echelon.com
Marek Krzyszton
marekk_at_nospam_polbox.com
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 22:35:25 +0100
Grzegorz Gajewski wrote:
[...]
Po pierwsze jest juz modem sieciowy PL - transmisja danych cyfrowych
przez siec 220V idzie
z szybkoscia 1200 bodow. Nie jest to duzo w porownaniu z LonWorks,
ale
chyba do sterowania wystarczy. W kazdym razie szybciej niz X-10 :-)))
[...]
Jacek.
Bardzo mnie interesuje taki modem, jezeli masz schemat (w postaci
cyfrowej), to prosilbym o przeslanie na priv, jakkolwiek rowniez opis
slowny bylby bardzo przydatny.
No i podstawowe pytanie (obok transferu) - jaki zasieg transmisji?
Co to jest Lon Works? (niestety nie mam pojecia...)
-----------------------------------------------
GaYos
gajos_at_nospam_bobo.ds5.agh.edu.pl
-----------------------------------------------
Co do modemu, to nie ma tajemnicy...Jest to scalak TDA5051A f-my
Philips, wraz z podstawowym ukladem aplikacyjnym. Opis mozna latwo
sciagnac w postaci PDF'a z site'a Philipsa. Najprosciej zapuscic na
Hotbocie - "Home Automation Modem" i przekonacie sie co Wam znajdzie.
-))) Scalaczek jest w wersji SMD only i kosztowal mnie po 50zl sztuka
czyli dosc drogo...niestety...
Jacek.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 16:06:11 GMT
Fri, 03 Apr 1998 00:05:10 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
napisał(a):
Po pierwsze: Kazdy "klocek" ma mozliwosc sterowania zdalnego jak i
lokalnego (klawiaturka) - na wypadek awarii systemu - zawsze mozemy
recznie wlaczyc/wylaczyc, etc...
Zreszta niekoniecznie przeciez musimy zawsze sterowac zdalnie, czasem
latwiej bedzie przechodzac cos wlaczyc lokalnie niz isc specjalnie do
komputera, odpalac program, szukac
urzadzenia i zmieniac jego stan - to byloby bez sensu.
Jednakze kazda zmiana stanu urzadzenia spowodowana przez nas lokalnie,
powinna byc
odnotowana w systemie (jesli np. przechodzac wlaczylismy swiatlo, to
poprzez siec informacja
o tym fakcie dostaje sie do komputera sterujacego i system ma "na
biezaco" aktualny stan).
Nie tak. System ma być niezależny i rozproszony. Nie może być tak, że
od jednego sterownika zależy działanie całości. Nic nam to nie daje,
że mamy w jednym miejscu wszystko skoro możemy w każdej chwili się o
to zapytać. Oczywiście znajdą się i usługi wymagające takiego serwera,
ale one same będą tak oprogramowane by taką rolę pełniły.
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia,
a PC'tem - trzymanie tego ostatniego wlaczonego non stop 24h na dobe nie
jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki (tzw.
Master Controller), posiadalby pamiec wszystkich zdarzen (events), jakie
ustawilismy za pomoca PC'ta i sam sterowalby systemem przesylajac odp.
rozkazy do klockow o odpowiednich godzinach, czy przy wystapieniu odp.
zdarzen. Informacje o events ladowane bylyby z PC'ta, ktory w tym
wypadku
spelnialby role posrednika miedzy uzytkownikiem a systemem.
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Powstanie serwera w systemie musi być uzasadnione. Nie ma potrzeby
wyróżniania jakiegoś sterownika dla kaprysu. Nic to nam nie da.
Po trzecie: Dobrze byloby dla ulatwienia sterowania zrobic cos w rodzaju
inteligentnego pilota
o dwukierunkowej komunikacji (odbiera i nadaje), z wyswietlaczem
alfarnumerycznym LCD,
za pomoca ktorego moglibysmy w prosty sposob bezposrednio sterowac
systemem. Tutaj jest wlasnie miejsce na tzw. sceny - wcisniecie jednego
klawisza powoduje iles tam dzialan...
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et, z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Szczegół techniczny.
Po czwarte: Komunikacja w sieci powinna byc dwukierunkowa tzn. ze
inicjatorem transmisji moze byc zarowno Master Controller, PC'et, jak i
dowolny z klockow (bo np. czujnik ruchu wykryl obiekt i informacja o tym
musi byc natychmiast przekazana).
Tu wlasnie jest miejsce na odpowiedni protokol transmisji - wykrywanie
kolizji (CSMA),
poprawnosc transmisji (CRC), etc. etc....
W ogóle nie powinno być rozróżnienia na serwer, klient i pc. To
wszystko ma być równoprawne z założenia. Jeśli np. mamy czujnik
przejścia przez framugę to rozgłasza on wszystkim takie zdarzenie. Nie
nawiązuje jednak dialogu ze sterownikami oświetlenia w sąsiednich
pomieszczeniach. Tylko one wiedzą czy mają być podatne na taką
informację. Z kolei budziki powinny raczej zapytać o ilość osób w
danym pomieszczeniu by nie dryndać bez sensu. A najciekawiej byłoby
zrealizować rozpoznawanie osób, ale to kiedyś...
Po piate: Jasne jest, ze dla obslugi tego typu dzialan, kazdy z klockow
musi byc wyposazony w
odp. mikroprocesorek, ktory bedzie w stanie obsluzyc transmisje z jednej
strony, a z drugiej
moc sterowac funkcjami urzadzenia. Jak dla mnie bedzie to Atmel
89C2051 - w wersji SMD jest dosc maly, ogolnie dostepny, dobrze znany.
Rodzi sie pytanie: Czy damy rade pomiescic w jednym procesorku obie w/w
funkcje (transmisja i sterowanie). Czy potrzebny bedzie jeszcze jeden
procesorek "dedykowany" tylko do obslugi transmisji. (51'ka podoba mi
sie jeszcze z tego wzgledu, ze ma sprzetowy port szeregowy - czekajacy
tylko na wykorzystanie :-))) - samo "wprowadzanie i wyprowadzanie"
danych mielibysmy juz z glowy - pozostalaby tylko ich interpretacja.)
Nie bardzo. Port szeregowy nie nadaje się do nadawania CSMA-CD po
magistrali jednoprzewodowej.
No i na razie tyle jesli chodzi o zalozenia. (na ten raz)
Aha...dla informacji podam, ze juz pewne elementy systemu mam opracowane
- od strony
sprzetowej raczej niz programowej.
Po pierwsze jest juz modem sieciowy PL - transmisja danych cyfrowych
przez siec 220V idzie
z szybkoscia 1200 bodow. Nie jest to duzo w porownaniu z LonWorks, ale
chyba do sterowania wystarczy. W kazdym razie szybciej niz X-10 :-)))
Po drugie mam juz projekt sciemniacza swiatla - elementem sterujacym
jest oczywiscie mikroprocesor... Plynne wlaczanie/wylaczanie,
sciemnianie, etc. bajery dzialaja - niestety na razie lokalnie (tj. po
nacisnieciu klawiszy na klawiaturce), brak protokolu i calej reszty.
Klocki typu czujnik ruchu, temperatury, wylacznik zasilania 220V nie
beda zadnym problemem i tak najtrudniejsza czescia programu ich
procesorka bedzie obsluga transmisji.
Właśnie w wykonaniu może być największy problem. To wszystko musi
przyzwoicie wyglądać, kosztować umiarkowanie i jeszcze być bezpieczne.
Nie można też zakładać, że każde urządzenie będzie sterowane osobno.
To zbyt drogie. Muszą powstać sensowne sterowniki uniwersalne
realizujące najbardziej popularne cele np. dla przeciętnego
pomieszczenia.
Zastanawiam sie czy jeszcze pozostac na tej liscie, czy tez juz powoli
zaczac przechodzic na
multi-priva, ze sie tak wyraze - sa spore opoznienia miedzy serwerami
newsow (sam np. przekonalem sie ze nie widze wszystkich listow ciagnac z
news.icm.edu.pl, a np. na news.nask.org.pl juz ich bylo wiecej) - moze
dac jeszcze z tydzien na "ustabilizowanie sie sytuacji"? :-)))
To nie jest lista tylko grupa i nie ma lepszego forum od niusów.
ps. W ciągu dwóch miesięcy muszę zbudować kartę do PC do sterowania
takim systemem. Jest zaprojektowana i prawie zbudowana w wersji
prototypowej. Brak tylko dobrego nadajnika linii...
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 22:37:42 +0100
Bonik Kujany wrote:
Nie tak. System ma być niezależny i rozproszony. Nie może być tak, że
od jednego sterownika zależy działanie całości. Nic nam to nie daje,
że mamy w jednym miejscu wszystko skoro możemy w każdej chwili się o
to zapytać.
Tego ostatniego zdania nie za bardzo rozumiem - kogo mozemy sie zapytac?
- czegos nie dopowiedziales...
Oczywiście znajdą się i usługi wymagające takiego serwera,
ale one same będą tak oprogramowane by taką rolę pełniły.
Co do rozproszonej inteligencji - tez sie nad takim wariantem
zastanawialismy (i tu dyskusja sie zazwyczaj zaostrzala :-)))) - bo i
to, i to ma kilka zalet i wad...Wada takiego zalozenia (rozproszenie)
jest to, ze jesli okreslone klocki zostana na stale przyporzadkowane do
innych (np. ze przy odp. temperaturze wlacza sie piecyk grzewczy - bez
udzialu PC'ta), to jest to "usztywnienie" systemu - a co bedzie jesli
zechcesz zmienic takie przyporzadkowanie na inne? Musisz
przeprogramowywac klocek - zeby zaczal reagowac na inny czujnik - zatem
kazdy z nich musi byc wyposazony w mozliwosc zdalnego
przeprogramowywania, musi pamietac adresy klockow i rozkazy na ktore ma
reagowac, etc...
To pozera pamiec i czas procesorka sterujacego klockiem.
Poza tym, aby znac aktualny stan systemu PC'et musi wysylac zapytania do
klockow typu: podaj swoj stan - i to niezaleznie od tego czy jest to w
danej chwili potrzebne czy nie (czy nastapila zmiana stanu urzadzenia),
ew. musi caly czas nasluchiwac transmisje jakie sa prowadzone w sieci...
Bo inaczej na ekranie PC'ta nie bedzie widac co sie aktualnie dzieje.
No chyba, ze wogole rezygnujemy z PC'ta i programu obslugi, a klocki
sobie dzialaja zupelnie niezaleznie - kazdy na "swoj typ" ...
Zaleta: to co powiedziales wyzej - autonomia.
W zasadzie to tak naprawde jesli chodzi o dzialanie to oba warianty zbyt
duzo sie nie roznia.
Wezmy np. czujnik ruchu - jesli wykryje ruch, puszcza w siec informacje
o tym - i teraz albo do komputera centralnego, ktory "wie" co z ta
informacja robic, albo odbieraja to pewne klocki, nastawione na odbior
danych z czujnika. (gorzej jednak teraz z potwierdzeniem poprawnosci
transmisji - przy wielu klockach odbierajacych jednoczesnie -
niemozliwe. chyba ze zalozymy brak potwierdzenia - urzadzenie wysylajace
"rozglasza" swoj stan do wszystkich)
Mozna tez "pomieszac" obie koncepcje i czesc klockow bedzie reagowac
bezposrednio na inne klocki, a czesc oczekiwac rozkazow z PC'ta...
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia,
a PC'tem - trzymanie tego ostatniego wlaczonego non stop 24h na dobe
nie
jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki
(tzw.
Master Controller), posiadalby pamiec wszystkich zdarzen (events),
jakie
ustawilismy za pomoca PC'ta i sam sterowalby systemem przesylajac
odp.
rozkazy do klockow o odpowiednich godzinach, czy przy wystapieniu
odp.
zdarzen. Informacje o events ladowane bylyby z PC'ta, ktory w tym
wypadku
spelnialby role posrednika miedzy uzytkownikiem a systemem.
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy
obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Powstanie serwera w systemie musi być uzasadnione. Nie ma potrzeby
wyróżniania jakiegoś sterownika dla kaprysu. Nic to nam nie da.
Wedlug mnie jest to uzasadnione. (patrz wyzej)
Nie bardzo. Port szeregowy nie nadaje się do nadawania CSMA-CD po
magistrali jednoprzewodowej.
Ja nie bylbym calkiem taki pewien...:-))) Owszem czas reakcji bedzie
nieco dluzszy - zamiast pojedynczego bitu - bajt, ale czy to jest az
takie wazne - tu nie chodzi o przesylanie MB danych.Caly czas pamietac
trzeba o tym, ze nasz procesorek musi jeszcze obsluzyc aplikacje - Jesli
np. zrobisz uklad z multipleksowanym wyswietlaczem LED, z przerwaniem
400Hz, to juz czas procesorka zostaje niezle "poszatkowany" - czy da
rade wowczas jeszcze kontrolowac transmisje na poziomie pojedynczych
bitow?
Właśnie w wykonaniu może być największy problem. To wszystko musi
przyzwoicie wyglądać, kosztować umiarkowanie i jeszcze być bezpieczne.
Mialem na mysli raczej rozwiazanie techniczne, a nie gotowy produkt.
Najpierw trzeba stwierdzic czy jest wogole mozliwe wykonanie czegos, a
potem mozemy myslec o jego wygladzie, etc...
Nie można też zakładać, że każde urządzenie będzie sterowane osobno.
To zbyt drogie.
Moim zdaniem tansze :-)))) Wbudowanie elektroniki do urzadzenia ,
powoduje wlasnie, ze nie musimy sie martwic o obudowe, estetyke, etc...a
elektronika i tak bedzie prawie ta sama...
ale rozumiem, ze miales na mysli, zeby wogole nie wbudowywac, a tylko
zrobic kilka uniwersalnych sterownikow...
Ja bym jednak byl za wbudowywaniem. :-))) - wtedy mozesz sterowac
"pelnia funkcji"
Muszą powstać sensowne sterowniki uniwersalne
realizujące najbardziej popularne cele np. dla przeciętnego
pomieszczenia.
Owszem...tez sie przydadza...
ps. W ciągu dwóch miesięcy muszę zbudować kartę do PC do sterowania
takim systemem. Jest zaprojektowana i prawie zbudowana w wersji
prototypowej. Brak tylko dobrego nadajnika linii...
A do czego Ci tak pilno? Praca dyplomowa? ;-))
Jacek.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 11:28:54 GMT
Fri, 03 Apr 1998 22:37:42 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
napisał(a):
Co do rozproszonej inteligencji - tez sie nad takim wariantem
zastanawialismy (i tu dyskusja sie zazwyczaj zaostrzala :-)))) - bo i
to, i to ma kilka zalet i wad...Wada takiego zalozenia (rozproszenie)
jest to, ze jesli okreslone klocki zostana na stale przyporzadkowane do
innych (np. ze przy odp. temperaturze wlacza sie piecyk grzewczy - bez
udzialu PC'ta), to jest to "usztywnienie" systemu - a co bedzie jesli
zechcesz zmienic takie przyporzadkowanie na inne?
to zmienię :-)
Musisz
przeprogramowywac klocek - zeby zaczal reagowac na inny czujnik - zatem
kazdy z nich musi byc wyposazony w mozliwosc zdalnego
przeprogramowywania, musi pamietac adresy klockow i rozkazy na ktore ma
reagowac, etc...
To pozera pamiec i czas procesorka sterujacego klockiem.
To tylko proste programy zdarzeniowe. Nic krytycznego czasowo. Jest
oczywiste, że i tak jakiemuś programowaniu z sieci podlegać będą
musiały. No bo jak wyobrazić sobie system sterujący oświetleniem na
podstawie sygnałów z fotokomórek. Każde przejście oddziałuje
przynajmnie na dwa punkty oświetleniowe. To co, mam na chamca wpisać
do ROMu, że reaguje na te a nie inne. Bez sensu.
Poza tym, aby znac aktualny stan systemu PC'et musi wysylac zapytania do
klockow typu: podaj swoj stan - i to niezaleznie od tego czy jest to w
danej chwili potrzebne czy nie (czy nastapila zmiana stanu urzadzenia),
ew. musi caly czas nasluchiwac transmisje jakie sa prowadzone w sieci...
Też większość z urządzeń będzie jednak wysyłała powiadomienia, ale
oprócz tego musi być możliwość odpytania. Jeśli załączysz serwer to on
nie wie jaki jest stan domu i tylko odpytywanie pozwala mu to odkryć.
Bo inaczej na ekranie PC'ta nie bedzie widac co sie aktualnie dzieje.
No chyba, ze wogole rezygnujemy z PC'ta i programu obslugi, a klocki
sobie dzialaja zupelnie niezaleznie - kazdy na "swoj typ" ...
Zaleta: to co powiedziales wyzej - autonomia.
Dokładnie o to chodzi. PC ma być tylko pomocą. Nikt nie zagwarantuje,
że umożliwi sterowanie nawet jeśli będzie załączony przez całą dobę.
Wszak służy do różnych innych, bardziej odpowiednich rzeczy.
W zasadzie to tak naprawde jesli chodzi o dzialanie to oba warianty zbyt
duzo sie nie roznia.
Wezmy np. czujnik ruchu - jesli wykryje ruch, puszcza w siec informacje
o tym - i teraz albo do komputera centralnego, ktory "wie" co z ta
informacja robic, albo odbieraja to pewne klocki, nastawione na odbior
danych z czujnika. (gorzej jednak teraz z potwierdzeniem poprawnosci
transmisji - przy wielu klockach odbierajacych jednoczesnie -
niemozliwe. chyba ze zalozymy brak potwierdzenia - urzadzenie wysylajace
"rozglasza" swoj stan do wszystkich)
Ależ to kropka w kropkę to samo :-) pomijając, że komputer centralny
może uczynić więcej szkody jak padnie niż jest z niego pożytku.
Mozna tez "pomieszac" obie koncepcje i czesc klockow bedzie reagowac
bezposrednio na inne klocki, a czesc oczekiwac rozkazow z PC'ta...
Każdy ma reagować na sygnały z PC, tyle, że nie po to by w ogóle
działał. Sterowniki sieci mają być równoprawne.
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia,
a PC'tem - trzymanie tego ostatniego wlaczonego non stop 24h na dobe
nie
jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki
(tzw.
Master Controller), posiadalby pamiec wszystkich zdarzen (events),
jakie
ustawilismy za pomoca PC'ta i sam sterowalby systemem przesylajac
odp.
rozkazy do klockow o odpowiednich godzinach, czy przy wystapieniu
odp.
zdarzen. Informacje o events ladowane bylyby z PC'ta, ktory w tym
wypadku
spelnialby role posrednika miedzy uzytkownikiem a systemem.
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy
obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Powstanie serwera w systemie musi być uzasadnione. Nie ma potrzeby
wyróżniania jakiegoś sterownika dla kaprysu. Nic to nam nie da.
Wedlug mnie jest to uzasadnione. (patrz wyzej)
Jednego do wszystkiego ? W żadnym wypadku!
Nie bardzo. Port szeregowy nie nadaje się do nadawania CSMA-CD po
magistrali jednoprzewodowej.
Ja nie bylbym calkiem taki pewien...:-))) Owszem czas reakcji bedzie
nieco dluzszy - zamiast pojedynczego bitu - bajt, ale czy to jest az
takie wazne - tu nie chodzi o przesylanie MB danych.
Właściwie to o to chodzi, ale na pewno nie dzisiaj. Konkretnie
wpuszczenie w sieć wszystkich sygnałów audiowizualnych tj. telefonu,
domofonu, tv, radio. Tyle, że można to puścić równolegle klasyczną
100Mb
Caly czas pamietac
trzeba o tym, ze nasz procesorek musi jeszcze obsluzyc aplikacje - Jesli
np. zrobisz uklad z multipleksowanym wyswietlaczem LED, z przerwaniem
400Hz, to juz czas procesorka zostaje niezle "poszatkowany" - czy da
rade wowczas jeszcze kontrolowac transmisje na poziomie pojedynczych
bitow?
No to już zależy jak rozsądnie zostanie oprogramowany i jak duże
postawimy wymagania.
Właśnie w wykonaniu może być największy problem. To wszystko musi
przyzwoicie wyglądać, kosztować umiarkowanie i jeszcze być bezpieczne.
Mialem na mysli raczej rozwiazanie techniczne, a nie gotowy produkt.
Najpierw trzeba stwierdzic czy jest wogole mozliwe wykonanie czegos, a
potem mozemy myslec o jego wygladzie, etc...
E no, nie przesadzajmy. Wszystko co można sobie wyobrazić jest do
zrealizowania.
Nie można też zakładać, że każde urządzenie będzie sterowane osobno.
To zbyt drogie.
Moim zdaniem tansze :-)))) Wbudowanie elektroniki do urzadzenia ,
powoduje wlasnie, ze nie musimy sie martwic o obudowe, estetyke, etc...a
elektronika i tak bedzie prawie ta sama...
No tak, ale my mamy podłączyć urządzenia, które niekoniecznie są do
tego przeznaczone i trzeba dorobić interfejs. Dopiero oprócz nich
podłączyć zupełnie nowe.
Jeśli każde z nich będzie kosztowało dodatkowo 150 zł to sprawa robi
się nieciekawa.
ale rozumiem, ze miales na mysli, zeby wogole nie wbudowywac, a tylko
zrobic kilka uniwersalnych sterownikow...
tak
Ja bym jednak byl za wbudowywaniem. :-))) - wtedy mozesz sterowac
"pelnia funkcji"
Zawsze możesz. Tylko musisz zrobić trochę inteligentniejszy sterownik
uniwersalny.
Muszą powstać sensowne sterowniki uniwersalne
realizujące najbardziej popularne cele np. dla przeciętnego
pomieszczenia.
Owszem...tez sie przydadza...
są niezbędne !
ps. W ciągu dwóch miesięcy muszę zbudować kartę do PC do sterowania
takim systemem. Jest zaprojektowana i prawie zbudowana w wersji
prototypowej. Brak tylko dobrego nadajnika linii...
A do czego Ci tak pilno? Praca dyplomowa? ;-))
Mhm
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:12 GMT
On Sat, 04 Apr 1998 11:28:54 GMT, hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
wrote:
to zmienię :-)
Ty tak, my tak itp., ale przecietny uzytkownik?
Pamietajmy tez o latwosci obslugi.
Też większość z urządzeń będzie jednak wysyłała powiadomienia, ale
oprócz tego musi być możliwość odpytania. Jeśli załączysz serwer to on
nie wie jaki jest stan domu i tylko odpytywanie pozwala mu to odkryć.
Zgadza sie. Odpytywanie przydac sie tez moze i do innych celow.
Np. do sprawdzenia urzadzen krytycznych np. kuchenek itp. gdzie wazne
jest bezpieczenstwo. Tutaj moze byc tak, ze na skutek awarii nie ma
sygnalu od urzadzenia a PC nic nie wie, po prostu nie ma sygnalu.
A tak jak sam zapyta i nie otrzyma odpowiedzi to bedzie wiedzial.
Dokładnie o to chodzi. PC ma być tylko pomocą. Nikt nie zagwarantuje,
że umożliwi sterowanie nawet jeśli będzie załączony przez całą dobę.
Wszak służy do różnych innych, bardziej odpowiednich rzeczy.
PC ma byc pomoca, choc mysle ze sobie z tym poradzi. Nie musi to byc
zreszta cud techniki, wiec przy duzej ilosci urzadzen moze byc
dedykowany dla tego celu co oczywiscie podraza rzecz wiec musi byc to
uzasadnione.
Ależ to kropka w kropkę to samo :-) pomijając, że komputer centralny
może uczynić więcej szkody jak padnie niż jest z niego pożytku.
Watchdog ;-)))
Każdy ma reagować na sygnały z PC, tyle, że nie po to by w ogóle
działał. Sterowniki sieci mają być równoprawne.
Nie odmawiam sterownikom inteligencji, ale najpierw proponuje
niemowlaki (ograniczona inteligencja), potem starsze, jeszcze strasze
dzieci itd.
Wedlug mnie jest to uzasadnione. (patrz wyzej)
Jednego do wszystkiego ? W żadnym wypadku!
E no, nie przesadzajmy. Wszystko co można sobie wyobrazić jest do
zrealizowania.
Brawo, tak trzymac i realizowac marzenia.
No tak, ale my mamy podłączyć urządzenia, które niekoniecznie są do
tego przeznaczone i trzeba dorobić interfejs. Dopiero oprócz nich
podłączyć zupełnie nowe.
Zgadzam sie i popieram idee uniwersalnyc sterownikow.
Muszą powstać sensowne sterowniki uniwersalne
realizujące najbardziej popularne cele np. dla przeciętnego
pomieszczenia.
Owszem...tez sie przydadza...
są niezbędne !
Oczywiscie.
Moze mieszajac koncepcej, proste uniweralne klocki bez inteligencji i
1 klocek dodatkowy na pomieszczenie lub dwa ale tylko jako "mozg".
A i PC moglby korzystac z takiego punktu koncentracji.
Takie rozwiazanie byloby przez mnie do przyjecia juz na poczatku o ile
nie ma koniecznosci stosowania takiego "mozgu".
Widze to tak:
1) instaluje sie wszedzie klocki bez inteligencji i pracuja pod
kontrola stale pracujacego PC
2) jak teraz ma wiecej kasy i chce takiego rozwiazania to dodajemy
odpowiednia ilosc punktow koncentracji dajac inteligencje i zwalniajac
PC.
Tomek
Tomek
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sun, 05 Apr 1998 17:35:32 GMT
Sat, 04 Apr 1998 21:04:12 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisał(a):
to zmienię :-)
Ty tak, my tak itp., ale przecietny uzytkownik?
Pamietajmy tez o latwosci obslugi.
No i co z tą łatwością ? Czemu miałbym to robić przy użyciu komputera
centralnego a nie np. dochodzącego PC?
Ależ to kropka w kropkę to samo :-) pomijając, że komputer centralny
może uczynić więcej szkody jak padnie niż jest z niego pożytku.
Watchdog ;-)))
Przecież jak padnie to wd nic tu nie pomoże. System po prostu
przestanie działać i już.
Każdy ma reagować na sygnały z PC, tyle, że nie po to by w ogóle
działał. Sterowniki sieci mają być równoprawne.
Nie odmawiam sterownikom inteligencji, ale najpierw proponuje
niemowlaki (ograniczona inteligencja), potem starsze, jeszcze strasze
dzieci itd.
Cena
10-ciu głupich sterowników 10x100=1000
1-go mądrego 1x300=300
Takie rozwiazanie byloby przez mnie do przyjecia juz na poczatku o ile
nie ma koniecznosci stosowania takiego "mozgu".
Widze to tak:
1) instaluje sie wszedzie klocki bez inteligencji i pracuja pod
kontrola stale pracujacego PC
2) jak teraz ma wiecej kasy i chce takiego rozwiazania to dodajemy
odpowiednia ilosc punktow koncentracji dajac inteligencje i zwalniajac
PC.
Zupełnie mnie nie zrozumiałeś. Nie można dać osobnego sterownika do
każdego urządzenia bo to ZA DROGIE. Chyba, że te sterowniki robią
on/off i nic więcej. No ale do tego wystarczy odpowiednio duża liczba
kabelków.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:09 GMT
On Fri, 03 Apr 1998 22:37:42 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
wrote:
Co do rozproszonej inteligencji - tez sie nad takim wariantem
zastanawialismy (i tu dyskusja sie zazwyczaj zaostrzala :-)))) - bo i
to, i to ma kilka zalet i wad...Wada takiego zalozenia (rozproszenie)
Wada jest tez miedzy innymi podniesienie kosztow klockow.
jest to, ze jesli okreslone klocki zostana na stale przyporzadkowane do
innych (np. ze przy odp. temperaturze wlacza sie piecyk grzewczy - bez
udzialu PC'ta), to jest to "usztywnienie" systemu - a co bedzie jesli
Proponuje przygotowac przede wszystkim oprocz specjalizowanych
klockow, klocki uniwersalne ktore moglyby byc wykorzystane jako
dodatki do unnych urzadzen przez jakies proset uklady aplikacyjne i
wykonawcze.
I tak jako klocki uniwersalne to np. klocki (terminologia moja):
D/0 - wyjscie on/off
0/D - wejscie on/off
A/0 - wyjscie analogowe
0/A - wejscie analogowe
oraz wszelkie modyfikacje jak np.
D2/D3 - 2 wyjscia on/off i 3 wejscia on/off
A2-D3/A4 - 2 wyjscia analogowe i 3 wyjscia on/off
oraz 4 wejscia analogowe
Takie rozwiazanie ustandaryzowalo by komunikacje od strony calej
sieci, klocki rozmawialy by juz po naszemu, a pozwolilo na
upowszechnienie calej idei, bo inni mogliby idee rozwijac.
Chodzi o to ze co podlaczymy do wejsc (czujnik dymu, czujnik ruchu,
sygnalizacja zalaczenia czegos itp.) oraz do wyjsc (silnik krokowy,
pralke, brame lub drziw garazowe itp.) nie ogranicza nas w tworzeniu
oprogramowania i protokolu a wszystkich w zastosowaniach.
Wazne byloby tylko odpowiednie zastosowanie aplikacyjne (dostosowanie
napiec, pradu czy obciazalnosci). Tu byloby duze pole do popisu dla
wczesniej sygnalizowanych grup montersko instalatorskich.
Mozna tez "pomieszac" obie koncepcje i czesc klockow bedzie reagowac
bezposrednio na inne klocki, a czesc oczekiwac rozkazow z PC'ta...
Proponuje jednak koncepcje z centralnym komputerem, pamietajac o tej
drugiej koncepcji i w kolejnych wersjach protokolu je "pomieszac", to
znaczy dodawac inteligencji do poszczegolnych klockow. Klocko
inteligentniejsze drozsze, bardziej skomplikowana instalacja itp.,
ale jak ktos chce to ma.
Na razie skomplikuje nam to prace, a jak juz gdzies wczesniej pisalem
protokol i oprogramowanie ma byc takie aby takie mozliwosci mozna w
sposob przejrzysty dodawac.
Wymiana jednego klocka na klocek z inteligencja nie moze powodowac
koniecznosci wymiany wszystskich klockowe :-(((.
Mialem na mysli raczej rozwiazanie techniczne, a nie gotowy produkt.
Najpierw trzeba stwierdzic czy jest wogole mozliwe wykonanie czegos, a
potem mozemy myslec o jego wygladzie, etc...
Zgadza sie. Ustalmy standardy, rozwiazania itp., potem mozemy sie tym
zajac hobbystycznie lub komercyjnie, cal grupa lub w kilku grupach
itp. i wtedy wazna jest estetyka i wyglad.
ale rozumiem, ze miales na mysli, zeby wogole nie wbudowywac, a tylko
zrobic kilka uniwersalnych sterownikow...
Ja bym jednak byl za wbudowywaniem. :-))) - wtedy mozesz sterowac
"pelnia funkcji"
Wbudowywac w bardzo ograniczonym zakresie, i rozwiazania uniwersalne
jak wyzej opisalem. Potem mozna zainteresowac np. producentow sprzetu
gospodarstwa domowego, ale musimy miec czym.
Tomek
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: Home Automation - opis c.d.
Date: 3 Apr 1998 23:26:34 GMT
Bonik Kujany <hocking_at_nospam_rorse.edu.pl> wrote:
Nie tak. System ma być niezależny i rozproszony. Nie może być tak, że
od jednego sterownika zależy działanie całości.
Moze. I tak mamy go w mieszkaniu.
Nic nam to nie daje,
że mamy w jednym miejscu wszystko skoro możemy w każdej chwili się o
to zapytać.
Daje daje - oszczednosc w kosztach. Wbrew obiekcjom - uproszczenie
software - robisz jeden ambitny master, i wiele kompletnie nieambitnych
slave.
Powstanie serwera w systemie musi być uzasadnione. Nie ma potrzeby
wyróżniania jakiegoś sterownika dla kaprysu. Nic to nam nie da.
Da da...
W ogóle nie powinno być rozróżnienia na serwer, klient i pc. To
wszystko ma być równoprawne z założenia. Jeśli np. mamy czujnik
przejścia przez framugę to rozgłasza on wszystkim takie zdarzenie.
Koncepcja interesujaca, ale zdefiniowanie zaleznosci - koszmar.
No i kto ma definiowac zaleznosci? Jakis pc...
Nie bardzo. Port szeregowy nie nadaje się do nadawania CSMA-CD po
magistrali jednoprzewodowej.
Hm, na dobra sprawe - nadaje sie. OC na przewodzie i kontrola co sie
dzieje w kablu...
J.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 14:16:24 GMT
3 Apr 1998 23:26:34 GMT, "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
napisał(a):
Nie tak. System ma być niezależny i rozproszony. Nie może być tak, że
od jednego sterownika zależy działanie całości.
Moze. I tak mamy go w mieszkaniu.
A co to kryterium rozpraszania jest wychodzenie poza zarys mieszkania
?
Nic nam to nie daje,
że mamy w jednym miejscu wszystko skoro możemy w każdej chwili się o
to zapytać.
Daje daje - oszczednosc w kosztach. Wbrew obiekcjom - uproszczenie
software - robisz jeden ambitny master, i wiele kompletnie nieambitnych
slave.
Gdzie tam. Co slave to inne peryferia.
Powstanie serwera w systemie musi być uzasadnione. Nie ma potrzeby
wyróżniania jakiegoś sterownika dla kaprysu. Nic to nam nie da.
Da da...
Co ? Chcesz powiedzieć, że postawienie serwera jest do czegokolwiek
potrzebne ?? W/g mnie nie. To będzie tylko dublowało to co już
istnieje -> paczka z czujnika do serwera, paczki z klientów do
serwera.
W ogóle nie powinno być rozróżnienia na serwer, klient i pc. To
wszystko ma być równoprawne z założenia. Jeśli np. mamy czujnik
przejścia przez framugę to rozgłasza on wszystkim takie zdarzenie.
Koncepcja interesujaca, ale zdefiniowanie zaleznosci - koszmar.
No i kto ma definiowac zaleznosci? Jakis pc...
OCZYWIŚCIE, w końcu po coś się przyda.
Nie bardzo. Port szeregowy nie nadaje się do nadawania CSMA-CD po
magistrali jednoprzewodowej.
Hm, na dobra sprawe - nadaje sie. OC na przewodzie i kontrola co sie
dzieje w kablu...
A jak CD ? To może narysuj schemat. W końcu u mnie na razie nic
sensownego nie wisi.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:15 GMT
On Sat, 04 Apr 1998 14:16:24 GMT, hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
wrote:
Co ? Chcesz powiedzieć, że postawienie serwera jest do czegokolwiek
potrzebne ?? W/g mnie nie. To będzie tylko dublowało to co już
istnieje -> paczka z czujnika do serwera, paczki z klientów do
serwera.
Koszt sprzetu i oprogramowania oraz inteligencji wymaganej od obslugi
w przypadku kiedy mamy koncepcje czujnik->sterownik jest o wiele
wiekszy niz maly naklad na transmisje, w koncu malych paczek
informacji w koncepcji czujnik->serwer->sterownik.
Zreszta danymi z tego czujnika moze byc zainteresowany wiecej niz
jeden sterownik. Musialyby one wysylac zapytania do danego czujnika, a
on wielokrotnie odpowiadac co powoduje nieustanny ruch (wprawdzie
porownywalny co do wielkosci) informacji po sieci, ale w sposob
nieuporzadkowany (co z konfliktami itp.).
Koncepcja interesujaca, ale zdefiniowanie zaleznosci - koszmar.
No i kto ma definiowac zaleznosci? Jakis pc...
Wlasnie. Zdefiniowanie bedzie koszmarem dla kazdego, a dla szeregowego
uzytkownika w szczegolnosci.
Tomek
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sun, 05 Apr 1998 17:35:35 GMT
Sat, 04 Apr 1998 21:04:15 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisał(a):
Co ? Chcesz powiedzieć, że postawienie serwera jest do czegokolwiek
potrzebne ?? W/g mnie nie. To będzie tylko dublowało to co już
istnieje -> paczka z czujnika do serwera, paczki z klientów do
serwera.
Koszt sprzetu i oprogramowania oraz inteligencji wymaganej od obslugi
w przypadku kiedy mamy koncepcje czujnik->sterownik jest o wiele
wiekszy niz maly naklad na transmisje, w koncu malych paczek
informacji w koncepcji czujnik->serwer->sterownik.
O jakim sprzęcie mówimy i jakim oprogramowaniu? Jeśli o wspomnianym
'51 to niestety nie masz racji.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:14 GMT
On 3 Apr 1998 23:26:34 GMT, "Jaroslaw Lis"
<lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
Moze. I tak mamy go w mieszkaniu.
I to jest zaleta calego przedsiewziecia.
Koncepcja interesujaca, ale zdefiniowanie zaleznosci - koszmar.
No i kto ma definiowac zaleznosci? Jakis pc...
;-))))
Tomek
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 17:49:44 GMT
Kilka odpowiedzi na goraco:
On Fri, 03 Apr 1998 00:05:10 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
wrote:
Po pierwsze: Kazdy "klocek" ma mozliwosc sterowania zdalnego jak i
lokalnego (klawiaturka) - na wypadek awarii systemu - zawsze mozemy
recznie wlaczyc/wylaczyc, etc...
Warto o tym pamietac, ale jezeli rozbudowujemy w ten sposob gniazdka
czy kontakty punktow swietlnych to mamy juz ten mechanizm.
Jednakze kazda zmiana stanu urzadzenia spowodowana przez nas lokalnie,
powinna byc odnotowana w systemie (jesli np. przechodzac wlaczylismy swiatlo, to
Dlatego tez protokol i przeplyw informacji powinien byc dwustronny.
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia, a PC'tem - trzymanie tego ostatniego
wlaczonego non stop 24h na dobe nie jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki (tzw.
Uwazam, ze PC calkowicie wystarczy bez dodatkow, mozna wlaczyc
funkcje oszczedzania energii itp. A co do zawieszania, wszystko zalezy
od sprzetu, stabilnosci zasilania itp. Ostatecznie wystarczy modul
wathdog dla tego PC.
systemem. Tutaj jest wlasnie miejsce na tzw. sceny - wcisniecie jednego
klawisza powoduje iles tam dzialan...
Sceny takie sa jak najbardziej na miejscu.
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et, z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Komunikacja pilota z PC poprzez fale radiowe (bo nie musisz byc w tym
miejscu gdzie jest ten PC)?
Po czwarte: Komunikacja w sieci powinna byc dwukierunkowa tzn. ze
inicjatorem transmisji moze byc zarowno Master Controller, PC'et, jak i
dowolny z klockow (bo np. czujnik ruchu wykryl obiekt i informacja o tym
musi byc natychmiast przekazana).
To mozna bylo zauwazycj juz wczesniej.
Po piate: Jasne jest, ze dla obslugi tego typu dzialan, kazdy z klockow
musi byc wyposazony w odp. mikroprocesorek, ktory bedzie w stanie obsluzyc transmisje z jednej
strony, a z drugiej moc sterowac funkcjami urzadzenia. Jak dla mnie bedzie to Atmel
89C2051 - w wersji SMD jest dosc maly, ogolnie dostepny, dobrze znany.
...
To juz pozostawiam kolegom elektronikom,
Zastanawiam sie czy jeszcze pozostac na tej liscie, czy tez juz powoli
zaczac przechodzic na multi-priva, ze sie tak wyraze - sa spore opoznienia miedzy serwerami
Chyba trzeba tak powoli zrobic. Trzeba by tez rozpoznac sprawe
uruchomienia nowej grupy dyskusyjnej, oraz umieszczenia stron WWW na
jakims serwerze.
news.icm.edu.pl, a np. na news.nask.org.pl juz ich bylo wiecej) - moze
Ja korzystam z news.atm.com.pl i jakos na razie jest chyba OK, ale to
moze specyfika mojego providera.
Tomek
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Fri, 03 Apr 1998 22:36:05 +0100
Tomasz Murawski wrote:
Kilka odpowiedzi na goraco:
On Fri, 03 Apr 1998 00:05:10 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
wrote:
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia, a PC'tem - trzymanie tego ostatniego
wlaczonego non stop 24h na dobe nie jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki
(tzw.
Uwazam, ze PC calkowicie wystarczy bez dodatkow, mozna wlaczyc
funkcje oszczedzania energii itp. A co do zawieszania, wszystko zalezy
od sprzetu, stabilnosci zasilania itp. Ostatecznie wystarczy modul
wathdog dla tego PC.
Mialem na mysli normalnego domowego PC'ta, takiego na jakim kazdy sobie
pracuje wlasnie w tej chwili :-))), do ktorego mozna dopuscic np.
mlodsze rodzenstwo, aby moglo sobie pograc w gre, albo przetestowac nowa
prototypowa karte, czy nowo zakupiony procesor, etc. etc...Ja nie moge
drzec z obawy, ze moze mi sie zawiesic komputer (a bedzie sie zawieszal
- na to daje glowe :-))) , i nic na nim nie robic , bo jest odpalony
program do obslugi sieci...
Ja musze moc w kazdej chwili go wylaczyc bez obaw, ze cale mieszkanie mi
zwariuje...
Master Controller stojacy sobie gdzies obok, polaczony tylko kablem do
RS'a z PC'tem, wyposazony w rozmaite watchdogi, podtrzymania zasilania,
roznego rodzaju modemy do
transmisji przez PL, RF, IRED czy kabel, etc, etc...bedzie doskonale
spelnial role "pomocnika"....
Chyba, ze miales na mysli wykorzystanie jako MC, odrebnego malego PC'ta
(np. jakies stare 386), a komputer "domowy" bylby zupelnie z tym nie
polaczony...
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et,
z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest
przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Komunikacja pilota z PC poprzez fale radiowe (bo nie musisz byc w tym
miejscu gdzie jest ten PC)?
Niekoniecznie RF...mozna i na podczerwieni - podobnie jak to jest z
IRDA...ale to jeszczedo ustalenia... A sam pilot nie polaczony bylby z
PC' tem a z siecia - a poprzez nia, z nim samym. (w kazdym pomieszczeniu
modul do komunikacji IR z pilotem - kazdy "wpiety" w siec)
Jacek.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:17 GMT
On Fri, 03 Apr 1998 22:36:05 +0100, Jacek Domanski <jado_at_nospam_kki.net.pl>
wrote:
Mialem na mysli normalnego domowego PC'ta, takiego na jakim kazdy sobie
pracuje wlasnie w tej chwili :-))), do ktorego mozna dopuscic np.
mlodsze rodzenstwo, aby moglo sobie pograc w gre, albo przetestowac nowa
[ciach]
Tak wiec kroi sie chyba takie roziwazanie, ze jezeli jestemy
uzytkownikiem komputera i na nim pracujemy itp. to powinnismy postawic
prosty PC np. 386DX dedykowany do automatyki, jezeli nie to sprawa
prosta i tak go musimy postawic.
Ludzie sei tez beda cieszyc jak zassiejemy z rynku te komputerki aby
instalowac u innych Home Automation.
BTW: Moze ma ktos pomysl na jakies rozsadne i chwyliwe okreslenie w
jezyku polskim (Automatyzacja domu, Inteligentne mieszkanie...).
Ja musze moc w kazdej chwili go wylaczyc bez obaw, ze cale mieszkanie mi
zwariuje...
;-))))
Tomek
From: "Norbert Lugowski" <nlugowsk_at_nospam_ic.com.pl>
Subject: Re: Home Automation - opis c.d.
Date: Tue, 7 Apr 1998 01:51:48 +0200
Tomasz Murawski napisał(a) w wiadomości:
<352696ae.4529664_at_nospam_news.atm.com.pl>...
Tak wiec kroi sie chyba takie roziwazanie, ze jezeli jestemy
uzytkownikiem komputera i na nim pracujemy itp. to powinnismy postawic
prosty PC np. 386DX dedykowany do automatyki, jezeli nie to sprawa
prosta i tak go musimy postawic.
PO CO??? Jeżeli ma być to standard dostępny szerokiemu gronu użytkowników,
a nie paru specjalistom to musi to być rozwiązanie możliwie proste i łatwe w
obsłudze.
Jak to już ktoś pisał istnienie w systemie stale pracującego PC jest niczym
nie uzasadnione.
Taki system będzie znacznie droższy, chaotyczny, podatny na awarie
i nie zrozumiały dla przeciętnego usera.
Rola komputera w tego typu systemie powinna ograniczyć się jedynie do
odpowiedniego
zaprogramowania kostek i ewentualnie monitorowania i wizualizacji stanu
budynku.
Dla tego nie widzę powodu, aby komputer nie był dołączany do systemu tylko
od czasami.
Np. w moim przypadku raz na początku, żeby ustawić cały system,
a potem raz na kwartał, żeby sprawdzić wydatki za prąd, gaz ...
Ponadto taki system wymagał by skomplikowanej i drogiej (bo innej dla
każdego przypadku)
modyfikacji w przypadku jakiejkolwiek zmiany w strukturze którejś z
instalacji domu.
W przypadku instalacji typu mądry centralny sterownik -> głupie servo
sterownik musiałby wiedzieć jak obsługiwać każdy typ urządzenia.
Np. jeżeli miał byś zaimplementowane sterowanie kaloryferem elektrycznym, a
dokupił byś sobie
piecyk olejowy to musiałbuś całkowicie przeprogramować Mastera.
W przypadku koncepcji opartej o równoprawne elementy (bez wyróżnionego
mastera)
czujnik temperatury wysyła komunikat "zmniejszyć ogrzewanie w pokoje XX o
50%",
a jak to zrobić to już sprawa serva w konkretnym urządzeniu.
Jak widać dołożenie nowego piecyka nie wymaga wcale zmiany algorytmu
działania całego budynku ( =prostota użytkowania). Poza tym, aby było
ciepło w pokoju
wystarczy, żeby działały tylko piecyki i czujnik, reszta systemu możę paść
(=większa niezawodność).
Powyższy przykład jest oczywiście mocno uproszczony, ale dobrze oddaje
zalety
sterowania rozproszonego i zastosowania inteligentnych sterowników.
Norbert.
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: Home Automation - opis c.d.
Date: 7 Apr 1998 08:18:26 GMT
Norbert Lugowski <nlugowsk_at_nospam_ic.com.pl> wrote:
Jak to już ktoś pisał istnienie w systemie stale pracującego PC jest niczym
nie uzasadnione.
Taki system będzie znacznie droższy, chaotyczny, podatny na awarie
i nie zrozumiały dla przeciętnego usera.
Alez odwrotnie: taki system z dedykowanym [tanim] pc bedzie tani, latwy
do naprawy, latwy do zresetowania, latwy do napisania programu.
Tyle ze jak sie doda wielkosc, halas, zuzycie pradu [mniejsza o
oszczednosci, ale o zasilanie awaryjne chodzi], to ja wole troche dolozyc
i miec maly, zgrabny dedykowany kontrolerek :-)
Takie czasy niestety: pecet jest tanszy niz cokolwiek innego.
Ponadto taki system wymagał by skomplikowanej i drogiej (bo innej dla
każdego przypadku)
modyfikacji w przypadku jakiejkolwiek zmiany w strukturze którejś z
instalacji domu.
Ja tam twierdze ze bedzie to tania modyfikacja, o ile w ogole bedzie.
W przypadku instalacji typu mądry centralny sterownik -> głupie servo
sterownik musiałby wiedzieć jak obsługiwać każdy typ urządzenia
Np. jeżeli miał byś zaimplementowane sterowanie kaloryferem elektrycznym, a
dokupił byś sobie
piecyk olejowy to musiałbuś całkowicie przeprogramować Mastera.
Nie musisz, o ile protokol jest odpowiednio dobrany. Obu tym urzadzeniom
wysylasz takie same informacje.
W przypadku koncepcji opartej o równoprawne elementy (bez wyróżnionego
mastera)
czujnik temperatury wysyła komunikat "zmniejszyć ogrzewanie w pokoje XX o
50%",
a jak to zrobić to już sprawa serva w konkretnym urządzeniu.
Fajnie - ale jak sie zmieni sytuacja jesli czujnik wysle to do MC,
a MC przekaze gdzie trzeba? Albo MC odpyta czujnik i przekaze gdzie trzeba.
Jak widać dołożenie nowego piecyka nie wymaga wcale zmiany algorytmu
działania całego budynku ( =prostota użytkowania).
Poza drobnostka. Trzeba sie przebiec po urzadzeniach i zdefiniowac
ktore komu ma wysylac sygnaly, jak serwo ma reagowac na rozne sygnaly.
No i jak informacje ze w pokoju ma byc cieplo. Albo ze cieplo ma byc
od 6:00, od 9:00 oszczedzamy, o 14:00 powoli grzejemy, o 22:00 konczymy ...
ale nie w tym tygodniu, bo dzis wyjezdzamy na narty.
ciepło w pokoju
wystarczy, żeby działały tylko piecyki i czujnik, reszta systemu możę paść
(=większa niezawodność).
99% uszkodzen bedzie dotyczylo serw, czujnikow i komunikacji.
Powyższy przykład jest oczywiście mocno uproszczony, ale dobrze oddaje
zalety
sterowania rozproszonego i zastosowania inteligentnych sterowników.
Z drugiej strony - doswiadczenie mnie nauczylo ze im wieksza koncentracja,
tym prosciej sie tym zarzadza.
J.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Tue, 07 Apr 1998 17:37:20 GMT
7 Apr 1998 08:18:26 GMT, "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
napisał(a):
Jak to już ktoś pisał istnienie w systemie stale pracującego PC jest niczym
nie uzasadnione.
Taki system będzie znacznie droższy, chaotyczny, podatny na awarie
i nie zrozumiały dla przeciętnego usera.
Alez odwrotnie: taki system z dedykowanym [tanim] pc bedzie tani, latwy
do naprawy, latwy do zresetowania, latwy do napisania programu.
No nie, napisanie programu reagującego na sygnały z wielu urządzeń nie
jest proste a umożliwienie jego dynamicznej konfiguracji to dodatkowy
kłopot. O ileż łatwiej jest każdemu sterownikowi przydzielić jakieś
relatywnie proste zadanie.
Tyle ze jak sie doda wielkosc, halas, zuzycie pradu [mniejsza o
oszczednosci, ale o zasilanie awaryjne chodzi], to ja wole troche dolozyc
i miec maly, zgrabny dedykowany kontrolerek :-)
Takie czasy niestety: pecet jest tanszy niz cokolwiek innego.
Kurcze, zdecydujmy się do czego w końcu zmierzamy. Jeśli do
komponentów na '51 to PC czy jakikolwiek osobny MC są zbędne. Zupełnie
inaczej w przypadku używania gotowych końcówek np. LonWorks.
W przypadku instalacji typu mądry centralny sterownik -> głupie servo
sterownik musiałby wiedzieć jak obsługiwać każdy typ urządzenia
Np. jeżeli miał byś zaimplementowane sterowanie kaloryferem elektrycznym, a
dokupił byś sobie
piecyk olejowy to musiałbuś całkowicie przeprogramować Mastera.
Nie musisz, o ile protokol jest odpowiednio dobrany. Obu tym urzadzeniom
wysylasz takie same informacje.
Bo przykład był nienajlepszy. Wystarczy rozważyć sterowanie budzikiem
a sterowanie pralką.
W przypadku koncepcji opartej o równoprawne elementy (bez wyróżnionego
mastera)
czujnik temperatury wysyła komunikat "zmniejszyć ogrzewanie w pokoje XX o
50%",
a jak to zrobić to już sprawa serva w konkretnym urządzeniu.
Fajnie - ale jak sie zmieni sytuacja jesli czujnik wysle to do MC,
a MC przekaze gdzie trzeba? Albo MC odpyta czujnik i przekaze gdzie trzeba.
Tylko tyle, że osobny MC staje się potrzebny podczas gdy tak w ogóle
jest zbędny.
Jak widać dołożenie nowego piecyka nie wymaga wcale zmiany algorytmu
działania całego budynku ( =prostota użytkowania).
Poza drobnostka. Trzeba sie przebiec po urzadzeniach i zdefiniowac
ktore komu ma wysylac sygnaly, jak serwo ma reagowac na rozne sygnaly.
No i jak informacje ze w pokoju ma byc cieplo. Albo ze cieplo ma byc
od 6:00, od 9:00 oszczedzamy, o 14:00 powoli grzejemy, o 22:00 konczymy ...
ale nie w tym tygodniu, bo dzis wyjezdzamy na narty.
I to ma być łatwiejsze do oprogramowania w MC ? W jakim sensie ?
ciepło w pokoju
wystarczy, żeby działały tylko piecyki i czujnik, reszta systemu możę paść
(=większa niezawodność).
99% uszkodzen bedzie dotyczylo serw, czujnikow i komunikacji.
Czyżbyś bez LonWorks potrafił zrealizować je w postaci urządzeń o
zerowej inteligencji ?
Powyższy przykład jest oczywiście mocno uproszczony, ale dobrze oddaje
zalety
sterowania rozproszonego i zastosowania inteligentnych sterowników.
Z drugiej strony - doswiadczenie mnie nauczylo ze im wieksza koncentracja,
tym prosciej sie tym zarzadza.
To będziesz miał skoncentrowane ... poprzez medium transmisyjne i
protokoły.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 11:29:00 GMT
Fri, 03 Apr 1998 17:49:44 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisał(a):
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia, a PC'tem - trzymanie tego ostatniego
wlaczonego non stop 24h na dobe nie jest chyba mozliwe,
a znajac jego tendencje do zawieszania....:-))) Komputerek taki (tzw.
Uwazam, ze PC calkowicie wystarczy bez dodatkow, mozna wlaczyc
funkcje oszczedzania energii itp. A co do zawieszania, wszystko zalezy
od sprzetu, stabilnosci zasilania itp. Ostatecznie wystarczy modul
wathdog dla tego PC.
Nieprawda. Minimalny koszt zrealizowania logiki w formie rozproszonej
po sterownikach (one i tak być muszą) nie uzasadnia centralizowania
sterowania.
systemem. Tutaj jest wlasnie miejsce na tzw. sceny - wcisniecie jednego
klawisza powoduje iles tam dzialan...
Sceny takie sa jak najbardziej na miejscu.
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et, z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Komunikacja pilota z PC poprzez fale radiowe (bo nie musisz byc w tym
miejscu gdzie jest ten PC)?
Do tego robi się w każdym pomieszczeniu odbiornik podczerwieni
sterujący innymi elementami systemu. PC zbędny!
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: Home Automation - opis c.d.
Date: 4 Apr 1998 13:03:35 GMT
Bonik Kujany <hocking_at_nospam_rorse.edu.pl> wrote:
Nieprawda. Minimalny koszt zrealizowania logiki w formie rozproszonej
po sterownikach (one i tak być muszą) nie uzasadnia centralizowania
sterowania.
Ale maksymalny koszt zmiany tej logiki w dziesiatkach miejsc jesli
przyjdzie nam taka ochota - uzasdnia :-)
J.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 16:57:22 GMT
4 Apr 1998 13:03:35 GMT, "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
napisał(a):
Nieprawda. Minimalny koszt zrealizowania logiki w formie rozproszonej
po sterownikach (one i tak być muszą) nie uzasadnia centralizowania
sterowania.
Ale maksymalny koszt zmiany tej logiki w dziesiatkach miejsc jesli
przyjdzie nam taka ochota - uzasdnia :-)
Ta, a w jaki sposób jest większy koszt przeprogramowania serwera od
przeprogramowania jednostki ? Naprawdę nie rozumiem. To ten sam koszt
tylko, że kiedy serwer będzie programowany tudzież padnie to cały
system jest niedostępny. I gdzie tu sens ?
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:21 GMT
On Sat, 04 Apr 1998 16:57:22 GMT, hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
wrote:
Nieprawda. Minimalny koszt zrealizowania logiki w formie rozproszonej
po sterownikach (one i tak być muszą) nie uzasadnia centralizowania
sterowania.
Ale maksymalny koszt zmiany tej logiki w dziesiatkach miejsc jesli
przyjdzie nam taka ochota - uzasdnia :-)
Calkowicie sie zgadzam.
Ta, a w jaki sposób jest większy koszt przeprogramowania serwera od
przeprogramowania jednostki ? Naprawdę nie rozumiem. To ten sam koszt
tylko, że kiedy serwer będzie programowany tudzież padnie to cały
system jest niedostępny. I gdzie tu sens ?
Kto powiedzial, ze na czas zmian w algorytmach sterujacych wylaczany
jest serwer?
A koszt jest wlasnie taki, ze jest to mniej skomplikowane i bardziej
zrozumiale dla ludzi.
Poza tym mozesz przygotowywac nowa konfiguracje i jak wprowadzisz
wszystkie zmiany to ja zatwierdzasz i wprowadzasz w zycie
jednoczesnie, a tak masz do przeprogramowania np. kilka klockow, nie
robisz oczywiscie tego jednoczesnie i po zaprogramowaniu jedengo
przechodzisz drugiego itd. a system pracuje juz niestabilnie bo
zmieniles np. sygnal wyjsciowy w jednym ze sterownikow na jakies
krytyczne urzadzenie. Mozna by to probowac obejsc, ale do normalnej
inteligencji czlowieka potrzebnej do przeprogramowania klockow
dochodzi jeszcze ustalenie kolejnosci ich konfiguracji. Nie jestem do
konca pewnien czy nie ma tu mozliwosci zapetlenia sie.
Moze jeszcze jeden argument. Centralizujac to wszystko w PC (lub kilka
jezeli masz automatyzowac np. dom wielorodzinny) mozesz zapamietywac
poszczegolne konfiguracje i powracac do nich np. sezonowo (zima, lato
itp.), albo jak okaze sie ze nowy algorytm jest gorszy.
Tomek
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sun, 05 Apr 1998 17:35:39 GMT
Sat, 04 Apr 1998 21:04:21 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisał(a):
Ta, a w jaki sposób jest większy koszt przeprogramowania serwera od
przeprogramowania jednostki ? Naprawdę nie rozumiem. To ten sam koszt
tylko, że kiedy serwer będzie programowany tudzież padnie to cały
system jest niedostępny. I gdzie tu sens ?
Kto powiedzial, ze na czas zmian w algorytmach sterujacych wylaczany
jest serwer?
To oczywiste i nie wymaga dowodu :-(
A koszt jest wlasnie taki, ze jest to mniej skomplikowane i bardziej
zrozumiale dla ludzi.
A jaki to ma związek z istnieniem serwera? Przecież bez dodatkowego
oprogramowania nie da się nic ułatwić! Czy konfiguracja będzie lokalna
czy rozproszona jest akurat bez różnicy.
Moze jeszcze jeden argument. Centralizujac to wszystko w PC (lub kilka
jezeli masz automatyzowac np. dom wielorodzinny) mozesz zapamietywac
poszczegolne konfiguracje i powracac do nich np. sezonowo (zima, lato
itp.), albo jak okaze sie ze nowy algorytm jest gorszy.
...co nie zależy od tego czy używam PC do sterowania czy nie. Gorzej,
że jeśli używam i się przypadkiem odłączy to nic nie działa.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:20 GMT
On Sat, 04 Apr 1998 11:29:00 GMT, hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
wrote:
Do tego robi się w każdym pomieszczeniu odbiornik podczerwieni
sterujący innymi elementami systemu. PC zbędny!
Jak dotychczas z wieloma Twoimi opiniami sie zgadzam, ale nie wyrzucaj
PC jako centrali. Sadze ze padlo juz wiele argumentow za tym zeby byl
(miedzy innymi prostota obslugi dla laikow), ze nie bede ich tutaj
powtarzal.
Tomek
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sun, 05 Apr 1998 17:35:45 GMT
Sat, 04 Apr 1998 21:04:20 GMT, tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
napisał(a):
Do tego robi się w każdym pomieszczeniu odbiornik podczerwieni
sterujący innymi elementami systemu. PC zbędny!
Jak dotychczas z wieloma Twoimi opiniami sie zgadzam, ale nie wyrzucaj
PC jako centrali. Sadze ze padlo juz wiele argumentow za tym zeby byl
(miedzy innymi prostota obslugi dla laikow), ze nie bede ich tutaj
powtarzal.
Przeciętny użytkownik nie potrzebuje żadnego PC. Kupuje czujniki,
sterowniki, podłącza i używa. Da się zrobić.
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: Home Automation - opis c.d.
Date: 3 Apr 1998 18:40:26 GMT
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
Po pierwsze: Kazdy "klocek" ma mozliwosc sterowania zdalnego jak i
lokalnego (klawiaturka) - na wypadek awarii systemu - zawsze mozemy
recznie wlaczyc/wylaczyc, etc...
Hm ... zyrandol z klawiatura? Nie dosiegne.
Po drugie: W systemie powinien sie znajdowac maly komputerek
posredniczacy miedzy siecia, a PC'tem
Tez bylbym za, wrecz z przeniesiemiem prawie wszystkich funkcji do niego.
Pecet po prostu jako zaawansowane zrodlo danych sterujacych - ale
nie niezbedny w systemie.
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Mowiac szczerze jeden moze obsluzyc kilka nosnikow
Po trzecie: Dobrze byloby dla ulatwienia sterowania zrobic cos w rodzaju
inteligentnego pilota o dwukierunkowej komunikacji (odbiera i nadaje),
z wyswietlaczem alfarnumerycznym LCD,
za pomoca ktorego moglibysmy w prosty sposob bezposrednio sterowac
systemem.
Brr :-)
Ale chyba masz racje - zaawansowanego sterowania bez zwrotnej
informacji nie da sie zrobic.
Inna sprawa ze jak mamy miec zaawansowana sekwencje ... to moze
jednak ruszyc tylek w kierunku peceta i tam to zrobic, a
pilot z gatunku prostych i tanich.
Po czwarte: Komunikacja w sieci powinna byc dwukierunkowa tzn. ze
inicjatorem transmisji moze byc zarowno Master Controller, PC'et, jak i
dowolny z klockow (bo np. czujnik ruchu wykryl obiekt i informacja o tym
musi byc natychmiast przekazana).
Tu wlasnie jest miejsce na odpowiedni protokol transmisji - wykrywanie
kolizji (CSMA), poprawnosc transmisji (CRC), etc. etc....
Hm - po pierwsze zastanowilbym sie nad ta dwukierunkowa transmisja -
niewatpliwie jednokierunkowa bedzie znacznie prostsza.
Jesli jednak ma byc, to niekoniecznie musi byc az tak ambitna.
Jak na moj gust wystarczy ze ruchem w sieci steruje MC, sterowniki
moga byc np odpytywane cyklicznie, a pecet ... jest podlaczony jedynie
do MC.
Po piate: Jasne jest, ze dla obslugi tego typu dzialan, kazdy z klockow
musi byc wyposazony w
odp. mikroprocesorek, ktory bedzie w stanie obsluzyc transmisje z jednej
strony, a z drugiej moc sterowac funkcjami urzadzenia.
No - to jest dyskusyjne. Na potrzeby wlasne - owszem.
Ale raczej pomyslalbym o czyms co sie latwo wprojektowuje w uklad
scalony. A potem podsuniemy Darkowi ze sa zamowienia na 10 tys
chipow sciemniaczy i ma przyjemnosc zrobic jakis uklad.
89C2051 - w wersji SMD jest dosc maly, ogolnie dostepny, dobrze znany.
Rodzi sie pytanie: Czy damy rade pomiescic w jednym procesorku obie w/w
funkcje (transmisja i sterowanie). Czy potrzebny bedzie jeszcze jeden
procesorek "dedykowany" tylko do obslugi transmisji. (51'ka podoba mi
sie jeszcze z tego wzgledu, ze ma sprzetowy port szeregowy - czekajacy
tylko na wykorzystanie :-)))
Nie powinno byc problemow z miejscem, co do tego portu - niekoniecznie
jest to najlepszy pomysl. Inne moga byc rownie dobre.
Aha...dla informacji podam, ze juz pewne elementy systemu mam opracowane
- od strony sprzetowej raczej niz programowej.
Po pierwsze jest juz modem sieciowy PL - transmisja danych cyfrowych
przez siec 220V idzie z szybkoscia 1200 bodow.
Napisz cos wiecej. Jaka kosc, ile elementow potrzebuje, ile miejsca
zajmuje..
J.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 11:29:02 GMT
3 Apr 1998 18:40:26 GMT, "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
napisał(a):
Po pierwsze: Kazdy "klocek" ma mozliwosc sterowania zdalnego jak i
lokalnego (klawiaturka) - na wypadek awarii systemu - zawsze mozemy
recznie wlaczyc/wylaczyc, etc...
Hm ... zyrandol z klawiatura? Nie dosiegne.
-))))))))))
Mozna tez wpiac w siec kilka Master Controllerow, np. kazdy obslugujacy
inny rodzaj nosnika, etc...To juz do ustalenia.
Mowiac szczerze jeden moze obsluzyc kilka nosnikow
W ogóle nie jest potrzebny osobny MC. To się robi w ramach któregoś z
elementów systemu zgodnie z realnymi potrzebami.
From: tomekm_at_nospam_ikp.atm.com.pl (Tomasz Murawski)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 04 Apr 1998 21:04:22 GMT
On 3 Apr 1998 18:40:26 GMT, "Jaroslaw Lis"
<lis_at_nospam_papuga.ict.pwr.wroc.pl> wrote:
Hm ... zyrandol z klawiatura? Nie dosiegne.
Kontakt swietlny na scianie, ale i tak trzeba do niego wstac.
Tez bylbym za, wrecz z przeniesiemiem prawie wszystkich funkcji do niego.
Pecet po prostu jako zaawansowane zrodlo danych sterujacych - ale
nie niezbedny w systemie.
Tak, ale prosty PC a nie jakas specjalna konstrukcja. Choc jak pisalem
gdzies wyzej, mozna miec na uwadze takie "mozgi" jako specjalizowane
kontrolery, co pozwoliloby na pewne rozproszenie systemu, ktore jest
postulowane.
Brr :-)
Ale chyba masz racje - zaawansowanego sterowania bez zwrotnej
informacji nie da sie zrobic.
Inna sprawa ze jak mamy miec zaawansowana sekwencje ... to moze
jednak ruszyc tylek w kierunku peceta i tam to zrobic, a
pilot z gatunku prostych i tanich.
A brr ;-))) Po t osie to robi, aby nie trzeba bylo sie ruszyc, a tu
nijak to nie chce sie dac zrobic ;-))))
Chyba ze nie bedziemy miec zaawansowanych sekwencji. ;-))))
Hm - po pierwsze zastanowilbym sie nad ta dwukierunkowa transmisja -
niewatpliwie jednokierunkowa bedzie znacznie prostsza.
Wydaje sie byc potrzebna. Nie widze problemu aby klocek sam wysylal
info o zmianie swojego stanu, a i mogl byc odpytany.
No - to jest dyskusyjne. Na potrzeby wlasne - owszem.
Ale raczej pomyslalbym o czyms co sie latwo wprojektowuje w uklad
scalony. A potem podsuniemy Darkowi ze sa zamowienia na 10 tys
chipow sciemniaczy i ma przyjemnosc zrobic jakis uklad.
Taki maly rynek przewidujesz ;-))))
Zreszta nie tylko sciemniacze, a uniwersalne klocki moga chyba byc w
jednym scalaku? Takie elementy mozna by jezeli ktos chce zabudowac we
wlasnej obudowie, a udostepnione innym mogly byc stosowane przez
producentow urzadzen gospodarstwa domowego, elektorniki uzytkowej itp.
Tomek
From: cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl (Jaroslaw Cichorski Jr.)
Subject: Re: Home Automation - opis c.d.
Date: Tue, 07 Apr 1998 21:06:17 GMT
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
I nie tylko Jacek wrote ;-)))
Po przeanalizowaniu ponad 30 postow na ten temat pozwole sobie
dorzucic 3 grolsche.
Poniewaz tendencje w elektronice sa takie, ze uC staja sie mniejsze,
szybsze, tansze itd mozna wiec w wiekszosci 'klockow' uzyc uC o
wiekszych mozliwosciach i z wieksza pamiecia - to nie wplynie znaczaco
na koszt
Proponuje nastepujace zalozenia:
1. PC tylko do zarzadzania ustawieniami klockow i do ich
programowania.
2. Klocki dwoch rodzajow: inteligentne i beznadziejnie glupie
(inteligentne inaczej).
2a. Inteligentne moga byc programowane z PC i moga same realizowac
zadane im programy;
2b. Beznadziejnie glupie sluza tylko do realizacji funkcji pomiarowych
i wykonawczych.
3. Transmisja dwukierunkowa, szeregowa, od 1200 do 2400 bps,
potwierdzenie tylko wtedy, gdy sobie tego zazyczymy - opcja
oczekiwania na potwierdzenie zaimplementowana w protokole.
Nadawanie rozpoczynane jest gdy na linii jest cisza, w trakcie
nadawania podsluchujemy, gdy konflikt - przerywamy na losowy czas
(takie troche CSMA-CD).
Przesylanie glownie po sieci zasilania 220V - jedyny problem to
propagacja na rozne fazy.
4. Jezyk programowania 'obrazkowy' tzn. dla klockow inteligentnych
ukladamy program jezykiem obrazkowym zrozumialym dla (nie ujmujac nic
przyszlym uzytkownikom) idiotow - byle umieli poruszac myszka ;-)).
Robimy to na PC, ten to 'prekompiluje' i przesyla do odpowiedniego
(nich) klockow.
5. Program w klocku realizuje sie na zasadzie wykonywania
makroinstrukcji przeslanych z PC (po prekompilacji) i zapisanych np. w
EEPROM.
6. Numeracja urzadzen w sieci. Daloby sie zrobic, zeby PC rozpoznawal
wszystkie urzadzenia i nadawal im numery w trakcie pierwszej
konfiguracji (lub pozniejszej rekonfoguracji) systemu.
--------------------------------------------------------
Teraz rozwiniecie i komentarze do zalozen:
ad.1. Nie mozna czynic PC glownym masterem, to obniza niezawodnosc i
elastycznosc systemu. Wymaga stosowania podtrzymania zasilania i
dodania watchdoga dla prawidlowej pracy systemu.
Zarzadzanie rozproszone w ramach realizacji konkretnych zadan - to
jest chyba prawidlowy kierunek naszego dzialania.
PC tylko jako 'programator'.
ad.2a. Klocki inteligentne maja pelnic role 'inteligencji
rozproszonej'. Mozna sobie wobrazic rozne wersje tych klockow - o
wiekszej lub mniejszej pojemnosci programu. Mozna do nich dolozyc
kilka wyjsc np. do zalaczania jakichs urzadzen. Ich zadaniem jest
realizacja programu. Moga sie komunikowac z innymi klockami
inteligentnymi lub z glupolami tylko po to by je odpytac, wyslac do
nich rozkaz i ew. oczekiwac potwierdzenia (jezeli jest taka potrzeba).
Mozna sobie wyobrazic takie klocki jako np. 'wklad' do puszek
podtynkowych lub modulowe tak jak bezpieczniki na listwy, zasilane z
sieci.
ad 2b. Klocki beznadziejnie glupie maja sluzyc w zasadzie tylko do
realizacji przeslanych im rozkazow i do wysylania zebranych danych.
Dostepne jako 'puszki' i 'bezpieczniki'.
ad 3. Komunikacja po sieci ma ta zalete, ze zapewnia elastycznosc, ale
ma tez i wady - wymaga homologacji (gdy chciec tym handlowac) i wymaga
stosowania transformatorow typu TOKO - zajmuje troche miejsca. Wymaga
tez specjalnej konstrukcji zasilacza (albo male trafo - znow miejsce,
albo Power Integrations - cena ;-(( )
ad 4. Bedzie troche zabawy ze stworzeniem takiego jezyka
programowania, ale mysle, ze do zrobienia. Korzysci przekrocza na
pewno wlozony trud.
ad 5. Zaleta jest stabilnosc takiego rozwiazania. Nawet jezeli uklad
sie na chwile powiesi (od czego watchdog) to nie ma szans (OK, sa, ale
b. male) na zmiane zawartosci programu. Mozna go przerwac w dowolnej
chwili (zanik zasilania) i wznowic bez obawy o przypadkowa zmiane
zawartosci programu. Dodatkowo taki sterownik nie musi nawet posiadac
ukladu wykrywajacego zanik zasilania, zeby sie ratowac -> nizszy koszt
sterownika.
ad. 6 Co tu wiecej mozna napisac ;-)))
----------------
Uff,
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
E-mail cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
WWW http://www.amart.com.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: "Mariusz Szepietowski" <mariusz.s_at_nospam_writeme.com>
Subject: Re: Home Automation - opis c.d.
Date: Wed, 8 Apr 1998 10:46:34 +0200
Jaroslaw Cichorski Jr. napisał(a) w wiadomości:
<6ge4i7$bfb$1_at_nospam_ikp2.ikp.pl>...
Mozna sobie wyobrazic takie klocki jako np. 'wklad' do puszek
podtynkowych lub modulowe tak jak bezpieczniki na listwy,
zasilane z
sieci.
Proponuję także formę gniazdek elektrycznych Np. podwójnych -
jedno sterowalne, drugie nie.
.
Pozdrawiam serdecznie
--
Mariusz Szepietowski
mariusz.s_at_nospam_writeme.com
www.mariusz.mypage.org - Automatyzacja domu/mieszkania
Zarzadzanie srodkami trwalymi, Vademecum Listy Przebojow
Programu III
.
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Wed, 08 Apr 1998 20:22:38 +0200
Jaroslaw Cichorski Jr. wrote:
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
I nie tylko Jacek wrote ;-)))
No i cale szczescie :-)))) Swiadomie dalem przerwe zeby inni sie mogli
wygadac...:-))) Aczkolwiek troche "nadaje" na "mailing list" - niestety
jakos cicho....jedna, dwie osoby tylko sie odzywaja - albo "goraczka
przedswiateczna" i nikt nie ma czasu na pisanie glupot, albo temat
nieciekawy ;-)))))
Po przeanalizowaniu ponad 30 postow na ten temat pozwole sobie
dorzucic 3 grolsche.
Poniewaz tendencje w elektronice sa takie, ze uC staja sie mniejsze,
szybsze, tansze itd mozna wiec w wiekszosci 'klockow' uzyc uC o
wiekszych mozliwosciach i z wieksza pamiecia - to nie wplynie znaczaco
na koszt
Co masz na mysli mowiac "o wiekszych mozliwosciach i pamieci" -
wiekszych niz taki np. Atmelek (2k ROM) ? Czy bedzie on "w sam raz" ?
(jak dla mnie to w sam raz - i tani, i maly)
Proponuje nastepujace zalozenia:
1. PC tylko do zarzadzania ustawieniami klockow i do ich
programowania.
2. Klocki dwoch rodzajow: inteligentne i beznadziejnie glupie
(inteligentne inaczej).
2a. Inteligentne moga byc programowane z PC i moga same realizowac
zadane im programy;
2b. Beznadziejnie glupie sluza tylko do realizacji funkcji pomiarowych
i wykonawczych.
A wlasciwie to do jakich celow chcialbys uzyc tych superinteligentnych
klockow? Ja mialem koncepcje tego typu, ze uC + modem stanowilyby tylko
interfejs do zdalnego sterowania, a o inteligencji jako takiej raczej
nie bylo mowy - to PC (czy MC) mialy "myslec ktorym klockiem jak
sterowac...
Dla mnie to wszystko pod wzgledem "zlomu elektronicznego" to i tak
prawie to samo - klocek do sterowania swiatlem zawiera: mikroprocesor,
modem sieci 220V i kilka elementow dodatkowych, klocek do sterowania
telewizorem moze byc jeszcze prostszy, jesli wpiac go np. w I2C, klocek
do pomiaru temperatury: uC, modem i jeden uklad Dallas'a (np. DS1621),
klocek z czujnikiem ruchu: uC, modem, i czujnik, klocek do wlaczania np.
piecyka, czy dowolnego urzadzenia (inteligentne gniazdko): uC, modem,
przekaznik.....itd, itp... I tak najbardziej skomplikowana jest z tego
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
3. Transmisja dwukierunkowa, szeregowa, od 1200 do 2400 bps,
potwierdzenie tylko wtedy, gdy sobie tego zazyczymy - opcja
oczekiwania na potwierdzenie zaimplementowana w protokole.
Nadawanie rozpoczynane jest gdy na linii jest cisza, w trakcie
nadawania podsluchujemy, gdy konflikt - przerywamy na losowy czas
(takie troche CSMA-CD).
Dokladnie...pozostaje do ustalenia ramka - jak bedzie wygladac, jaki
adres, jak dlugie pole danych, czy CRC? itd... (nad tym wlasnie mysle)
Przesylanie glownie po sieci zasilania 220V - jedyny problem to
propagacja na rozne fazy.
No fakt ... Tylko czy w domu (normalnym) ktos ma 3 fazy? Zazwyczaj jest
jedna...ten problem chyba mozemy sobie zostawic na pozniej...
4. Jezyk programowania 'obrazkowy' tzn. dla klockow inteligentnych
ukladamy program jezykiem obrazkowym zrozumialym dla (nie ujmujac nic
przyszlym uzytkownikom) idiotow - byle umieli poruszac myszka ;-)).
Robimy to na PC, ten to 'prekompiluje' i przesyla do odpowiedniego
(nich) klockow.
Dokladnie - PC'et tylko do "przyrzadzania przepisu" (aczkolwiek w mojej
koncepcji PC'et przesylal prekompilowane dane do MasterController'a, a
nie bezposrednio do klockow - lokalnym RS'em, bez potrzeby obciazania
sieci - bo przeslanie tak duzej ilosci danych jakim bedzie program dla
kazdego klocka, troche "przyblokuje siec")
6. Numeracja urzadzen w sieci. Daloby sie zrobic, zeby PC rozpoznawal
wszystkie urzadzenia i nadawal im numery w trakcie pierwszej
konfiguracji (lub pozniejszej rekonfoguracji) systemu.
A mnie sie marzy dynamiczny numer urzadzenia - po wlaczeniu do gniazdka,
urzadzenie zglasza swoja obecnosc w sieci i zostaje mu przydzielony
adres, od tego momentu urzadzenie jest identyfikowane z tym adresem -
ale wtedy zarzadca sieci musi caly czas "czuwac" i reagowac na
pojawienie sie nowego urzadzenia (lub wypadniecie starego).
--------------------------------------------------------
Teraz rozwiniecie i komentarze do zalozen:
ad.1. Nie mozna czynic PC glownym masterem, to obniza niezawodnosc i
elastycznosc systemu. Wymaga stosowania podtrzymania zasilania i
dodania watchdoga dla prawidlowej pracy systemu.
Dlatego ja sklanialem sie w kierunku MasterController'a, ktory bylby
"ladowany" odpowiednio przekompilowanymi danymi (z postaci obrazkowej,
czytelnej dla uzytkownika, na odp. polecenia rozkazy, czasy wlaczen
itp...), a jednoczesnie mialby watchdoga i inne rodzaje zabezpieczen -
on "madry", klocki "glupie" :-)))
Zarzadzanie rozproszone w ramach realizacji konkretnych zadan - to
jest chyba prawidlowy kierunek naszego dzialania.
PC tylko jako 'programator'.
A co z Master Controllerem? Gdzie wobec tego miejsce na "sceny",
tygodniowe programy, etc, etc?.... To wszystko w "klockach" ? - mam
wrazenie ze koncepcja z "inteligencja rozproszona" jest duzo trudniejsza
do realizacji niz "scentralizowana" - i program w kazdym klocku i progam
w PC'cie realizujacy "zdalne przeprogramowywanie" bedzie bardziej
skomplikowany...Ale nie chce tu wystepowac jako "negujacy wszystko"
-)))) Moze macie racje, tylko jakos ja sie nie moge do tego
przekonac... (widocznie z trudne dla mnie ;-))))
ad 3. Komunikacja po sieci ma ta zalete, ze zapewnia elastycznosc, ale
ma tez i wady - wymaga homologacji (gdy chciec tym handlowac) i wymaga
stosowania transformatorow typu TOKO - zajmuje troche miejsca. Wymaga
tez specjalnej konstrukcji zasilacza (albo male trafo - znow miejsce,
albo Power Integrations - cena ;-(( )
Wlasnie nad tym mysle :-))) Wymysliles juz cos moze? Jak dla mnie to
mam zamiar skoncentrowac sie na minimalizacji samego ukladu
elektronicznego (SMD, dwustronny druk, etc), a trafa zostawic takie
jakie sa.... I tak sie powinno zmiescic....Gorzej, ze brak przewodu
zerowego w kontakcie (od swiatla) ....pozostaje zatem kucie :-))) i
dociaganie go z puszki.... Tak, tak...taki glupi z pozoru sterownik
swiatla jest wlasnie tym najtrudniejszym elementem (no prawie.. :-)))
ad 5. Zaleta jest stabilnosc takiego rozwiazania. Nawet jezeli uklad
sie na chwile powiesi (od czego watchdog) to nie ma szans (OK, sa, ale
b. male) na zmiane zawartosci programu. Mozna go przerwac w dowolnej
chwili (zanik zasilania) i wznowic bez obawy o przypadkowa zmiane
zawartosci programu. Dodatkowo taki sterownik nie musi nawet posiadac
ukladu wykrywajacego zanik zasilania, zeby sie ratowac -> nizszy koszt
sterownika.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez mala
dziurke w obudowie....Zawsze mozna by klocek przywrocic do dzialania
"recznie" (szczegolnie jesli chodzi o "wbudowane" w sciane urzadzenia,
gdzie nie mozna wylaczyc zasilania, no chyba zeby cala instalacje
wylaczyc)
ad. 6 Co tu wiecej mozna napisac ;-)))
Trzeba dzialac! Budowac uklady doswiadczalne, wyprobowywac rozne
warianty, szukac mozliwosci, etc, etc... A na liscie przedyskutowywac
"to i owo"... (lub mailing list, albo jak oferowal sie Jarek Lis -
specjalny serwer "rozsylajacy" listy tylko do zainteresowanych)
----------------
Uff,
Pozdrawiam
Czesc, czesc......to dopiero poczatek.....:-)))))
Jacek.
From: cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl (Jaroslaw Cichorski Jr.)
Subject: Re: Home Automation - opis c.d.
Date: Thu, 09 Apr 1998 15:21:48 GMT
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
Co masz na mysli mowiac "o wiekszych mozliwosciach i pamieci" -
wiekszych niz taki np. Atmelek (2k ROM) ? Czy bedzie on "w sam raz" ?
(jak dla mnie to w sam raz - i tani, i maly)
To wyjdzie w praniu. Wydaje sie, ze 2051 + zewnetrzny EEPROM do
podtrzymywania kodu makroinstrukcji wystarczy.
Do prostszych klockow wystarczy nawet jakis maly PIC.
A wlasciwie to do jakich celow chcialbys uzyc tych superinteligentnych
klockow? Ja mialem koncepcje tego typu, ze uC + modem stanowilyby tylko
interfejs do zdalnego sterowania, a o inteligencji jako takiej raczej
nie bylo mowy - to PC (czy MC) mialy "myslec ktorym klockiem jak
sterowac...
No ale, zeby uniezaleznic wszystko od PC to proponowalem, aby PC
sluzyl do konfiguracji sieci i ukladania programow, a te po
'skompilowaniu' bylyby wykonywana w postaci makroinstrukcji przez
'superinteligentne' klocki.
Dlatego w kazdym takim klocku potrzebny jest interpreter
makroinstrukcji oraz pamiec na nie (EEPROM).
<snip>
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
3. Transmisja dwukierunkowa, szeregowa, od 1200 do 2400 bps,
potwierdzenie tylko wtedy, gdy sobie tego zazyczymy - opcja
oczekiwania na potwierdzenie zaimplementowana w protokole.
Nadawanie rozpoczynane jest gdy na linii jest cisza, w trakcie
nadawania podsluchujemy, gdy konflikt - przerywamy na losowy czas
(takie troche CSMA-CD).
Dokladnie...pozostaje do ustalenia ramka - jak bedzie wygladac, jaki
adres, jak dlugie pole danych, czy CRC? itd... (nad tym wlasnie mysle)
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
-adres odbiorcy (lub 'do wszytkich)',
-status (m.in. czy wymagane jest potwierdzenie, nie moze byc wymagane
gdy 'do wszystkich'),
-typ urzadzenia nadajacego,
-identyfikator nadawcy (adres),
-ilosc przesylanych bajtow,
-iles bajtow danych,
-CRC (8 bit starczy)
Byc moze cos jeszcze i byc moze w innej kolejnosci (zeby latwiej bylo
analizowac).
Mozliwe, ze np. typ urzadzenia nadajacego i status da sie polaczyc w
jeden bajt.
Ramka nie moze byc za dluga, bo nie starczy pamieci w kontrolerkach na
jej przygotowanie lub odebranie.
Adresy chyba 1 bajtowe (a moze jednak 2)
Przesylanie glownie po sieci zasilania 220V - jedyny problem to
propagacja na rozne fazy.
No fakt ... Tylko czy w domu (normalnym) ktos ma 3 fazy? Zazwyczaj jest
jedna...ten problem chyba mozemy sobie zostawic na pozniej...
Ja mam trzy ....
Zastanawialem sie nad 'bridge'em na inne fazy.
Powiniem wystarczyc kondensator sprzegajacy poszczegolne fazy (oj duze
to bedzie ;-)), a '0' i tak jest wspolne.
Przynajmniej my tak robimy w naszych urzadzeniach (co prawda na jedna
'faze' 24V~) i dziala bez problemow o ile nie ma za duzo rozgalezien.
4. Jezyk programowania 'obrazkowy' tzn. dla klockow inteligentnych
ukladamy program jezykiem obrazkowym zrozumialym dla (nie ujmujac nic
przyszlym uzytkownikom) idiotow - byle umieli poruszac myszka ;-)).
Robimy to na PC, ten to 'prekompiluje' i przesyla do odpowiedniego
(nich) klockow.
Dokladnie - PC'et tylko do "przyrzadzania przepisu" (aczkolwiek w mojej
koncepcji PC'et przesylal prekompilowane dane do MasterController'a, a
nie bezposrednio do klockow - lokalnym RS'em, bez potrzeby obciazania
sieci - bo przeslanie tak duzej ilosci danych jakim bedzie program dla
kazdego klocka, troche "przyblokuje siec")
Ale robisz to rzadko, tylko gdy konfigurujesz siec (i tak nie dziala -
mozna przesylac bez obaw o zatkanie), lub gdy ja troche
rekonfigurujesz (zazwyczaj malo danych - nie powinno zaklocac).
Tak na prawde duzy ruch to bedzisz generowal wlasnie wtedy gdy bedzie
Master, ktory bedzie zbieral wszystkie dane i odsylal rozkazy do
wykonania. Jego pad to koniec dzialania sieci.
Gdy zastosujesz inteligencje rozproszona, to ruch jest mniejszy, a
niezawodnosc wieksza. Latwiej tez robic rekonfiguracje, bo w PC
definiujesz sobie jakies lokalne centrum decyzyjne (czyli inteligentny
klocek) np. 'PIEC C.O.' i do niego ukladasz program korzystajac ze
wszystkich zasobow sieci - czujnikow, ukl. wykonawczych itd. Takie
lokalne centrum dziala niezaleznie od innych , choc rozne centra moga
miec wspolne zasoby (np. czujniki)
6. Numeracja urzadzen w sieci. Daloby sie zrobic, zeby PC rozpoznawal
wszystkie urzadzenia i nadawal im numery w trakcie pierwszej
konfiguracji (lub pozniejszej rekonfoguracji) systemu.
A mnie sie marzy dynamiczny numer urzadzenia - po wlaczeniu do gniazdka,
urzadzenie zglasza swoja obecnosc w sieci i zostaje mu przydzielony
adres, od tego momentu urzadzenie jest identyfikowane z tym adresem -
ale wtedy zarzadca sieci musi caly czas "czuwac" i reagowac na
pojawienie sie nowego urzadzenia (lub wypadniecie starego).
Tak, to mozna zrobic-to nawet jest zalecane, tylko trzeba to zrobic w
inteligentny sposb - zeby nie przydzielic przypadkowo adresu juz
istniejacego, zeby latwo zidentyfikowac nowe urzadzenia w sieci i zeby
niezawodnie nadac numer kazdemu z nich z osobna, a nie wszystkim taki
sam, gdy jest ich wiecej ;-)
Jezeli w PC bylaby baza informacji o elementach sieci (a musi byc), to
zadanie jest stosunkowo proste.
ad.1. Nie mozna czynic PC glownym masterem, to obniza niezawodnosc i
elastycznosc systemu. Wymaga stosowania podtrzymania zasilania i
dodania watchdoga dla prawidlowej pracy systemu.
Dlatego ja sklanialem sie w kierunku MasterController'a, ktory bylby
"ladowany" odpowiednio przekompilowanymi danymi (z postaci obrazkowej,
czytelnej dla uzytkownika, na odp. polecenia rozkazy, czasy wlaczen
itp...), a jednoczesnie mialby watchdoga i inne rodzaje zabezpieczen -
on "madry", klocki "glupie" :-)))
A ja jednak rodzielibym ta inteligencje na klocki ;-))) z powodow jak
wyzej.
Zarzadzanie rozproszone w ramach realizacji konkretnych zadan - to
jest chyba prawidlowy kierunek naszego dzialania.
PC tylko jako 'programator'.
A co z Master Controllerem? Gdzie wobec tego miejsce na "sceny",
tygodniowe programy, etc, etc?.... To wszystko w "klockach" ? - mam
wrazenie ze koncepcja z "inteligencja rozproszona" jest duzo trudniejsza
do realizacji niz "scentralizowana" - i program w kazdym klocku i progam
w PC'cie realizujacy "zdalne przeprogramowywanie" bedzie bardziej
skomplikowany...Ale nie chce tu wystepowac jako "negujacy wszystko"
-)))) Moze macie racje, tylko jakos ja sie nie moge do tego
przekonac... (widocznie z trudne dla mnie ;-))))
Mysle, ze to da sie zrobic niewiele wiekszym nakladem pracy.
<snip>
Wlasnie nad tym mysle :-))) Wymysliles juz cos moze? Jak dla mnie to
mam zamiar skoncentrowac sie na minimalizacji samego ukladu
elektronicznego (SMD, dwustronny druk, etc), a trafa zostawic takie
jakie sa.... I tak sie powinno zmiescic....Gorzej, ze brak przewodu
zerowego w kontakcie (od swiatla) ....pozostaje zatem kucie :-))) i
Tu Cie nie rozumiem, masz w kontakcie miedzyfazowe 380V~ ?
ad 5. Zaleta jest stabilnosc takiego rozwiazania. Nawet jezeli uklad
sie na chwile powiesi (od czego watchdog) to nie ma szans (OK, sa, ale
b. male) na zmiane zawartosci programu. Mozna go przerwac w dowolnej
chwili (zanik zasilania) i wznowic bez obawy o przypadkowa zmiane
zawartosci programu. Dodatkowo taki sterownik nie musi nawet posiadac
ukladu wykrywajacego zanik zasilania, zeby sie ratowac -> nizszy koszt
sterownika.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez mala
dziurke w obudowie....Zawsze mozna by klocek przywrocic do dzialania
"recznie" (szczegolnie jesli chodzi o "wbudowane" w sciane urzadzenia,
gdzie nie mozna wylaczyc zasilania, no chyba zeby cala instalacje
wylaczyc)
Eeee klawisz reset ? To nieprofesjonalne ;-)))
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
E-mail cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
WWW http://www.amart.com.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Thu, 09 Apr 1998 20:10:21 +0200
Jaroslaw Cichorski Jr. wrote:
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
Co masz na mysli mowiac "o wiekszych mozliwosciach i pamieci" -
wiekszych niz taki np. Atmelek (2k ROM) ? Czy bedzie on "w sam raz"
?
(jak dla mnie to w sam raz - i tani, i maly)
To wyjdzie w praniu. Wydaje sie, ze 2051 + zewnetrzny EEPROM do
podtrzymywania kodu makroinstrukcji wystarczy.
Do prostszych klockow wystarczy nawet jakis maly PIC.
No to w tym punkcie jestesmy zgodni: AT89C2051 lub PIC.
A wlasciwie to do jakich celow chcialbys uzyc tych
superinteligentnych
klockow? Ja mialem koncepcje tego typu, ze uC + modem stanowilyby
tylko
interfejs do zdalnego sterowania, a o inteligencji jako takiej raczej
nie bylo mowy - to PC (czy MC) mialy "myslec ktorym klockiem jak
sterowac...
No ale, zeby uniezaleznic wszystko od PC to proponowalem, aby PC
sluzyl do konfiguracji sieci i ukladania programow, a te po
'skompilowaniu' bylyby wykonywana w postaci makroinstrukcji przez
'superinteligentne' klocki.
Dlatego w kazdym takim klocku potrzebny jest interpreter
makroinstrukcji oraz pamiec na nie (EEPROM).
Dla mnie to prawie to samo co z Master Controllerem - czy on nie jest
takim wlasnie superinteligentnym klockiem? , bo o tym ze nie ma co
uzywac PC'ta do zarzadzania sieciato juz wczesniej pisalem.
Czyli prawie, ze jestesmy zgodni tutaj..;-)))
<snip>
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
Tak...tylko mnie jedna rzecz zastanawia - te superklocki, to chyba
musialyby byc uniwersalne, nie przywiazane do konkretnego urzadzenia?
3. Transmisja dwukierunkowa, szeregowa, od 1200 do 2400 bps,
potwierdzenie tylko wtedy, gdy sobie tego zazyczymy - opcja
oczekiwania na potwierdzenie zaimplementowana w protokole.
Nadawanie rozpoczynane jest gdy na linii jest cisza, w trakcie
nadawania podsluchujemy, gdy konflikt - przerywamy na losowy czas
(takie troche CSMA-CD).
Dokladnie...pozostaje do ustalenia ramka - jak bedzie wygladac, jaki
adres, jak dlugie pole danych, czy CRC? itd... (nad tym wlasnie
mysle)
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a nie
np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150, to
nie mozna "jawnie" puscic bajtu danych,
ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem" trafic
w 150.
Wowczas klocek myslalby, ze to poczatek pakietu i blad gotowy (tzn.
strata czasu, bo CRC i tak by sie nie zgodzilo, wiec musialaby byc
powtorka).
W tej sytuacji myslalem nad kodowaniem bajtu danych na dwoch bajtach
(kazdy o wartosci max. 0-127).
-adres odbiorcy (lub 'do wszytkich)',
Ja myslalem o dwoch adresach: najpierw adres odbiorcy, a potem adres
nadawcy (zeby bylo wiadomo komu odpowiedziec) - a przy "rozglaszaniu"
odp. zarezerwowany adres
-status (m.in. czy wymagane jest potwierdzenie, nie moze byc wymagane
gdy 'do wszystkich'),
-typ urzadzenia nadajacego,
-identyfikator nadawcy (adres),
-ilosc przesylanych bajtow,
-iles bajtow danych,
-CRC (8 bit starczy)
Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich koncepcji
inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz nie
-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie -
mozesz wtedy pociagnac pakiet o 200 bajtach np.
Byc moze cos jeszcze i byc moze w innej kolejnosci (zeby latwiej bylo
analizowac).
Mozliwe, ze np. typ urzadzenia nadajacego i status da sie polaczyc w
jeden bajt.
Ja bym typu urzadzenia nie okreslal - chyba ze tylko dwa rodzaje : glupi
i inteligentny, bo jesli chodzi Ci o jakies okreslanie rodzin, typow
klockow itp, to moze okazac sie ,ze z czasem ta ilosc przekroczy 256 i
co wtedy? :-)))
Ramka nie moze byc za dluga, bo nie starczy pamieci w kontrolerkach na
jej przygotowanie lub odebranie.
No wlasnie :-)))
Adresy chyba 1 bajtowe (a moze jednak 2)
Ja bym stawial na 2 bajtowe (rozwojowo :-)) , bo 256 (128?) urzadzen to
moze okazac siezbyt malo w jakims duzym mieszkaniu (3 pietrowej willi, z
garazem, przybudowka i diabli wiedza czym jeszcze) No i przy (moim)
zalozeniu, ze najstarszy bit we wszystkich bajtach oprocz naglowka jest
wyzerowany (wlasnie dla odroznienia ich od naglowka) to ilosc adresow
urzadzen spada na 128 , a to chyba ciut malo?...
Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu (cisza
na linii), pierwszy
bajt jaki sie na niej pojawi jest traktowany jako naglowek (niezaleznie
od jego wartosci), a reszta za nim to dalszy ciag pakietu... Wtedy
mozesz stosowac pelne bajty (0-255).
(Ciekawy jestem czy znowu tu sie podziela koncepcje ;-))))
Przesylanie glownie po sieci zasilania 220V - jedyny problem to
propagacja na rozne fazy.
No fakt ... Tylko czy w domu (normalnym) ktos ma 3 fazy? Zazwyczaj
jest
jedna...ten problem chyba mozemy sobie zostawic na pozniej...
Ja mam trzy ....
Zastanawialem sie nad 'bridge'em na inne fazy.
Powiniem wystarczyc kondensator sprzegajacy poszczegolne fazy (oj duze
to bedzie ;-)), a '0' i tak jest wspolne.
Przynajmniej my tak robimy w naszych urzadzeniach (co prawda na jedna
'faze' 24V~) i dziala bez problemow o ile nie ma za duzo rozgalezien.
Acha...a co jesliby zastosowac sprzezenie indukcyjne? (cos a'la TOKO?)
4. Jezyk programowania 'obrazkowy' tzn. dla klockow inteligentnych
ukladamy program jezykiem obrazkowym zrozumialym dla (nie ujmujac
nic
przyszlym uzytkownikom) idiotow - byle umieli poruszac myszka ;-)).
Robimy to na PC, ten to 'prekompiluje' i przesyla do odpowiedniego
(nich) klockow.
Dokladnie - PC'et tylko do "przyrzadzania przepisu" (aczkolwiek w
mojej
koncepcji PC'et przesylal prekompilowane dane do MasterController'a,
a
nie bezposrednio do klockow - lokalnym RS'em, bez potrzeby obciazania
sieci - bo przeslanie tak duzej ilosci danych jakim bedzie program
dla
kazdego klocka, troche "przyblokuje siec")
Ale robisz to rzadko, tylko gdy konfigurujesz siec (i tak nie dziala -
mozna przesylac bez obaw o zatkanie), lub gdy ja troche
rekonfigurujesz (zazwyczaj malo danych - nie powinno zaklocac).
Tak na prawde duzy ruch to bedzisz generowal wlasnie wtedy gdy bedzie
Master, ktory bedzie zbieral wszystkie dane i odsylal rozkazy do
wykonania. Jego pad to koniec dzialania sieci.
Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie i
tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub czesciowego
wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci -
starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja wysylam
tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore chcesz
przyblokowac).A pad sieci moze sie zdarzyc i taki, ze jakies urzadzenie
bedzie bez przerwy "siac" pakietami i wowczas wszystko lezy -
niezaleznie od tego czy jest sterowane centralnie czy autonomicznie.
Master Controller bedzie wlasnie tak pomyslany, zeby jego pad byl czyms
naprawde malo prawdopodobnym.
Gdy zastosujesz inteligencje rozproszona, to ruch jest mniejszy, a
niezawodnosc wieksza.
Ruch bedzie taki sam, tylko u Ciebie miedzy samymi klockami, u mnie
miedzy klockami i MC.Chyba, ze masz na mysli to ,ze klocki same
realizuja pewne programy, bez koniecznosci komunikowania sie z zarzadca
sieci - u mnie moze byc podobnie, tyle tylko, ze programy
beda zaimplementowane na stale (tzn. ze urzadzenie ma takie i takie
funkcje i wiecej nie potrzeba - np. telewizor ma 60 kanalow i wiecej nie
wymusisz)
Moje klocki nie beda takie zupelnie glupie - jesli chodzi o sterowanie
urzadzeniem do ktorego beda podlaczone, to beda wyposazone w odp.
inteligencje, nawet zestawy podprogramow, o parametrach ustawianych
zdalnie (np. zakres regulacji - od...do)
I tak i tak sprzet ogranicza uniwersalnosc dzialania klockow.
Latwiej tez robic rekonfiguracje, bo w PC
definiujesz sobie jakies lokalne centrum decyzyjne (czyli inteligentny
klocek) np. 'PIEC C.O.' i do niego ukladasz program korzystajac ze
wszystkich zasobow sieci - czujnikow, ukl. wykonawczych itd. Takie
lokalne centrum dziala niezaleznie od innych , choc rozne centra moga
miec wspolne zasoby (np. czujniki)
Ja tu nie widze zadnej roznicy - ja rowniez moge przypisac dowolnemu
urzadzeniu reakcje na dowolne inne urzadzenia - nawet mam latwiej, bo
wszystkie adresy klockow mam zapamietanew MC (a pamieci tam mam znacznie
wiecej niz w uC). - Ty musisz zapamietac adresy w swoim klocku, a on ma
tylko 128 bajtow RAM'u - chyba ze zapamietasz w EEPROM'ie...
ad.1. Nie mozna czynic PC glownym masterem, to obniza niezawodnosc
i
elastycznosc systemu. Wymaga stosowania podtrzymania zasilania i
dodania watchdoga dla prawidlowej pracy systemu.
Dlatego ja sklanialem sie w kierunku MasterController'a, ktory bylby
"ladowany" odpowiednio przekompilowanymi danymi (z postaci
obrazkowej,
czytelnej dla uzytkownika, na odp. polecenia rozkazy, czasy wlaczen
itp...), a jednoczesnie mialby watchdoga i inne rodzaje zabezpieczen
-
on "madry", klocki "glupie" :-)))
A ja jednak rodzielibym ta inteligencje na klocki ;-))) z powodow jak
wyzej.
A ja nie :-)))) z powodow rowniez jak wyzej :-))) Zreszta moje klocki
tez jak mowilem beda dosc inteligentne, tylko ze nie pod wzgledem
wzajemnej komunikacji (klocek z klockiem), a pod wzgledem podprogramow
"obslugujacych" dane urzadzenie.
Zarzadzanie rozproszone w ramach realizacji konkretnych zadan - to
jest chyba prawidlowy kierunek naszego dzialania.
PC tylko jako 'programator'.
A co z Master Controllerem? Gdzie wobec tego miejsce na "sceny",
tygodniowe programy, etc, etc?.... To wszystko w "klockach" ? - mam
wrazenie ze koncepcja z "inteligencja rozproszona" jest duzo
trudniejsza
do realizacji niz "scentralizowana" - i program w kazdym klocku i
progam
w PC'cie realizujacy "zdalne przeprogramowywanie" bedzie bardziej
skomplikowany...Ale nie chce tu wystepowac jako "negujacy wszystko"
-)))) Moze macie racje, tylko jakos ja sie nie moge do tego
przekonac... (widocznie z trudne dla mnie ;-))))
Mysle, ze to da sie zrobic niewiele wiekszym nakladem pracy.
Wszystko da sie zrobic....:-)))) Ciekawe tylko co sie sprawdzi :-)))
<snip>
Wlasnie nad tym mysle :-))) Wymysliles juz cos moze? Jak dla mnie
to
mam zamiar skoncentrowac sie na minimalizacji samego ukladu
elektronicznego (SMD, dwustronny druk, etc), a trafa zostawic takie
jakie sa.... I tak sie powinno zmiescic....Gorzej, ze brak przewodu
zerowego w kontakcie (od swiatla) ....pozostaje zatem kucie :-))) i
Tu Cie nie rozumiem, masz w kontakcie miedzyfazowe 380V~ ?
Chodzi o kontakt do wlaczania swiatla - dziala on na zasadzie "rozcietej
fazy" - zero do zyrandola idzie bezposrednio z puszki, wiec nie jest
dostepne w kontakcie.Kiedy wlaczasz swiatlo, to zwierasz "rozciecie" i w
kontakcie nie ma zadnego napiecia (tyle co masz spadku na stykach
wylacznika swiatla :-)))) Po prostu brak punktu odniesienia (zera)
Jak w tej sytuacji mozna np. przeslac dane po kablu (nie mowiac juz o
zasilaniu klocka)?
Jak sobie z tym radzisz Mariusz? ;-)))) (w X-10)
Teoretycznie mozna by umiescic sterownik w samym zyrandolu, tam gdzie
sie "schodza" oba przewody - faza i zero - tylko gdzie to zmiescisz?
(Musialby byc duuuzyy zyrandol :-)))
ad 5. Zaleta jest stabilnosc takiego rozwiazania. Nawet jezeli
uklad
sie na chwile powiesi (od czego watchdog) to nie ma szans (OK, sa,
ale
b. male) na zmiane zawartosci programu. Mozna go przerwac w
dowolnej
chwili (zanik zasilania) i wznowic bez obawy o przypadkowa zmiane
zawartosci programu. Dodatkowo taki sterownik nie musi nawet
posiadac
ukladu wykrywajacego zanik zasilania, zeby sie ratowac -> nizszy
koszt
sterownika.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez
mala
dziurke w obudowie....Zawsze mozna by klocek przywrocic do dzialania
"recznie" (szczegolnie jesli chodzi o "wbudowane" w sciane
urzadzenia,
gdzie nie mozna wylaczyc zasilania, no chyba zeby cala instalacje
wylaczyc)
Eeee klawisz reset ? To nieprofesjonalne ;-)))
Powiedz to producentom komputerow osobistych, notatnikow
elektronicznych, etc... :-)))
Jacek.
From: "Jaroslaw Lis" <lis_at_nospam_papuga.ict.pwr.wroc.pl>
Subject: Re: Home Automation - opis c.d.
Date: 9 Apr 1998 20:18:34 GMT
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
Jaroslaw Cichorski Jr. wrote:
To wyjdzie w praniu. Wydaje sie, ze 2051 + zewnetrzny EEPROM do
podtrzymywania kodu makroinstrukcji wystarczy.
Do prostszych klockow wystarczy nawet jakis maly PIC.
No to w tym punkcie jestesmy zgodni: AT89C2051 lub PIC.
Przy PICu zachodzi pytanie: ktory?
Bo zdaje sie ze RS to one maja tylko software'owy.
P.S. Przyjmowane propozycje jedynie w rozsadnej cenie :-)
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
Tak...tylko mnie jedna rzecz zastanawia - te superklocki, to chyba
musialyby byc uniwersalne, nie przywiazane do konkretnego urzadzenia?
Uniwersalna to musialaby byc jedynie ich polowa - zeby kazdy z kazdym
mogl sie skomunikowac.
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a nie
np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150, to
nie mozna "jawnie" puscic bajtu danych,
ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem" trafic
w 150.
Wowczas klocek myslalby, ze to poczatek pakietu i blad gotowy (tzn.
strata czasu, bo CRC i tak by sie nie zgodzilo, wiec musialaby byc
powtorka).
Niekoniecznie - po odczytaniu naglowka probujemy czytac zadana [
potrzebne pole dlugosc] ilosc bajtow az do CRC. Jesli nie nadejda w
odpowiednim czasie - rozpoczynamy od czekania na naglowek.
W tej sytuacji myslalem nad kodowaniem bajtu danych na dwoch bajtach
(kazdy o wartosci max. 0-127).
8051 ma taki mily tryb, gdy wysyla sie 9bitowe znaki, i ten 9-ty bit
moze pelnic role naglowka. Jedynie on wywoluje przerwanie, a potem
kostka sprawdza czy pozostale 8 bitow to jej adres, jesli nie - to ignoruje
znaki ze zgaszonym 9-tym bitem.
Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich koncepcji
inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz nie
-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie -
mozesz wtedy pociagnac pakiet o 200 bajtach np.
No coz - ustalenie MAKSYMALNEGO rozmiaru ramki ma swoj sens, ale
stalego - raczej nie.
Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu (cisza
na linii),
Taki czas spokoju generalnie warto co najmniej rozwazyc.
pierwszy
bajt jaki sie na niej pojawi jest traktowany jako naglowek (niezaleznie
od jego wartosci), a reszta za nim to dalszy ciag pakietu...
Wtedy nie potrzebujesz bajtu naglowka w ogole, bo i po co ?
Zastanawialem sie nad 'bridge'em na inne fazy.
Powiniem wystarczyc kondensator sprzegajacy poszczegolne fazy (oj duze
to bedzie ;-)), a '0' i tak jest wspolne.
Dlaczego duze? kondensator ma byc maly, zeby ta nosna prepuscil, a 50Hz
juz prawie nie. Nosna ma chyba z 50kHz?
Przynajmniej my tak robimy w naszych urzadzeniach (co prawda na jedna
'faze' 24V~) i dziala bez problemow o ile nie ma za duzo rozgalezien.
Acha...a co jesliby zastosowac sprzezenie indukcyjne? (cos a'la TOKO?)
pojemnosciowe chyba prosciej.
mozna przesylac bez obaw o zatkanie), lub gdy ja troche
rekonfigurujesz (zazwyczaj malo danych - nie powinno zaklocac).
Tak na prawde duzy ruch to bedzisz generowal wlasnie wtedy gdy bedzie
Master, ktory bedzie zbieral wszystkie dane i odsylal rozkazy do
wykonania. Jego pad to koniec dzialania sieci.
Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie i
tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub czesciowego
wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci -
starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja wysylam
tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore chcesz
przyblokowac).
No coz - rozsyla broadcastem haslo, a kiedys wczesniej kazdy klocek
mial zaprogramowane jak na podanie hasla reagowac.
Ja popieram idee centralnego MC.
Tu Cie nie rozumiem, masz w kontakcie miedzyfazowe 380V~ ?
Chodzi o kontakt do wlaczania swiatla - dziala on na zasadzie "rozcietej
fazy" - zero do zyrandola idzie bezposrednio z puszki, wiec nie jest
dostepne w kontakcie.Kiedy wlaczasz swiatlo, to zwierasz "rozciecie" i w
kontakcie nie ma zadnego napiecia (tyle co masz spadku na stykach
wylacznika swiatla :-)))) Po prostu brak punktu odniesienia (zera)
Jak w tej sytuacji mozna np. przeslac dane po kablu (nie mowiac juz o
zasilaniu klocka)?
Hm, teoretycznie mozna by zrobic dwuprzewodowa skrzynke, ktora w stanie
otwartym nie przepuszcza pradu wiecej niz 1mA [zyrandol nie zaswieci],
po zamknieciu spadek napiecia wynosi pare wolt, wiec da sie zasilic
uklady, a zyrandol 215 dostanie, i ma na tyle indukcyjnosci, ze
sygnal danych wychwyci. Tylko czy nie prosciej doprowadzic brakujacy
przewod?
Teoretycznie mozna by umiescic sterownik w samym zyrandolu, tam gdzie
sie "schodza" oba przewody - faza i zero - tylko gdzie to zmiescisz?
(Musialby byc duuuzyy zyrandol :-)))
Wiekszosc zyrandoli ma taki talerz przy suficie, ktory zaslania hak i
kostke. I miejsca tam zwykle wiecej niz w typowym wylaczniku.
J.
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Sun, 12 Apr 1998 15:24:50 +0200
Jaroslaw Lis wrote:
Jacek Domanski <jado_at_nospam_kki.net.pl> wrote:
Jaroslaw Cichorski Jr. wrote:
To wyjdzie w praniu. Wydaje sie, ze 2051 + zewnetrzny EEPROM do
podtrzymywania kodu makroinstrukcji wystarczy.
Do prostszych klockow wystarczy nawet jakis maly PIC.
No to w tym punkcie jestesmy zgodni: AT89C2051 lub PIC.
Przy PICu zachodzi pytanie: ktory?
Bo zdaje sie ze RS to one maja tylko software'owy.
Ja na PIC'ach tez sie nie znam :-)))) ale przy softwareowym
"wyprowadzaniu/wprowadzaniu"danych moze byc chyba dowolny? (ja mam
zamiar zastosowac Atmel'ka)
P.S. Przyjmowane propozycje jedynie w rozsadnej cenie :-)
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
Tak...tylko mnie jedna rzecz zastanawia - te superklocki, to chyba
musialyby byc uniwersalne, nie przywiazane do konkretnego
urzadzenia?
Uniwersalna to musialaby byc jedynie ich polowa - zeby kazdy z kazdym
mogl sie skomunikowac.
No to w takim razie owe "makroinstrukcje" odnosilyby sie tylko do sfery
komunikacji, a nie dowarstwy uzytkowej (uzaleznionej od funkcji)
klocka?
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a
nie
np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150,
to
nie mozna "jawnie" puscic bajtu danych,
ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem"
trafic
w 150.
Wowczas klocek myslalby, ze to poczatek pakietu i blad gotowy (tzn.
strata czasu, bo CRC i tak by sie nie zgodzilo, wiec musialaby byc
powtorka).
Niekoniecznie - po odczytaniu naglowka probujemy czytac zadana [
potrzebne pole dlugosc] ilosc bajtow az do CRC. Jesli nie nadejda w
odpowiednim czasie - rozpoczynamy od czekania na naglowek.
Ale marnujemy czas na czekanie.... :-(((
W tej sytuacji myslalem nad kodowaniem bajtu danych na dwoch bajtach
(kazdy o wartosci max. 0-127).
8051 ma taki mily tryb, gdy wysyla sie 9bitowe znaki, i ten 9-ty bit
moze pelnic role naglowka. Jedynie on wywoluje przerwanie, a potem
kostka sprawdza czy pozostale 8 bitow to jej adres, jesli nie - to
ignoruje
znaki ze zgaszonym 9-tym bitem.
Owszem...ma i myslelismy nad tym, ale ....co by bylo gdybys chcial
wpiac bezposrednio do sieci 220V PC'ta...on nie ma tego trybu...Czy nie
lepiej wiec nie uzalezniac sie od niestandardowych szczegolow
sprzetowych? Moze np. wejda PIC'e z RS'em? ale bez mechanizmu obslugi
wieloprocesorowego dostepu? :-))))
Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich
koncepcji
inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz
nie
-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie -
mozesz wtedy pociagnac pakiet o 200 bajtach np.
No coz - ustalenie MAKSYMALNEGO rozmiaru ramki ma swoj sens, ale
stalego - raczej nie.
Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu
(cisza
na linii),
Taki czas spokoju generalnie warto co najmniej rozwazyc.
pierwszy
bajt jaki sie na niej pojawi jest traktowany jako naglowek
(niezaleznie
od jego wartosci), a reszta za nim to dalszy ciag pakietu...
Wtedy nie potrzebujesz bajtu naglowka w ogole, bo i po co ?
No wlasnie...to moze zrezygnowac z naglowka? :-)))) A zastapic go
jakims bajtem statusu np.?
Zastanawialem sie nad 'bridge'em na inne fazy.
Powiniem wystarczyc kondensator sprzegajacy poszczegolne fazy (oj
duze
to bedzie ;-)), a '0' i tak jest wspolne.
Dlaczego duze? kondensator ma byc maly, zeby ta nosna prepuscil, a
50Hz
juz prawie nie. Nosna ma chyba z 50kHz?
Nosna ma 125-140kHz w zaleznosci od kwarcu (w TDA5051) -taka jest
zreszta norma europejska na te zastosowania (HomeAutomation)
mozna przesylac bez obaw o zatkanie), lub gdy ja troche
rekonfigurujesz (zazwyczaj malo danych - nie powinno zaklocac).
Tak na prawde duzy ruch to bedzisz generowal wlasnie wtedy gdy
bedzie
Master, ktory bedzie zbieral wszystkie dane i odsylal rozkazy do
wykonania. Jego pad to koniec dzialania sieci.
Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie
i
tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub
czesciowego
wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci
-
starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja
wysylam
tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore
chcesz
przyblokowac).
No coz - rozsyla broadcastem haslo, a kiedys wczesniej kazdy klocek
mial zaprogramowane jak na podanie hasla reagowac.
To do wszystkich, ale do czesci? No...ale nie lapmy sie za
slowka....:-))))
Ja popieram idee centralnego MC.
To dobrze... witaj w klubie :-)))) Kto jeszcze? :-))))
Tu Cie nie rozumiem, masz w kontakcie miedzyfazowe 380V~ ?
Chodzi o kontakt do wlaczania swiatla - dziala on na zasadzie
"rozcietej
fazy" - zero do zyrandola idzie bezposrednio z puszki, wiec nie jest
dostepne w kontakcie.Kiedy wlaczasz swiatlo, to zwierasz "rozciecie"
i w
kontakcie nie ma zadnego napiecia (tyle co masz spadku na stykach
wylacznika swiatla :-)))) Po prostu brak punktu odniesienia (zera)
Jak w tej sytuacji mozna np. przeslac dane po kablu (nie mowiac juz
o
zasilaniu klocka)?
Hm, teoretycznie mozna by zrobic dwuprzewodowa skrzynke, ktora w
stanie
otwartym nie przepuszcza pradu wiecej niz 1mA [zyrandol nie zaswieci],
po zamknieciu spadek napiecia wynosi pare wolt, wiec da sie zasilic
uklady, a zyrandol 215 dostanie, i ma na tyle indukcyjnosci, ze
sygnal danych wychwyci. Tylko czy nie prosciej doprowadzic brakujacy
przewod?
Otoz to....ale moze ktos "w przyplywie natchnienia" wykombinuje taki
uklad?W sumie warto bylo by to sprawdzic....
Teoretycznie mozna by umiescic sterownik w samym zyrandolu, tam
gdzie
sie "schodza" oba przewody - faza i zero - tylko gdzie to zmiescisz?
(Musialby byc duuuzyy zyrandol :-)))
Wiekszosc zyrandoli ma taki talerz przy suficie, ktory zaslania hak i
kostke. I miejsca tam zwykle wiecej niz w typowym wylaczniku.
Sam pisales, ze nie dasz rady dosiegnac :-)))) a gdzie miejsce na
sterowanie "reczne" swiatlem? Musialoby zostac na scianie (klawiaturka
+modem sieci + mikroprocesor do obslugi transmisji, a drugie tyle w
zyrandolu do sterowania swiatlem...brrr...)
J.
Jacek.
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 10 Apr 1998 17:01:26 GMT
Thu, 09 Apr 1998 20:10:21 +0200, Jacek Domanski <jado_at_nospam_kki.net.pl>
napisał(a):
<snip>
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
Tak...tylko mnie jedna rzecz zastanawia - te superklocki, to chyba
musialyby byc uniwersalne, nie przywiazane do konkretnego urzadzenia?
Nie, tylko interpreter ma być uniwersalny na tyle by mógł być używany
w różnych sprzętowo kontrolerkach. A sterowniki uniwersalne to inna
historia. Już pisałem, że są prawie niezbędne. Chyba, że ktoś ma za
dużo pieniędzy albo zbyt mało podpiętych urządzeń. Moja koncepcja
zakłada, że jest podłączone każde urządzenie elektryczne, więc sam
wiesz...
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a nie
np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150, to
nie mozna "jawnie" puscic bajtu danych,
ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem" trafic
w 150.
W zasadzie nie musi być wiadomo, że mamy do czynienia z nagłówkiem
paczki. Cała paczka po skonfrontowaniu z jednym polem CRC zostanie
uznana za prawidłową, albo nie. Jeśli nie to treści się nie analizuje.
-status (m.in. czy wymagane jest potwierdzenie, nie moze byc wymagane
gdy 'do wszystkich'),
-typ urzadzenia nadajacego,
-identyfikator nadawcy (adres),
-ilosc przesylanych bajtow,
-iles bajtow danych,
-CRC (8 bit starczy)
Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich koncepcji
inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz nie
-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie -
mozesz wtedy pociagnac pakiet o 200 bajtach np.
ten nagłówek-paczka poprzedzające dane też ma jakieś CRC
Ramka nie moze byc za dluga, bo nie starczy pamieci w kontrolerkach na
jej przygotowanie lub odebranie.
No wlasnie :-)))
A to już kwestia konkretnej aplikacji. Jednym wystarczą krótkie
informacje a innym trzeba przesyłać rasowe dane. A może DWIE
magistrale transmisyjne ? A przynajmniej programowe rozróżnienie
umożliwiające wprowadzenie jej w przyszłości. To jest myśl...
Adresy chyba 1 bajtowe (a moze jednak 2)
Ja bym stawial na 2 bajtowe (rozwojowo :-)) , bo 256 (128?) urzadzen to
moze okazac siezbyt malo w jakims duzym mieszkaniu (3 pietrowej willi, z
garazem, przybudowka i diabli wiedza czym jeszcze) No i przy (moim)
zalozeniu, ze najstarszy bit we wszystkich bajtach oprocz naglowka jest
wyzerowany (wlasnie dla odroznienia ich od naglowka) to ilosc adresow
urzadzen spada na 128 , a to chyba ciut malo?...
Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu (cisza
na linii), pierwszy
bajt jaki sie na niej pojawi jest traktowany jako naglowek (niezaleznie
od jego wartosci), a reszta za nim to dalszy ciag pakietu... Wtedy
mozesz stosowac pelne bajty (0-255).
(Ciekawy jestem czy znowu tu sie podziela koncepcje ;-))))
Tu nie ma co kombinować. Sensowny obszar adresowy to 64 bity.
Śmieszne, ale prawdziwe...
Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie i
tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub czesciowego
wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci -
starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja wysylam
tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore chcesz
przyblokowac).A pad sieci moze sie zdarzyc i taki, ze jakies urzadzenie
bedzie bez przerwy "siac" pakietami i wowczas wszystko lezy -
niezaleznie od tego czy jest sterowane centralnie czy autonomicznie.
Master Controller bedzie wlasnie tak pomyslany, zeby jego pad byl czyms
naprawde malo prawdopodobnym.
A właściwie co osiągniesz wyłączając MC ? To nie chodzi o bajery tylko
o SENS. W/g mnie centralne sterowanie w sieci tego rodzaju nic nie
daje. Można to robić lokalnie w sensie zastosowania.
Gdy zastosujesz inteligencje rozproszona, to ruch jest mniejszy, a
niezawodnosc wieksza.
Ruch bedzie taki sam, tylko u Ciebie miedzy samymi klockami, u mnie
miedzy klockami i MC.
Chodzi o to, że zamiast przesyłania do urządzenia docelowego klocek
przesyła do MC a MC do urządzenia docelowego. Znacznie lepiej w razie
potrzeby postawić pięć dodatkowych sterowników MC dla konkretnych
potrzeb niż jeden do wszystkiego i na dodatek na zapas. Póki co nie
wiemy w ogóle do czego nam potrzebny jakikolwiek MC. I nie dowiemy się
póki nie zaczniemy mówić o zastosowaniach. Tyle, że ja już to
rozważałem i uznałem, że na pewno nie jeden wyróżniony MC tylko kilka
i to nie klasycznych MC a zwykłych kontrolerków, które zechciały np.
zająć się jakimś zadaniem w roli koordynatora.
Chyba, ze masz na mysli to ,ze klocki same
realizuja pewne programy, bez koniecznosci komunikowania sie z zarzadca
sieci - u mnie moze byc podobnie, tyle tylko, ze programy
beda zaimplementowane na stale (tzn. ze urzadzenie ma takie i takie
funkcje i wiecej nie potrzeba - np. telewizor ma 60 kanalow i wiecej nie
wymusisz)
Moje klocki nie beda takie zupelnie glupie - jesli chodzi o sterowanie
urzadzeniem do ktorego beda podlaczone, to beda wyposazone w odp.
inteligencje, nawet zestawy podprogramow, o parametrach ustawianych
zdalnie (np. zakres regulacji - od...do)
I tak i tak sprzet ogranicza uniwersalnosc dzialania klockow.
Sprzęt decyduje a nie ogranicza. Trudno robisz jednakowe sterowniki do
różnych celów. Z tego wyniika ich odmienna inteligencja i odmienne
sterowania. Przekonanie sprzętowego w końcu MC aby znał sposoby
komunikacji z każdym jest MZ mało potrzebne i trudne do zrealizowania.
Kiedy dostaniemy jakiś nowy klocek znowu czeka nas przeprogramowanie
MC.
Latwiej tez robic rekonfiguracje, bo w PC
definiujesz sobie jakies lokalne centrum decyzyjne (czyli inteligentny
klocek) np. 'PIEC C.O.' i do niego ukladasz program korzystajac ze
wszystkich zasobow sieci - czujnikow, ukl. wykonawczych itd. Takie
lokalne centrum dziala niezaleznie od innych , choc rozne centra moga
miec wspolne zasoby (np. czujniki)
Ja tu nie widze zadnej roznicy - ja rowniez moge przypisac dowolnemu
urzadzeniu reakcje na dowolne inne urzadzenia - nawet mam latwiej, bo
wszystkie adresy klockow mam zapamietanew MC (a pamieci tam mam znacznie
wiecej niz w uC). - Ty musisz zapamietac adresy w swoim klocku, a on ma
tylko 128 bajtow RAM'u - chyba ze zapamietasz w EEPROM'ie...
...ale kilku istotnych dla działania a nie wszystkich. Nawet 8B (64b)
adresy dadzą się upchać pod warunkiem, że klocek jest specjalizowany.
Jak zresztą pisano umożliwienie rozproszenia nie wyklucza możliwości
postawienia MC. Nie ma jednak sensu tego eksponować zbytnio. Być może
w jednym przypadku warto postawić taki MC a w innych nie.
A ja jednak rodzielibym ta inteligencje na klocki ;-))) z powodow jak
wyzej.
A ja nie :-)))) z powodow rowniez jak wyzej :-))) Zreszta moje klocki
tez jak mowilem beda dosc inteligentne, tylko ze nie pod wzgledem
wzajemnej komunikacji (klocek z klockiem), a pod wzgledem podprogramow
"obslugujacych" dane urzadzenie.
To może opisz jakiś klocek wymagający poważniejszej inteligencji w
postaci programu. Mnie się widzi, że sam klocek nie musi posiadać
praktycznie żadnej intelignecji. Dopiero kilka połączonych klocków
musi ze sobą współpracować i reagować na zdarzenia.
Eeee klawisz reset ? To nieprofesjonalne ;-)))
Powiedz to producentom komputerow osobistych, notatnikow
elektronicznych, etc... :-)))
To mimo wszystko dość inteligentne urządzenia potencjalnie zawierające
jakieś błędy oprogramowania i wymagające resetu sprzętowego.
From: Jacek Domanski <jado_at_nospam_kki.net.pl>
Subject: Re: Home Automation - opis c.d.
Date: Sun, 12 Apr 1998 15:25:16 +0200
--------------E51A036D1B0535C17A893C2D
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Bonik Kujany wrote:
Thu, 09 Apr 1998 20:10:21 +0200, Jacek Domanski <jado_at_nospam_kki.net.pl>
napisał(a):
Dlugo nad tym nie myslalem, ale jakos tak:
-naglowek,
No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a
nie
np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150,
to
nie mozna "jawnie" puscic bajtu danych,
ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem"
trafic
w 150.
W zasadzie nie musi być wiadomo, że mamy do czynienia z nagłówkiem
paczki. Cała paczka po skonfrontowaniu z jednym polem CRC zostanie
uznana za prawidłową, albo nie. Jeśli nie to treści się nie analizuje.
Tak..CRC, tylko trzeba wiedziec, ktory bajt jest wlasnie tym CRC...Jak
nie trafisz z odbiorem, to mozna wziac za CRC zupelnie inny bajt (np.
danych) i oczywiscie wowczas CRC sie nie zgodzi - wiec powtorka i strata
czasu.
-status (m.in. czy wymagane jest potwierdzenie, nie moze byc
wymagane
gdy 'do wszystkich'),
-typ urzadzenia nadajacego,
-identyfikator nadawcy (adres),
-ilosc przesylanych bajtow,
-iles bajtow danych,
-CRC (8 bit starczy)
Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich koncepcji
inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz nie
-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie -
mozesz wtedy pociagnac pakiet o 200 bajtach np.
ten nagłówek-paczka poprzedzające dane też ma jakieś CRC
Owszem, ale zakladamy, ze owo CRC bedzie bajtem na samym koncu pakietu,
tak? Jesli wiec nastapi przeklamanie w bajcie okreslajacym dlugosc
pakietu i zamiast powiedzmy 16 bajtow w pakiecie, uznamy ze powinien on
miec np. 50 bajtow, to za bajt zawierajacy CRC wezmiemy bajt 50 a nie 16
- oczywiscie CRC sie nie zgodzi, wiec powtorka, ale po cholere ciagnac
te 50 bajtow - strata czasu, blokada sieci, etc, etc...
Ramka nie moze byc za dluga, bo nie starczy pamieci w kontrolerkach
na
jej przygotowanie lub odebranie.
No wlasnie :-)))
A to już kwestia konkretnej aplikacji. Jednym wystarczą krótkie
informacje a innym trzeba przesyłać rasowe dane. A może DWIE
magistrale transmisyjne ? A przynajmniej programowe rozróżnienie
umożliwiające wprowadzenie jej w przyszłości. To jest myśl...
Szczerze mowiac, to myslalem nad kilkoma rodzajami protokolow, kazdy
przystosowany do innego rodzaju nosnika transmisji (chodzi mi w tej
chwili o odpornosc na zaklocenia - przy kablu, ilosc bledow bedzie
znacznie mniejsza niz np. przy transmisji radiowej - wobec tego nie
potrzeba stosowac az tak bardzo wyszukanych protokolow jak w przypadku
RF, gdzie bez przerwy beda zaklocenia, powtorki) Podobnie tez rzecz ma
sie jesli chodzi o szybkosc transmisji - przy kablu mozesz pociagnac
znacznie szybciej niz przy PL, IRED lub RF.Tak wiec nie wiem czy nie
byloby dobrze opracowac moduly "tlumaczace" czy tez integrujace
rozne protokoly specjalizowane do jednego podstawowego protokolu
puszczonego np. kablem.
W ten sposob mamy jakby kilka MC z ktorych kazdy zarzadza swoim
"kawalkiem" sieci (a jednoczesnie odrebnym nosnikiem) a wzajemnie
polaczone sa one na wyzszym poziomie - kablem
Taka hierrarchiczna struktura: na samym szczycie mamy PC, potem sa MC, a
potem juz poszczegolne klocki.
Adresy chyba 1 bajtowe (a moze jednak 2)
Ja bym stawial na 2 bajtowe (rozwojowo :-)) , bo 256 (128?) urzadzen
to
moze okazac siezbyt malo w jakims duzym mieszkaniu (3 pietrowej
willi, z
garazem, przybudowka i diabli wiedza czym jeszcze) No i przy (moim)
zalozeniu, ze najstarszy bit we wszystkich bajtach oprocz naglowka
jest
wyzerowany (wlasnie dla odroznienia ich od naglowka) to ilosc adresow
urzadzen spada na 128 , a to chyba ciut malo?...
Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu
(cisza
na linii), pierwszy
bajt jaki sie na niej pojawi jest traktowany jako naglowek
(niezaleznie
od jego wartosci), a reszta za nim to dalszy ciag pakietu... Wtedy
mozesz stosowac pelne bajty (0-255).
(Ciekawy jestem czy znowu tu sie podziela koncepcje ;-))))
Tu nie ma co kombinować. Sensowny obszar adresowy to 64 bity.
Śmieszne, ale prawdziwe...
Osiem bajtow na jeden adres? fiu, fiu.... To dla adresu nadawcy i
odbiorcy w jednym pakiecie potrzebujemy 16 bajtow...Ale mysle, ze mozna
byloby to zrealizowac ciut inaczej, przy zalozeniu hierrarchicznej
struktury sieci. Popatrz: na "samym dole", gdzie mamy te najprostsze
klocki, adresy sa powiedzmy dwubajtowe, ale juz o stopien wyzej, na
poziomie MC aby zaadresowac pojedynczy klocek potrzebujemy: adres MC
plus adres klocka - czyli adresy nam sie sumuja
(address=MCaddress+group+deviceID) - tak wiec ilosc bitow potrzebnych na
adres rosnie wraz z hierarchia - im "wyzej" znajduje sie urzadzenie
adresujace, tym wiecej bitow potrzebuje aby zaadresowac pojedynczy
klocek "z dolu".
Z tym, ze na wyzszych poziomach komunikacji moga istniec inne protokoly
transmisji.
Ale, to oczywiscie sa rozwazania czysto teoretyczne w tej chwili -
musimy zaczac od samego dolu, a potem zawsze mozemy "dobudowac" wyzsze
poziomy.
Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie i
tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub
czesciowego
wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci
-
starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja
wysylam
tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore
chcesz
przyblokowac).A pad sieci moze sie zdarzyc i taki, ze jakies
urzadzenie
bedzie bez przerwy "siac" pakietami i wowczas wszystko lezy -
niezaleznie od tego czy jest sterowane centralnie czy autonomicznie.
Master Controller bedzie wlasnie tak pomyslany, zeby jego pad byl
czyms
naprawde malo prawdopodobnym.
A właściwie co osiągniesz wyłączając MC ? To nie chodzi o bajery tylko
o SENS. W/g mnie centralne sterowanie w sieci tego rodzaju nic nie
daje. Można to robić lokalnie w sensie zastosowania.
Zastosowanie MC daje nam to, ze mozesz kazdy klocek maksymalnie uproscic
- jego inteligencja bedzie minimalna, bo caloscia "wiedzy" bedzie
zawiadywal MC.Wtedy mozna zastosowac bardzo prosty uklad uC (np. 2051),
a co za tym idzie tani i maly.
Jesli klocki beda tanie, to mozesz ich "napchac" w domu tyle ile Ci sie
podoba, wmontowywac do kazdego urzadzenia itd..itp...
Robisz TYLKO JEDEN drogi i skomplikowany MasterController i masz spokoj.
Sorry, ale wydaje mi sie, ze nie uda Wam sie "upchnac" tych protokolow o
ktorych mowilisie
(inteligencja rozproszona, ladowanie programow do klockow, etc...) plus
programow uzytkowych do malego Atmel'ka...
Gdy zastosujesz inteligencje rozproszona, to ruch jest mniejszy, a
niezawodnosc wieksza.
Ruch bedzie taki sam, tylko u Ciebie miedzy samymi klockami, u mnie
miedzy klockami i MC.
Chyba, ze masz na mysli to ,ze klocki same
realizuja pewne programy, bez koniecznosci komunikowania sie z
zarzadca
sieci - u mnie moze byc podobnie, tyle tylko, ze programy
beda zaimplementowane na stale (tzn. ze urzadzenie ma takie i takie
funkcje i wiecej nie potrzeba - np. telewizor ma 60 kanalow i wiecej
nie
wymusisz)
Moje klocki nie beda takie zupelnie glupie - jesli chodzi o
sterowanie
urzadzeniem do ktorego beda podlaczone, to beda wyposazone w odp.
inteligencje, nawet zestawy podprogramow, o parametrach ustawianych
zdalnie (np. zakres regulacji - od...do)
I tak i tak sprzet ogranicza uniwersalnosc dzialania klockow.
Sprzęt decyduje a nie ogranicza. Trudno robisz jednakowe sterowniki do
różnych celów. Z tego wyniika ich odmienna inteligencja i odmienne
sterowania. Przekonanie sprzętowego w końcu MC aby znał sposoby
komunikacji z każdym jest MZ mało potrzebne i trudne do zrealizowania.
Niekoniecznie MC musi spelniac role posrednika pomiedzy klockami - czesc
z klockow bedzie sie komunikowala tylko z MC, a on w/g danych
otrzymanych uprzednio z PC'ta, bedzie nimi sterowal. (np. o okreslonej
godzinie wlaczal/wylaczal urzadzenie).
MC zna tylko adresy klockow, rozkazy i dane ktore ma przesylac do nich,
oraz sposoby reakcji
jednego klocka na drugi (lub wieksza ilosc) - wlasciwosci elektrycznych
urzadzen MC nie zna - te zna uzytkownik oraz PC'et w postaci programu
graficznego do obslugi sieci.
Uzytkownik obslugujac program PC'towy, widzi jakie sa wlasciwosci
urzadzenia, jak moze je programowac, co dane urzadzenie moze wykonac
itd... I robi to - na ekranie komputera.
PC'et nastepnie zamienia te wszystkie "ikonki, tabelki i jak to ma
jeszcze wygladac na ekranie", na ciag konkretnych rozkazow np. "o
godzinie 10.05 przeslij rozkaz 0efh, dane 04h i 47h, do klocka o adresie
1483h." lub tez " jesli pojawi sie rozkaz 95h z urzadzenia o adresie
2341h, to
przeslij rozkaz 34h do urzadzenia o adresie 0a589h" - koniec. MC "nie
wnika" w tresc rozkazow on tylko "rozdaje karty" - tasowaniem zas
zajmuje sie PC'et. :-)))
Znowu mamy tutaj "przenoszenie inteligencji" z wyzszego poziomu (tj.
PC'ta) na nizszy tj. MC.
Po stworzeniu nowego rodzaju klocka, uzytkownik "na ekranie" musi tylko
zdefiniowac jego
wlasciwosci (rozkazy na jakie reaguje i jak) oraz sposob sterowania jaki
sobie zalozyl - to dzieje sie wszystko na poziomie aplikacji uzytkownika
- pamieci w PC'cie mamy dosc, wiec dla nowych urzadzen nie zabraknie.
Wy, przy zalozeniu inteligencji rozproszonej chcecie ladowac te dane od
razu do konkretnych klockow - tak to rozumiem, a nie do posrednika jakim
jest MC.
Owszem, ale jak juz wyzej pisalem - czy to sie pomiesci w procesorkach
klockow?
Kiedy dostaniemy jakiś nowy klocek znowu czeka nas przeprogramowanie
MC.
Was tez czeka przeprogramowywanie klocka, bo nie mozecie "od razu"
wiedziec jakie on bedzie spelnial funkcje w systemie, jakie sa adresy
urzadzen itp. itd...
Latwiej tez robic rekonfiguracje, bo w PC
definiujesz sobie jakies lokalne centrum decyzyjne (czyli
inteligentny
klocek) np. 'PIEC C.O.' i do niego ukladasz program korzystajac ze
wszystkich zasobow sieci - czujnikow, ukl. wykonawczych itd. Takie
lokalne centrum dziala niezaleznie od innych , choc rozne centra
moga
miec wspolne zasoby (np. czujniki)
Ja tu nie widze zadnej roznicy - ja rowniez moge przypisac dowolnemu
urzadzeniu reakcje na dowolne inne urzadzenia - nawet mam latwiej, bo
wszystkie adresy klockow mam zapamietanew MC (a pamieci tam mam
znacznie
wiecej niz w uC). - Ty musisz zapamietac adresy w swoim klocku, a on
ma
tylko 128 bajtow RAM'u - chyba ze zapamietasz w EEPROM'ie...
...ale kilku istotnych dla działania a nie wszystkich. Nawet 8B (64b)
adresy dadzą się upchać pod warunkiem, że klocek jest specjalizowany.
Kilka moze Ci sie uda upchac, ale nie za wiele - ja mam wieksze
mozliwosci - wiecej pamieci.
Jak zresztą pisano umożliwienie rozproszenia nie wyklucza możliwości
postawienia MC. Nie ma jednak sensu tego eksponować zbytnio. Być może
w jednym przypadku warto postawić taki MC a w innych nie.
Moim zdaniem i tak bedziecie musieli postawic kilka "co bardziej
inteligentnych klockow", ktore w rzeczy samej beda odpowiednikami MC,
dla realizacji bardziej "wyrafinowanych" dzialan sieci (sceny, czasowe
dzialania, etc) - trudno przeciez w kazdym klocku realizowac
np.autonomiczna funkcje pomiaru czasu (godziny, dni, tygodnie nawet) - a
rozsylanie czasu po sieci, znowu sprowadza sie do wniosku: ktos musi ten
czas rozsylac - i bedzie to jakis inteligentniejszy klocek = MC :-))))
Jedyna roznica jaka tu widze, to taka, ze u mnie MC "totalnie" zarzadza
siecia i integruje wszystkie funkcje sterujace w jednym urzadzeniu
dzialajacym non stop (w odroznieniu od PC'ta, przygotowujacego tylko
dane jako kompilator), a u Was to samo "rozmyje sie" na kilka bardziej
inteligentniejszych i autonomicznych klockow. Ciekawym tylko jak
poradzicie sobie z "kompetencjami" poszczegolnych "superinteligentow"
;-))) - ktory za jaka czesc sieci bedzie odpowiadal... Bo chyba nie
chcecie do "kazdego najdrobniejszego nawet klocka" ladowac danych o
czasach wlaczen, reakcji na inne urzadzenia itp, itd...?
Chodzi o to, że zamiast przesyłania do urządzenia docelowego klocek
przesyła do MC a MC do urządzenia docelowego. Znacznie lepiej w razie
potrzeby postawić pięć dodatkowych sterowników MC dla konkretnych
potrzeb niż jeden do wszystkiego i na dodatek na zapas. Póki co nie
wiemy w ogóle do czego nam potrzebny jakikolwiek MC. I nie dowiemy się
póki nie zaczniemy mówić o zastosowaniach. Tyle, że ja już to
rozważałem i uznałem, że na pewno nie jeden wyróżniony MC tylko kilka
i to nie klasycznych MC a zwykłych kontrolerków, które zechciały np.
zająć się jakimś zadaniem w roli koordynatora.
No wlasnie... Czyli nie jeden a az piec MC :-)))) - jesli chodzi o
niezawodnosc tych urzadzen (odpornosc na zawieszenie, pad zasilania
itp..) Wy musicie "uzbroic je dodatkowo" 5 krotnie, ja tylko raz. Jakie
beda koszta tych operacji?
A ja jednak rodzielibym ta inteligencje na klocki ;-))) z powodow
jak
wyzej.
A ja nie :-)))) z powodow rowniez jak wyzej :-))) Zreszta moje klocki
tez jak mowilem beda dosc inteligentne, tylko ze nie pod wzgledem
wzajemnej komunikacji (klocek z klockiem), a pod wzgledem
podprogramow
"obslugujacych" dane urzadzenie.
To może opisz jakiś klocek wymagający poważniejszej inteligencji w
postaci programu. Mnie się widzi, że sam klocek nie musi posiadać
praktycznie żadnej intelignecji. Dopiero kilka połączonych klocków
musi ze sobą współpracować i reagować na zdarzenia.
Prosze bardzo...Wezmy dla przykladu klocek do pomiaru temperatury w
domu, sluzacy dodatkowo jako termometr pokojowy i ew. termostat dla
utrzymywania temperatury w pokoju na zadanym poziomie.Klocek taki musi
posiadac wyswietlacz (np. 4 cyfry LED), klawiaturke (np. 4 klawisze :
'+', '-', 'enter', 'select') oraz czujnik temperatury (np. w postaci
ukladu scalonego DS1621 Dallas'a).
Do obslugi w/w funkcji musimy miec w klocku procedurke multipleksowanego
wyswietlacza LED, takiejz klawiatury oraz I2C dla Dallas'a... dodatkowo
dochodza podprogramiki obslugi menu (programowanie temperatury)...i
jeszcze troche pomniejszych jak to zwykle bywa :-)))
(np. tablica konwersji kodow BCD na 7SEG - przy zalozeniu braku dekodera
7447)
To bylo oprogramowanie uzytkowe - sluzace realizacji podstawowych
funkcji klocka - pomiaru, wyswietlania i ustawiania temperatury w
pomieszczeniu.
Czyli klocek musi byc troche inteligentny, aby wszystko to nalezycie
obsluzyc..nie?
I do tego dochodza jeszcze procedury obslugi transmisji np. przez siec
220V...
Oczywiscie ten przyklad byl dla klocka, o dosyc skomplikowanych
funkcjach uzytkowych, aczkolwiek mozna wyobrazic sobie jeszcze bardziej
skomplikowane klocki (np. sterownik pralki automatycznej).
Dla klockow typu :"wlacz/wylacz" oczywiscie program uzytkowy bedzie
bardzo prosty.
Ale nie mozemy zakladac ze tylko takie typy prostych klockow bedziemy
budowac...
No i tyle tym razem...:-))))
Jacek.
--------------E51A036D1B0535C17A893C2D
Content-Type: multipart/related; boundary="------------7FD87DC59E46F35E2E9704E4"
--------------7FD87DC59E46F35E2E9704E4
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<HTML>
<BODY BACKGROUND="cid:part1.3530C0BA.AF733B34_at_nospam_kki.net.pl">
Bonik Kujany wrote:
<BLOCKQUOTE TYPE=CITE>Thu, 09 Apr 1998 20:10:21 +0200, Jacek Domanski <jado_at_nospam_kki.net.pl>
<BR>napisa³(a):
<BR>
<P>>> Dlugo nad tym nie myslalem, ale jakos tak:
<BR>>> -naglowek,
<BR>>
<BR>>No wlasnie - tutaj mamy ciekawostke - w jaki sposob bedzie wygladal
<BR>>naglowek i w jaki sposob bedzie wiadomo, ze to jest wlasnie on? (a
nie
<BR>>np. bajt danych).Jesliby mial to byc jakis bajt o np. wartosci 150,
to
<BR>>nie mozna "jawnie" puscic bajtu danych,
<BR>>ktory moze przeciez przyjac dowolna wartosc 0-255 i "przypadkiem"
trafic
<BR>>w 150.
<P>W zasadzie nie musi byæ wiadomo, ¿e mamy do czynienia z
nag³ówkiem
<BR>paczki. Ca³a paczka po skonfrontowaniu z jednym polem CRC zostanie
<BR>uznana za prawid³ow±, albo nie. Je¶li nie to tre¶ci
siê nie analizuje.</BLOCKQUOTE>
Tak..CRC, tylko trzeba wiedziec, ktory bajt jest wlasnie tym CRC...Jak
nie trafisz z odbiorem, to mozna wziac za CRC zupelnie inny bajt (np. danych)
i oczywiscie wowczas CRC sie nie zgodzi - wiec powtorka i strata czasu.
<BLOCKQUOTE TYPE=CITE>
<P>>
<BR>>> -status (m.in. czy wymagane jest potwierdzenie, nie moze byc wymagane
<BR>>> gdy 'do wszystkich'),
<BR>>> -typ urzadzenia nadajacego,
<BR>>> -identyfikator nadawcy (adres),
<BR>>> -ilosc przesylanych bajtow,
<BR>>> -iles bajtow danych,
<BR>>> -CRC (8 bit starczy)
<BR>>
<BR>>Ja bym ustawil ramke na stala dlugosc (oczywiscie dla moich koncepcji
<BR>>inteligencji scentralizowanej, to ma sens - dla Twojej pewnie juz
nie
<BR>>:-)))), bo musisz pchac programy...)A co bedzie jesli w momencie
<BR>>nadawania bajtu okreslajacego dlugosc ramki, nastapi przeklamanie
<BR>>mozesz wtedy pociagnac pakiet o 200 bajtach np.
<P>ten nag³ówek-paczka poprzedzaj±ce dane te¿
ma jakie¶ CRC</BLOCKQUOTE>
Owszem, ale zakladamy, ze owo CRC bedzie bajtem na samym koncu pakietu,
tak? Jesli wiec nastapi przeklamanie w bajcie okreslajacym dlugosc pakietu
i zamiast powiedzmy 16 bajtow w pakiecie, uznamy ze powinien on miec np.
50 bajtow, to za bajt zawierajacy CRC wezmiemy bajt 50 a nie 16 - oczywiscie
CRC sie nie zgodzi, wiec powtorka, ale po cholere ciagnac te 50 bajtow
- strata czasu, blokada sieci, etc, etc...
<BLOCKQUOTE TYPE=CITE>
<P>>
<BR>>>
<BR>>>
<BR>>> Ramka nie moze byc za dluga, bo nie starczy pamieci w kontrolerkach
na
<BR>>>
<BR>>> jej przygotowanie lub odebranie.
<BR>>
<BR>>No wlasnie :-)))
<P>A to ju¿ kwestia konkretnej aplikacji. Jednym wystarcz±
krótkie
<BR>informacje a innym trzeba przesy³aæ rasowe dane. A mo¿e
DWIE
<BR>magistrale transmisyjne ? A przynajmniej programowe rozró¿nienie
<BR>umo¿liwiaj±ce wprowadzenie jej w przysz³o¶ci.
To jest my¶l...</BLOCKQUOTE>
Szczerze mowiac, to myslalem nad kilkoma rodzajami protokolow, kazdy przystosowany
do innego rodzaju nosnika transmisji (chodzi mi w tej chwili o odpornosc
na zaklocenia - przy kablu, ilosc bledow bedzie znacznie mniejsza niz np.
przy transmisji radiowej - wobec tego nie potrzeba stosowac az tak bardzo
wyszukanych protokolow jak w przypadku RF, gdzie bez przerwy beda zaklocenia,
powtorki) Podobnie tez rzecz ma sie jesli chodzi o szybkosc transmisji
- przy kablu mozesz pociagnac znacznie szybciej niz przy PL, IRED lub RF.Tak
wiec nie wiem czy nie byloby dobrze opracowac moduly "tlumaczace" czy tez
integrujace
<BR>rozne protokoly specjalizowane do jednego podstawowego protokolu puszczonego
np. kablem.
<BR>W ten sposob mamy jakby kilka MC z ktorych kazdy zarzadza swoim "kawalkiem"
sieci (a jednoczesnie odrebnym nosnikiem) a wzajemnie polaczone sa one
na wyzszym poziomie - kablem
<BR>Taka hierrarchiczna struktura: na samym szczycie mamy PC, potem sa
MC, a potem juz poszczegolne klocki.
<BLOCKQUOTE TYPE=CITE>
<P>>
<BR>>>
<BR>>>
<BR>>> Adresy chyba 1 bajtowe (a moze jednak 2)
<BR>>
<BR>>Ja bym stawial na 2 bajtowe (rozwojowo :-)) , bo 256 (128?) urzadzen
to
<BR>>moze okazac siezbyt malo w jakims duzym mieszkaniu (3 pietrowej willi,
z
<BR>>garazem, przybudowka i diabli wiedza czym jeszcze) No i przy
(moim)
<BR>>zalozeniu, ze najstarszy bit we wszystkich bajtach oprocz naglowka
jest
<BR>>wyzerowany (wlasnie dla odroznienia ich od naglowka) to ilosc adresow
<BR>>urzadzen spada na 128 , a to chyba ciut malo?...
<BR>>Chyba, ze przyjmie sie koncepcje, ze po uplywie okreslonego czasu
(cisza
<BR>>na linii), pierwszy
<BR>>bajt jaki sie na niej pojawi jest traktowany jako naglowek (niezaleznie
<BR>>od jego wartosci), a reszta za nim to dalszy ciag pakietu... Wtedy
<BR>>mozesz stosowac pelne bajty (0-255).
<BR>>(Ciekawy jestem czy znowu tu sie podziela koncepcje ;-))))
<P>Tu nie ma co kombinowaæ. Sensowny obszar adresowy to 64 bity.
<BR>¦mieszne, ale prawdziwe...</BLOCKQUOTE>
Osiem bajtow na jeden adres? fiu, fiu.... To dla adresu nadawcy i
odbiorcy w jednym pakiecie potrzebujemy 16 bajtow...Ale mysle, ze mozna
byloby to zrealizowac ciut inaczej, przy zalozeniu hierrarchicznej struktury
sieci. Popatrz: na "samym dole", gdzie mamy te najprostsze klocki,
adresy sa powiedzmy dwubajtowe, ale juz o stopien wyzej, na poziomie MC
aby zaadresowac pojedynczy klocek potrzebujemy: adres MC plus adres klocka
- czyli adresy nam sie sumuja (address=MCaddress+group+deviceID) - tak
wiec ilosc bitow potrzebnych na adres rosnie wraz z hierarchia - im "wyzej"
znajduje sie urzadzenie adresujace, tym wiecej bitow potrzebuje aby zaadresowac
pojedynczy klocek "z dolu".
<BR>Z tym, ze na wyzszych poziomach komunikacji moga istniec inne protokoly
transmisji.
<BR>Ale, to oczywiscie sa rozwazania czysto teoretyczne w tej chwili -
musimy zaczac od samego dolu, a potem zawsze mozemy "dobudowac" wyzsze
poziomy.
<BLOCKQUOTE TYPE=CITE>
<P>>Sieci tak (tzn. brak automatycznego dzialania) - lokalne sterowanie
i
<BR>>tak zostaje - wtedy czujesz sie jak w zwyklym mieszkaniu - Ciekawym
<BR>>jednak jak zrealizujesz np. funkcje wlasnie "calkowitego lub czesciowego
<BR>>wylaczenia sieci" (np. w celu blokady dostepu do urzadzen dla dzieci
<BR>>starzy wychodza i blokuja co "niebezpieczniejsze urzadzenia") Ja wysylam
<BR>>tylko jeden rozkaz do Master Controller'a i mam spokoj - Ty musisz
<BR>>przeslac stosowne rozkazy do wszystkich klockow (lub tych ktore chcesz
<BR>>przyblokowac).A pad sieci moze sie zdarzyc i taki, ze jakies urzadzenie
<BR>>bedzie bez przerwy "siac" pakietami i wowczas wszystko lezy -
<BR>>niezaleznie od tego czy jest sterowane centralnie czy autonomicznie.
<BR>>Master Controller bedzie wlasnie tak pomyslany, zeby jego pad byl
czyms
<BR>>naprawde malo prawdopodobnym.
<P>A w³a¶ciwie co osi±gniesz wy³±czaj±c
MC ? To nie chodzi o bajery tylko
<BR>o SENS. W/g mnie centralne sterowanie w sieci tego rodzaju nic nie
<BR>daje. Mo¿na to robiæ lokalnie w sensie zastosowania.</BLOCKQUOTE>
Zastosowanie MC daje nam to, ze mozesz kazdy klocek maksymalnie uproscic
- jego inteligencja bedzie minimalna, bo caloscia "wiedzy" bedzie zawiadywal
MC.Wtedy mozna zastosowac bardzo prosty uklad uC (np. 2051), a co za tym
idzie tani i maly.
<BR>Jesli klocki beda tanie, to mozesz ich "napchac" w domu tyle ile Ci
sie podoba, wmontowywac do kazdego urzadzenia itd..itp...
<BR>Robisz TYLKO JEDEN drogi i skomplikowany MasterController i masz spokoj.
<BR>Sorry, ale wydaje mi sie, ze nie uda Wam sie "upchnac" tych protokolow
o ktorych mowilisie
<BR>(inteligencja rozproszona, ladowanie programow do klockow, etc...)
plus programow uzytkowych do malego Atmel'ka...
<BLOCKQUOTE TYPE=CITE>
<P>>
<BR>>> Gdy zastosujesz inteligencje rozproszona, to ruch jest mniejszy,
a
<BR>>> niezawodnosc wieksza.
<BR>>
<BR>>Ruch bedzie taki sam, tylko u Ciebie miedzy samymi klockami, u mnie
<BR>>miedzy klockami i MC.
<BR>
<BR>
<P>>Chyba, ze masz na mysli to ,ze klocki same
<BR>>realizuja pewne programy, bez koniecznosci komunikowania sie z zarzadca
<BR>>sieci - u mnie moze byc podobnie, tyle tylko, ze programy
<BR>>beda zaimplementowane na stale (tzn. ze urzadzenie ma takie i takie
<BR>>funkcje i wiecej nie potrzeba - np. telewizor ma 60 kanalow i wiecej
nie
<BR>>wymusisz)
<BR>>Moje klocki nie beda takie zupelnie glupie - jesli chodzi o sterowanie
<BR>>urzadzeniem do ktorego beda podlaczone, to beda wyposazone w odp.
<BR>>inteligencje, nawet zestawy podprogramow, o parametrach ustawianych
<BR>>zdalnie (np. zakres regulacji - od...do)
<BR>>I tak i tak sprzet ogranicza uniwersalnosc dzialania klockow.
<P>Sprzêt decyduje a nie ogranicza. Trudno robisz jednakowe sterowniki
do
<BR>ró¿nych celów. Z tego wyniika ich odmienna inteligencja
i odmienne
<BR>sterowania. Przekonanie sprzêtowego w koñcu MC aby zna³
sposoby
<BR>komunikacji z ka¿dym jest MZ ma³o potrzebne i trudne do
zrealizowania.</BLOCKQUOTE>
Niekoniecznie MC musi spelniac role posrednika pomiedzy klockami - czesc
z klockow bedzie sie komunikowala tylko z MC, a on w/g danych otrzymanych
uprzednio z PC'ta, bedzie nimi sterowal. (np. o okreslonej godzinie wlaczal/wylaczal
urzadzenie).
<BR>MC zna tylko adresy klockow, rozkazy i dane ktore ma przesylac do nich,
oraz sposoby reakcji
<BR>jednego klocka na drugi (lub wieksza ilosc) - wlasciwosci elektrycznych
urzadzen MC nie zna - te zna uzytkownik oraz PC'et w postaci programu graficznego
do obslugi sieci.
<BR>Uzytkownik obslugujac program PC'towy, widzi jakie sa wlasciwosci urzadzenia,
jak moze je programowac, co dane urzadzenie moze wykonac itd... I
robi to - na ekranie komputera.
<BR>PC'et nastepnie zamienia te wszystkie "ikonki, tabelki i jak to ma
jeszcze wygladac na ekranie", na ciag konkretnych rozkazow np. "o godzinie
10.05 przeslij rozkaz 0efh, dane 04h i 47h, do klocka o adresie 1483h."
lub tez " jesli pojawi sie rozkaz 95h z urzadzenia o adresie 2341h, to
<BR>przeslij rozkaz 34h do urzadzenia o adresie 0a589h" - koniec.
MC "nie wnika" w tresc rozkazow on tylko "rozdaje karty" - tasowaniem zas
zajmuje sie PC'et. :-)))
<BR>Znowu mamy tutaj "przenoszenie inteligencji" z wyzszego poziomu (tj.
PC'ta) na nizszy tj. MC.
<BR>Po stworzeniu nowego rodzaju klocka, uzytkownik "na ekranie" musi tylko
zdefiniowac jego
<BR>wlasciwosci (rozkazy na jakie reaguje i jak) oraz sposob sterowania
jaki sobie zalozyl - to dzieje sie wszystko na poziomie aplikacji uzytkownika
- pamieci w PC'cie mamy dosc, wiec dla nowych urzadzen nie zabraknie.
<BR>Wy, przy zalozeniu inteligencji rozproszonej chcecie ladowac te dane
od razu do konkretnych klockow - tak to rozumiem, a nie do posrednika jakim
jest MC.
<BR>Owszem, ale jak juz wyzej pisalem - czy to sie pomiesci w procesorkach
klockow?
<BR>
<BLOCKQUOTE TYPE=CITE>Kiedy dostaniemy jaki¶ nowy klocek znowu czeka
nas przeprogramowanie
<BR>MC.</BLOCKQUOTE>
Was tez czeka przeprogramowywanie klocka, bo nie mozecie "od razu" wiedziec
jakie on bedzie spelnial funkcje w systemie, jakie sa adresy urzadzen itp.
itd...
<BLOCKQUOTE TYPE=CITE>
<P>>
<BR>>> Latwiej tez robic rekonfiguracje, bo w PC
<BR>>> definiujesz sobie jakies lokalne centrum decyzyjne (czyli inteligentny
<BR>>>
<BR>>> klocek) np. 'PIEC C.O.' i do niego ukladasz program korzystajac
ze
<BR>>> wszystkich zasobow sieci - czujnikow, ukl. wykonawczych itd. Takie
<BR>>> lokalne centrum dziala niezaleznie od innych , choc rozne centra
moga
<BR>>> miec wspolne zasoby (np. czujniki)
<BR>>
<BR>>Ja tu nie widze zadnej roznicy - ja rowniez moge przypisac dowolnemu
<BR>>urzadzeniu reakcje na dowolne inne urzadzenia - nawet mam latwiej,
bo
<BR>>wszystkie adresy klockow mam zapamietanew MC (a pamieci tam mam znacznie
<BR>>wiecej niz w uC). - Ty musisz zapamietac adresy w swoim klocku, a
on ma
<BR>>tylko 128 bajtow RAM'u - chyba ze zapamietasz w EEPROM'ie...
<P>...ale kilku istotnych dla dzia³ania a nie wszystkich. Nawet 8B
(64b)
<BR>adresy dadz± siê upchaæ pod warunkiem, ¿e
klocek jest specjalizowany.</BLOCKQUOTE>
Kilka moze Ci sie uda upchac, ale nie za wiele - ja mam wieksze mozliwosci
<BLOCKQUOTE TYPE=CITE>Jak zreszt± pisano umo¿liwienie rozproszenia
nie wyklucza mo¿liwo¶ci
<BR>postawienia MC. Nie ma jednak sensu tego eksponowaæ zbytnio.
Byæ mo¿e
<BR>w jednym przypadku warto postawiæ taki MC a w innych nie.</BLOCKQUOTE>
Moim zdaniem i tak bedziecie musieli postawic kilka "co bardziej inteligentnych
klockow", ktore w rzeczy samej beda odpowiednikami MC, dla realizacji bardziej
"wyrafinowanych" dzialan sieci (sceny, czasowe dzialania, etc) - trudno
przeciez w kazdym klocku realizowac np.autonomiczna funkcje pomiaru czasu
(godziny, dni, tygodnie nawet) - a rozsylanie czasu po sieci, znowu sprowadza
sie do wniosku: ktos musi ten czas rozsylac - i bedzie to jakis inteligentniejszy
klocek = MC :-))))
<BR>Jedyna roznica jaka tu widze, to taka, ze u mnie MC "totalnie" zarzadza
siecia i integruje wszystkie funkcje sterujace w jednym urzadzeniu dzialajacym
non stop (w odroznieniu od PC'ta, przygotowujacego tylko dane jako kompilator),
a u Was to samo "rozmyje sie" na kilka bardziej inteligentniejszych i autonomicznych
klockow. Ciekawym tylko jak poradzicie sobie z "kompetencjami"
poszczegolnych "superinteligentow" ;-))) - ktory za jaka czesc sieci bedzie
odpowiadal... Bo chyba nie chcecie do "kazdego najdrobniejszego nawet klocka"
ladowac danych o czasach wlaczen, reakcji na inne urzadzenia itp, itd...?
<BLOCKQUOTE TYPE=CITE>
<PRE>Chodzi o to, ¿e zamiast przesy³ania do urz±dzenia docelowego klocek
przesy³a do MC a MC do urz±dzenia docelowego. Znacznie lepiej w razie
potrzeby postawiæ piêæ dodatkowych sterowników MC dla konkretnych
potrzeb ni¿ jeden do wszystkiego i na dodatek na zapas. Póki co nie
wiemy w ogóle do czego nam potrzebny jakikolwiek MC. I nie dowiemy siê
póki nie zaczniemy mówiæ o zastosowaniach. Tyle, ¿e ja ju¿ to
rozwa¿a³em i uzna³em, ¿e na pewno nie jeden wyró¿niony MC tylko kilka
i to nie klasycznych MC a zwyk³ych kontrolerków, które zechcia³y np.
zaj±æ siê jakim¶ zadaniem w roli koordynatora.</PRE>
</BLOCKQUOTE>
No wlasnie... Czyli nie jeden a az piec MC :-)))) - jesli chodzi
o niezawodnosc tych urzadzen (odpornosc na zawieszenie, pad zasilania itp..)
Wy musicie "uzbroic je dodatkowo" 5 krotnie, ja tylko raz. Jakie
beda koszta tych operacji?
<BLOCKQUOTE TYPE=CITE>
<P>>> A ja jednak rodzielibym ta inteligencje na klocki ;-))) z powodow
jak
<BR>>> wyzej.
<BR>>
<BR>>A ja nie :-)))) z powodow rowniez jak wyzej :-))) Zreszta moje klocki
<BR>>tez jak mowilem beda dosc inteligentne, tylko ze nie pod wzgledem
<BR>>wzajemnej komunikacji (klocek z klockiem), a pod wzgledem podprogramow
<BR>>"obslugujacych" dane urzadzenie.
<P>To mo¿e opisz jaki¶ klocek wymagaj±cy powa¿niejszej
inteligencji w
<BR>postaci programu. Mnie siê widzi, ¿e sam klocek nie musi
posiadaæ
<BR>praktycznie ¿adnej intelignecji. Dopiero kilka po³±czonych
klocków
<BR>musi ze sob± wspó³pracowaæ i reagowaæ
na zdarzenia.</BLOCKQUOTE>
Prosze bardzo...Wezmy dla przykladu klocek do pomiaru temperatury w domu,
sluzacy dodatkowo jako termometr pokojowy i ew. termostat dla utrzymywania
temperatury w pokoju na zadanym poziomie.Klocek taki musi posiadac wyswietlacz
(np. 4 cyfry LED), klawiaturke (np. 4 klawisze : '+', '-', 'enter', 'select')
oraz czujnik temperatury (np. w postaci ukladu scalonego DS1621 Dallas'a).
<BR>Do obslugi w/w funkcji musimy miec w klocku procedurke multipleksowanego
wyswietlacza LED, takiejz klawiatury oraz I2C dla Dallas'a... dodatkowo
dochodza podprogramiki obslugi menu (programowanie temperatury)...i jeszcze
troche pomniejszych jak to zwykle bywa :-)))
<BR>(np. tablica konwersji kodow BCD na 7SEG - przy zalozeniu braku dekodera
7447)
<BR>To bylo oprogramowanie uzytkowe - sluzace realizacji podstawowych funkcji
klocka - pomiaru, wyswietlania i ustawiania temperatury w pomieszczeniu.
<BR>Czyli klocek musi byc troche inteligentny, aby wszystko to nalezycie
obsluzyc..nie?
<BR>I do tego dochodza jeszcze procedury obslugi transmisji np. przez siec
220V...
<BR>Oczywiscie ten przyklad byl dla klocka, o dosyc skomplikowanych funkcjach
uzytkowych, aczkolwiek mozna wyobrazic sobie jeszcze bardziej skomplikowane
klocki (np. sterownik pralki automatycznej).
<BR>Dla klockow typu :"wlacz/wylacz" oczywiscie program uzytkowy bedzie
bardzo prosty.
<BR>Ale nie mozemy zakladac ze tylko takie typy prostych klockow bedziemy
budowac...
<BR>
<P>No i tyle tym razem...:-))))
<P>Jacek.
</BODY>
</HTML>
--------------7FD87DC59E46F35E2E9704E4
Content-Type: image/jpeg
Content-ID: <part1.3530C0BA.AF733B34_at_nospam_kki.net.pl>
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="C:\WINDOWS\TEMP\nsmail6A.jpeg"
/9j/4AAQSkZJRgABAAEAeAB4AAD//gAXVS1MZWFkIFN5c3RlbXMsIEluYy4A/9sAhAAIBQYH
BgUIBwYHCQgICQwUDQwLCwwYERIOFB0ZHh4cGRwbICQuJyAiKyIbHCg2KCsvMTM0Mx8mODw4
MjwuMjMxAQgJCQwKDBcNDRcxIRwhMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTEx
MTExMTExMTExMTExMTExMTH/xAGiAAABBQEBAQEBAQAAAAAAAAAAAQIDBAUGBwgJCgsBAAMB
AQEBAQEBAQEAAAAAAAABAgMEBQYHCAkKCxAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEG
E1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpT
VFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2
t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6EQACAQIEBAMEBwUE
BAABAncAAQIDEQQFITEGEkFRB2FxEyIygQgUQpGhscEJIzNS8BVictEKFiQ04SXxFxgZGiYn
KCkqNTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqCg4SFhoeIiYqSk5SV
lpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV1tfY2dri4+Tl5ufo6ery8/T1
9vf4+fr/wAARCACBAfwDASEAAhEBAxEB/9oADAMBAAIRAxEAPwD2GigAooAKKACigAooAKKA
CigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACi
gAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigA
ooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAoo
AKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAKKACigAooAK
KACigAooAKKACigAooAKKALDWZU4aaEEdi1J9l/6bwf990AH2X/pvB/33R9l/wCm8H/fdAEc
UfmzGKN0YgkZByMipPsv/TeD/vugA+y/9N4P++6Psv8A03g/77oAR7cIjMZ4cKMn56gBBAIO
QehFAC0UAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAVLHAZE370UZx8xxQAv2b/ptD/3
1R9m/wCm0P8A31QAjQbVJ82I47BuaZEnmNtDBeM80ASfZv8AptD/AN9UfZv+m0P/AH1QA2WI
RRl2miwPRqjoAKKACigAooAKKACigAooAKKACigAooAKnsY/MuV9F+Y/hQBHPJ5kzP6nj6Uy
gAqO4k8qF3/ujjPr2oAn0SP7Np7zdCV4I55P+RTKACigCrqLZiWFSN0rAc/5+lWVUIoVRgAY
FAC0UAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAVZuv3cUUPPA3H6/5zQBWooAKZCTG+
0cbTuX6f/W/woAlkADZXhWGRTaAK13iSWKHjk7j9P85qzQAUUAFFABRQAUUAOSN5DhFJ+lEs
bRMFfAYjOM0ANooAKKACigAooAKtQ/urOWQ9X+Rcj8/8+1AFWigAqpffvHitx/G2Wwew/wA/
pQBq3P7q2hh7n524wf8AP+FVaACigCov73USR92FccHjJ/z+lW6AHRxvIcIpb6CpvsUgXMjJ
Hzj5moAigTz5SkLo+CRuU5FSG2YYCyROScYVxmgCFlKnDAgjsaSgB8MTTSBE6+/QVJ9l/wCm
8H/fdAB9l/6bwf8AfdRzosIXdPCSxwAH5NAEi2rGNXZ40DdAxwaQ20nOzbIF6lDmgCGrCWUx
GWAQYzljigBPsv8A03g/77qN4XjUMw+U9CCCP0oAZRQA6NGkbailj7VOLJlx50iRA+p5oAru
0QuPJhl8x8ZwFIqeW2jjfZ56788hlIH50AQujJjcOD0I5B/Gm0AS2qeZOq44ByeM0lw/mTMw
6E8fSgCOigApkgPDL95T+Y7j/PtQBNGQ8ZUHOPmX+v6fyplAFa3/AHlxLL2Hyrzkf5/xqzQB
NFbSyAELgHueKSWOKGIvJcJkAnAGaAEt41liMpfagxztznNBiz/q2D89B1/KgCOigCeO3Xyx
JNIEU9Bjk07zLePiOLeeRl/8KAGPdzPn5toPZeKgt7VnmlnkkiBY4GWwcf5xQAKwYZUgj1FL
QAUUAFFABRQAVavf3axQD+BcnB7/AOf50AVaKACoNPj+1aqzMPlQ7Bkfnz+f50AXbuTzLh2B
4BwOc1DQAU12CIzHooycUAQachEBkb70hLHjH+f/AK9aUNuqxedcEqnZR1agAmvHb5YR5UY6
BeDVK7lMcEkmTux1680AWNJj+y6a8nRyNo7HJ/yPyqOgBWdtm3OQOgP+eKYjB0DDjPY9qALl
t+6tppu5+RecH/P+FVaACqwU3GqJGOkQ7jjJ/wAj8qANG/YGYIv3YwFHOf8AP/1qr0ANllcz
puJYMCMn16/4/kKsTgmKGQ912/kcUAQ0qsVOV4IoAht5PMVgeqMVJ9cVctbczEljtjX7zUAP
e5WNPLtV2jGC56mqpJJJJyTQAzQkE13Jcv0zkbhjAHT+n5VLK5kkZz3OetADSTtIU4z+WabG
29A2MHuPQ9xQBNbyeWzY6spUHOMGoyCDgjBFABRQAUUAMjJjkKg4z8y/1/X+dOvGEUJkXgEc
exoAjtIykKKB8x5IxzmtARx2yhphvkI4TsKAIJpnlOXPHoOlU73LBIlzmRueM8UAaEgEVnFE
uBu+Y4Pbt/n2qvQA1nIkG7kN39/8/wAqeilnCjqTigCa9YGUIv3UG0c5qCgCO4fy4XYdQOPr
UMNnF5S+YmWIyeSKALCIsaBUGAOgp1ABRQAUUAFFAE9jH5lyvovzH8Kjnk8yZn9Tx9KAGUUA
MlkWKNnfovpUtldzmEtCkiR56sowf88UANooAKq6i2YlhUjdKwHP+fpQBo2ECAb3wIYh37+1
NuJ2nfc3AHQelAEVVL3Es8NvxgncwPoP8mgDVvMxQwwcjA3MPf8AzmqtABVezJPnAnpK2KAN
K8zFDDByMDcw9/8AOaq0AIzBFLMcADJo8PJ/rbtx6udv8v50AOZizFm5JOTSUAVbnD3lvHk8
EsQP0/lWneL5ccEWDuVST+NAFaigCDS1aZSQuDLISO9aN5IEAtoiQideepoAq1Xv5PLtX9W+
Ufj/APWoAv2cf2TSiOhfC8cj3 rUFABVey5b/8AXVqALl0ghlRMY3ID179x/n3pJPmUP3PD
fX/P9aAGUUAFFADXUsAV+8pyKbKonhCdVDBv8R/n0oAu2oEUbXDjpwo6ZP8An+tV2YuxZjkm
gBKhtU+06ke4T5eOD7/1oAuXj77hvReBUNAEF3 yx66LV+xGJGkOcRqTx/n60AQMSzEnqTk
0lAFa7xJLFDxydx+n+c1ZoAKKACigAooAKKALUP7qzlkPV/kXI/P/PtVWgAooAqX37x4rcfx
tlsHsP8AP6Vq3P7q2hh7n524wf8AP+FAFWigAqov73USR92FccHjJ/z+lAGrOTHZwxgj5/mb
H6f59qq0AFRaTH9p1J5eqA7R3GB1/p+dAFm5k8yd3HQnj6VHQAyeQQxM7dFFGiQFhHuyS53t
nn/Pb86AJ7mTzJ3cdCePpUdAFbUHIgEafekIUDOP8/8A160VQW2mpGOsh7jnA/z+tAFeigCL
SY/tOpPL1QHaO4wOv9PzqzcyeZO7joTx9KAI6r38nl2r+rfKPx/+tQBe0mP7PCzfL+6j7/3j
/k1CSSSSck0AFVJ/3t9FEOkfztg/l/n3oAs3BnlCKkwjVBwAgNQ+Tc/8/X/kMUAHk3P/AD9f
+QxVjTLXY4QsXy25iRQA68PnSOy4znKn6dKIHDjHRXGOex/z/WgBpBBwRgiigAooAKgtnLtK
QBsDfLg/n/j+NAGheEoI4cjCKM49arUANlcRxs5/hGaZp5eGEOpw7ZbJGetADfKn/wCfj/xw
UeVP/wA/H/jgoAT7PIzoZJiwQ5A24rRP7uyA/ilOeR2H+f1oArUUAVrf95cSy9h8q85H+f8A
GrNABRQAUUAFFABRQBavf3axQD+BcnB7/wCf51VoAKKAINPj+1aqzMPlQ7Bkfnz+f51du5PM
uHYHgHA5zQBDRQA12CIzHooycVBpyEQGRvvSEseMf5/+vQBoXJ3LCwBx5YH5ZqCgCK6k8q3d
x1A4+tWdJj+y6a8nRyNo7HJ/yPyoAjpCQoJJwB1JoApMWvpQqjECHJJ/iNbFt+6tppu5+Rec
H/P+FAFWigCsFNxqiRjpEO44yf8AI/KtG/YGYIv3YwFHOf8AP/1qAK9RXUnlW7uOoHH1oAs6
TH9l015OjkbR2OT/AJH5VHQAVUn/AHt9FEOkfztg/l/n3oA0oD/o86AEkgHj2NQUAFVLH948
twf42wuR2H+f0oAt1LBA0p4+VB1Y9BQBBNd+fMsNmoFvEfmkI5c+1W7f93byy9z8q84NAFam
fccDGFb+dAE0nzKH7nhvr/n+tMoAKKAI7h/Lhdh1A4+tJax+XAq4wcZPGKALd2d05bBAYAjP
0qGgCve5YJEucyNzxnirAAAAAwBQAAEnAGSalkdLGMSSjdM3+rj/AKmgCvF5hTMuNxOcAYx7
Vbvj++CDhUAAGaAK9R3D+XC7DqBx9aAEtY/LgVcYOMnjFS0AFFABRQAUUAFT2MfmXK+i/Mfw
oAjnk8yZn9Tx9KZQAVHcSeVC7/3Rxn17UAT6JH9m095uhK8Ec8n/ACKZQAUUAVdRbMSwqRul
YDn/AD9KsqoRQqjAAwKAHFyI9uM4OR61GkiOcK3zD+E8EfhQBXvcSzw2/GCdzA+g/wAmtW9P
kwRQk42rubOP8+tAGbLewR/x7j6LzURSe8P73MMPHy9zQBbRFjQKgwo6Crl5mKGGDkYG5h7/
AOc0AVaRmCKWY4AGTQAeHk/1t249XO3+X86czFmLNyScmgBKqXuJZ4bfjBO5gfQf5NAGrdny
4IYeRhdxB9T/AJNVaACqlj+8eW4P8bYXI7D/AD+lAFxTtORUbyoh/efICSFyePzoAbLmW3YQ
sp3DAOeKsQ2a29uqtcW6hRyfM4zQAklzp9uxBmNy44CRjr+PT9agmlub4BZB9mt+0aHk/WgB
6IsaBUGFHQVbuv3cUUPPA3H6/wCc0AVqa67kIzg9j6GgB8L5TDDG4cg9jQwKsVPBBwaAEooA
rXeJJYoeOTuP0/zmrNAAzHaBtzg9c9B/n+tMSWNzhXGfTofyoAIrZpboys8aqq4Xc2D/AJ61
O6wRBjNdRLjsp3H8qAIzfKDt0+HeenmydB9PzqKOIh/NmcySkcsTnH0oAlpZpQSGc44AJNAC
VWu8SSxQ8cncfp/nNAFmigAooAKKACigApGUMpVhkEYNAEH2G2/55/8Ajxo+w23/ADz/APHj
QAfYbb/nn/48aPsNt/zz/wDHjQBLLEkyhZFyAc9cVF9htv8Ann/48aAD7Dbf88//AB40fYbb
/nn/AOPGgB0dpBE4dEww6HJqagApkkSSDEiBvqOlADYbaKFt0abSRjqaSS0gkcu6ZY9Tk0AP
jhjj/wBWirgYyBzT6ACoZLSCRy7plj1OTQA37Dbf88//AB40fYbb/nn/AOPGgCVokaLymX5M
AYz6VF9htv8Ann/48aAD7Dbf88//AB40+G2ihbdGm0kY6mgBJbWGV90iZP8AvGm/Ybb/AJ5/
+PGgA+w23/PP/wAeNTRxrEgRBhR0FADqKAIXtIHxmJRj04/lTfsNt/zz/wDHjQBMkaR52Iq5
64GKdQAVE9tFIxZ0yT7mgBv2OD+5+po+xwf3P1NAEkUSRAiMYB9zTXtopGLOmSfc0AN+xwf3
P1NH2OD+5+poAfFBHE26NcHGOpqSgAprIj43qrY6ZGaAIvscH9z9TTltoUziNefXmgCWigAo
oAia3THyFo+c/IcURQCOTfvdjjHzHNAEtFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUA
FFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFF
ABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFAB
RQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQ
AUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAU
UAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUA
FFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFF
ABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFABRQAUUAFFAA
/9k=
--------------7FD87DC59E46F35E2E9704E4--
--------------E51A036D1B0535C17A893C2D--
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 10 Apr 1998 08:37:51 GMT
Thu, 09 Apr 1998 15:21:48 GMT, cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
(Jaroslaw Cichorski Jr.) napisał(a):
A wlasciwie to do jakich celow chcialbys uzyc tych superinteligentnych
klockow? Ja mialem koncepcje tego typu, ze uC + modem stanowilyby tylko
interfejs do zdalnego sterowania, a o inteligencji jako takiej raczej
nie bylo mowy - to PC (czy MC) mialy "myslec ktorym klockiem jak
sterowac...
No ale, zeby uniezaleznic wszystko od PC to proponowalem, aby PC
sluzyl do konfiguracji sieci i ukladania programow, a te po
'skompilowaniu' bylyby wykonywana w postaci makroinstrukcji przez
'superinteligentne' klocki.
Dlatego w kazdym takim klocku potrzebny jest interpreter
makroinstrukcji oraz pamiec na nie (EEPROM).
<snip>
wszystkiego transmisja danych..:-)))) Tak wiec rozumiem, ze
"skomplikowanie" klocka polegaloby tylko na jego oprogramowaniu?
Polegaloby na napisaniu dobrego intepretera makroinstrukcji.
Ktoś produkuje klocuszki chodzące w javie.
A mnie sie marzy dynamiczny numer urzadzenia - po wlaczeniu do gniazdka,
urzadzenie zglasza swoja obecnosc w sieci i zostaje mu przydzielony
adres, od tego momentu urzadzenie jest identyfikowane z tym adresem -
ale wtedy zarzadca sieci musi caly czas "czuwac" i reagowac na
pojawienie sie nowego urzadzenia (lub wypadniecie starego).
Tak, to mozna zrobic-to nawet jest zalecane, tylko trzeba to zrobic w
inteligentny sposb - zeby nie przydzielic przypadkowo adresu juz
istniejacego, zeby latwo zidentyfikowac nowe urzadzenia w sieci i zeby
niezawodnie nadac numer kazdemu z nich z osobna, a nie wszystkim taki
sam, gdy jest ich wiecej ;-)
Jezeli w PC bylaby baza informacji o elementach sieci (a musi byc), to
zadanie jest stosunkowo proste.
Noooo, nie musi. Każdy kontroler może np. generować losowy numer i
pytać czy ktoś inny w sieci nie ma takiego. A sam kontroler może umieć
się przedstawiać podając swoje możliwości - javabeans. Oczywiście
można iść jeszcze dalej tyle, że nie wiadomo czy warto. W końcu chodzi
tylko o to by robiło konkretne rzeczy i trzeba zapewnić środki do
realizacji tych koń-kretów.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez mala
dziurke w obudowie....
Jakie obudowy masz zamiar stosować ?
From: cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl (Jaroslaw Cichorski Jr.)
Subject: Re: Home Automation - opis c.d.
Date: Fri, 10 Apr 1998 08:51:03 GMT
hocking_at_nospam_rorse.edu.pl (Bonik Kujany) wrote:
Jezeli w PC bylaby baza informacji o elementach sieci (a musi byc), to
zadanie jest stosunkowo proste.
Noooo, nie musi. Każdy kontroler może np. generować losowy numer i
pytać czy ktoś inny w sieci nie ma takiego. A sam kontroler może umieć
Musi dlatego, zeby moc w ogole skonfigurowac sprzet i ew. pozniej
zmienic konfiguracje. PC musi znac numery urzadzen w sieci i to on
powinien te numery przydzielac. Inaczej zrobi sie bu.... balagan.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez mala
dziurke w obudowie....
Jakie obudowy masz zamiar stosować ?
To nie ja mam zamiar stosowac reset w tych urzadzeniach - jestem
zdecydowanie przeciw jakimkolwiek przyciskom - nawet reset ;-)))
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
E-mail cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
WWW http://www.amart.com.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Sat, 11 Apr 1998 10:36:25 GMT
Fri, 10 Apr 1998 08:51:03 GMT, cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
(Jaroslaw Cichorski Jr.) napisał(a):
hocking_at_nospam_rorse.edu.pl (Bonik Kujany) wrote:
Jezeli w PC bylaby baza informacji o elementach sieci (a musi byc), to
zadanie jest stosunkowo proste.
Noooo, nie musi. Każdy kontroler może np. generować losowy numer i
pytać czy ktoś inny w sieci nie ma takiego. A sam kontroler może umieć
Musi dlatego, zeby moc w ogole skonfigurowac sprzet i ew. pozniej
zmienic konfiguracje. PC musi znac numery urzadzen w sieci i to on
powinien te numery przydzielac. Inaczej zrobi sie bu.... balagan.
Niekoniecznie tak. Dostawca przygotowuje produkt pod konkretną
konfigurację i do tego użyje PC ale klient już nie. No i można jeszcze
praktykować zworkologię lub przyciskologię.
Ja bym dal jednak klawisz "Reset" - gdzies dostepny, chocby przez mala
dziurke w obudowie....
Jakie obudowy masz zamiar stosować ?
To nie ja mam zamiar stosowac reset w tych urzadzeniach - jestem
zdecydowanie przeciw jakimkolwiek przyciskom - nawet reset ;-)))
Poza reset ok, ale zawiesić zawsze się może.
From: cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl (Jaroslaw Cichorski Jr.)
Subject: Re: Home Automation - opis c.d.
Date: Mon, 13 Apr 1998 23:00:22 GMT
hocking_at_nospam_rorse.edu.pl (Bonik Kujany) wrote:
<snip>
Niekoniecznie tak. Dostawca przygotowuje produkt pod konkretną
konfigurację i do tego użyje PC ale klient już nie. No i można jeszcze
praktykować zworkologię lub przyciskologię.
Plug and Play (with the jumpers ;-))))) - no thanks
Zadnych jumperow.
Uzytkownik jest najczesciej malo zainteresowany tym, co jest w srodku
i jak to dziala, wiec trzeba mu to skonfigurowac.
Teraz wyobraz sobie, ze masz takich klientow 1000 i co piaty cos
ciagle chce w systemie zmieniac, ale nie potrafi i Ty musisz do nich
ciagle jezdzic. Lepiej sie powiesic od razu.
Wniosek:
Powinna istniec mozliwosc dokonania pelnej (re/)konfiguracji z poziomu
PC i to najlepiej zdalnie przez modem.
<snip>
Poza reset ok, ale zawiesić zawsze się może.
Od tego jest watchdog, zeby odwiesic ;-))))
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
E-mail cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
WWW http://www.amart.com.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
From: "Wojciech Wiercigroch" <Wojciech.Wiercigroch_at_nospam_ComArch.Pl>
Subject: Re: Home Automation - opis c.d.
Date: 14 Apr 1998 07:25:58 GMT
Jaroslaw Cichorski Jr. <cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl> napisał(a) w
artykule <353299c0.0_at_nospam_news.tpnet.pl>...
hocking_at_nospam_rorse.edu.pl (Bonik Kujany) wrote:
<snip>
Niekoniecznie tak. Dostawca przygotowuje produkt pod konkretną
konfigurację i do tego użyje PC ale klient już nie. No i można jeszcze
praktykować zworkologię lub przyciskologię.
Plug and Play (with the jumpers ;-))))) - no thanks
Zadnych jumperow.
Uzytkownik jest najczesciej malo zainteresowany tym, co jest w srodku
i jak to dziala, wiec trzeba mu to skonfigurowac.
To jest oczywiste
Teraz wyobraz sobie, ze masz takich klientow 1000 i co piaty cos
ciagle chce w systemie zmieniac, ale nie potrafi i Ty musisz do nich
ciagle jezdzic. Lepiej sie powiesic od razu.
Wniosek:
Powinna istniec mozliwosc dokonania pelnej (re/)konfiguracji z poziomu
PC i to najlepiej zdalnie przez modem.
Tu bym polemizowal. Jak przecietny klient dowie sie, ze mozesz
mu cos mieszac w jego domu przez modem to tego nie kupi. Poza
tym i z marketingowego i ekonomicznego punktu widzenia, lepiej
do klienta jezdzic i brac za to kase. Klient lubi byc dobrze
obsluzony, a jak bedzie za to placil (co jest chyba normalne),
to nad kazda zmiana bedzie sie lepiej zastanawial.
<snip>
Poza reset ok, ale zawiesić zawsze się może.
Od tego jest watchdog, zeby odwiesic ;-))))
Pozdrawiam
--------
Jaroslaw Cichorski Jr.
E-mail cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
WWW http://www.amart.com.pl
UWAGA Adres niewazny!
Prosze usunac JUNK MAIL PROTECTION. zeby otrzymac prawidlowy adres.
Kto to jest General Failure i dlaczego czyta z mojego dysku twardego ?
wosiek
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Tue, 14 Apr 1998 22:19:03 GMT
Mon, 13 Apr 1998 23:00:22 GMT, cichy_at_nospam_amart.JUNKMAILPROTECTION.com.pl
(Jaroslaw Cichorski Jr.) napisał(a):
hocking_at_nospam_rorse.edu.pl (Bonik Kujany) wrote:
<snip>
Niekoniecznie tak. Dostawca przygotowuje produkt pod konkretną
konfigurację i do tego użyje PC ale klient już nie. No i można jeszcze
praktykować zworkologię lub przyciskologię.
Plug and Play (with the jumpers ;-))))) - no thanks
nie. albo, albo lub po części tak, po części inaczej
Zadnych jumperow.
Uzytkownik jest najczesciej malo zainteresowany tym, co jest w srodku
i jak to dziala, wiec trzeba mu to skonfigurowac.
no, ale jak usłyszy w sklepie, że musi to ktoś skonfigurować to może
kupi coś cudzego, prymitywniejszego z jumperkami
Teraz wyobraz sobie, ze masz takich klientow 1000 i co piaty cos
ciagle chce w systemie zmieniac, ale nie potrafi i Ty musisz do nich
ciagle jezdzic. Lepiej sie powiesic od razu.
To wtedy stawiam mu łatwi programowalny MC (albo PC rzecz jasna), ale
DOPIERO wtedy.
Wniosek:
Powinna istniec mozliwosc dokonania pelnej (re/)konfiguracji z poziomu
PC i to najlepiej zdalnie przez modem.
To już inna sprawa. Faktem jest, że przeciętnemu klientowi PC
niepotrzebny.
<snip>
Poza reset ok, ale zawiesić zawsze się może.
Od tego jest watchdog, zeby odwiesic ;-))))
Cuda-dziwy a mój komputer nie patrzy na psy i tak z większością co
bardziej skomplikowanych urządzeń
From: hocking_at_nospam_rorse.edu.pl (Bonik Kujany)
Subject: Re: Home Automation - opis c.d.
Date: Thu, 09 Apr 1998 17:34:23 GMT
Wed, 08 Apr 1998 20:22:38 +0200, Jacek Domanski <jado_at_nospam_kki.net.pl>
napisał(a):
Wlasnie nad tym mysle :-))) Wymysliles juz cos moze? Jak dla mnie to
mam zamiar skoncentrowac sie na minimalizacji samego ukladu
elektronicznego (SMD, dwustronny druk, etc), a trafa zostawic takie
jakie sa.... I tak sie powinno zmiescic....Gorzej, ze brak przewodu
zerowego w kontakcie (od swiatla) ....pozostaje zatem kucie :-))) i
dociaganie go z puszki.... Tak, tak...taki glupi z pozoru sterownik
swiatla jest wlasnie tym najtrudniejszym elementem (no prawie.. :-)))
ukryć w ozdobnej listwie
From: "Filip R. Zawadiak" <philz_at_nospam_wasko.gliwice.pl>
Subject: Re: Home Automation - opis c.d.
Date: Mon, 06 Apr 1998 11:14:19 +0200
Jacek Domanski wrote:
Po trzecie: Dobrze byloby dla ulatwienia sterowania zrobic cos w rodzaju
inteligentnego pilota
o dwukierunkowej komunikacji (odbiera i nadaje), z wyswietlaczem
alfarnumerycznym LCD,
za pomoca ktorego moglibysmy w prosty sposob bezposrednio sterowac
systemem. Tutaj jest wlasnie miejsce na tzw. sceny - wcisniecie jednego
klawisza powoduje iles tam dzialan...
To jakby druga mozliwosc "wejscia w system" - z jednej strony PC'et, z
drugiej wlasnie taki pilot, do ktorego kazdy z nas jest przyzwyczajony
(tylko troche wiecej "bajerow" :-))))
Najlepiej w postaci programu na jakies PDA z podczerwienia, np
Pilot (nowy)
Avigo10
Newton - to akurat znam najlepiej
--
Filip R. Zawadiak (Philz) http://www.wnet.silesia.pl/~philz
main(){for(;;)fork();} mailto:philz_at_nospam_silesia.linux.org.pl