Domotica Ontwikkelen

Er wordt gezegd dat VSCP niet CAN als vereiste heeft, ik ben het daar niet geheel mee eens. VSCP is ontworpen voor CAN. Hoe ga ja anders een 29 bit woord verdedigen? Het is bijna dezelfde bewering dat DMX niet perse via RS-485 hoeft te gaan, want het kan ook via Ethernet in de vorm van ArtNet.
Bovendien: VSCP leunt voor de routering op het feit dat CAN ditzelfde 29 bit woord voor adressering gebruikt. Om ditzelfde protocol over Ethernet te transporteren moet een extra medium in het leven geroepen worden dat CAN addresses aan Ethernet MAC addresses koppelt.
Ik pleit dus juist voor een 8bit woord gebaseerd protocol, dit is de meest universele eenheid (sommigen zullen 7bit eerder bepleiten, maar toch).
Een domotica protocol via CAN laten verlopen moet evenveel moeite kosten als ditzelfde protocol via Ethernet (ofwel TCP/IP / UDP/IP) te laten verlopen. VSCP heeft dit kenmerk duidelijk niet: het is verweven met het transport medium.

Ik pleit voor een applicatie laag protocol voor domotica dat expliciet geen keuze maakt voor het transportmedium. Ja, dit betekent een extra schepje overhead. Deze overhead is een bewuste keuze, een keuze om niet te leunen op het medium voor delen van de functionaliteit.
Men kan ook kiezen om juist wel op het medium te steunen voor functionaliteit, maar dat beperkt mij teveel in de mogelijkheden van een domotica systeem.
Daarom, ik pleit voor het volgende medium:
een medium voorziet in garantie van transport en integriteit: een bericht zal gegarandeerd en correct aankomen op ten minste de juiste bestemming.

Het is waar dat bepaalde documentatie van VSCP uitgaat van een CAN bus, maar de core specificatie doet dit niet. Je spreekt over een 29-bit woord als adres. VSCP "misbruikt" dit stuk van CAN om de nodige informatie in kwijt te kunnen. Op level 1 gebruik VSCP een 9-bit nummer als adressering (de nickname). Voor het RF protocol wordt hier de eerste bit in een header gestopt en de de rest als standaard byte verstuurd. Het vaste adres van een node is zelfs een 128-bit GUID (wordt eigenlijk enkel op level 2 echt gebruikt).
Het belangrijkste deel van VSCP is naar mijn mening echter de specificatie van events. Een event wordt bepaalt door een class en een type: http://www.vscp.org/wiki/doku.php/vscp/spec/10_vscp_spec_events1

Voor een idee hoe deze specificatie naar fysieke layers gemapt wordt kan je naar de volgende pagina kijken: http://www.vscp.org/wiki/doku.php/vscp/spec/phy/start (hier staat info voor CAN, serieel, RS-485, Ethernet, TCP/IP, RF en MiWi).

Zo het gaat hard..
Erg vervelend. Straks als de hosting er is, is het misschien toch fijn om een forumpje op te zetten, aangezien we dan de discussies niet door elkaar heen gaan roepen, maar elk een apart topic kunnen krijgen. Ik zie door de bomen het bos niet meer.

Of het VSCP word of iets anders, het moet wel op CAN en draadloos kunnen draaien..
Ik denk al snel aan hardware: Ik zie nodes die standaard op CAN werken en eventueel kunnen worden uitgebreid met een draadloze (XBee/ZigBee) module. Waarna deze ook gelijk als bridge zou moeten kunnen dienen?
Ja ik denk vrij veel vooruit, maar ik ben meer van het ontwerpen

Alles komt goed, Joomla met forum staat al online. Ik ben alles aan het instellen zodat alles van moment 1 goed is. Momenteel zit ik wel in de examens en is de tijd beperkt, ik hoop deze avond nog de nodige instellingen te kunnen treffen om de ingebruikname te kunnen starten.

Ik kan eventueel mee de boel opzetten. Heb hier veel ervaring mee en in de avonden/nachten meer dan genoeg tijd.

Voeg me even toe op msn (?)
Zie adres in profiel alleen word 'mail' dan 'msn'

@roadrunner:
Na een jaartje met VSCP bezig te zijn weet ik nog bijlange niet alles van het protocol. Volgens mijn kennis van het protocol denk ik echter wel dat een aantal beweringen van u niet correct zijn.

