Sida 1 av 1
Smart hem
Postat: 18 februari 2008, 12:58:44
av Micke_N
Nu har jag bestämt mig för att ta itu med ett lite större projekt. För att inte dra pannan i väggen direkt så blir det dock i ganska liten skala till en början, sen är det också tänkt att den slutliga lösningen ska bli i någon typ av modulform för att få hela systemet skalbart.
Tanken är ungefär såhär i första steget:
1. En central styrenhet tar in signaler från strömbrytare i ett hus/lägenhet
2. Styrenheten styr eluttag, lamper osv i huset/lägenheten
3. Styrenheten ska även ha ett nätverksinterface (troligast UDP) för att kunna styra/monitorera mha en dator. Detta möjliggör www- och wap-interface, schemalagda aktiviteter osv.
I ett senare skede är det tänkt att tillkomma perifera moduler som t ex motorstyrning (ventilation, cirkulationspump, rullgardiner osv), temperaturmonitorering, effektmonitorering....
Allt detta ska tryckas in i en Atmel-uC, i första läget blir det nog en ATmega88 sen kanske det blir något större när fler IO behövs. Jag hämtar en del inspiration (UDP-stacken...) från
www.tuxgraphics.org. I övrigt tänker jag nog uppfinna hjulet igen om det behövs, allt i lärandets tecken.
Just nu väntar jag på lite komponenter och håller också på att programmera (och definiera) kommandon osv som skickas via LAN. Nästa post blir väl när det finns något fungerande, eller kanske troligare när det borde fungera men inte gör det

.
/MVH Micke
Postat: 18 februari 2008, 14:18:34
av blueint
Kolla denna tråd:
http://elektronikforumet.com/forum/view ... hp?t=24147
Elektronikforumet är som en Deja vu..
Postat: 6 april 2008, 21:32:26
av Micke_N
Ping - Pong!
Nu har jag kunnat få ett svar från labbplattan, kul! Har inte haft så mycket tid att lägga på detta lilla jätteprojekt på sista tiden, men jag har försökt att hitta en halvtimme här och där...
Sen tycker jag att app. note:n till ENC28J60 är lite otydlig i vissa fall, ett problem jag drabbades av var att det i databladet visas att man ska koppla en ferrit mellan centertappen på TX-lindningen i ethernettrafon och Vcc men att den är valfri (anv för att minska EMI). Så jag satte inte dit den till att börja med, men det som inte stod i klartext var att om man inte hade ferriten så skulle man koppla centertappen rakt till Vcc. Nu sitter iaf ferriten där och den svarar som den ska.
Nu börjar det roliga jobbet med att skriva funktioner för att sätta och läsa utgångar/ingångar. Tror jag har någon LM35 liggandes som blir bra att testa AD:n med.
MVH Micke
Postat: 6 april 2008, 22:52:39
av eqlazer
Kan tipsa om denna
tråden. Projektet har mycket av det du efterfrågar (eller ja, gemensamma mål), och du är väldigt välkommen att hjälpa till att utveckla på det ifall du vill.
Projektets wiki:
http://projekt.auml.se/
Postat: 7 april 2008, 10:37:14
av Micke_N
Jag har läst din/er tråd eqlazer, ni har kommit mycket längre än jag. Jag har blivit lite avskräckt från CAN-bussen (i jobbet) genom en medioker och ogenomtänkt applikation med ett rysligt dåligt interface.... Men uppenbarligen finns det de som kan det bättre!
Jag satsar lite annorlunda, i stället för att sprida ut noder satsar jag på att ha en/ett par styrlåda/-or vid säkringsskåpet och styra belysning, vägguttag etc därifrån. Det blir lite dyrare med Ethernet men det tar jag (eventuellt) igen på att ha färre lådor.
MVH Micke
Postat: 7 april 2008, 18:50:54
av Noddan
CAN-bussen fungerar jättebra när vi har tämjt den så det är inga problem

