Hoofdcategorieën

Nieuw reactie in topic: [EiP] room control

Let op:
  • Reageer ontopic, plaats geen onzinnige berichten en ga niet flamen of uitlokken (trollen).
  • Zie je iets dat niet door de beugel kan, attendeer dan een moderator via een topicreport maar post hierover niet in het topic, dat werkt alleen averechts. Zie ook de policy die wij op dit forum hanteren.
  • Lees je eigen bericht even door voor je het post.

Insert message
 

Let op! Het laatste bericht in deze discussie is meer dan 2 weken oud!

 

Smilies: :) :( ;) >:) :> :P :9 :o :*) :'( 8) :+ :D _/-\o_ :9~ O+ :O }:O :/ :| :X :? 8)7 |:( O-) :z ;( meer »

Page navigation

Laatste reacties:

 
Inleiding
Omdat ik van de zomervakantie niet echt iets om handen heb, heb ik me voorgenomen een nieuw - dit keer wat groter - electronica project te starten en wel een 1337 room control system voor mijn kamertje.

Na een middagje nadenken kwam ik tot de conclusie dat mijn systeem toch tenminste de volgende (technische) functies moet incorpereren:
• Het moet draaien op een nog te bouwen pentium 2-3 systeempje.
• Alle apparatuur (nodes) moeten op dezelfde maximaal 2-wire bus aangesloten kunnen worden
• Configureerbaar via webinterface (en eventueel in de toekomst met voice-control).
• Het systeem moet compatible (of iig bridgable) zijn met de welbekende klik-aan-klik-uit (achtige) systemen.
• Ik ben van plan in de nabije toekomst een deel van mijn verlichting te vervangen met een RGB-led systeem. Hiermee moet het uiteraard ook goed werken.

Software
Omdat ik niet zo houd van het combineren van verschillende stukken software en nog geen software heb gezien die alle functies die ik hierboven noem heeft, ben ik zelf aan de slag gegaan en ben ik in java begonnen aan een stukje programmatuur dat als daemon proces op de server gaat draaien en alles controleert. Via een telnet-achtige interface is vervolgens van elke node de huidige status op te vragen en de nog te bouwen webapplicatie (php) vertaalt de telnet commando's naar een echt werkbare interface.

De bus
Om alle nodes met elkaar te laten communiceren zal ik een bus bouwen gebaseerd op de RS-485 specificatie waar twee-wegs communicatie met 1 masternode mogelijk is ('party-line'). De feitelijke communicatie gebeurt net zoals bij RS-232 op een vooraf bepaalde baud snelheid en een start en stopbit bij elke byte:
http://upload.wikimedia.org/wikipedia/en/8/85/RS-485_waveform.png
Elke childnode heeft een (virtueel) geheugen, waar de master data naartoe kan schrijven of data uit kan trekken. Als communicatieprotocol wil ik het volgende gebruiken:
When writing:
    Master > Slave: 101010ii iiiiiiii aaaaaaaa aaaaaaaa dddddddd
When reading:
    Master > Slave: 110011ii iiiiiiii aaaaaaaa aaaaaaaa
    Slave > Master: 111000ii iiiiiiii dddddddd

i: device id
a: address
d: data
Het nadeel hiervan is dat bijvoorbeeld schakelaar nodes elke paar milliseconden gepulled moeten worden om statusveranderingen aan te geven, maar indien slaves zonder request gaan praten op de lijn gaat het ook niet helemaal goed. Hier is dus eventueel ruimte voor verbetering, maar non-master multi-point bussen zijn vaak een stuk lastiger te implementeren.

Master node
De master node zal uit een eenvoudige rs232 <--> rs485 converter bestaan, mbv een max232 en een sn65hvd07, waarbij de RTS lijn van de seriele poort gebruikt zal worden om de master node in transmit mode te zetten.

Child nodes
Over de verschillende child nodes heb ik nog niet echt nagedacht, maar ik zie voldoende mogelijkheden om hier wat moois van te maken. Enkele voorbeelden.

rgb-light control unit
Doel: het aansturen van een rgb-(led-)verlichting.
Adresindeling:
0x0001 RW : rood
0x0002 RW : groen
0x0003 RW : blauw


