Automation av lampor, kaffekokare etc.
Automation av lampor, kaffekokare etc.
Nå, nu är jag i farten igen med ett nytt projekt. Jag läste lite här på forumet om nån som byggt ett system för att styra lampor etc (tror det var oJsan). via trådlösa brytare. Så jag tänkte att det där låter ju häftigt, plus att jag har ett ypperligt tillfället att genomföra det nu när jag bygger ett nytt rum åt mig på vinden. Dock tyckter jag att jag inte behöver den trådlösa funktionaliteten då jag mycket väl kan dra kabel för brytare och sånt (jag har planerat att lägga Ductel-rännor (heter väl nåt sånt) längs alla väggar i det nya rummet. Plus att det kan vara ganska svårt, eller åtminnstone onödigt jobbigt att hitta just Nexa's brytare. Nu kommer mina några problem.
1: Jag har i princip ingen erfarenhet av picprogramering, men jag har en programerare och jag har gett mig fan på att lära mig.
2: Jag har ytterst lite erfarenhet av interfaceing med datorer, har nångång lekt lite med att tända och släcka leddar via parallell-porten, men that's it.
3: Jag har bara en vag ide om hur detta skall gå till.
Så här är min ide.
1: Jag ansluter ett antal reläer till en krets, som sköter om interfacing:en med min server. Antingen görs detta över serieporten med en pic (jag antar att detta ger en ganska stor mängd reläer som kan styras) eller så använder jag datapinnarna på LPT:n, dock med max 8 reläer. Det skulle väl också kunna gå med att använda kontrollpinnarna för att utöka antalet till 32, men då kan jag lika bra använda mig av PIC:en (skall ju försöka lära mig nåt)
2: Servern kör ett program (i C++, eftersom jag kan det någorlunda. I PIC:en hade jag tänkte köra med C) som kommunicerar med PIC;en och knyter ihop det hela. Hade tänkt mig nåt CLI-system under Linux som man sedan eventuellt kan ge kommandon genom ett webinterface med hjälp av PHP-kod.
3: Reläerna ansluts till styrkortet med en sladd och läggs sedan mellan stickproppen/alternativt installeras i takdosor/brytardosor som trappbrytare
Nu får in komma med synpunkter. Jag har inte spikat fast nåt ännua, så allt är möjligt. Just upplägget av styrkortet + programmeringen är det jag är mest osäker på, resten borde nog gå ganska smidigt.
1: Jag har i princip ingen erfarenhet av picprogramering, men jag har en programerare och jag har gett mig fan på att lära mig.
2: Jag har ytterst lite erfarenhet av interfaceing med datorer, har nångång lekt lite med att tända och släcka leddar via parallell-porten, men that's it.
3: Jag har bara en vag ide om hur detta skall gå till.
Så här är min ide.
1: Jag ansluter ett antal reläer till en krets, som sköter om interfacing:en med min server. Antingen görs detta över serieporten med en pic (jag antar att detta ger en ganska stor mängd reläer som kan styras) eller så använder jag datapinnarna på LPT:n, dock med max 8 reläer. Det skulle väl också kunna gå med att använda kontrollpinnarna för att utöka antalet till 32, men då kan jag lika bra använda mig av PIC:en (skall ju försöka lära mig nåt)
2: Servern kör ett program (i C++, eftersom jag kan det någorlunda. I PIC:en hade jag tänkte köra med C) som kommunicerar med PIC;en och knyter ihop det hela. Hade tänkt mig nåt CLI-system under Linux som man sedan eventuellt kan ge kommandon genom ett webinterface med hjälp av PHP-kod.
3: Reläerna ansluts till styrkortet med en sladd och läggs sedan mellan stickproppen/alternativt installeras i takdosor/brytardosor som trappbrytare
Nu får in komma med synpunkter. Jag har inte spikat fast nåt ännua, så allt är möjligt. Just upplägget av styrkortet + programmeringen är det jag är mest osäker på, resten borde nog gå ganska smidigt.
-
- Inlägg: 31
- Blev medlem: 22 augusti 2006, 21:21:30
- Ort: Uppsala
- Kontakt:
Jag har inte så mkt koll pic-programmering men rent spontant känner jag att det vore vettigt att bygga någon slags kommunikationsslinga med enheter som sitter vid varje apparat, alternativt inhandla X10-moduler(dyrt) som det finns färdiga kompontenter för att kommunicera med(åtminstone till ASP och MS IIS vad jag vet) eller bygga egna X10-grejer. Det jag rent spontant känner när det gäller gränssnittet för att styra detta är att bygga nånting likt ett överordnat system för larm, dvs med planritning och olika symboler man kan klicka på för att knäppa på, stänga av osv. Blir förvisso ett komplext system att bygga men ack så hög imponationsfaktor för alla teknikintresserade vänner..
/Staffan

/Staffan
Ingen dum ide där.
Jag jobbar på något liknande och tänkte köra som staffolainen sa, en liten uC vid varje 'enhet', alt att den får ett par uppgifter ( tänkte att samma uC kan kontrollera en rörelsedetektor samt belysningen i ett rum, man har ju trots allt lite IO pinnar att leka med).
Har inte bestämt vilket protokoll jag vill ha ännu, men I2C verkar smidigt och man behöver som max 4 ledningar som man drar runt till de olika rummen, något som borde få rum i pvc rören ( ska kolla om det blir för mycket störningar innan jag drar på riktigt ), två för datat och två för gnd och Vcc. Man kan ju om man vill tillverka strömförsörjning vid varje uC, men en central trafo känns mer rätt.
Varje uC kan agera på egen hand, dvs en tryckknapp kopplad till uCn stänger av och på lampan, samtidigt som den försöker skicka den förändrade statusen till en huvudcentral, och man kan då även skicka kommandon från huvudcentralen för att ställa om lamporna centralt.
även rörelsedetektorn kan isf om man vill lokalt styra en lampa, alt så skickas enbart info till centralen som får agera på det.
Interfacet mot datorn kommer bli en uC som kör I2C och rs232 så man kan översätta kommandona mellan dessa system, och vill man så kan man sätta in en större uC här så behövs inte datorn mer än för att konfigurera om 'Master' uCn.
Kostnaden borde i vilket fall som helst bli långt under de färdiga komponenterna för X10 systemet.
Jag jobbar på något liknande och tänkte köra som staffolainen sa, en liten uC vid varje 'enhet', alt att den får ett par uppgifter ( tänkte att samma uC kan kontrollera en rörelsedetektor samt belysningen i ett rum, man har ju trots allt lite IO pinnar att leka med).
Har inte bestämt vilket protokoll jag vill ha ännu, men I2C verkar smidigt och man behöver som max 4 ledningar som man drar runt till de olika rummen, något som borde få rum i pvc rören ( ska kolla om det blir för mycket störningar innan jag drar på riktigt ), två för datat och två för gnd och Vcc. Man kan ju om man vill tillverka strömförsörjning vid varje uC, men en central trafo känns mer rätt.
Varje uC kan agera på egen hand, dvs en tryckknapp kopplad till uCn stänger av och på lampan, samtidigt som den försöker skicka den förändrade statusen till en huvudcentral, och man kan då även skicka kommandon från huvudcentralen för att ställa om lamporna centralt.
även rörelsedetektorn kan isf om man vill lokalt styra en lampa, alt så skickas enbart info till centralen som får agera på det.
Interfacet mot datorn kommer bli en uC som kör I2C och rs232 så man kan översätta kommandona mellan dessa system, och vill man så kan man sätta in en större uC här så behövs inte datorn mer än för att konfigurera om 'Master' uCn.
Kostnaden borde i vilket fall som helst bli långt under de färdiga komponenterna för X10 systemet.
Jag har funderat på hur man skulle lösa problemet med att veta om en lampa/annan grej är på om man kopplar in reläerna som trappbrytare. Har funderat lite på om dallas 1-wire serie har nån lämplig volt-mätare eller annat för att få detta att fungera.
Annars så fick jag ihoplödd min programerare idag (Velleman k8048 tror jag), nu måste jag bara hitta en 15VDC power nånstans ifrån...
Annars så fick jag ihoplödd min programerare idag (Velleman k8048 tror jag), nu måste jag bara hitta en 15VDC power nånstans ifrån...
-
- Inlägg: 31
- Blev medlem: 22 augusti 2006, 21:21:30
- Ort: Uppsala
- Kontakt:
Det bästa vore väl nästan att varje enhet är autonom, att man gör ett standardiserat adresskort(eller miniDUC som det heter i styr och reglervärlden) där man har ett antal ingångar och ett antal utgångar, sen kan man ladda ner konfigureringsdata via bussen till dessa som talar om hur ingångarna ska påverka utgångarna(t.ex. puls på ingång 1, dimma upp ljuset på samtliga lampor i rummet osv) och att detta fungerar även om mastercontrollern(server i detta fallet) är frånslagen(lagrat lokalt i något slags minne i adresskortet), då skulle man ju även(överkurs kanske) förbereda kortet med IR-fotodiod så kan man koppla till fjärrkontroll som den sen vidarebefordrar till mastercontrollern(i det här fallet servern) som i sin tur kan göra andra kommandon med den, tex stänga av belysningen i sovrummet etc etc. det blir mångsidigt och flexibelt, det svåra är väl att göra ett kort som är tillräckligt litet för att få plats i en apparatdosa. Och vill man göra det riktigt överkursigt så lägger man även till en IR-diod som vidarebefordrar alla kommandon mellan rummen(tex sänka stereon i vardagsrummet från köket med fjärrkontrollen) men nu börjar det kanske spåra ut lite, vilket inte är så ovanligt ..
men som sagt, färdiga adresskort som sköter ett rum med x ingångar och x utgångar och kanske lite mer lull och sen konfigureras dessa centralt och kommunicerar statusen på sina in och utgångar till en överordnad dator placerad någonstans. Det vore ju nackdel om servern skulle lägga av och man inte kan knäppa på lamporna i huset.

-
- Inlägg: 31
- Blev medlem: 22 augusti 2006, 21:21:30
- Ort: Uppsala
- Kontakt:
Jo det var jag som drog den andra tråden. =)
Bara för att parallellporten har x bitar så behöver det inte begränsa sig till x reläer. Ca tre databitar skulle räcka till "oändligt" antal reläer om man använder ett skiftregister och en latch. Du klarar dig dessutom utan uC.
Men serieporten är ju bättre eftersom du får dubbelriktad kommunikation och ett lätt gränssnitt att arbeta med i datorn. Nackdelen är att det kräver mer hårdvara...
Proove-fjärrbrytare har samma protokoll som Nexa och finns att köpa i trepack på Rusta för 189:-. Nio stycken för 567:- ...det får man nog inte så mycket Ductelrännor och kabel för.
En kommande plan i mitt projekt är att koppla en rf-mottagare till PC:n och på så sätt få feedback om brytarens faktiska läge, oavsett om det är jag själv eller grannen(!) som ändrat läge.
Hur du än gör så ska det bli spännande att följa det här projektet. Lita på att jag ska knycka alla dina bra idéer!
Bara för att parallellporten har x bitar så behöver det inte begränsa sig till x reläer. Ca tre databitar skulle räcka till "oändligt" antal reläer om man använder ett skiftregister och en latch. Du klarar dig dessutom utan uC.
Men serieporten är ju bättre eftersom du får dubbelriktad kommunikation och ett lätt gränssnitt att arbeta med i datorn. Nackdelen är att det kräver mer hårdvara...
Proove-fjärrbrytare har samma protokoll som Nexa och finns att köpa i trepack på Rusta för 189:-. Nio stycken för 567:- ...det får man nog inte så mycket Ductelrännor och kabel för.
En kommande plan i mitt projekt är att koppla en rf-mottagare till PC:n och på så sätt få feedback om brytarens faktiska läge, oavsett om det är jag själv eller grannen(!) som ändrat läge.
Hur du än gör så ska det bli spännande att följa det här projektet. Lita på att jag ska knycka alla dina bra idéer!

En annan synpunkt på serieport versus parallellport är att båda blir allt mer ovanliga på våra kära datorer. Båda går att ersätta med USB-adaptrar, men det är problem att köra bitstyrning på en parallellport över USB. Och även om man kör med en "riktig" port så krävs det dessutom speciella drivrutiner för att få tillgång till porten.
En serieport som skickar normal asynkron data är däremot kompatibel även med USB-adaptrar och kräver inga speciella drivrutiner alls. Därför använder jag alltid serieporten för sånt här.
En serieport som skickar normal asynkron data är däremot kompatibel även med USB-adaptrar och kräver inga speciella drivrutiner alls. Därför använder jag alltid serieporten för sånt här.