1. De licentie
Die is volgens mij wel vrij, je hebt me nog niet laten weten wat je opmerking hier op is.

2. De claim van look-up table
VSCP gebruikt een XML beschijving van de module capabilities. Op die manier kan de PC applicatie je perfect een beschrijving geven van de mogelijkheden van de module die je aanspreekt. Deze functie kan je op verschillende manieren implementeren afhankelijk van hoeveel flash je micro heeft.

3. VSCP heet (NIET!) als vereiste CAN
Waar het eigenlijk bij VSCP rond draait zijn de 'events'. Een event bestaat uit de velden zoals ik ze in m'n vorige post beschreef. Dit zijn de 'level I' type events, speciaal compact gemaakt om makkelijk implementeerbaar te zijn op een kleine micro. Er zijn ook nog 'level II' events met veel meer mogelijkheden.
Het totaal van al die velden samen met een proriteit mappen inderdaad netjes op de 29bit identifier van CAN. Dit zal bewust zo gedaan zijn omdat de eerste modules CAN based waren, dit is volgens mij echter geen beperking. Als je niet blij bent met 9-bit velden ... dan stuff je die toch gewoon?
De link die Gyrbo aanhaalde geeft trouwens een suggestie hoe je de VSCP berichten kan mappen op andere protocollen. Dit is geen harde verplichting hoor, als jij een beter idee hebt doe je maar een voorstel. Dat is net het mooie aan open-source.

Je claim die eindigd met 'VSCP heeft dit kenmerk duidelijk niet' lijkt me dus bijzonder kort door de bocht.

Is er trouwens een applicatie laag die wel aan je requirements voldoet? Is die open source? Ga je die zelf ontwikkelen?
Dat laatste zou ik toch willen vermijden. Ik zou niet graag al dit enthousiasme voor domotica zien stranden in het zoveelste half afgewerkte community project ... die zijn er veel te vinden.

@MdW, de link naar openremote kende ik reeds.
Openremote is een perfecte aanvulling op een domotica/automatisatie protocol. Openremote kan perfect de visualisatie zijn van een eigen ontwikkeld domotica protocol. Het is echter geen domotica protocol op-zich, het gebruikt X10, KNX, Insteon ...

Busware kende ik niet, maar even verder klikken en je komt bij Freebus uit. Hier heb ik ook een tijdje naar gekeken. Zeer interessant omdat ze proberen modules te maken die volgens de EIB standaard werken. Los van het feit dat de EIB standaard niet open is was de grootste beperking die ik toen zag de ETS tool nodig. Deze ETS tool heb je nodig om je netwerk te configureren. Dit is een vrij dure tool en er bestaat nog geen open-source versie van. Bijkomend kan de ETS tool enkle modules configureren waarvoor bibliotheken beschikbaar zijn ... die electronisch signed zijn. Dit betekend dus dat voor het ontwerpen van eigne modules je volledig een bestaande moet reverse-engineeren.

Groete Ghole

@Ghole:
De licentie is vrij voor niet commercieel gebruik. Als iemand in deze club bedenkt een bedrijfje hieromtrent op te zetten dan zal hij toch geld op tafel moeten brengen. Als een protocol open/free is dan is het minstens GPLv2 (GPL, LGPL, BSD, CC, MPL en APL zijn ook oke), maar niet GPL-tenzij-je-er-geld-mee-verdiend.
2. Je hebt gelijk, de XML bestanden beschrijven behoorlijk compleet de functionaliteit van VSCP.
3. Mja, het heeft geen vereiste, maar het leunt er wel veel op, ik zou voor mijn eigen netwerk een level2 only systeem maken, al was het maar omdat dit minder CAN gebaseerd is. (bitstuffing is een oplossing, maar dat geeft al aan dat er een probleem is. Ja het kan, nee het is geen charmante manier.)

Ik probeer niet VSCP af te branden, ik probeer alleen aan te geven welke stappen in het design van een domotica systeem ik van belang vind om het een mooie oplossing te vinden. VSCP is al duizenden keren netter dan X10, maar er zijn dingen waar ik vraagtekens bij zet. en dat is niet altijd terecht! Ik snap ook maar half hoe het protocol werkt, daarom ben ik blij dat jullie me daarbij ook kunnen helpen het beter te snappen.

