Domotica Ontwikkelen

Ik ben maar zo vrij geweest om al een eerste opzetje te maken op de wiki pagina. Nu dus nog per onderdeel de informatie beschikbaar stellen zodat we per onderdeel de voor en nadelen kunnen bespreken.

Misschien ook wel leuk dat iedereen kort op de wiki aangeeft wat zijn achtergrond is, zodat ook een beetje duidelijk is welke kennis je hebt en waar je zou kunnen bijdragen.

Marc

Ik wil natuurlijk ook graag meewerken. Mijn hosting gaat niet offline trouwens, ben er email afhankelijk van.

Mijn voorkeur gaat uit naar draadloos via zigbee.
Binnenkort eens was modules bestellen.

Arne heeft van mij de voorkeur gekregen (zonder reden hoor) hierbij al bedankt voor zijn support.
Jullie zeggen, om eerst op die wiki pagina te beginnen, ik vind dit een slecht idee. Porteren gaat namelijk niet omdat ik op die wiki-site geen ftp of MySQL heb. Ik ben nu bezig met het opzetten van Wiki op de defenitieve hosting. Denk al eens na over een goede domeinnaam ;).

Waar halen we EIB kabel of andere alternatieven?

als kabel zou ik eerder CAT5 UTP gebruiken, algemeen te vinden, constante kwaliteit, twisted pair in overvloed

@ The dutchman

Wat is er mis met het gebruik maken van bestaande wiki platformen dan? Lijkt me een hoop minder tijd te kosten (tijd die we beter in onze technische vaardigheden kunnen stoppen:P). Bovendien werkt het over algemeen betrouwbaarder dan dat er één iemand zo`n wiki beheerd.

laten we discussies voeren in dit forum

De huidige wiki kan gebruikt worden om besluiten genomen in deze discussies samen te vatten

De definitieve wiki heeft dan enkel de uitgewerkte "dossiers"

Ik heb al gezegd wat er mis is met zo'n wiki,
Als je wil overstappen naar een fantsoenlijke hosting, en er staat al veel informatie op je wiki, dan moet je het link voor link, pagina voor pagina overzetten. En dat is niet echt een hobby van mij...
Een kwestie van beter voorkomen dan genezen denk ik.

Op 18 januari 2010 16:48:56 schreef The Dutchman:
Niet helemaal correct vrees ik. Bij CAN heb je de identifier van je frame. Dit geeft aan waar het bericht over gaat. Als er een master zend, dan gaat elke module dit bericht ontvangen (dus ze zijn wel wakker). Als de identifier vertelt dat dit bericht helemaal niets te maken heeft men hun functie (temperatuur van sensor doorsturen of...), dan belist de module om daar niets mee te doen. En ik denk zelfs dat de descision Matrix bij VSCP exact hetzelfde principe hanteerd.

Ik neem aan dat dit een reactie op mijn bericht is?

Je hebt natuurlijk gelijk. Je zult sowieso bij elke message een wakeup hebben. Het voordeel van een multimaster systeem is dat je niet om de x tijd moet zitten pollen. Als je niet moet pollen, en er gebeurt niets dan kunnen de modules rustig blijven slapen.

# the dutchman

Bedenk wel dat het zelf opzetten van zo`n wiki al een behoorlijke klus op zich is, het is niet alleen opzetten maar ook onderhouden ervan en er zullen dan ook meerdere mensen mee om kunnen gaan om niet afhankelijk te worden van elkaar.

@sven, zo denk ik er precies ook over. Dit forum is ideaal omdat ook iedereen het blijft zien. Anders krijg je een afsplitsing waarbij het zonde is feedback te missen van personen uit dit forum.

Multi-master systeem is noodzaak, weg met RS485 is dan mijn besluit.
Hoewel ik vind dat je voor verlichting aansturing wel DMX kan gebruiken, dit is zowaar RS485 (maar dan ook weer vastgelegd). Hier moeten continu waardes worden doorgestuurd naar de dimeenheden, en hier zou de overhead van CAN onnodig zijn lijkt me.
Om op de kabel terug te komen:

Letterlijke quote van buitenaf iemand die ooit CAT5 UTP voor KNX heeft gebruikt

Long story short, it caused all sorts of units to seem faulty as it wasn't always communicating properly. The main problem is the cable thickness. Even when "doubled up", the CAT5 wasn't making proper contact within the KNX Branch Terminals. This led to many site visits before we pinpointed what was wrong. So, while it seems like an easy out I would definitely recommend against it. (If I were you, I'd actually run, kicking and screaming.)

If sourcing Certified KNX Cable is the problem, I'd recommend looking at http://www.knxshop.co.uk, or else http://www.eibshop.de. (Don't know where you're writing from ... your name would lead me to think the Netherlands, so maybe eibshop rather than knxshop.) They don't seem to sell to the general public, but it's worth a shot. Otherwise, try Eelectron, (http://www.eelectron.com) as I do know they manufacture Certified KNX Cable and should direct you to a retailer in your area.

En kijk is naar de prijs:
http://www.eibmarkt.com/cgi-bin/eibmarkt.storefront/DE/Product/NS01401…
vs Farnell:
http://be.farnell.com/belden/ye00906-00100/cable-bus-lszh-2-pair-grn-1…

@Willyp, Wiki opzetten is gebeurd, onderhoud gaat genoeg automatisch.

Ik ga hierin mee met The Dutchman. Beter meteen goed dan later alles over moeten zetten met de hand. Als we dan ook meteen een member login maken kan iedereen die meewerkt editen (is maar een wil idee hoor).

Ik ben al heel blij dat Arne en The Dutchman een beetje het voortouw genomen hebben in het project. Ik ben absoluut vóór een internationaal initiatief maar ik ben van mening dat we éérst een goede gefundeerde start moeten maken. Een goede basis leggen is heel belangrijk.

Ik zie graag een systeem wat onafhankelijk van de beschikbare hardware werkt (dus Physical Layer Independant). Op deze manier kunnen we alle modules laten communiceren op elke mogelijke manier.

Ik zie het voor me als een bedraad systeem waarbij we gateways maken waardoor ook draadloze modules mee kunnen werken. Of we nu CAN gebruiken of iets anders maakt me niet zoveel uit. Als het maar onafhankelijk is van de Physical Layer.

Ik heb vanmiddag met roadrunner84 zitten kijken naar VSCP maar ook ik ben nog niet overtuigd van deze oplossing.

Als ik nadenk over de structuur dan lijkt een multimaster systeem me erg nuttig omdat het veel stabieler is lijkt me (één node kwijt = geen probleem). Wat betreft slapen van de modules weet ik nog niet hoe ik dit exact moet zien. Is er geen mogelijkheid tot multimaster waarbij er alleen een wakeup is al de node de goede data krijgt?

Ik lees ondertussen dat er alweer wat posts bij zijn gekomen dus ga ik daar ook maar meteen op in. Ik was niet van plan om heel speciale kabel te gaan kopen voor een project als dit. Ik ben van mening dat CAT5 of 6 zeer belangrijk is voor het slagen van dit project. Dure kabel betekend mijns inziens veel mensen die afhaken. Ergens in den beginnen is er toch al overeengekomen dat we vooral ook goedkoop willen werken?!

Ik hoor wel weer feedback voorbij komen hier of op de wiki.

Groeten

Wat betreft slapen van de modules weet ik nog niet hoe ik dit exact moet zien. Is er geen mogelijkheid tot multimaster waarbij er alleen een wakeup is al de node de goede data krijgt?

De node moet dan wel eerst wakker zijn om te controleren of het goede data is. Maar na de identifier kan de module alweer gaan slapen hoor. Duurt dus maar 11 of 29 bits.

Ik ben van mening dat CAT5 of 6 zeer belangrijk is voor het slagen van dit project. Dure kabel betekend mijns inziens veel mensen die afhaken. Ergens in den beginnen is er toch al overeengekomen dat we vooral ook goedkoop willen werken?!

Ik lees dat mensen dit in hun huis willen plaatsen. Dan denk ik dat stabiliteit over goedkoop moet komen. 30€ voor 100m kabel, dat is niet duur. Ik weet niet wat UTP kost, maar veel schelen zal dat niet.

@Dutchman

Ik las je link pas later. €30,- voor 100 meter is inderdaad zeker niet duur. Het slapen en multimaster klinkt goed zoals je het uitlegt. Ik meen dat er overigens ook AVR's/PIC's zijn die op de UART en de Core na alles stil kunnen leggen dus dat is een mooie tussen status voor de processor. Voor de rest kunnen ze inderdaad lekker gaan slapen ja.

Waar ik me bij CAN (ik neem tenminste aan dat je daar nog steeds erg graag naar toe wil) wel zorgen over maak ik de integratie met wireless modules etc. Is het mogelijk om bedraad en draadloos te combineren in één netwerk? Kun je ook alleen draadloos werken? Ik weet namelijk zeker dat we een hybride oplossing moeten verzinnen waarbij het niet uitmaakt of je nu zigbee/Wifi of wat dan ook gebruikt. Als het maar werkt. Zoals ik al eerder aangaf, onafhankelijk van de physical layer. Is dit mogelijk met een CAN oplossing?

Ik wacht overigens eerst het betoog over VSCP af om te zien of dit mij misschien kan overtuigen.

Mzzls

EDIT: Ik heb trouwens al wat op de wiki bij de functies aangevuld zoals ik mijn verlanglijstje tot nu toe zie.

@ Dutchman
Misschien ga je soms wat snel. Als je dan toch weer een andere wiki opzet, laat dan even weten voor welke je wil kiezen. Straks komen we er misschien opnieuw achter dat we beter voor iets anders hadden kunnen kiezen.

Kan maar zo zijn dat CAN de beste oplossing is, maar laten we de voor en nadelen maar naast elkaar zetten, zien we vanzelf of het al een gelopen race is.

Wat betreft kabel zou ik niet direct kiezen voor EIB kabel. Dat het duurder is, is al grotendeels achterhaald zie ik. Maar het is wel minder multifunctioneel. Als je ergens een UTP kabel hebt getrokken, kan je hem achteraf ook prima gebruiken voor andere toepassingen. EIB kabel heeft minder aders, is niet getwist en veel stugger. Nog een hele klus om die goed door buizen heen te trekken.

Wat betreft dat contact probleem. Daar heb je alleen mee te maken als je EIB modules gebruikt. Aangezien we zelf modules willen ontwikkelen is dat dus geen probleem.

Marc

@Dutchman

Heb je alleen een wiki? Voor een project als dit lijkt een volledig pakket als redmine me handiger, inclusief repository, wiki, tickets en roadmap mogelijkheden.

Hebben we nu inmiddels één of twee wiki's? Ik volg het ff niet meer. Graag een beetje duidelijkheid :D.

Misschien kunnen we bij deze afpreken dat we iemand de leiding geven over het hele www gebeuren rondom dit project. Zo voorkomen we onduidelijkheden. Als je me de link doorstuurt zet ik deze in de openingspost erbij voor de duidelijkheid.

Groeten

[Bericht gewijzigd door JustME125 op (51%)]

Zover ik begrijp is er 1 wiki bereikbaar (de eerste link van Dutchman) en is er een tweede onderweg. De tweede heeft de voorkeur omdat die op een dedicated host komt (met dank aan Arne).

Wat betreft het overzetten van de ene wiki naar een andere, da's een stukje cake. Even een wget, awk er over heen en resultaten pasten op de nieuwe wiki.

@MdW Ik zie net, je hebt EIB in 2 vormen, 1 Quad en 2 Pair. De link die ik gaf voor 30€ zal dan wel 1Quad zijn vrees ik...EDIT 59€ voor dubbele twisted pair. Trouwens, al wat bij domotica komt zien is namelijk tamelijk duur. Domotica is dan ook een luxeonderdeel van een woning. Wat denk je dat een wireless touchscreen maken kost om alle instellingen te doen terwijl je door het huis loopt? ;)