klik-aan-klik-uit bridge
Doel: het controleren van klik-aan-klik-uit switch en dimmer units.
Adresindeling:
0x0001 RW : tx-kanaal-selectie
0x0002 R- : zodra hier een 0x01 naartoe wordt geschreven wordt het 'aan' signaal
            verstuurd naar het betreffende kanaal; bij een 0x00 wordt het 'uit' signaal verstuurd.
0x0003 R- : rx-kanaal
0x0000 RW : interrupt-byte: indien 0x00 is er niets gebeurd, indien 0x01 is er een
            uit-signaal ontvangen, indien 0x02 is er een aan-signaal ontvangen; nadat
            de master deze byte heeft gelezen met een waarde anders dan 0x00
            moet hij er opnieuw 0x00 naartoe schrijven.


4-button-unit met lcd
Doel: bijvoorbeeld snel schakelen tussen 4 voorgedefinieerde verlichtings-programma's.
Adresindeling:
0x0000 RW : interrupt-byte: geeft aan welke knoppen ingedrukt
            zijn (geweest) sinds de laatste poll. Elke knop wordt gerepresenteerd door
            een van de 4 least significant bits. Net zoals bij de kaku bridge moet de
            master er 0x00 naartoe schrijven zodra hij deze gepolled heeft.
0x0100 RW : lcd character 1
...
0x0150 RW : lcd character 80
Naast de bovengenoemde geheugenadressen zal elke childnode drie identificatiebytes krijgen - zodat de software de juiste drivers kan laden - die read-only is op adres 0xFFFD, 0xFFFE en 0xFFFF.

Voor elk type device zal een device driver worden gemaakt, die bijvoorbeeld ook als taak heeft elke paar milliseconden de interrupt byte (0x00) te lezen voor de betreffende nodes.

Doel van dit topic
Het project is momenteel nog in onderzoeksfase, en ik open het topic nu al vooral om jullie mening en tips aan te horen, zodat ik eventuele goede ideeen of wijzigingen kan gebruiken voordat de eerste printplaatjes geetst worden. Gedurende de vorderingen komen er natuurlijk mooie plaatjes en fotos :).
 
 
Update 0x00 - Meer software
Goed, ik begin maar geljk met een update over de java software waarmee ik aan de slag ben gegaan. Het idee is dat het systeem uit verschillende configureerbare modules bestaat, die je met een dbdesigner-achtige tool aan elkaar kunt verbinden. Naast modules die de devices op de bus representeren, zal er een library aan standaard modules komen voor enkele nuttige functies (logic and/or ports, flipflops, etc). Uiteraard hoort hier ook een mooie configuratie-util bij:
http://public.emielmols.info/homecontrol_topic/update0x00/configuratorapp.png

Daarnaast heb ik nagedacht over hoe ik vanuit java de seriele poort ga aansturen. Waarschijnlijk gaat dit gebeuren met de rxtx library, die zelfs native RS-485 ondersteuning lijkt te hebben. Hier kan ik pas mee aan de slag als ik het p3-tje heb ingericht voor dit project. Helaas ben ik erachter gekomen dat het moederbord van mijn mooie compacte Compaq Deskpro EN zo nu en dan vage pci bus errors geeft, waardoor het ding problemen heeft met ethernet transfer rates boven de 20kb/s (zowel onboard netwerkkaart als plugin kaartjes). Hier moet ik dus even een vervanger voor op de kop tikken.
 
 
Ziet er hip uit :) Je zou trouwens het pollen kunnen tegengaan door het volgende protocol: master stuurt 'idle, geef een gil als je iets wilt'-commando. Slaves gaan fijn idlen, zodra er eentje iets wil gaat 'ie een willekeurige byte over de lijn versturen. Als 'ie niet iets wil, stuurt 'ie niets en wacht 'ie tot er een (random) byte over de lijn is gegaan. Op die manier kan alles fijn blijven idlen totdat er iets gebeurt, waarop de master fijn kan rondvragen wie het gedaan heeft. Omdat het geheel alleen op het feit dat er activiteit is triggert, en niet op de verzonden byte zelf, boeien collisions niets.

