Re: Protokol transmisji dla Home Automation



Masz problem? Zapytaj na forum elektroda.pl z bramką pl.misc.elektronika!

Poprzedni Następny
Wiadomoœć
spis treści
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


Poprzedni Następny
Wiadomoœć
spis treści
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.




Poprzedni Następny
Wiadomoœć
spis treści
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
-----------------------------------------------




Poprzedni Następny
Wiadomoœć
spis treści
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



Poprzedni Następny
Wiadomoœć
spis treści
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:
dowolnym medium transmisyjnym
sieciach (np. roznych mediach transmisyjnych)
sterowania i monitorowania sieci
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



Poprzedni Następny
Wiadomoœć
spis treści
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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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...



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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?

    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.

    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.




    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.

    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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!



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.

    Poprzedni Następny
    Wiadomoœć
    spis treści
    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 ?



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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ć.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.

    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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 ?


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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
    .



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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 ?


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.

    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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
    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
    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
    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 &lt;jado_at_nospam_kki.net.pl>
    <BR>napisa&sup3;(a):
    <BR>&nbsp;

    <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&aelig; wiadomo, &iquest;e mamy do czynienia z
    nag&sup3;&oacute;wkiem
    <BR>paczki. Ca&sup3;a paczka po skonfrontowaniu z jednym polem CRC zostanie
    <BR>uznana za prawid&sup3;ow&plusmn;, albo nie. Je&para;li nie to tre&para;ci
    si&ecirc; 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>&nbsp;

    <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&sup3;&oacute;wek-paczka poprzedzaj&plusmn;ce dane te&iquest;
    ma jakie&para; 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
    <BLOCKQUOTE TYPE=CITE>&nbsp;

    <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&iquest; kwestia konkretnej aplikacji. Jednym wystarcz&plusmn;
    kr&oacute;tkie
    <BR>informacje a innym trzeba przesy&sup3;a&aelig; rasowe dane. A mo&iquest;e
    DWIE
    <BR>magistrale transmisyjne ? A przynajmniej programowe rozr&oacute;&iquest;nienie
    <BR>umo&iquest;liwiaj&plusmn;ce wprowadzenie jej w przysz&sup3;o&para;ci.
    To jest my&para;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)&nbsp; Podobnie tez rzecz ma sie jesli chodzi o szybkosc transmisji
    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>&nbsp;

    <P>>
    <BR>>>
    <BR>>>
    <BR>>> Adresy chyba 1 bajtowe (a moze jednak&nbsp; 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)&nbsp; 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&aelig;. Sensowny obszar adresowy to 64 bity.
    <BR>&brvbar;mieszne, ale prawdziwe...</BLOCKQUOTE>
    Osiem bajtow na jeden adres?&nbsp; 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.&nbsp; 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
    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>&nbsp;

    <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&sup3;a&para;ciwie co osi&plusmn;gniesz wy&sup3;&plusmn;czaj&plusmn;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&iquest;na to robi&aelig; lokalnie w sensie zastosowania.</BLOCKQUOTE>
    Zastosowanie MC daje nam to, ze mozesz kazdy klocek maksymalnie uproscic
    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>&nbsp;

    <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>&nbsp;
    <BR>&nbsp;

    <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&ecirc;t decyduje a nie ogranicza. Trudno robisz jednakowe sterowniki
    do
    <BR>r&oacute;&iquest;nych cel&oacute;w. Z tego wyniika ich odmienna inteligencja
    i odmienne
    <BR>sterowania. Przekonanie sprz&ecirc;towego w ko&ntilde;cu MC aby zna&sup3;
    sposoby
    <BR>komunikacji z ka&iquest;dym jest MZ ma&sup3;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...&nbsp; 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.&nbsp;&nbsp;
    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
    <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>&nbsp;
    <BLOCKQUOTE TYPE=CITE>Kiedy dostaniemy jaki&para; 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>&nbsp;

    <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&sup3;ania a nie wszystkich. Nawet 8B
    (64b)
    <BR>adresy dadz&plusmn; si&ecirc; upcha&aelig; pod warunkiem, &iquest;e
    klocek jest specjalizowany.</BLOCKQUOTE>
    Kilka moze Ci sie uda upchac, ale nie za wiele - ja mam wieksze mozliwosci
    <BLOCKQUOTE TYPE=CITE>Jak zreszt&plusmn; pisano umo&iquest;liwienie rozproszenia
    nie wyklucza mo&iquest;liwo&para;ci
    <BR>postawienia MC. Nie ma jednak sensu tego eksponowa&aelig; zbytnio.
    By&aelig; mo&iquest;e
    <BR>w jednym przypadku warto postawi&aelig; 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.&nbsp;&nbsp; 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, &iquest;e zamiast przesy&sup3;ania do urz&plusmn;dzenia docelowego klocek&nbsp;
    &nbsp; przesy&sup3;a do MC a MC do urz&plusmn;dzenia docelowego. Znacznie lepiej w razie&nbsp;
    &nbsp; potrzeby postawi&aelig; pi&ecirc;&aelig; dodatkowych sterownik&oacute;w MC dla konkretnych&nbsp;
    &nbsp; potrzeb ni&iquest; jeden do wszystkiego i na dodatek na zapas. P&oacute;ki co nie&nbsp;
    &nbsp; wiemy w og&oacute;le do czego nam potrzebny jakikolwiek MC. I nie dowiemy si&ecirc;&nbsp;
    &nbsp; p&oacute;ki nie zaczniemy m&oacute;wi&aelig; o zastosowaniach. Tyle, &iquest;e ja ju&iquest; to&nbsp;
    &nbsp; rozwa&iquest;a&sup3;em i uzna&sup3;em, &iquest;e na pewno nie jeden wyr&oacute;&iquest;niony MC tylko kilka&nbsp;
    &nbsp; i to nie klasycznych MC a zwyk&sup3;ych kontrolerk&oacute;w, kt&oacute;re zechcia&sup3;y np.&nbsp;
    &nbsp; zaj&plusmn;&aelig; si&ecirc; jakim&para; zadaniem w roli koordynatora.</PRE>
    </BLOCKQUOTE>
    &nbsp;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.&nbsp; Jakie
    beda koszta tych operacji?
    <BLOCKQUOTE TYPE=CITE>&nbsp;

    <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&iquest;e opisz jaki&para; klocek wymagaj&plusmn;cy powa&iquest;niejszej
    inteligencji w
    <BR>postaci programu. Mnie si&ecirc; widzi, &iquest;e sam klocek nie musi
    posiada&aelig;
    <BR>praktycznie &iquest;adnej intelignecji. Dopiero kilka po&sup3;&plusmn;czonych
    klock&oacute;w
    <BR>musi ze sob&plusmn; wsp&oacute;&sup3;pracowa&aelig; i reagowa&aelig;
    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,&nbsp; 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>&nbsp;

    <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--


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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ć ?



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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 ?


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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.


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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 ?


    Poprzedni Następny
    Wiadomoœć
    spis treści
    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




    Poprzedni Następny
    Wiadomoœć
    spis treści
    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ń



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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



    Poprzedni Następny
    Wiadomoœć
    spis treści
    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