Misschien loop ik te hard van stapel, maar ik wil ook dat het een beetje voorruit gaat en dat er iets bereikt wordt. Of het nu een Wiki is of redmine of weet ik veel welk ander systeem dat maakt mij niet uit. Maar alles 4 keer doen heeft geen zin. Wat de Wiki's betreft moet je enkel kijken naar degene die hier met zijn URL opstaat. Degene die ik opgezet heb is weer evensnel verwijderd.

Dan is het misschien aangewezen om eerst een akkoord te vinden om de data op te slaan. Wiki-site.com is mijns insziens geen langdurige optie. Hosting hebben we al, dus enkel nog het systeem kiezen. Redmine ziet er ook leuk uit.

Voor CAN naar Wireless. Hier komen we in een snelheidsprobleem terecht. Als we van onze CAN bus geen snelheid willen verliezen, dan moeten we een soort van omzetter maken naar Wireless. Stel onze Wired CAN is 1Mbit/s (makkelijker haalbaar), en onze Wireless is 20kb/s (makkelijk haalbaar). Nu kun je dit op 2 manieren bekijken. Wired stuurt naar Wireless module, deze Wired naar Wireless node geeft een Wired ACK. En het 2de wireless gedeelte is dan volledige gescheiden. De ontvangst van deze data wordt dan op het Wireless netwerk gecontroleerd. Met als 1 nadeel, veel trager. Dit is natuurlijk onder aanname van een gedeeltelijk Wireless netwerk met een overschakeling. Volledig draadloos zou je eigenlijk gewoon CAN kunnen maken op een "laag" pitje. Inplaats van dat je data dan differentieel is wordt hij serieel. Voor de rest blijft echter alles hetzelfde.

@_danny_

dankjewel. Zo begreep ik het ook. De link naar de wiki staat inmiddels in de openingspost. Zodra de dedicated webspace er is plaats ik de nieuwe link wel.

Mag ik jou ook op de huidige wiki erbij zetten als teamlid? Mag je meteen daar wat over jezelf vertellen. :p

@The Dutchman
Bedankt dat je zo snel bezig bent met de webstek. Ik begrijp dat er dus al iets is geregeld met betrekking tot de hosting? Wie gaat dat stukje beheren? Hoe gaan we het allemaal invullen? Ik vind het allemaal best (klinkt een beetje ongeïnteresseerd misschien maar zo is het zeker niet). Ik vind het vooral belangrijk dat we één lijn trekken en die allemaal volgen dus wil ik bij deze vragen of jij dat de leiding wil nemen met betrekking tot de webstek. De invulling mag je wat mij betreft zelf bedenken maar opzich klinkt zoiets al redmine wel tof ja. Kijk er eens rustig naar, denk er eens rustig over na en maar er iets moois van. Tot die tijd redden we ons met de wiki die we hebben.

EDIT
Ik begrijp uit je verhaal dat wireless CAN met name op het gebeid van snelheid een probleem gaat worden. Is dit op te lossen? Kunnen we een volledig hybride netwerk maken? Dit is wel echt een must voor een fatsoenlijk open source project. Is het misschien een idee om van CAN af te stappen en een andere oplossing te bekijken mocht dit op het gebied van hybride beter zijn?! Lijkt me misschien handig. Ik wacht nog steeds op het betoog over VSCP van Ghole. Misschien brengt dat wel iets moois.

Mzzls

Indien je UTP combineert met RJ45 terminals denk ik niet dat je problemen zal krijgen hoor. Bovendien heb ik al tientallen bussen aangesloten via een UTP & op gewone klemmen. Nooit contactproblemen gehad. Als EIB-kabel dan ook nog niet getwist is, valt hij helemaal af voor mij.
Al kan deze keuze best wel individueel gemaakt worden lijkt mij. De manier van aansluiten is kwestie van een andere print. Dit is iets wat we allen toch wel zelf kunnen. Er gaan zowiezo variaties in prints komen omdat deze op andere plekken moeten ingebouwd worden. (verdeelbord, inbouwdoosjes Helia, inbouwdoosjes Bticino,...)

Ik denk dat het voor een hybride systeem beter is om uit te gaan van 2 aparte netwerken, die op bepaalde punten met elkaar communiceren.

Als het draadloze verkeer kan je rustig over de bedraade bus sturen (ivm logging, etc.). In de omgekeerde richting lijkt me dit minder nuttig. Ik zou eerder een bridge gebruiken die dan selectief bepaalde messages door de lucht stuurt. Draadloze modules kunnen dan "subscriben" op een bepaald (type) message waarin ze geïnteresseerd zijn.
Ik neem aan dat in een hybride systeem de draadloze modules zeer specifieke doelen hebben, bv. schakelaars. Als deze meestal zenden, dan moeten deze modules helemaal geen messages ontvangen. Ook als zowel lampen als schakelaar op draadloos zitten is er geen probleem. Als de schakelaar op draad zitten en de lampen op draadloos moet je weer wel wat regelen om ze met elkaar te doen praten met dit systeem.
Als je zoals arne de verbinding tussen verdiepingen draadloos moet doen werkt dit natuurlijk niet optimaal.

De eenvoudigste oplossing is natuurlijk beide netwerken op dezelfde snelheid te laten draaien en alles te spiegelen.

Ik moet mij eens gaan verdiepen in het ZigBee domotica profiel om te kijken of dit eenvoudig te gebruiken zou zijn in een VSCP omgeving.

[Bericht gewijzigd door Gyrbo op (10%)]

Ach ja die kabel doet er eigenlijk niet zoveel toe. Iedereen mag daar wat mij betreft zijn eigen keuze in maken. Als iedereen maar zorgt dat er communicatie tussen de modules mogelijk is.

Wat betreft die snelheid van de communicatie. Hoewel CAN misschien wel 1Mbit kan halen, heb je dat natuurlijk nooit nodig. Er gaat immers alleen maar besturingsinformatie over de lijn. Dat heeft niet zoveel om hakken.

Ik weet niet of er CAN over wireless bestaat, maar ook hier geldt weer, al zou de bus niet de gelijke opzet hebben, als ze maar wel dezelfde taal spreken. Heb je alleen maar een gateway nodig die de communicatie tussen het bedraade en draadloze deel voor zijn rekening neemt. Dat kan een aparte module zijn, maar waarschijnlijk ook een soort master module.

Trouwens veel van deze info zou eigenlijk even opgeschreven moeten worden op de wiki.

Marc

Ik denk dat we dan met een bridge/gateway moeten gaan werken (of meerdere om betere dekking te garanderen voor het wireless gedeelte). Ik denk wel dat we zorg moeten dragen dat alle modules ook over wireless kunnen werken. Eventueel kunnen we twee versies opzetten. Één met draad en een wireless en een gateway/bridge mogelijkheid voor elke module of is zoiets netwerktechnisch zeer onverantwoord?

MdW mag ik jou vragen om misschien een en ander te documenteren op de wiki aangezien jij meer thuis bent op dit gebied? Ik ben echt nog niet thuis in het hele netwerk gebeuren en vermoed dat ik alleen maar meer onduidelijkheid schep.

Groeten

[Bericht gewijzigd door JustME125 op (27%)]

@JustME: Ik heb mezelf al even toegevoegd.

Een collega van me opperde het idee om netwerk communicatie te doen op basis van XPL en ik moet zeggen dat ik daar ook wel van gecharmeerd ben. Ik ben er alleen nog niet uit of daarbij een dedicated PC/server noodzakelijk is.

XPL lijkt te communiceren via XML. Alleen al daardoor valt het voor mij af. Een XML parser schrijven voor AVR lijkt mij niet zo'n toffe bezigheid. XPL lijkt mij dan ook voornamelijk gericht op krachtigere modules of als "glue" tussen verschillende protocollen.