Edit: Voor het geval dat het niet obvious was: De master kan de slaves natuurlijk zelf ook uit die state halen door een random byte te versturen.
 
 
Goed plan inderdaad, ik zal binnenkort sowieso eens een testopstellinkje maken en dan een en ander mbt de bus testen.
 
 
Update 0x01 - RS485 transceivers doen het
Klein updateje. Daarnet een one-way testsetup gemaakt met de RS-485 transceivers en dat doet het prima. Pica's:

http://public.emielmols.info/homecontrol_topic/update0x01/thumb/PICT0010.jpg
Breadboard-kabel-rommel

http://public.emielmols.info/homecontrol_topic/update0x01/thumb/PICT0014.jpg
Rechts-boven de max232, rechtsonder de transceiver die transmit; door de blauwe en gele kabel gaat het rs485 signaal; in het midden onder de receiver die de gedecode data doorstuurt naar een rs232 driven lcd controllertje

http://public.emielmols.info/homecontrol_topic/update0x01/thumb/PICT0011.jpg
En er komt tekst op het lcd \o/

http://public.emielmols.info/homecontrol_topic/update0x01/thumb/PICT0012.jpg
Dankzij de MAX232 werkt dit alles met zowel high- als low-voltage RS-232 - uit deze convertor komt low-voltage.

http://public.emielmols.info/homecontrol_topic/update0x01/thumb/PICT0013.jpg
En een overzichtspic.



@hieronder: fixed
 

Acties: [quote]


Door: roelieboelie
 
Ik kan je plaatjes niet vergrote, krijg ik een 404 error. ;(

//edit: open dir, ook makkelijk :) http://public.emielmols.info/homecontrol_topic/update0x01/
 
 
Kleine update, ik heb net na 2 dagen kutten het capturen van het klik-aan-klik-uit signaal (voor de kaku-bridge) voor elkaar gekregen. Omdat ik mn AB niet open wilde slopen zoals in het topic hierover ([howto] Klik-aan-klik-uit aan computer) is gedaan, heb ik gebruik gemaakt van een 433mhz ontvangertje en met een lpt poort 'logic analyzer' de data ingelezen. Het resultaat:
http://public.emielmols.info/woei.png.
Het aan-commando op kanaal A/1

Ik ga nu meerdere signaaltjes (verschillende kanalen etc) capturen om het ding te rev-engineeren en dan volgt een echte update.
 
 
quote:
Emiel schreef op woensdag 26 juli 2006 @ 13:54:
Kleine update, ik heb net na 2 dagen kutten het capturen van het klik-aan-klik-uit signaal (voor de kaku-bridge) voor elkaar gekregen. Omdat ik mn AB niet open wilde slopen zoals in het topic hierover ([howto] Klik-aan-klik-uit aan computer) is gedaan, heb ik gebruik gemaakt van een 433mhz ontvangertje en met een lpt poort 'logic analyzer' de data ingelezen. Het resultaat:
[afbeelding].
Het aan-commando op kanaal A/1

Ik ga nu meerdere signaaltjes (verschillende kanalen etc) capturen om het ding te rev-engineeren en dan volgt een echte update.

Post je die config dan ook even door aan mij? Ik ben bezig met een simpele website waar users deze config's zelf kunnen uploaden. Nog niet klaar maar het komt er aan in ieder geval.
[/semi-offtopic]
 
 
Op Megabit ga ik volgende week een presentatie geven over DoIP. Dit is een concept protocol op dit moment waarmee verlichting e.d. kan worden aangestuurd. Lijkt hier een beetje op moet ik zeggen, al hoewel DoIP denk ik dat meer gevorderd is. Zal proberen eerdaags een website online te zetten.
 
 
quote:
Emiel schreef op woensdag 26 juli 2006 @ 13:54:
Kleine update, ik heb net na 2 dagen kutten het capturen van het klik-aan-klik-uit signaal (voor de kaku-bridge) voor elkaar gekregen. Omdat ik mn AB niet open wilde slopen zoals in het topic hierover ([howto] Klik-aan-klik-uit aan computer) is gedaan, heb ik gebruik gemaakt van een 433mhz ontvangertje en met een lpt poort 'logic analyzer' de data ingelezen. Het resultaat:
[afbeelding].
Het aan-commando op kanaal A/1

Ik ga nu meerdere signaaltjes (verschillende kanalen etc) capturen om het ding te rev-engineeren en dan volgt een echte update.


ik kan niet wachten tot dat je gegevens over dit protocol kan publiceren. ik heb inmiddels wel de onderdelen van mijn logic analyser binnen maar nog in elkaar gezet.

ik ben ook wel eens bezig geweest met een scoop, maar dan kwam ik niet verder als dat het pulsjes van 0,5mS en 1mS waren.

edit,
ik zie dat je bezig bent met een rs458 bus. ik weet niet in hoe verre je verstand hebt van elektronica maar misschien moet je ook eens gaan kijken naar een CAN netwerkt.
het voordeel is:
heel betrouwbaar, het word ook in autos toe gepast.
ook twee draads.
geen onnodige belasting op het netwerk
grote afstanden > lage snelheid
korte afstanden > hoge snelheid

berichten hebben een bepaalde priortijd waardoor je berichten van de "master" altijd door kunt laten komen. berichten van de "nodes" geef je dan een lagere prioritijd, zodat ze later door komen.
 
 
kan het ook niet interessant zijn, om het zo in elkaar te steken dat het op een (draadloze) router kan draaien? 8)
Tegenwoordig draaien veel van die dingen linux... (veel) minder stroomverbruik, geen fans en kleine behuizing?
 
 
Update 0x02 - kaku reverse engineered
Hier een update over het revengineeren van het kaku protocol:

http://public.emielmols.info/homecontrol_topic/update0x02/samples/a1on.png


De data is gecodeerd in de vorm 1x0, waar x de eigenlijke databit is (200% overhead dus). De databits worden per 25 verstuurd in het volgende formaat:
0 h 0 h 0 h 0 h 0 k 0 k 0 k 0 k 0 0 0 1 0 1 0 c 0
h: huis-installatie (A-P)
k: kanaal (1-4, 1-4)
c: commando (1 = aan, 0 = uit)

Van de h's en de k's staat de msb rechts.

De hele reeks van 25 bits wordt in 32ms verzonden. Zoals je ziet is de afbeelding hierboven van een commando met h = 0 (A), k = 0 (1, 1) en c = 1 (aan)

Dit alles is reverse engineered met een 433mhz ontvangertje en lpt poort probe software.

Nu ik dit weet kan ik verder met het programmeren van de controller voor de kaku-bridge, een pic18f1320.

update @ 20060629: En het aansturen van de kaku units met een pic18f1320 gaat inmiddels prima. Klik hier voor de gebruikte c source. Toen het na heel wat timing tweaks nog niet werkte en er toch een bijzonder goede gelijkenis was tussen de verzonden data door de controller en de verzonden data door een kaku ab (zie afbeelding hieronder), bleken de setjes alleen te reageren als de transmitter dezelfde sequence 3 keer herhaalde binnen 500ms.
http://public.emielmols.info/homecontrol_topic/update0x02/verschil.png
 
 
@LauPro: ik ben benieuwd.

@ymoona: ik ben bekend met CAN inderdaad, het probleem is dat implementatie hiervan toch relatief een stuk ingewikkelder is. Mocht de bestaande RS485 oplossing nu niet (betrouwbaar) werken, zal ik hier zeker een en ander mee testen.

@Promy: ik heb hier zo'n sweex routertje liggen, maar daar kan geen java op draaien, waardoor ik over zou moeten stappen naar c++ of iets dergelijks. Tevens is voice-control geen mogelijkheid meer en wordt het toch programmeren met het gebrek aan system resources in gedachte.

@hieronder: Een software oplossing blijft een stuk makkelijker, makkelijker upgradable en werkt waarschijnlijk nog beter ook.
 
 
Voor voice-control kan je ook dit ding gebruiken: http://www.sensoryinc.com/html/products/vrstamp.html
Al lijkt het me helaas niet een ding wat je in een middagje onder de knie hebt.
Verder heeft Atmoz volgens mij ook een keer iets gemaakt met spraakherkenning.

Edit:
Atmoz heeft een RSC-364 van Sensory gebruikt (is ook de fabrikant van de VRstamp).
 
 
had dragondictate (heet dat tegenwoordig niet anders??) geen scripting taal? ik dacht van wel.