Die link van openremote geeft precies aan waar ik nog wat mis in mijn begrip. Het is een mooie manier om een PDA/Smartphone als remote te gebruiken. Dit kan ik echter niet toepassen in mijn wandschakelaar, hoe kan ik mijn wandschakelaar instellen dat bepaalde lampen erop gaan reageren? Hoe kan ik dat op een cleane manier doen?
Bij X10 zie je dat er met een rood en een zwart ringetje heel fool-proof met hardcoded adressen gewerkt wordt. Bij complexere systemen gaat dit niet meer werken. Hoe kan je gebruiksvriendelijkheid en complexiteit in één systeem plakken?
Openremote is een mooi antwoord, maar het is nog maar het puntje van de ijsberg.

Toch maar weer verder ermee... gisteren véél kabels getrokken door mn nieuwe huis ... het moet er gewoon van komen!

Ik zou als ik jullie was het protocoll en het medium even laten rusten. Laat dit gewoon gedurende de volgende fase uitkristalliseren. Ga gewoon uit van verstuurde messages. Die kan je in elk protocoll door elk medium versturen. Praat gewoon over messages, dan kan de funktionaliteit besproken worden.

Er zijn twee basis messages die je zou kunnen gebruiken: Events en Commando's.

Events:

Verstuurde 'ik' opdracht. De zender geeft aan: bij mij is mijn status aldus veranderd. Hij zend dit als broadcast, dus aan alle ontvangers.

bijvoorbeeld: sfeerselektor woonkamer geeft door dat op knop 4 is gedrukt om sfeer 4 te kiezen.

Alle apparaten kijken in hun lijstje hoe ze op deze event moeten reageren. De dimmer van de lamp in de hoek van de woonkamer bv gaat dimmen naar presetwaarde 4.

Commando:

Verstuurde 'jij'opdracht. De zender geeft aan: henk, piet, of iedereen, of alle vrouwen, moeten nu .... dit of dat doen.
Er wordt een UNICAST verzonden, geadresseerd dus.

Voorbeeld sfeerselektor woonkamer geeft door dat alle ontvangers in groep 'lampen' in zone 'woonkamer' op preset-stand 4 moeten gaan dimmen.

Er moet wel voor events gekozen worden, omdat meerdere zenders samen een ontvanger doen besluiten wat te doen. bijvoorbeeld:

Het garagelicht krijgt signaal van een bewegingsmelder én van een lichtsensor. En van een RF-ID ontvanger. Een logische vergelijking in de dimmer van het garagelicht zorgt voor het gekozen gedrag van de dimmer.

Met commando's kan dat niet. Je kunt niet modules voorwaardelijke commando's laten sturen. Bijvoorbeeld een commando als:
bewegingsensor zegt: garagelicht ga branden als de lichtsensor daar ook zo over denkt tenminste.

Alleen eenvoudige klikaanklikuit sets werken met commando's. Flexibiliteit onstaat volgens mij bij gebruik van events.

Events dus. Nou die kun je gaan bedenken voor alle mogelijke zenders en ontvangers. (waarvan de meesten als hart een klein microcontrollertje zullen krijgen ivm kosten).

Volgens mij zou een ontvanger zo kunnen werken:

Je maakt voor alle ontvangers 8 preset standen.
b.v. 8 dimstanden, aan/uit/ en de andere 6 niet gebruikt,
of 8 verschillende temperaturen voor de kachel etc. bedenkt 't maar.
zonwering half open 10 procent open etc. etc.

Je maakt voor elke preset-stand een timeout in uren of minuten of seconden waarna hij automatisch terugspringt op presetstand 1. (Of instelbaar op oneindig, dan doet ie dat niet, dan blijft hij altijd op de laatst gekozen).

Je reserveert 8 triggers met hun eigen instelbare timeout:
Je programmeert per trigger op welke event én van wie deze triggert, en hoelang (in seconden of minuten) deze aktief blijft.

Je definieert voor elke preset welke logische bewerking geldig is voor deze trigger. Bv: Trig1 & Trig2 OR Trig 3 -> ga naar preset 1. Hiervoor zijn mischien sub-triggers nodig voor wat ingewikkeldere vergelijkingen. Met een kleine matrix ga je 't wel redden.

Dan lijkt 't me dat je behoorlijke effekten kan gaan programmeren met verschillende sensorcombinaties. Zoals een lichtend pad door je woning als het nacht is.