Man behöver inte tänka på att det är CAN man jobbar med. Visst går det att köra helt centraliserat också, men ta en extra funderare på om du inte kommer att ångra dig till sist när du har ett system som är svårt att uppgradera.
(Jag är också projektmedlem och trådskapare till tråden som eqlazer tänkade till

)
Postat: 8 april 2008, 15:48:31
av Micke_N
Tanken jag har är att bygga ett modulbaserat system med t ex en strömbrytarmodul med ett 10-tal reläer, en dimmermodul med ett antal dimmers osv. Jag har också tänkt om lite vad gäller vart intelligensen ska ligga, nu lutar det åt att modulerna enbart kommer att reagera på kommandon och vidarebefodra insignaler. Sedan kommer allt tänkande göras av en pc på nätverket, som det är nu känns det som det bästa sättet att lösa t ex kron- och trappkoppling av strömbrytare mjukvarumässigt.
Mitt system är tänkt för nybyggda hus (en intresserad kompis bygger nu och själv har jag också tankar på detta), så jag har även fördelen att kunna anpassa el och nätverk i huset efter smart hem-systemet - vilket är en stor fördel. Att dra elnätet i huset som ett stjärnnät med säkringspanel och smart hem-moduler i mitten kostar lite kabel men det gör att allt blir så mycket lättare att styra och att uppgraderingarna inte heller blir särskilt invecklade eftersom allt sitter i samma rack. Jag ska försöka peta in en bild på hur detta ska se ut någon gång när jag har en stund över.
MVH Micke
Postat: 15 juni 2008, 17:00:14
av Micke_N
Två månader senare.... Nu finns det åtminstone något att berätta, jag har knåpat ihop kod så att det går att slå av/på digitala utgångar och läsa AD-omvandlarna via UDP. Dessutom kan man se temperatur via webbläsare, eftersom jag labbar och håller på (och dessutom pågår det stambyte i lägenheten) är den inte uppe 24/7 men när den fungerar finns den på
http://81.216.192.21:88
Ett skumt problem är att den ser OK ut i webbläsare på datorn, men om jag går in på adressen med min mobiltelefon får jag bara ett "200 OK"-meddelande. Det beror på att det (av AVR:en) mottagna paketet inte känns igen som en http-GET-fråga, då ger den detta svar till klienten. Jag har inte lyckats lista ut om TCP-paketet ser annorlunda ut om det kommer från en mobil, eller om det är min router som modifierar paketet på ett dåligt sätt. Det blir inte tvärlätt att felsöka, men det ska nog lösa sig till sist.
Postat: 15 juni 2008, 18:06:56
av blueint
Kan vara att mobiltelefonen förväntar sig något annat än det du ger den t.ex. wml. Hitta någon webbsida som fungerar i mobiltelefonen och jämför med det som din webbserver ger (mha telnet etc..).
Testa också någon webbläsare som simulerar mobiltelefoners beteende.
Kan också vara strul med HTTP 1.0 kontra 1.1, då den senare stödjer flera http-förfrågningar på samma tcp kontakt.
Tror inte problemet ligger på TCP nivå, utan i innehållet.
Postat: 15 juni 2008, 21:42:49
av ghost_rider
sök på KNX eller EIB, stort sätt samma sak som du pysslar med, fast "dyrare"
men dock så spännade, brossans kunskaper smittade av sig, så nu sitter man o programerar hans hus

Postat: 15 juni 2008, 22:10:11
av marcla
In-door temp : 38 -28.5'C [-19.3'F]
Har du verkligen -28'C innomhus??
EDIT: Nu verkar det vara fixat...
Postat: 17 juni 2008, 20:02:19
av Micke_N
Jag är på samma spår som blueint, jag tror att det är paketets innehåll som skiljer sig på något sätt. Det är lite knivigt att felsöka eftersom jag inte har någon hub och på så sätt inte har något enkelt sätt att sniffa paketen som skickas. Jag provade också att nå min dator med mobilen men det gick inte heller, Wireshark visade inte något meningsfullt där heller så vete katten vad det är som pågår egentligen. Om jag lyckats skriva ut rätt del av paketet verkar det som att det står "Application" där det bordet stå "GET /" i tcp-paketet, sen om GET kommer före eller efter är svårt att avgöra eftersom det är en del skumma tecken inblandat i paketet som inte visas eller visas fel vid utskrift. Fortsättning lär följa (efter midsommar....).
Jag är ju norrlänning från början så -28 är ju egentligen inget konstigt, fast i detta fall berodde det på att jag förmodligen bytt A/D-kanal på kopplingsdäcket eller i koden utan att göra det på det andra stället också. Sen är det så att kopplingsdäcket sitter ovanpå ett spänningsagg och tempgivaren sitter mellan alla komponenter på däcket så den visar normalt ca 27-28 grader, men precis när man slår på visar den 23 grader vilket stämmer med min vanliga inomhustermometer.