ik heb zelf wel eens met de spraakherkenning van microsoft gespeeld (SDK kun je gewoon downen) , maar die is niet super.
 
 
Ik heb idd ook eens met de Microsoft SDK geklooid, maar dat was echt niks.

Dragon naturally speaking 8 SDK, is alleen niet gratis (zo te zien), en dus hoogstwaarschijnlijk te duur.
 
 
nee dat klopt, er is ook nog een opensource project (even op sourceforge zoeken) , maar daar kon ik niet zoveel mee (ben maar een VB prutser).

ik meen me te herinneren dat ik die dragon naturally speaking al eens ergens goedkoop heb zien staan inc sdk.

mijn doel was eerst de touchinterface aan de gang te krijgen die ik in gedachte had, en daarna eventueel nog een spraak interface (via blue-tooth headset ofzo).
ik maak gebruik van een 433 zendertje via winlirc met de config(s) uit het klikaan/klikuit topic , en dat werkt prima. ik heb een 12"touchscreen in de woonkamer hangen voor de bediening.
ik heb een velleman usb-i/o interface boardje, en een aantal velleman relaisboardjes voor andere meuk, de rest gaat klik/aan klikuit worden (helaas geen override knop op de klik/aan klikuit stopcontactjes , das handig als je server crashed, die goedkopere blokker dingen hebben dat wel)
 
 
Update 0x03 - kaku bridge vorderingen en printplaatjes ontworpen
En is weer flink wat gebeurd; tijd voor een update dus \o/. Nadat ik de laatste firmware heb gemaakt voor de controller van de kaku bridge die nu kaku commando's kan versturen adhv requests die via de rs485 bus binnenkomen, ben ik het geheel gaan testen met een simpel stukje java code die gebruikt maakt van de rxtx lib (die in Windows in ieder geval voortreffelijk werkt). Dit testen maakt totnogtoe gewoon gebruik van een directe rs232 verbinding, het testen met de echte rs485 link moet nog gebeuren, maar hier verwacht ik geen problemen.

Daarom ben ik ook verder gegaan met het ontwerpen van de printplaatjes voor de rs232 - rs485 converter en de kaku bridge node.

rs232 - rs485 converter
http://public.emielmols.info/homecontrol_topic/update0x03/rs232_rs485.png
Hier had ik de keuze om een externe 5 volt voeding te gebruiken, of met bijvoorbeeld de RTS lijn, een diode en een 7805 de benodigde 5 volt uit de seriele poort te trekken. Uiteindelijk hier toch maar niet voor gekozen, mede omdat ik de RTS lijn nodig heb om de rs485 transceiver in transmit mode te gooien en omdat deze module toch bij een pc komt te hangen, waar ik natuurlijk 5 volt gewoon uit een molexje kan trekken. Tevens gebruikt een max232 met al zn condo's toch redelijk wat stroom heb ik het idee, en met de gemaakte keuze kom ik straks in ieder geval niet voor een verrassing te staan bij de uiteindelijke hardware. Naast de geplande onderdelen (max232, sn65hvd05) heb ik nog een extra ledje toegevoegd en is er ruimte voor een terminator weerstand tussen de rs485 lijnen. Daarnaast is er, wellicht ten overvloede, nog een elcotje aanwezig om de voeding wat te stabiliseren.

Kaku bridge node
http://public.emielmols.info/homecontrol_topic/update0x03/kaku_bridge.png
Dit printje wordt naast de bekende sn65hvd05 uitgerust met een pic18f1320 als controller die portb.0 als ingang gebruikt om de radio receiver (rx434) te monitoren, porta.0 gebruikt om de radio transmitter (tx434n) aan te sturen, dezelfde transmitter kan in- en uitschakelen mbv een standaard transistor via porta.1 en naast de hardware uart poorten die verbinding leggen met de rs485 transceiver een ledje ter beschikking heeft op PORTB.2. Verder heeft deze print een ingebouwde rs485 terminator, die kan worden geactiveerd met een jumpertje. Ook voor dit printje is een externe voeding nodig, waarvan de spanning wederom wordt gestabiliseerd met een elco.