Ik ga zelf zowiezo een dcf realtime clock programmeerbare event-zender maken. Deze kan bijvoorbeeld timer-events gaan broadcasten, of uitgerust met een zonsondergangtabel zon-op en zon-onder events gaan spugen voor alle hiervoor geinteresseerde ontvangers.

Nog een voordeel van event gebruik: De zigbee module die ik gebruik kan deze zonder picje versturen als reactie op een druktoets.

Voilla, 't is gebeurd !
Samen met de hulp van Ken536 heb ik het toch nog kunnen afkrijgen ""Vandaag"".. ;)
Omdat we nog geen domeinnaam gekozen hebben (die al wel klaar staat dankzij de donatie van Arne (waarvoor nogmaals dank!!)) is dit voorlopig de URL:

http://77.74.53.70/~codomo/Joomla/

Gelieve een account te registreren, ik geef jullie allemaal "tekstverwerker" rechten zodat je artikels kan maken en wijzigen.
Bij elk artikel verschijnt dan een pennetje of iets dergelijks.
EDIT: De eerste 4 zijn al ingeschreven.
Verder werkt diezelfde login ook gewoon op het forum.

Dus vanaf nu gelieve niets meer op de Wiki te plaatsen.

Ik denk dat Johan_ een punt heeft. Ik ben er ook voor om de implementatie details even opzij te leggen en eerst te bepalen wat voor systeem we precies gaan maken. Dus eerst compleet te documenteren/bedenken hoe het systeem gaat werken.

Ik zie een combinatie van een event- en commandosysteem. Sensoren zouden event genereren. (schakelaar omgezet, dimmer verdraait, timeroverflow, enz..) Een centrale component (kan per kamer of per huis) zou deze event kunnen opvangen en vervolgens commando's kunnen sturen. (Lamp 3 aan, thermostaatkraan verder open ...)
Een actuator zou ook direct zelf op een event kunnen reageren, zo zou je een schakelaar direct aan een lamp kunnen koppelen.

Ik zie verder een centrale computer voor me die al deze events ontvangt en zelf ook commando's kan versturen. Dit zou dan je internetgateway zijn zodat andere apparaten (iphone, webbrower op je pc) het systeem kunnen monitoren en sturen.

De keuze van het protocol/medium heeft natuurlijk invloed op de functionaliteit die je kan gebruiken. Als je protocol geen board/multicast ondersteund kan je natuurlijk niet efficiënt met events werken. Laten we dus voor het gemak uitgaan de broadcasts kunnen en efficiënt zijn.

Volgens de definities van Johan_ zou ik eerder voor een commando system gaan, maar de definities zijn niet degene die ik zou gebruiken. Ik zou een systeem gebruiken dat logisch gezien steeds een groep addresseerd. Bv. schakelaar stuurt een berich "schakelaar aan" naar groep "woonkamer: noordkant". Alle lampen in deze groep gaan dan aan. Op die manier kan je eenvoudig schakelaar en lampen toevoegen zonder dat deze elkaar moeten kennen. Fysiek kan dit met een broadcast systeem werken waarbij modules niet-interessante (niet aan hun groep(en) geaddresseerd) messages negeert.

Complexere acties kunnen door een aparte module afgehandelt worden. Deze zal dan een beslissing nemen en een nieuwe message doorsturen naar een andere groep. Als alternatief kun je dezelfde matrix natuurlijk in elke relevante module zetten. Op die manier werk je volledig decentraal.

Volgens mij moeten we nog een stap terug.

Hoewel de discussie technisch gezien nu een niveau hoger is door de commandoset te bespreken, lijkt het er toch sterk op dat de insteek is zelf iets te ontwikkelen.

Die richting moet je eigenlijk pas opgaan als je zeker weet dat de bestaande systemen en protocollen (zelfs met het accepteren van enkele minpunten) echt niet bruikbaar zijn. De kans dat het initiatief gaat stranden is vele malen groter als we op elk vlak zelf het wiel willen uitvinden. Dan bouw je misschien wel het ideaal systeem, als je al tot overeenstemming komt, maar dan heb je weer een volledig nieuw initiatief waarvan zeer de vraag is of je daar ooit voldoende aanhangers voor gaat vinden. Dan zal het uiteindelijk toch een stille dood sterven. Zo werkt dat nu eenmaal in de wereld van ICT en internet. Het is een heidens karwei om een nieuwe standaard te introduceren. Grote bedrijven geven daar bakken met geld aan uit en redden het vaak nog niet eens.

Als je op internet kijk zie je namelijk meer open source initiatieven die hebben geprobeerd het ideale systeem te bedenken. Vele van die initiatieven bestaan alleen nog maar op papier en er wordt niet meer actief aan gewerkt.

Volgens mij heeft dit initiatief alleen kans van slagen als wij in staat zijn om op deskundige wijze de beste (reeds bestaande) standaarden bij elkaar weten te zoeken en zorgen dat het één werkend en betaalbaar geheel wordt. Daar gaan we dan goedkope hardware voor bouwen.

@The dutchman
Bedankt voor je inzet. Ik mis aan de site de wiki. Om de informatie in artikelen op de site te zetten, maakt het er niet leesbaarder op. de naam 'Codom' zou ik niet gebruiken. Slechts 1 letter verschil en je denkt aan iets anders. Daarnaast weet ik niet of we zo perse de verwijzing naar CO in de naam hoeven te hebben. Op termijn weten nieuwe lezers niet waar dat op slaat. Mijn voorstel zou zijn om bv te kiezen voor:

www.osdomotics.org of www.osdomotics.nl

eventueel oshomeautomation

Marc

Ik zie het anders Marc.
We kunnen voor de discussies van de verschillende onderwerpen strijd voeren op een duidelijk overzichtelijk forum met topics voor de verschillende subcategories. Als er dan besluiten worden getrokken komt er een artikel over. Werkt toch gemakkelijk denk ik?

Nu voeren we al 10blz topics over Domotica ontwikkelen. Domotica ontwikkelen is zoals het OSI-model, je moet het opsplitsen in verschillende delen. En dat gaat niet met 1 topic. Op het andere forum kunnen we topics maken ter vergelijking van VSCP met andere. Voordelen afwegen van CAN vs RS485 of RS232 of andere systemen enz. Ik denk dat een Wiki hier niet noodzakelijk voor is, maar dat het net makkelijker is om dat op een forum te doen dat daar voor dient.

Aan het einde van 1 specifiek topic kunnen er besluiten getrokken worden. De vraag is, waar beginnen. En dan denk ik dat we eerder moeten beginnen met bijvoorbeeld een functionaliteitsdiagram op te stellen van het protocol dat gevoerd wordt over een bepaald fysieke laag. (als we het zelf gaan uitvinden, wat ik niet aanraad..) maar het overkoepelende protocol is volgens mijn mening de basis. Maar, we gingen dat protocol niet zelf schrijven en het warm water heruitvinden. Daarom zou ik graag zien dat er verschillende overkoepelende protocols zoals VSCP, LONWorks enz. met elkaar worden vergeleken tot in de puntjes, zodat er tabellen kunnen opgesteld worden met de voor en de nadelen. Zo kunnen we van op afstand kijken naar wat nu eigenlijk het beste van toepassing is op een domotica systeem.

Wat de naam betreft kunnen we nog alle kanten uit.
Ook hiervoor moet een overeenkomst getroffen worden natuurlijk.

Ik merk dat we meer met de neuzen dezelfde kant op staan :D. Zoals Marc al aangaf lijkt het me verstandig om te beginnen met de scope.
Ik ben ervan overtuigd dat we onze eigen applicatielaag wel op een bestaand protocol of project gemapt krijgen. Ik heb nog even naar KNX gekeken maar heb weinig technische inhoud gevonden helaas dus ik ben nog zoekende.

@The Dutchman,
bedankt voor je inspanningen. Ik zit momenteel ook met tentamens en moet er ook echt tijd voor maken om het forum hier door te lezen.

Ik denk nog even rustig verder hier en laat wel weer iets van me horen.

Groeten

Een voorzetje wat zeker niet volledig is. Ik hoor graag hoe jullie hierover denken.

Doel van dit initiatief
Te komen tot een degelijk en compleet domotica concept wat:
* vooral betaalbaar is
* voldoende open van structuur is
* waar geen licenties noodzakelijk zijn voor (commercieel) gebruik
* waar zelf additionele hardware voor te ontwikkelen is
* waar zelf additionele software voor te ontwikkelen is
* waar breed draagvlak voor kan ontstaan
* een waardevermeerdering voor de woning is

Onderzoeksvragen
Als je dit als uitgangspunt neemt, dan kan je o.a. de volgende vragen stellen.
* Wat zijn functioneel en technisch gezien minimaal de vereisten aan een acceptabel systeem
* Waarom niet aansluiting zoeken bij KNX, zie www.freebus.org
* Waarom niet aansluiting zoeken bij LonWorks, zie www.lonmark.nl
* Waarom niet aansluiting zoeken bij BTicino, zie www.myopen-bticino.it
* Waarom niet aansluiting zoeken bij systeem Y enz

Als wij dan in al onze wijsheid de reeds bestaande systemen naar de prullenbak hebben verwezen, dan pas kunnen we zinvol besluiten zelf een systeem te ontwikkelen. Dan zou je trouwens weer dezelfde slag moeten maken om de bestaande protocollen en busstandaarden te beoordelen. Want ook hier geldt weer, aansluiten bij een standaard is vele malen slimmer dan zelf het wiel uit te vinden. Ook al zouden we dan enkele minpunten moeten accepteren.

Ik hoor graag hoe jullie hierover denken.

Marc

@MdW

Ik ben het volledig eens met je voorzet hierboven. Aansluiting zoeken bij een bestaand protocol lijkt me prima. Ik ben geen netwerk man en kan dit moeilijk overzien en doorgronden dus laat staan bedenken. Ik zal je geposte links eens goed gaan bekijken.

@The Dutchman
Ik heb net een artikeltje toegevoegd op de site maar kan m niet terugvinden (zou onder elektriciteit moeten staan). Enig idee hoe/wat/waar het mis is gegaan?

Mzzls

@MdW, Ik had toch gehoopt dat je de weg naar het andere forum zou kunnen vinden voor dit soort zeer duidelijke zaken.
Alles hier onder mekaar blijven zetten is geen manier van duidelijk werken. Verder is het doel en onderzoeksvragen al goed uitgelijnd. We zijn het er allen over eens om aan te sluiten bij iets bestaand denk ik.

@JustME125 eigenlijk moet je hier geen vragen stellen over wat er mis is gelopen op een andere site. Graag op het ander forum vragen stellen. Het is er trouwens voor gemaakt. Ik zal straks kijken voor de fout. Fout is inmiddels opgelost, je had "Published" niet geselecteerd. Ik heb em maar meteen bij de hardware modules geplaatst. En de het schema bij de download sectie geupload.

[Bericht gewijzigd door The Dutchman op (14%)]

@the Dutchman:
de website is buggy. Ik kan niet registeren, want ik ben al geregistreerd. Ik kan niet inloggen want ik heb mijn account niet geactiveerd. Ik heb geen e-mail gekregen. Ik kan wel mijn gebruikersnaam per e-mail opvragen, maar niet mijn wachtwoord.

Aangezien iedereen tot nu toe foutloos heeft kunnen registreren kan de website het probleem niet zijn. Waarschijnlijk heeft je mailbox het als spam gefilterd. Ik heb je account geactiveerd handmatig, en je zou nu wel moeten kunnen inloggen. Je hebt ook mail ontvangen. (als het opgegeven mailadres juist was)

@ghole: Heb jij toevallig nota's genomen van hoe je de setup van PC-software hebt uitgevoerd? Via de uitleg op de wiki geraak ik niet ver... ik krijg de vscpservice maar niet gestart :-(

:-)
Die Wiki moet ECHT eens dringend opgekuist worden.

Wat is je setup? Heb je een USB2CAN?
Je kan dan best eerst eens proberen met een directe verbinding met dit device.
Ik kan je mijn config files sturen als dat helpt.

Ghole

ik heb de CANUSB zoals hier beschreven

config files altijd welkom, mogelijks verklaart dit wat.

edit: tot nu alles aan de praat gekregen, behalve VSCPWORKS, heb jij daar enige aanpassingen mee gedaan?

[Bericht gewijzigd door sven op (23%)]

Ik merk dat er nog veel twijfel is over het gebruik/haalbaarheid van CAN in domoticasystemen. Misschien interessant om te weten is dat het domoticasysteem van Velleman, velbus, ook gebruik maakt van een canbus.

Het protocol is ook 'min of meer' open/gekend. Daarnaast is er ook nog een forum waar er af en toe vragen over het protocol en dergelijke worden gesteld, bv. http://forum.velleman.eu/viewtopic.php?t=383

vervolg:

http://77.74.53.70/~codomo/Joomla/index.php?option=com_kunena&Item…

Bovenstaande site kun je nu bereiken via

http://www.opendomotics.eu