Webstek wil ik volledig beheren. Als er een akkoord is over wat er op mag komen staan, dan zal ik dat installeren. Iedereen krijgt toegang en alles in orde. Die webstek is een fluitje van een cent.
Ik geef de hybride oplossing al voor een deel. Alleen zeg ik maar dat de maximum snelheid over de draad gigantisch hoger "KAN" liggen als over draadloos(op zijn maximium snelheid). Het risico op slechte communicatie is bij draadloos ook hoger en zal er veel meer weg en weer moeten gestuurd worden. Ik ga dan uit dat de draadloze modules zowal stand-alone als bij op een wired netwerk kunnen gehangen worden. Dit om het systeem dynamisch te houden.
Dus we maken eigenlijk een soort van buffer van onze microcontroller. Deze leest data van de CAN bus op hoge snelheid en plaatst deze dan rustig op de draadloze module. Als we via de Wired CAN-bus dan een request naar data krijgen, dan gaat weer de microcontroller dit vragen over het draadloos netwerk. (dit duurt dan weer een tijdje), er komt antwoord. En de microcontroller plaatst dit dan weer op de hogesnelheidsbus.
Er wordt gezegd, die hoge snelheid is niet van toepassing. Op het eerste zicht lijkt dat zo, maar zoveelste sneller onze modules in sleep mode kunnen gaan zoveelste meer centen houd je in je zakken ! En dat wil toch iedereen? 
Groeten
Joeri de Man
LED there be light
Ik snap het nog steeds niet, ik heb wel eens op de 433 MHz band geluisterd met een eenvoudige ontvanger dat is non stop ruis. Al met al is het maar 16 mA op 5 volt.
EDIT:
Uhh detail... Hoe kan iets slapen? daar ging dit stukje over
[Bericht gewijzigd door Joeri de Man op (18%)]
Op 18 januari 2010 21:12:02 schreef Joeri de Man:
Ik snap het nog steeds niet, ik heb wel eens op de 433 MHz band geluisterd met een eenvoudige ontvanger dat is non stop ruis. Al met al is het maar 16 mA op 5 volt.
Is dat een grap? Ik vind hem wel goed !! 
XPL kan ook XML based, het protocol is het echter niet. Alle documentatie begint echter met windows/Linux/mac based computer ... ethernet ... enz. Hoewel ik uiteindelijk wel degelijk op ethernet aan wil sluiten (lijkt mij op zijn minst prima bruikbaar als backbone) gaat mijn voorkeur uit, net als hier al is uitgesproken, naar een systeem dat zonder PC kan draaien.
Misschien is een XPL gateway, ik denk bijvoorbeeld aan een dedicated avr/ethernet combinatie, wel een optie?
@Dutchman: Een systeem als Redmine heeft o.a. het voordeel dat je een versiebeheer systeem hebt. Wel handig als je zodadelijk schema's, sources e.d. kwijt wil.
Op 18 januari 2010 21:12:02 schreef Joeri de Man:
Ik snap het nog steeds niet, ik heb wel eens op de 433 MHz band geluisterd met een eenvoudige ontvanger dat is non stop ruis. Al met al is het maar 16 mA op 5 volt.EDIT:
Uhh detail... Hoe kan iets slapen? daar ging dit stukje over
Door de ruis eruit te filteren?
@JustMe
Ik zal kijken of ik morgen effe wat tijd vrij kan maken om wat informatie naar de wiki over te hevelen. Maar dan vooral als een beginnetje. Ik zie het niet zo voor mij om alle relevante data steeds uit de posts te gaan vissen en op de wiki te zetten. Ik ben dan wel een groot voorstander van gestructureerd werken, maar die wiki moet natuurlijk niet mijn feestje gaan worden.
Graag een bijdrage van ons allen op dat vlak. Dit initiatief heeft alleen kans van slagen als er zoveel mogelijk mensen echt voor willen gaan.
Marc
Anders gaan we voor Redmine op de defenitieve hosting? Dan kan je projects maken, nog steeds een wiki hebben enz. ? Ik zou wel graag reply hebben voor ik weer iets "onnuttigs" doe 
En dan hoeft MdW ook zeker geen werk voor niets te leveren.
Redmine (of een ander project management systeem) heeft mijn voorkeur boven enkel wiki. Thempolis heeft linux hosting, ik weet vrijwel zeker dat Redmine daar zal kunnen draaien. Een wiki is geintegreerd in redmine.
@Dutchman
Ja dat zou ik wel zo prettig vinden;-) Zelf ken ik redmine niet, maar het ziet wel goed uit. Ik zat even te denken aan foswiki.org Maar dat is dan weer meer een wiki. Waar had jij zelf aan gedacht dan? Had jij een wiki op het oog met MySQL als database?
Hoewel het van mij niet perse zo snel hoeft, zou ik uiteindelijk ook forum functionaliteit overwegen op een eigen site. Uiteindelijk wil je medewerkers en gebruikers de gelegenheid geven over het toekomstige systeem te kunnen discussiëren.
Marc
Er worden veel dingen tegelijk behandeld, terwijl nog geen goede beginwaarden voor de werking zijn vastgelegd.
bijvoorbeeld:
- is terugmelding nodig? Volgens mij niet: hier mijn betoog:
(hierbij ga ik uit van een draadloos/bedraad systeem volgens CAN/ZIGBEE, de twee meest geschikte transportmethodes volgens mij).
Bij uitblijven van ontvangstbevestiging (ACK)volgt een volgende stap, bijvoorbeeld opnieuw de boodschap verzenden, met instelbaar aantal retry's. Gevolg: belasting van het netwerk, maar een lamp gaat er niet sneller door aan. Als de boodschap de tweede keer wel binnenkomt dan betekent dit dat er een storing was tijdens de eerste transmissie? Dit vindt ik zeer onwaarschijnlijk, zeker bij CAN. De can-zender luistert mee op de lijn, en als je de baudrate laag houdt, detekteert de zender zelf deze storing en zal dus zowiezo een retry doen (De kabel is ook nog 'ns balanced, en bij lage baudrates spelen reflekties geen rol). Bij Zigbee wordt ook al automatisch een aantal retry's gedaan.
(Terugmelding is soms handig als timing-hulp, omdat de ontvanger de data niet aankan. Meer als een handshake dus. Dit verwacht ik niet bij een relais-ontvangertje, of een dimmer-ontvanger. Die processen zijn echt klein en nemen nauwelijks processortijd in.)
Als terugmelding niet vereist is, is een CAN naar Zigbee brug heel eenvoudig te maken.
Je kunt de kans op gemiste berichten nog eens verkleinen door de message een aantal malen te herhalen.
Je kunt de kans op verstoorde berichten (ik geloof er zelf niet in) nog eens verkleinen door extra foutcorrectie bytes mee te sturen.
Let wel: de messages worden, hoeveel mogelijkheden je ook bedenkt voor het hele systeem, klein. 32 bytes is al een heleboel.
Bij alle communicaties die ik tot nu toe heb gemaakt kwam alleen de TIMEOUT error tevoorschijn: dit is dan een losse verbinding. De CRC-check error, framing error, etc. zie ik alleen eens langskomen bij foutieve adressering van slaves.
Ik sta open voor argumenten die VOOR terugmelding pleiten!
JustME125
Correct me if I'm wrong!
@MdW
Natuurlijk maak jou niet "in charge of the wiki". Ik lever mijn bijdrage zeker ook en verwacht dit van de rest ook. Ik heb alleen op dit moment voor mijzelf nog geen overzicht en vrees dus voor grote l*lverhalen als ik dit ga posten op de wiki. Als ik ideeën of documentatie heb die zinvol zijn dan kun je ze daar wel terugvinden.
@The Dutchman
Ik sluit me volledig aan bij de opmerking van MdW. Redmine ziet eruit als een schappelijk systeem voor onze toepassing.
@Johan
Als netwerknoob klinkt je betoog goed. Ik zal je dus niet tegenspreken. De eenvoudige CAN-Zigbee Bridge is natuurlijk een erg aantrekkelijk voordeel.
Allen nogmaals hartelijk dank voor de inzet.
Groeten
[Bericht gewijzigd door JustME125 op (13%)]
@arne/Joeri de Man: Inderdaad, filteren. Bepaalde modules kunnen ook een preamble detecteren en dan pas de microcontroller laten ontwaken. Als je de ontvanger in diepere slaap wil doen kan je ook met timeslots werken. Je spreekt af om om de x tijd te luisteren en dan weer dieper te slapen. Je moet dan wel een redelijk vaste frequentie hebben en regelmatig synchroniseren. Ik denk dat ZigBee op dergelijke manier werkt.
In een geoptimaliseerd systeem kan je bv schakelaars gebruiken die enkel wakker worden als je op een knop drukt. De ontvangers hangen dan aan het net en luisteren constant (of werken weer met timeslots).
@MdW: Een forum lijkt mij niet direct een goed idee. Enerzijds is er CO zelf. Anderzijds bestaand er forums waar een hoop gebruikers al een tijd bezig zijn met domotica, bv. http://www.domoticaforum.eu/
Ik denk dat het beter is daar bij aan te sluiten dan nog maar eens een aparte community te maken. Op die manier vinden we het warm water ook niet steeds opnieuw uit.
@Johan_: Ik ga volledig met je akkoord. Ik heb zelfs nog een ander argument tegen terugkoppeling. Als de boodschap toch onverhoopt niet moest aankomen is dit meestal niet erg. Als na een druk op de knop de lichten niet aangaan druk je nog maar eens. Als de thermostaat detecteerd dat de temperatuur niet goed is stuurt hij een nieuw commando, etc. Er zijn volgens mij weinig messages die echt kritisch zijn.
@The Dutchman (hieronder): Je kan nooit 100% zekerheid halen. Er bestaat een "wet van 9'ens". Voor elke 9 die je na de komma aan 99% wil toevoegen zul je fors bij voor moeten betalen. De vraag is: op welk moment stop je? Moet het systeem nog werken als je huis onder water staat? (misschien wel) Als een atoombom op je huis gevallen is? (waarschijnlijk niet) Ik denk dat de betrouwbaarheid van een systeem voldoende hoog kunnen maken ook zonder de terugkoppeling, of enkel in kritische gevallen terugkoppelen.
Persoonlijk dacht ik aan Joomla!, dat is iets waar we alle kanten mee uit kunnen. Zowel op vlak van Fora als projecten, je kunt die op en afzetten enz.
@Johan_ :Je hebt gelijk wat die terugmelding betreft. De kans is uiteraard zeer klein dat er met zulke "minieme" communicatie iets gaat mislopen. Maar eigenlijk wil ik zelfs dat minieme nog stabiliseren. Het mag in mijn ogen NOOIT!!! gebeuren dat je 2 keer moet klikken vooraleer de lamp aangaat omdat er eentje iets gemist heeft. Ik vind dat dit allemaal fool proof moet werken.
@Johan
Een waardevolle bijdrage! Zo nu en dan effe pas op de plaats. Dit soort info moet ook naar de wiki.
Even een voorbeeld waarom terugmelding volgens mij wel noodzakelijk is. Als je van een bedieningspaneel een actor (bv lamp) opdracht geeft om in een bepaalde stand te gaan, dan moet je ook zeker weten dat het gebeurd is. Anders gaat je systeem uit de pas lopen. Het systeem denkt dat er iets geregeld is, maar het blijkt niet geregeld te zijn. Als je dan bv een batch van opdrachten hebt en een essentiële stap is niet uitgevoerd, dan kan de hele batch in het honderd lopen. Dat is bv zo irritant bij X10. Als je maar vaak genoeg aan/uit klikt bij dat systeem gaat ie geheid uit de maat lopen. Volgens mij moeten we dat niet willen.
@Gyrbo
Hoeft van mij ook niet perse zo'n apart forum, maar als we echt serieus ambitie hebben om 'het beste en meest complete OS domotica systeem' te bedenken, dan mag daar wel een apart forumpje bij voor de grote community die ons dan te wachten staat;-)
Dus een beetje afhankelijk van ambitie, maar vooral afhankelijk of we echt in staat zijn iets goeds tot stand te brengen. Maar zoals al aangegeven, wachten we wat mij betreft nog even voordat we de vervolgstap zetten met een nieuwe website. Eerst maar eens meters maken.
Marc
Joeri de Man
LED there be light
Stuur in je bericht dan mee hoevaak je het commando toegestuurd heb, en stuur het standaard drie keer. Je merkt er bijna niets van, en als het na 3 keer niet aankomt dan is er iets mis.
Stel dat het om een dim commando gaat, dan zal die altijd evenveel dimmen omdat de ontvanger weet dat het om een bericht gaat uit dezelfde groep (van drie).
---
Het filteren van ruis moet je toch iets actief bezig laten zijn. Dan kan je net zo goed niet laten slapen. In plaats van op elk dingetje wakker worden.
de kans op transmissie fouten bij X10 is TOTAAL niet vergelijkbaar met Can of Zigbee. Dat X10 niet goed werkt weet ik.
Hoeveel ervaring is hier met echt in het veld geplaatste zelf ontwikkelde en geservicede communicerende al dan niet multi-master systemen? (met CAN RS232 422 485 Zigbee?)
Hoeveel logfiles over foutmeldingen zijn daarbij bestudeerd?
Argumenten voor terugmelding:
Het systeem wil, vanwege hoge zoninval, de zonwering naar beneden hebben en stuurt een signaal. De zonwering ontvangt het signaal maar de zonwering blokkeert (waarom is onbelangrijk) en gaat niet naar beneden. Zonder terugmelding zal het systeem opdrachten blijven sturen totdat het een grens bereikt (die je zelf ergens moet defineren) en een foutmelding geeft. Met terugmelding zal het systeem deze fout veel sneller kunnen detecteren (en eventueel kunnen reageren).
Ik vind het juist een nadeel dat de huidige huis, tuin en keuken "domotica" geen terugkoppeling geeft. Voor een lamp is het simpel, die is aan of niet, maar zodra je functionaliteit uitbreid wil je ook meer weten.
@Dutchman: Redmine bied de functionaliteit die Joomla je kan bieden (ook fora). Ik denk dat je met Joomla ook een wenselijke site kunt bouwen maar eerst de wenselijke plugins bij elkaar moet zoeken en moet uitzoeken of die wel samengaan. Redmine heeft alle wenselijke functionaliteit al in zich. Mocht je hulp nodig hebben bij de inrichting ervan kan ik wel bijspringen.
Joeri de Man
LED there be light
Als het bij sommige apparaten wel handig is, dan maak je het toch optioneel de terugkoppeling? Hoeveel meer moeite zal dit kosten?
Sorry, ik denk zeker dat terugkoppeling optioneel moet zijn! Als het ff kan wil ik ook graag het chinese - zo goedkoop kan ik niet eens een relais krijgen - contactdoosje aan kunnen sturen, en daar krijg ik zeker geen terugkoppeling.
willyp
http://www.020it.nl - Industriële elektronica ontwikkeling. - http://www.procircuits.nl
Wat denken jullie? Kunnen we voor _voorlopig_ anders hier even meer forum topics aanmaken? Dan kunnen we naar mijn idee beter doelgericht werken.
In die paar uur dat ik even dit topic niet lees gaan er echt te veel dingen door elkaar heen. Laat staan de personen die dit nog later lezen.
Topics die nu van toepassing zijn:
*Website ontwikkeling - Wiki etc.
*Protocol keuze
*Te ontwikkelen modules / opzet
*...
Nee, als het al niet in de regels staat dan mag het er wat mij betreft meteen bij; circuitsonline is geen chat site. Gezien het aantal reacties in dit topic (alleen vanavond al) zou je het wel bijna denken. Ik moet toegeven dat ik daar zelf behoorlijk aan meegewerkt heb!
Volgens mij hangt de eigen website op een domein naam? Het maakt mij niets uit wat het wordt, internationaal lijkt mij prima, maar dan moet je ook volledig engels gaan (is voor mij geen probleem). zelfs een ip-adres is (voorlopig) fine by me.
Op die website zou ik enkele forum topics starten omtrent hardware, protocollen en overige wensen.
codom.org is overigens ook een optie
roadrunner84
Meep! Meep!
Ik kijg het gevoel dat we niet helemaal op het goeie spoor zitten.
Er wordt gediscusieerd welke PHY het meest geschikt is. Knadidaten zijn voornamelijk CAN en ZigBee, met af en toe iemand die RS-485 opgooit.
Wat ik denk is dat dit niet het juiste uitgangspunt is. De start vanuit een PHY beperkt al bij voorbaat je flexibiliteit, een slechte zaak.
Het is beter te kijken naar je netwerk opbouw! In feite is de gewenste situatie als volgt: iedere node moet op een betrouwbare wijze gegevens kunnen ontvangen en zenden met de garantie dat die nodes die het aangaat het ontvangen.
Dit is een ontzettend brede definitie, maar geeft wel de meeste flexibiliteit.
In een bedraad netwerk is dit relatief eenvoudig: iedere node ziet iedere andere, garantie is te geven bij de gratie van checksums en acknowledgements. In draadloze netwerken is dit lastiger: niet iedere node kan iedere andere zien. In wireless moet er routering plaatsvinden tussen nodes om integriteit van het netwerk te garanderen.
En daar zit de clue: we willen een netwerk dat op een deugdelijke wijze routering uitvoert.
Door te routeren spelen problemen als bandbreedte niet meer: berichten worden door een verbinding geleid, deze verbinding is in zichzelf immuun voor falen. De mechanismes voor het opzetten van een verbinding en de integriteit van de transmissie zijn een laag die zich bevind tussen de physical layer en de daadwerkelijke berichtsinhoud.
Het probleem valt nu uiteen in drie blokken:
- Welk medium wordt er gebruikt? CAN/ZigBee/etc.
- Hoe wordt routering en transmissie gegarandeerd?
- Hoe zijn berichten opgebouwd?
Het uitgangspunt zou mijns inziens moeten zijn dat de tweede en derde vraag beantwoord moeten kunnen worden voor de eerste! Is dat niet het geval, dan heb je een medium-lock-in: je domotica systeem is afhankelijk van zijn transmissiemedium en dus niet meer portable.
Routering is een gruwelijk moeilijk iets. Het is een vak apart. Gelukkig zijn anderen ons voor geweest: Ethernet en ZigBee. Deze twee systemen gebruiken onder andere routeringstabellen om virtuele verbindingen tussen nodes tot stand te brengen. In een goed domotica systeem zullen we hier dus niet onderuit kunnen komen in de transmissie laag.
De truck bij domotica systemen zit in de derde vraag: hoe zijn berichten opgebouwd. De meeste protocollen zijn gebouwd naar een beperkte mogelijkheid, maar juist dit systeem moet uitbreidbaar zijn. Daar zijn een paar mogelijkheden voor:
- Een lookup table (zoals RC-5 / RDM)
- Een versiebeheer (zoals HTML)
- Een zelfdocumentatie
HCSP gebruikt het eerste: een lookup table. Deze moet worden bijgehouden en gesyncroniseerd met ofwel masters in een systeem ofwel met controllers. Dat is geen wenselijke situatie.
Versiebeheer is in feite hetzelfde, maar gebruikt nummering om blokken lookup tables aan te duiden.
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. Dit is het probleem dat we moeten oplossen.
Beste allemaal,
Zoals ik eerder heb laten weten, ben ik zeer geïnteresseerd in domotica voor eigen gebruik en alles wat hier allemaal geschreven wordt.
Ik ben niet zo thuis in communicatieprotocollen als veel van jullie. Voor mij geldt dat een domoticasysteem goedkoop en zo eenvoudig mogelijk moet zijn. Een van de punten die daar nog bij meespeelt is dat ik liever niet nieuwe kabels hoef te trekken. Waarom is communicatie over het net eigenlijk afgeschreven? Ik zou me kunnen voorstellen dat deze vorm van communicatie lastig is bij hoge snelheden, maar dat speelt volgens mij niet echt bij domoticacommando's. Als ik bijvoorbeeld denk aan een snelheid van 20 kb/s, dan heb je volgens mij nog steeds 2.500 bytes per seconde...van mij mag het best een paar milliseconden duren voordat een lamp aangaat.
Nogmaals ik ben een NooB, maar als het systeem te moeilijk wordt (qua techniek, qua protocol of qua aanleg in huis), vallen volgens mij veel mensen af.
Waar mogelijk wil ik meehelpen, maar ik verwacht dat mijn kennis van deze materie te beperkt is.
Groeten,
Jeroen
het zonwering verhaal:
als de motor blokkeert ziet deze module dat zelf (door timeout, of door meting belastingstroom) en schakelt uit.
Waarom moet hij dat terugmelden? Aan wie? Aan de zonnesensor? Wat moet die ermee? Moet het gemeld op je mobiel? Ga je dan meteen naar huis om 't te fixen?
Uit de pas lopen: Dat hangt dan weer af van je manier van adresseren: Stuurt de schakelaar een 'sfeer up/down'-commando of stuurt hij een 'sfeer x'-commando waarbij hij zelf x eerst verhoogd/verlaagt? In de tweede situatie doet zich het probleem niet voor. Kleine verschillen met grote gevolgen voor de werking.
Terugmelding biedt schijnzekerheid, verlaagt de kans op slechte werking niet, en gaat uit van een slechte verbinding.
Gewoon omdat alle modules over 1 kanaal communiceren.
(Zowel bij Can, RS485, Zigbee, 433 866 etc.)
Fool-proof maken kun je proberen. Het is in mijn ogen verspilling.
Ga dan een industriele of medische toepassing bedenken.
Waar er echte levens van de 100% werking afhangen.
Ik haak af bij dit projekt en wens jullie succes verder bij de ontwikkeling.
JustMe: bedankt voor de tip met het Viper16 voedingkje!
hallo iedereen,
effe ook mijn "domodroom" schetsen.
Ik ben nu sinds een tijdje aan het overschakelen op domotica.
Het is gebaseerd naar een idee van Frits K. van Picbasic.
Ik werk met standaard zelfgemaakte modules, ik heb nu al 3 modules gebouwd.
Alles is verbonden met utp 3 draads systeem.
Modules zijn 4cm op 4cm en passen perfect in een inbouwdoos, hebben 8i/o en 1 pwm out voor de achtergrondverlichting van de schakelaars.
Alle modules kunnen zenden en ontvangen.
Ondertussen heb ik al een testprintje gemaakt dat de bus signalen converteert naar rs232 en vica versa.
Ik wil enkel verlichting en verwarming sturen via bewegingsensoren, tempsens, druknoppen en eencentraal touchscreen.
Fotos volgen.