De gehele setup zal ik binnenkort op een breadbordje uitproberen, en als dit allemaal werkt kan het etsen, boren en solderen beginnen :).
 
 
Dit klinkt wel enigzins bekend.
Het Home Control Project. Alleen vanwege tijdgebrek is er nix van gekomen. Mijn idee was om het in te bouwen in de bestaande inbouwdozen, en te communiceren over de 230V kabel.
 
 
Update 0x04 - rs232 - rs485 printje af
En het rs232 <--> rs485 converter printje is af! Na heel wat mislukte etspogingen (het is weer een tijdje geleden en de etsvloeistof deed het niet goed meer) vind ik het uiteindelijke resultaat, gemaakt met nieuw etsmiddel, erg goed. Hierbij een snelle update met alleen wat pictures.

http://public.emielmols.info/homecontrol_topic/update0x04/thumbs/PICT0025.jpg
Onderkant

http://public.emielmols.info/homecontrol_topic/update0x04/thumbs/PICT0028.jpg
Bovenkant

update: en de testresults lijken prima. Ik heb wel de pull-up/-down weerstanden voor de rs485 lijnen van mn bordje af kunnen halen, want de transceiver doet dat zelf al :). Op naar het printje voor de kaku bridge node zodat ik het echt kan testen.

update: de uiteindelijke brd (eagle) kan hier worden gedownload door de geinteresseerden. Let erop dat weerstandje E$19 en E$14 niet geplaatst hoeven te worden. De weerstanden waaronder een blauwe lijn is geplaatst zijn gewoon draadbruggen; de waarden van de overige componenten komen niet erg precies en kun je zelf bedenken door de datasheets van de gebruikte ic's te bekijken.
 
 
Mooi, mooi
mijn EiP ligt voolopig stil :(
Ik sta op het punt van componenten te halen, maar mijn 2de zit :r gaat voor :| kut chemie

Je bent wel zuinig geweest met de tin rond je connector zie ik :P
Ik vind je banen ook wat dun, mja kan ook aan mij liggen.

Voor de rest: Goe bezig!!
 
 
Zojuist het printje van de KAKU bridge geetst. Morgen het leukere gedeelte: boren en componenten solderen :).

http://public.emielmols.info/homecontrol_topic/update0x05/thumbs/PICT0032.jpg

Overigens vind ik het aantal replies hier een beetje tegenvallen. In fact, na 5 updates zijn bijna de helft van de posts hier van mijzelf. Graag zou ik toch willen weten hoeveel mensen dit nu serieus volgen, anders is het typen van de updates het me niet echt waard.

@hieronder: Ah, dat geeft de burger moed :). Nouja, na het boren en solderen komt morgen weer een echte update.
 
 
quote:
Emiel schreef op donderdag 03 augustus 2006 @ 00:32:
Zojuist het printje van de KAKU bridge geetst. Morgen het leukere gedeelte: boren en componenten solderen :).


Overigens vind ik het aantal replies hier een beetje tegenvallen. In fact, na 5 updates zijn bijna de helft van de posts hier van mijzelf. Graag zou ik toch willen weten hoeveel mensen dit nu serieus volgen, anders is het typen van de updates het me niet echt waard.
Ik volg deze EiP, alleen kan ik niet echt meepraten over dit soort dingen en om nou na iedere update 'goed bezig!' ofzo te typen vind ik ook weer een beetje suf.

goed bezig!
 
 
Ik volg het zeker,
alleen vind ik het nogal nutteloos om een reply te zetten, gewoon om een reply te zetten...
Naja, ik hoop dat je blijft updaten, ziet er zeer leuk uit :) !
 
 
Ik volg :) Joehoe IKKE :p Hierzo. Ja ik ;)

Ik vind het ook wel tegenvallen, maar dat is eigenlijk meer iets van het volledige Elektronica gedeelte. Soms een ganse dag dat er geen post is in dit deel van tweakers.

Nu ja, het is misschien omdat het nog tamelijk nieuw is; of er zijn weinig tweakers into elektronica. Die mensen zullen meer op CO zitten dan zeker :/

Edit: How zekers 3 replies in 1 minuut :D en dat op dit uur.

Edit2: Ik denk trouwens dat deze EiP meer gevolgd wordt als die van mij ;(
 

VNU Media logo Powered by True

© 1998 - 2008 Tweakers.net - Alle rechten voorbehouden

Uitgever van: