Domotica Ontwikkelen

@Johan
Wat mij betreft niet afhaken. Je kennis en visie worden op prijs gesteld. Maar als je stelt dat terugmelding niet nodig is, dan moet je ook ruimte geven voor tegenargumenten. Door die discussies krijgen we nu juist helder wat een wijze oplossing is.

Dus graag nog effe meedenken!

@Roadrunner
Inderdaad gaat de discussie soms alle kanten op. Voor even niet erg. Zie het maar als een soort brainstorm sessie. Uiteindelijk moet er wel een kop en een staart aan de discussie komen. Grote kans ook dat we compromissen moeten sluiten. Het systeem moet degelijk van opzet zijn. Maar draagvlak is ook essentieel. Daarvoor moeten we soms wat pragmatisch zijn, lijkt me.

Marc

Hallo allemaal,

Wat een activiteit plots
Ik zie dat er wat vragen zijn over VSCP. Laat maar weten als er iets niet duidelijk is, dan probeer ik te verduidelijken.

Hier zijn al wat puntjes die ik oppikte:
VSCP en CAN
VSCP draait onder andere boven op CAN maar is niet beperkt tot CAN. CAN heeft inderdaad al de voordelen die hier reeds werden aangehaald, de transmissie over CAN is dus uitermate betrouwbaar. 'CAN' op zich is echter 'slechts' een physical/MAC protocol ... het zegt op zich NIETS over de applicaties (of hogere OSI lager) die erover lopen. VSCP is dus zo'n applicatie die over CAN kan lopen. VSCP verpakt dus de berichten die het wilt versturen in een vorm die netjes op het CAN protocol past.

Een VSCP bericht bestaat typisch uit:

1. VSCP Class - 9 bits -> Geeft 'klasse' aan van bericht
2. VSCP Type - 8 bits -> Type bericht in klasse
3. Originating nickname - 8 bits -> Zender van bericht
4. Data - 0 tot 8 bytes per CAN frame -> eventuele data bytes

Dit bericht wordt bij VSCP over CAN dus netjes gemapt op de 29 bit CAN identifier & CAN data field in frame.
(zie: http://www.vscp.org/wiki/doku.php/vscp/spec/phy/vscp_over_can

VSCP en Wireless
Als je het VSCP bericht van hierboven mapt op je draadloze communicatie standaard kan je dus ook VSCP over deze wireless link doen.
Hier is reeds over nagedacht bij VSCP, staat echter nog als status 'prelim'. Zie: http://www.vscp.org/wiki/doku.php/vscp/spec/phy/vscp_over_rf_and_plc

Kwestie snelheden ... zoals reeds aangehaald moet je dus bufferen/filteren. Wired zal altijd sneller kunnen dan wireless, dus buffering is nodig. Je buffer zouden normaal wel niet snel overlopen, zelfs op mijn bus tegen 250kbit zal load niet hoog zijn. Er is trouwens de mogelijkheid in VSCP om prioriteiten van messages in te stellen.

VSCP licentie
Die is toch wel 'vrij' hoor. Roadrunner, wat bedoel je met 'niet volledig vrij'?
Zie: http://www.vscp.org/wiki/doku.php/vscp/05_vscp_license

Terugmelding
Denk dat je hier over 2 soorten van terugmelding spreekt:
De eerste gaat over het effectief overbrengen van de bits van het bericht. Hier moet je physical/mac/llc laag voor zorgen. Bij een bekabeld systeem is de kans op niet aankomen van berichten toch wel heel klein, typisch denk ik dat er BER rates zijn van 10e-6 en beter?
Bij wireless moet je hier waarschijnlijk wel een oplossing voor zorgen. Wireless kan BER rates hebben tot typisch 10e-3? Dus lijkt error coding en ontvangst bevestiging met best.

De andere terugmelding is die op 'applicatie' niveau. Een terugmelding die je zegt dat die lamp effectief is aangegaan, dat dat rolluik effectief naar beneden gegaan is. Als je naar mijn demo kijkt op youtube zie je dat er een led in de schakelaar aangaat op het moment dat de lamp aangaat. Dit is dus effectief wel een terugmelding, niet gewoon simpelweg de led die 'ook' aangaat door de schakelaar.
Dit werkt als volgt:

1. Schakelaar zend bericht 'toggle lamp status'
2. Lamp ziet berecht 'toggle status' en toggled.
3. Afhankelijk van status zend lamp een status bericht de bus op: 'ON' of 'OFF'
4. De led in de schakelaar(s) gaan aan als ze dit 'ON' bericht zien, en uit als ze het 'OFF' bericht zien.

Voila,
dat was het voor vandaag

Nog een edit voor Roadrunner:
Je hebt gelijk dat de discussie zich nu nogal fel focussed op de phy laag. De phy laag is voor mij ook secundair, als mensen voorkeur hebben voor een andere phy ... so be it. Als er maar VSCP boven op draait
De mensen achter VSCP (daar reken ik mezelf nog niet toe) hebben best al wel veel nagedacht over al de problemen die bij een automatisatie protocol aan bod komen. Vandaar dat ik meen het warm water niet nog eens te moeten uitvinden.

HCSP gebruikt het eerste: een lookup table. ... In feite willen we een zelfdocumenterend systeem: een node moet aan het netwerk duidelijk kunnen maken wat hij kan en hoe dat gecodeerd moet worden in een bericht.

Ik veronderstel dat je VSCP bedoeld?
Indien zo denk ik toch dat je claim dat VSCP een lookup table gebruikt fout is. Het zelfdocumenterende systeem zit namelijk in VSCP -> MDF, Module Discription File, een XML beschrijving van de capabilities van de module.
Ik zal er morgen wat meer over vertellen.

Ghole

[Bericht gewijzigd door Ghole op dinsdag 19 januari 2010 00:21:06 (13%)]

Ik denk dat het grootste probleem momenteel is dat er geen scope gedefineerd is. Hoe diep willen we gaan met het ontwikkelen van dit domotoca systeem? Dit is de "gelaagdheid" zoals ik hem zie (je moet meestal ook steeds de bovenliggende lagen ontwerpen):

1. modules maken die voldoen aan een standaard, bv. VSCP
2. zelf een "standaard" maken, m.a.w. de applicatie laag van het netwerk model. Dit draait dan op een lager protocol, bv. ZigBee, CAN, ...
3. zelf een protocol definiëren (routing via draadloze HopeRF modules, iets over RS-485, ...)
4. zelf een physical layer uitdokteren (ik denk niet dat iemand dit wil doen?)

Ik zou zelf voor (1) willen gaan. Op die manier wordt er zo veel mogelijk reeds bestaande kennis herbruikt en heb je veel minder werk. Ik betrap mij zelf ook geregeld op het "not invented here" syndroom, maar ik probeer de neiging te weerstaan. Ik vind het natuurlijk ook interessant om alles te bedenken, maar dat helpt natuurlijk niet bij het maken van een volledig systeem.
Het is natuurlijk belangrijk dat je een goede standaard kiest. Bij mij waren er een aantal belangrijke vereisten: bedraad, differentiële bus (betrouwbaarheid) en multimaster (voordelen hiervan zijn al uitgelegd). De enige bus die ik vond die hieraan voldoet is CAN. Vervolgens heb ik gezocht naar een standaard/project die van CAN gebruikt maakt, en kwam ik dus (mede door dit topic) uit op VSCP. Ik sta natuurlijk steeds open voor alternatieven, maar dan moeten ze wel minstens zo goed zijn als de opgenoemde bus (CAN) en standaard (VSCP).

Terugkoppeling
Ik moet mijn mening hierover wat nuanceren. Een expliciete terugkoppeling op de applicatie laag lijkt mij weinig nuttig. Op een gedeelde bus is er namelijk zo goed als geen one-to-one communicatie. Er wordt meestal messages naar groepen gestuurd. Dat maakt het bevestigen van aankomst een stuk moeilijker. CAN lost dit op door een enkele bit in de message te gebruiken. Andere nodes die een message ontvangen moeten een dominante bit op deze positie sturen. De "zender" zelf stuurt een recesieve bit, dus als hij een dominante bit leest, weet hij dat "iemand" de message ontvangen heeft. Bij CAN wordt de terugkoppeling dus op een lager niveau afgehandelt.
Een systeem zoals Ghole uitlegt lijkt mij handiger. Om het voorbeeld van de zonnewering te nemen: sensor stuurt door dat de zon schijnt; zonnewering schakelt in, maar motor blokkeert; zonnewering stuurt nu een "ERROR: moter geblokkeert" op de bus. Dit kan dan door een centrale module gebruikt worden om een mail te sturen, een waarschuwing op een display te zetten, etc.

Op 19 januari 2010 10:02:08 schreef Gyrbo:
Ik denk dat het grootste probleem momenteel is dat er geen scope gedefineerd is. Hoe diep willen we gaan met het ontwikkelen van dit domotoca systeem?

Ik denk dat je hiermee de hamer op de kop slaat. Ik twijfel er niet aan dat we een goed protocol met z`n allen kunnen bedenken/weten. Ik heb het gevoel dat we vooruit lopen op vele zaken.

En het is zonde dat, mede om die reden, iemand van dit project afziet.

Los van alle achterliggende technische items, wat willen wij als product straks thuis zien werken? Welke apparaten hebben we het dan over?
Aan de hand van deze apparaten lijst zouden we dan gericht een geschikt protocol kunnen bediscussiëren. En stap voor stap de producten aflopen.

Als we vanaf hier nou verder gaan met het bedenken welke (realistisch haalbare) producten we willen opleveren, dan kunnen we ernaar toe werken en deze producten uitschrijven op de Wiki. Dan is er een duidelijke scope van het project; de producten.

Voor elk product kunnen we dan kijken wat de voor/nadelen zijn qua protocol (hoewel ik verwacht dat dit echt nog een stuk later ter sprake komt).

Eerder verwacht ik dat we moeten nadenken welke specificaties verwacht worden van de apparaten,

• hoe snel moeten ze reageren,
• wordt er een terugkoppeling verwacht,
• moet het draadloos,
• voeding,
• hoeveel stroom kunnen we verbruiken,
• etc.

Zo, ik heb 12 uur niet meer gekeken hier en we zijn 2 pagina's verder. Het gaat hard hier.

Ik wil Johan vragen om absoluut nog niet af te haken. Zijn kennis en visie zijn zeer belangrijk hier.

Ik heb nog even met roadrunner overleg gepleegd (hij zit hier naast me) en ik ben tot de conclusie gekomen dat we:

Eerst moeten bedenken welke invulling we willen geven aan de applicatielaag. Daarnaast moeten we een link-layer definieren welke voor ons de correcte transmissie van de packets afhandeld, de applicatielaag heeft hier dus niets mee van doen. Als we dit goed doen dan zitten we niet vast aan de physical layer omdat we de hele error detectie, ack en nack etc. afhandelen in de link layer. Het zal dan voor het systeem worst wezen of ik het over 1, 2, 3, 4 of 10 stukken koper stuur, door de lucht stuur of voor mijn part moduleer op "het aantal ijsklontjes per minuut uit mijn ijsklontjesmachine".

Ik vind dat we de discussie rondom de physical layer op moeten schorten en ons eerst zorgen moeten maken om de applicatielaag. Als deze goed is (lees: niet afhankelijk van de physical of link layer) kunnen we het systeem laten draaien op elke link layer die je je maar kunt bedenken. De link layer handelt namelijk je transmissie af maakt zich ook druk over het wél of niet goed aankomen van packages. Als de link layer goed gekozen is dan maakt het helemaal niet meer uit waarover ze gaat verzenden zoals ik al zei.

Ik denk dat we deze kant op moeten denken en het van bovenaf moeten ontwerpen:

• Applicatielaag
• Link layer kiezen (bijvoorbeeld CAN/Zigbee/etc. eigenlijk maakt dit niet meer uit als de bovenste laag goed is)
• Physical layer (UTP, 2 losse draden, Wireless. maakt ook niet uit als de bovenstaande laag goed is)

Groeten

Ik ben het met de voorgaande schrijvers eens. Laten we eerst een scope bepalen en op basis daarvan kijken naar de technische invulling.

Voor zover ik me kan herinneren gaat het ons met name om een domotica systeem waarbij we zelf in staat zijn de 'dure' modules te ontwikkelen. De onderliggende techniek zou zo veel mogelijk op (open) standaarden gebaseerd moeten zijn om deze ontwikkeling mogelijk te maken. Hoe meer we vasthouden aan standaarden hoe meer kans van slagen dit initiatief heeft. We moeten niet vergeten dat de bewoners na ons het systeem ook moeten kunnen gebruiken en eventueel uitbreiden. Als wij dus één of ander exotisch systeem bedenken dan zal een domotica systeem in je woning eerder een waardevermindering betekenen dan een waardevermeerdering.

Mede om die redenen moeten we toch ook eens kijken in hoeverre het zinvol is aan te haken aan bestaande domotica concepten. Denk aan KNX of LONWorks. Als wij modules zouden maken die dezelfde taal spreken, dan kan je goedkoop een dergelijk systeem opbouwen, maar houdt je toch de mogelijkheid open voor toekomstige bewoners om verder uit te breiden. www.openremote.org een www.busware.de zijn initiatieven die dat doen. Zie ook de informatie:
https://www.auto.tuwien.ac.at/.../knxsci06/reinisch-wireless-knxsci06-…
http://www.scribd.com/doc/11949446/Comparative-LonWorks-vs-KNX

Ik zal eind van de middag een poging wagen om een scope te bepalen en op de wiki te zetten. Kunnen jullie daarna beoordelen of deze scope juist is.

Marc

JustME125,

Voor mij persoonlijk is de beslissing al gevallen op VSCP voor de applicatie laag. Ik lijk ook niet de enige te zijn die er zo over denkt.
Er zijn nog wel een aantal mensen die niet overtuigd zijn. Zouden deze mensen met een aantal argumenten/nadelen kunnen komen? De voordelen zijn ondertussen al uit de doeken gedaan, dus ik hoop dat we de nadelen kunnen weerleggen of een compromis kunnen sluiten om deze te minimaliseren/oplossen.

Voor alle duidelijkheid nog maar eens herhalen: VSCP werkt standaard via CAN, maar dit is geen vereiste. Momenteel lijkt het enige gebruikte alternatief ethernet, maar dit kunnen we zelf natuurlijk veranderen.

Een alternatief dat geopperd werd is XPL. Volgens wat ik zie is dit een ASCII protocol. Dit zorgt er natuurlijk voor dat de messages behoorlijk groot worden. Bovendien heb je dan een ingewikkeldere parser nodig. Het protocol zelf wordt liefst zo simpel mogelijk gehouden zodat dit ook in de kleinste AVR/PIC gebruikt kan worden.

Een andere mogelijkheid (nu zakken we wel weer wat af naar een lager niveau) is het Home Automation profiel voor ZigBee. Hierbij zit je dan waarschijnlijk wel vast aan ZigBee. Bovendien is de standaard niet echt open te noemen (de specificatie is wel op aanvraag gratis te krijgen).

MdW,

LonWorks lijkt mij interessant. De documentatie is vrij beschikbaar op de website. Ik moet alleen even zoeken naar een basis introductie van hoe het procotol precies in elkaar zit. Als we een "echte" industriestandaard kunnen gebruiken is dit natuurlijk nog beter.

Ik heb VSCP nog niet afgeschoten . Ik denk alleen nog maar globaal en wil me nog niet vastleggen op namen/protocollen etc. ect. Ik ben absoluut geneigd om VSCP als uitgangspunt voor de applicatielaag te bekijken maar ik weet nog niet zeker of VSCP écht zo draagbaar is als wat nodig is. Ik krijg een beetje het vermoeden dat VSCP gebruik maakt van een aantal CAN eigenschappen om de adressering etc af te handelen. Dit wil je eigenlijk niet want dan is je applicatielaag niet onafhankelijk van je link layer (en je physical layer).

Ik ben me nog in aan het lezen in de kwestie van VSCP maar heb moeite met alle bestaande netwerkmodellen etc. Ik ben meer een hardware man en hier dus niet zo in thuis.

Groeten

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 . 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 woensdag 20 januari 2010 13:50:26 (14%)]