DoIP: Domotica-over-IP

[LauPro]

In navolging van deze reply: LauPro in "[EiP] room control"

Inleiding

Wat is DoIP? DoIP staat voor Domotics-over-IP, een soort van afgeleide van VoIP. Doel van het systeem is om eenvoudig domoticatoepassingen aan te kunnen sturen met de computer. Dit enerzijds door ervoor te zorgen dat er een breed scala aan hardware wordt ondersteund en anderzijds een zeer eenvoudige bediening. Wat is domotica? Domotica is het automatiseren van een woning of bedrijfspand. Dit klinkt heel erg duur en ingewikkeld maar het komt er op neer dat als je bijvoorbeeld thuis komt van je werk, en het is donker, automatisch de verlichting aan gaat. Zodra je TV gaat kijken gaat bijvoorbeeld de lamp boven de eettafel uit. Dit kan je nog veel verder trekken door het integreren van verwarming, airco's, koeling, ventilatie (hvac), irrigatie, mediacenters, dvd, tv etc. Praktisch alle apparaten met een afstandsbediening kunnen worden geautomatiseerd. Kanttekening is wel dat nu nog niet alles apparaten ook echt goed geschikt zijn. Dit kan ik toch al met de Philips Pronto of Logitech Harmony? Ja klopt, het probleem met deze producten is echter dat ze zijn ontwikkeld met het idee om de bediening van apparaten te vereenvoudigen. Bij de meest 'simpele' home theatre-opstelling heb je al snel een legio aan apparaten. Bij DoIP spreken we meer over een integratie van deze apparaten in een groter geheel, en eigenlijk kan de bediening van de verlichting bij domotica niet ontbreken.

Domotica

Oke, ik snap de bedoeling, wat nu? Ongeveer 3 jaar geleden ben ik gaan kijken wat er voor mogelijkheden waren voor domoticaoplossingen. Er zijn veel gesloten systemen op de markt, de meeste leveranciers van domoticaoplossingen die gebruiken PLC aansturingstechniek. Dit omdat er eigenlijk nog nauwelijks apparatuur beschikbaar is die aan alle eisen voor een goede domoticaopstelling voldoet (in mijn ogen). Een domotica-implementatie kan je opsplitsen in 2 situaties: • Integratie in een bestaande situatie Bij een bestaande situatie is het belangrijk dat er zonder veel verbouwingen (sleuven frezen) het aan te leggen valt. Te denken aan bijvoorbeeld veel tussenadapters van KlikAanKlikUit. • Integratie bij nieuwbouw Bij nieuwbouw is er veel meer ruimte voor een goede implementatie van domotica. Zo kunnen er vooraf extra leidingen worden gefreesd (mooie afwerking) en kan je er rekening houden bij het kopen van bepaalde apparatuur. Wat levert mij domotica op, het klinkt heel erg prijzig De aanleg van domotica t.o.v. de klassieke bouw is altijd duurder. Toch moet je vooral de voordelen er van kunnen inzien. Daarnaast kan, een goede installatie, je huis bij een eventuele verkoop een leuke waardevermeering geven. Maar opgepast, een slecht aangelegde installatie kan alleen maar meer kosten met zich meebrengen. Domotica is in eerste instantie bedoeld om het leven makkelijker te maken, dus nooit meer de verlichting aan of uit te hoeven doen en de tuin wordt automatisch besproeid als de hele dag de zon scheen. Tevens kan het zorgen voor een flinke energiebesparing (ondanks dat het systeem ook energie nodig heeft). Maar ik heb al een bewegingsmelder in de gang? De kracht van domotica is dat je alles gecentraliseerd kan beheren. Natuurlijk zijn er al diverse producten op de markt waar je per situatie een vorm van automatisering kan toepassen (denk aan lampen met bewegingsmelders, tijdklokken, schemerschakelaars). Het probleem met deze producten is dat je ze niet gecentraliseerd kan bedienen. Een tijdklok loopt vaak door de zomer/wintertijd steeds hopeloos achter, een schemerschakelaar hoeft misschien als je op vakantie bent niet de tuinverlichting aan te zetten, etc. Door dus op 1 punt alles te beheren kan je dus alles veel sneller afstellen. Belangrijkste is dat je natuurlijk altijd klein kan beginnen en het langzaam uitbouwen. Zijn alle apparaten compatible? Nee, je moet eerst goed uitzoeken welke apparaten compatible zijn.

DoIP

De bedoeling van DoIP is om alle protocollen die nodig zijn voor de communicatie samen te vatten onder 1 standaard. Er zit bijvoorbeeld een stukje XML in waarmee eenvoudig bijvoorbeeld een webinterface kan praten. Daarnaast zijn er wat zaken gespecificeerd aangaande de opbouw van installaties. Om gewoon eens praktisch iets te kunnen doen heb ik een programma geschreven waarmee een domotica-installatie kan worden aangestuurd en beheerd. Het werkt op basis van regels. Zie de onderstaande screenshots: DoIP Previews De (open source) software zelf kan worden gevonden op: http://doip.laupro.nl.

Hardware ondersteund

Op dit moment is de volgende hardware ondersteund: • Velleman K8055 • Velleman K8061 • Parallele poort • LIRC (dus ook indirect KaKu, zie ander topic, zelf nog niet getest) • De velbus is WIP. • Metasys N2 protocol is ook WIP. • Optomux is ook WIP. Er is ook een vrituele driver voor testdoeleinden, je kan dus de software gebruiken zonder hardware. De software zelf is nog BETA, dus niet helemaal bugvrij. Uiteindelijk is het de bedoeling dat je op IP-niveau je lamp aan/uit kan doen. Tot die tijd zullen er aparte interfaces nodig zijn.

Doel van dit topic?

Het bespreken van domoticatoepassingen en -installaties. Daarnaast kan er over nagedacht over het verder uitbreiden van de software en het integreren van de verschillende apparaten.

[Verwijderd]

Mooie opener!
Klopt het dat het "IP-aspect" in de hardware nog niet aan bod komt?

[Verwijderd]

Had je al eens gekeken naar XPL
http://www.xpl-home.org/
Inmiddels zijn er al een groot aantal drivers geschreven voor diverse hardware. Onder andere voor RFXCom (hiermee kun je RF spul aansturen zoals Klik Aan Klik Uit). Koppeling met MCE, Slimserver en andere audio en video devices is gerealiseerd. X10 en Zwave wordt ook ondersteund. Als centraal systeem is er XPLHal beschikbaar voor windows. Voor Linux is er Zenah. Er zijn libraries beschikbaar om zelf te ontwikkelen in C++, C#, Visual Basic, C, Perl en Python dus er zijn mogelijkheden genoeg.
Verder is XPL geheel open source.

Michael

[feelthepower]

Wat is de connectie of het verschil met bijvoorbeeld x-10 dan?

[Sypher]

Interessant topic.

Laatste tijd begint het Domotica verhaal mij steeds meer te trekken, en nu ik plannen heb om een HTPC neer te gaan zetten kan ik die misschien wel dubbel inzetten voor zowel media als management.

Leuke webinterface overigens

[battler]

Prachtig, voor mij ook zeker iets om mee te experimenteren.

[LauPro]

Verwijderd schreef op woensdag 20 februari 2008 @ 08:33:
Mooie opener!
Klopt het dat het "IP-aspect" in de hardware nog niet aan bod komt?

Op dit moment zijn er nog geen apparaten die native DoIP-ondersteuning (oid) hebben.

Verwijderd schreef op woensdag 20 februari 2008 @ 08:55:
Had je al eens gekeken naar XPL

Het probleem dat ik bij deze systemen vind (ook bijvoorbeeld MrHouse) is dat het veel teveel op scripting af hangt. Ik wil met de lpDoIPd echt een solide daemon maken die eventueel ook embedded kan draaien op bijvoorbeeld een Sweex router (dus met lage footprint). De software kan zelf ook worden gebruikt om apparaten IP-ondersteuning te geven, je kan de daemon 'nesten'.

feelthepower schreef op woensdag 20 februari 2008 @ 09:01:
Wat is de connectie of het verschil met bijvoorbeeld x-10 dan?

X10 is een systeem op zichzelf en heel veel implementatieproblemen bij bestaande installaties. Uiteindelijk is het de bedoeling om vanuit de lpDoIPd ook een X10 driver aan te kunnen sturen, het is een kwestie van het ontwikkelen van een driver.

[vso]

Dit is ook een wens van mij geweest
immers IP is makkelijker te beheren dan (weer) een extra systeem.

het zou handig wezen als je
- thermostaat
- verwarming kraan zelf
- was machine (aan/uit zetten op voordelige tijden)
- vaatwasser (aan/uit zetten op voordelige tijden)
- verlichting
- aquarium (verlichting pompen etc)
- zonnescherm / rolluik(ken)
kan aansturen

[maddog_rvo]

vso schreef op woensdag 20 februari 2008 @ 12:30:
Dit is ook een wens van mij geweest
immers IP is makkelijker te beheren dan (weer) een extra systeem.

het zou handig wezen als je
- thermostaat
- verwarming kraan zelf
- was machine (aan/uit zetten op voordelige tijden)
- vaatwasser (aan/uit zetten op voordelige tijden)
- verlichting
- aquarium (verlichting pompen etc)
- zonnescherm / rolluik(ken)
kan aansturen

Probleem met IP lijkt me dat je telkens weer dure converter apparaten nodig hebt?
Wireless lijkt me ook moeilijk

[xtra]

maddog_rvo schreef op woensdag 20 februari 2008 @ 13:12:
[...]


Probleem met IP lijkt me dat je telkens weer dure converter apparaten nodig hebt?
Wireless lijkt me ook moeilijk

Het voordeel van IP lijkt me juist dat het ook met goedkope converterapparaten kan. Een thermostaat met BlueTooth-chippie en wat software is in theorie genoeg. Je kunt per apparaat verzinnen wat de handigste verbinding is. (BT, WiFi, koper etc.)

[maddog_rvo]

xtra schreef op woensdag 20 februari 2008 @ 13:23:
[...]

Het voordeel van IP lijkt me juist dat het ook met goedkope converterapparaten kan. Een thermostaat met BlueTooth-chippie en wat software is in theorie genoeg. Je kunt per apparaat verzinnen wat de handigste verbinding is. (BT, WiFi, koper etc.)

Hmm als je het zo bekijkt... is het inderdaad wel handig.
Nu nog hopen dat homemade goed mogelijk is (voor mij dan, ben nl niet zo heel goed in software schrijven voor uC )

[ Voor 5% gewijzigd door maddog_rvo op 20-02-2008 13:41 ]

[j-a-s-p-e-r]

En IPv6 erbij, lijkt me ook wel vrij handig als je alle schemerlampen een eigen IP gaat geven

[maddog_rvo]

j-a-s-p-e-r schreef op woensdag 20 februari 2008 @ 13:51:
En IPv6 erbij, lijkt me ook wel vrij handig als je alle schemerlampen een eigen IP gaat geven

Hoeveel schemerlampen heb jij

[Tukk]

maddog_rvo schreef op woensdag 20 februari 2008 @ 13:58:
[...]


Hoeveel schemerlampen heb jij

Ik neem aan dat hij bedoelt dat zijn schemerlamp rechtstreeks op het Internet kan zitten, achter je router heb je IPv6 niet nodig.

[vso]

erhm hoewel ik graag alles deel lijkt me het beschikbaar stellen van diverse apparatuur voor de wereld niet echt een wens.. ik zie de 404 page al .. requested website is not found @ this lightsource

BT of Wifi gaat mij persoonlijk iets te ver omdat het wel makkelijk te hakken is.
maar de keuze tussen kabel/niet kabel is oke..

Wat de TS stelt van NTP services gebruiken en meer samenwerking van apparaten ipv
diverse protocolen die slecht op elkaar af te stemmen daar ben ik helemaal voor

[ Voor 43% gewijzigd door vso op 20-02-2008 14:21 ]

[j-a-s-p-e-r]

Ik ben met een soortgelijk projectje bezig. Het past eigelijk niet 100% in dit topic, maar het meer om mensen een idee te geven wat je er mee kan cq. hoe het er uit kan zien.


Achter deze site zit een apache 2 webserver samen met PHP & MySQL. De MySQL bevat een database met 3 tabellen: een met tijden en 'winlirc code' , een met 'winlirc code' versus 'echte naam' en nog een tabel voor de knoppen rechts.
De feitelijke aansturing gebeurd met een zelfgebouwd zendertje aan de comport (10 euro) welke via WinLirc aan wordt gestuurd. Deze zender kan dan de bekende Klik Aan Klik Uit schakelaars bedienen.

Dan nog @TS; erg leuk initiatief. Het doet me een beetje denken aan het java progsel van Emiel (room control) leuk dat het zo universeel is.:)

[Verwijderd]

mgb schreef op woensdag 20 februari 2008 @ 08:55:
Had je al eens gekeken naar XPL

Het probleem dat ik bij deze systemen vind (ook bijvoorbeeld MrHouse) is dat het veel teveel op scripting af hangt. Ik wil met de lpDoIPd echt een solide daemon maken die eventueel ook embedded kan draaien op bijvoorbeeld een Sweex router (dus met lage footprint). De software kan zelf ook worden gebruikt om apparaten IP-ondersteuning te geven, je kan de daemon 'nesten'.

Op dit moment heb ik de XPLHub draaien op een sweex routertje. Op deze router ben ik nu bezig met de interface voor de io lijnen. Met XPL is het mogelijk om een schakelaar die xpl praat rechstreeks te laten communiceren met een lamp die xpl praat zonder dat daar overige scripting bij komt. Echter wil je wel graag centraal weten of een lamp aan of uit is en of iemand een schakelaar gebruikt. Scripting heb je nodig om meer complexe dingen te gaan doen. Bij XPL is het vrij simpel om de afstandsbediening van je squeezebox ook te gebruiken om de verlichting op je kamer aan en uit te zetten. Als je de squuezebox aanzet, dan kun je vrij simpel ook de versterker aan laten schakelen.

XPL draait op de sweex router als een daemon. Ik zie de meerwaarde van nog een extra protocol dus niet.

[Verwijderd]

Pilight werkt in ad-hoc configuratie bijvoorbeeld compleet over TCPIP. Communicatie naar devices echter niet.

[ Voor 191% gewijzigd door Verwijderd op 28-01-2017 18:56 ]

[LauPro]

Verwijderd schreef op woensdag 20 februari 2008 @ 14:58:
Op dit moment heb ik de XPLHub draaien op een sweex routertje. Op deze router ben ik nu bezig met de interface voor de io lijnen. Met XPL is het mogelijk om een schakelaar die xpl praat rechstreeks te laten communiceren met een lamp die xpl praat zonder dat daar overige scripting bij komt. Echter wil je wel graag centraal weten of een lamp aan of uit is en of iemand een schakelaar gebruikt. Scripting heb je nodig om meer complexe dingen te gaan doen. Bij XPL is het vrij simpel om de afstandsbediening van je squeezebox ook te gebruiken om de verlichting op je kamer aan en uit te zetten. Als je de squuezebox aanzet, dan kun je vrij simpel ook de versterker aan laten schakelen.

XPL draait op de sweex router als een daemon. Ik zie de meerwaarde van nog een extra protocol dus niet.

Voordat ik met het project begon ben ik gaan kijken of er vergelijkbare systemen zijn. XPL heb ik toen ook zeker bekeken en mijn ervaring is dat het niet de robustheid heeft die ik verwacht. Sowieso is het niet echt platform onafhankelijk, per OS zijn er aparte drivers nodig en alle automatiseringen zijn gebaseerd op scripting - iets dat voor een eindgebruiker onmogelijk te bedienen is.

Ik heb hier overigens al een Sqeezebox icm een versterker draaien met DoIP. Er zal in DoIP ook zeker een XPL-module komen zodat je met die devices kan communiceren.

Het idee is dat je overal dezelfde software gebruikt maar steeds andere modules activeert. Er zijn bijvoorbeeld een aantal logica-modules die een 'hub' in principe niet nodig heeft, die kan je dan uitschakelen. De coreapplicatie zal dus overal draaien.

Eventueel kan er met een externe (Java) GUI worden verbonden met deze core zodat je instellingen kan wijzingen. 1 'Core' in je netwerk dan de centrale controller die bepaalt welke apparaten moeten worden aangestuurd bij welke events, eventueel valt er nog redundantie in te bouwen.

Dus er zijn zeker gelijkenissen, maar ik denk dat de projecten beide bestaandsrecht hebben op hun eigen kernpunten.

[Megamind]

Ik heb dit ook eens overwogen en bekeken.

Ik wilde dus elk stopcontact en schakelaar over IP laten gaan, maar dat is ondoen. Het maken van de print is nog wel te doen kwa prijs, maar dan al die netwerk kabels + switches.

Ik ben nu eigen RF prints aan het maken. Maar het idee is inderdaad leuk.

[ Voor 5% gewijzigd door Megamind op 20-02-2008 22:04 ]

[Verwijderd]

Pilight is ongetwijfeld de lichtste optie totdat een universeel (be)draad(loos) domotica TCPIP protocol ontstaat.

[ Voor 126% gewijzigd door Verwijderd op 28-01-2017 18:57 ]

[Megamind]

Verwijderd schreef op woensdag 20 februari 2008 @ 22:16:
[...]

Switches? Kabels? Wikipedia: HomePlug

Dat is een beetje dezelfde koek als X10, Z-Wave etc. Leuk spul allemaal, maar vaak beperkt assortiment, én dure SDK / software. Als HomePlug een simpel opensource alternatief zou bieden zou het perfect zijn, maar aangezien het product amper op de markt is zie ik dat nog niet gebeuren voorlopig.

[LauPro]

Dat klopt, naast X10 en KaKu zijn er er eigenlijk geen fatsoenlijke beschikbare systemen op de markt in mijn ogen.

[FloRadix]

Ik weet dat er hier niet lang op werd gereageerd, maar ondertussen is er nieuwe speler om de markt waarbij heel de installatie als beheer 'over IP'wordt beheerd.

Het systeem komt van Easyplus


Zijn er al mensen deze techniek gebruiken?

[Verwijderd]

Ik ben met wat mensen ook bezig met domotica, onze insteek is echter totaal anders. Waar jij een daemon als kern hebt, willen wij een abstract netwerk als kern gebruiken.
Onze keypoints zijn:
- Decentraal
- Transportlaag onafhankelijk
- Open
Er zijn al genoeg systemen die met een centrale werken, het is juist een goed punt om zonder centrale te werken. Redundantie is dan ook geen punt meer, omdat iedere node (ongeveer) evenveel gewicht in de schaal legt.
Bovendien willen we werken zonder een vaste keuze voor een transportlaag. Later komen er implementaties voor transport over bijvoorbeeld CAN, Ethernet, IP, ZigBee, enzovoort. De routering tussen de verschillende transporten wordt volledig transparant.

[0fbe]

Megamind schreef op woensdag 20 februari 2008 @ 22:04:
Ik heb dit ook eens overwogen en bekeken.

Ik wilde dus elk stopcontact en schakelaar over IP laten gaan, maar dat is ondoen. Het maken van de print is nog wel te doen kwa prijs, maar dan al die netwerk kabels + switches.

Ik ben nu eigen RF prints aan het maken. Maar het idee is inderdaad leuk.

Wat dacht je van 6LoWPAN

[Boudewijn]

Die post is dik 2 jaar oud .

[0fbe]

Boudewijn schreef op vrijdag 16 april 2010 @ 13:02:
Die post is dik 2 jaar oud .

Ow damn, goeiemorgen Simplendi

[pasz]

Verwijderd schreef op vrijdag 16 april 2010 @ 12:24:
Ik ben met wat mensen ook bezig met domotica, onze insteek is echter totaal anders. Waar jij een daemon als kern hebt, willen wij een abstract netwerk als kern gebruiken.
Onze keypoints zijn:
- Decentraal
- Transportlaag onafhankelijk
- Open
Er zijn al genoeg systemen die met een centrale werken, het is juist een goed punt om zonder centrale te werken. Redundantie is dan ook geen punt meer, omdat iedere node (ongeveer) evenveel gewicht in de schaal legt.
Bovendien willen we werken zonder een vaste keuze voor een transportlaag. Later komen er implementaties voor transport over bijvoorbeeld CAN, Ethernet, IP, ZigBee, enzovoort. De routering tussen de verschillende transporten wordt volledig transparant.

Vreemd genoeg is het vaak de transport laag die problemen veroorzaakt. Iedere [censuur] kan een eigen protocolletje schrijven en dat over tcp/ip versturen. Maar een reeks schakelaars simpel aansluiten op een netwerk is een ander verhaal.

[LauPro]

Daar ligt dus de uitdaging in om een uniforme interface te ontwikkelen zodat je wel een schakelaar direct kan aansturen.

Dan zit je alleen nog met de vraag hoe je security/ACL's gaat implementeren.

[Verwijderd]

Wat bedoel je Lau? Denk je dat het naief is van me om binnen mijn netwerk impliciete vertrouwensbanden tussen nodes te hebben? Wat voor effect kan dat volgens jou hebben op de betrouwbaarheid van mijn netwerk? Ik kan toch moeilijk iedere node als een potentiele indringer gaan behandelen?

[mux]

Ik denk wel dat je encryptie en authenticatie moet toepassen, en daarom denk ik dat je ook een aparte, uniforme transportlaag moet hebben waarbinnen alle domotica zit, met één gateway naar iets publieks toe. Bijvoorbeeld (dit is maar een voorbeeld) één TCP/IP client op je thuisnetwerk met daarachter een CAN-netwerk met domotica. Zo kan alle security in de tcp/ip client worden gegooid, en kunnen je nodes zo simpel mogelijk (maw je kunt gemakkelijk nodes ontwikkelen voor alle mogelijke toepassingen, zonder daar veel rekenkracht of moeilijke features nodig te hebben).

Een domoticaserver zoals ik die hier voorstel kan dan ook domotica area network (DAN)-wide settings beheren, profielen, etc., en dat maakt je nodes nog simpeler omdat die enkel directe, lineaire, ongetimede (geen rtc nodig!) events uit hoeven te voeren. En, om al je domotica te beheren hoef je maar één keer authenticatie uit te voeren.

[FloRadix]

welke software gebruiken jullie voor dergelijk systemen gebruikmakend van tcp/ip protocol?

[Verwijderd]

@ssj3gohan:
Je bedoelt dat je beveiliging nodig hebt op je internet-attached domotica controller? Ja, dat lijkt me wel een goed idee, maar dat is dan toch geen beveiliging van het domotica netwerk zelf?

[mux]

Nee, een beveiliging van het domotica-netwerk naar welke andere interface dan ook. Het ligt voor de hand om het geheel te besturen via een TCP/IP-gateway ('domotica over IP') maar om elke node uit te rusten met een ethernetpoort is mechanisch lastig, gebruikt erg dikke kabels en zorgt voor extra software-complexiteit.

Dus je gooit alle domotica op hun eigen netwerk. Dat netwerk op zichzelf kan helemaal niks! Het is afgesloten van elke vorm van interface naar de buitenwereld. Juist op die punten van interface naar de buitenwereld - zoals een tcp/ip domoticaserver, maar dat kan net zo goed een zigbee of blauwtandmodule zijn - gooi je je security.

[MisterData]

Ik ben zelf ook al een tijdje bezig met het ontwikkelen van een domoticasysteem dat diverse systemen aan elkaar kan koppelen. In tegenstelling tot de eerder genoemde systemen zorgt dat van mij naast het simpelweg koppelen van andere systemen/protocols ook voor automatische koppeling van functionaliteit.

Het idee is dat apparaten elkaar automatisch vinden (nu geïmplementeerd via Bonjour, maar ook andere protocols als SLP kunnen worden gebruikt) en dan automatisch onderhandelen over het gebruikte transportmechanisme (op dit moment voornamelijk OSC over UDP of TCP over IPv4 of IPv6). Als dat is gebeurd, kan een apparaat kijken welke functies het andere apparaat ondersteunt (waarbij gebruik wordt gemaakt van een set met 'standaard' messages). Stel dat je bijvoorbeeld een lamp in het netwerk hebt hangen, dan ondersteunt deze een 'dim' methode. Iedere client in het netwerk die het licht wil dimmen, vindt vanzelf alle apparaten die 'dim' ondersteunen. Zodra ik een nieuwe lamp heb gekocht, zou simpelweg inpluggen genoeg moeten zijn.

Door middel van tagging is het mogelijk om groepen apparaten te maken (als je een film gaat kijken wil je niet dat álle lampen in je netwerk gedimd worden, maar alleen die in de huidige kamer, bijvoorbeeld). Het systeem werkt verder op basis van een soort 'apps' die op basis van regels bepaalde functionaliteit aan elkaar koppelen. Zo heb ik hier een 'wake up light'-app die op een in te stellen tijd alle lampen in m'n kamer aanzet (geleidelijk, dan). De apps draaien als scripts in een server-applicatie (waarvan je er dus meerdere in een netwerk kunt hebben); ik draai ze zelf onder Linux op energiezuinige ARM-bakjes (zoals de NSLU2 en de SheevaPlug).

Een en ander gaat binnenkort open-source worden; een groot deel van de documentatie is nu vast te vinden op deze website

[ Voor 5% gewijzigd door MisterData op 16-04-2010 16:07 ]

[LauPro]

Verwijderd schreef op vrijdag 16 april 2010 @ 13:37:
Wat bedoel je Lau? Denk je dat het naief is van me om binnen mijn netwerk impliciete vertrouwensbanden tussen nodes te hebben? Wat voor effect kan dat volgens jou hebben op de betrouwbaarheid van mijn netwerk? Ik kan toch moeilijk iedere node als een potentiele indringer gaan behandelen?

Dat ligt aan het protocol. Op een CAN-bus mag je er min of meer vanuit gaan dat het hele systeem als zodanig binnen 1 beveiligingszone valt. Bij een (switched) ethernet omgeving vind ik dat weer minder acceptabel. Mogelijkheden zijn er met IPsec e.d..

[SA007]

Ik ben het zelf er totaal niet over een dat je een lokaal can netwerk als veilig kunt beschouwen.

CAN zoals veel type netwerken op de hardwarelaag geen beveiliging, en als je al je binnenverlichting eraan gaat hangen is het tot daar aan toe.

Maar als je ook andere dingen zoals buitenverlichting, poort(alsin fysieke poort op je uitrit)besturing en dergelijke eraan hebt hangen wil ik toch een vrij goede security layer.
Wat zou anders een inbreker tegenhouden om een schop in de grond te zetten, de CAN kabel naar het tuinlampje bij het hek aan zijn laptop te hangen een scannetje draaien en vervolgens de deur voor zichzelf opendoet.

Als dat far-fetched lijkt, het wordt al actief gebruikt bij de CAN bus in auto's, sla een lampje in, trek de CAN eruit, lappie eraan en hoppa deuren open en motor starten...

Security zou ik daarom zeer zeker in de modules zelf plaatsen. Dat hoeft niks complex als AES ofzo te zijn, maar een layer zodat niet alles 1op1 kan.

Hier hangt wel weer aan vast dat je een centrale kast moet hebben om die keys te managen etc, maar die moet je toch wel hebben om events te beheren etc.

[Verwijderd]

SA007 schreef op vrijdag 16 april 2010 @ 23:40:
...
Maar als je ook andere dingen zoals buitenverlichting, poort(alsin fysieke poort op je uitrit)besturing en dergelijke eraan hebt hangen wil ik toch een vrij goede security layer.
Wat zou anders een inbreker tegenhouden om een schop in de grond te zetten, de CAN kabel naar het tuinlampje bij het hek aan zijn laptop te hangen een scannetje draaien en vervolgens de deur voor zichzelf opendoet.
...
Hier hangt wel weer aan vast dat je een centrale kast moet hebben om die keys te managen etc, maar die moet je toch wel hebben om events te beheren etc.

Je hebt gelijk, een zekere beveiliging is op zijn plaats.
Ik wilde in mijn systeem geen centrale kast hebben (volledig distributed). Maar er zijn genoeg mogelijkheden om de beveiliging ook te distribueren, volop hashes, signs, keys enzovoort. Bedankt voor dit inzicht

[Stoney3K]

[b][message=33843913,noline]Maar als je ook andere dingen zoals buitenverlichting, poort(alsin fysieke poort op je uitrit)besturing en dergelijke eraan hebt hangen wil ik toch een vrij goede security layer.
Wat zou anders een inbreker tegenhouden om een schop in de grond te zetten, de CAN kabel naar het tuinlampje bij het hek aan zijn laptop te hangen een scannetje draaien en vervolgens de deur voor zichzelf opendoet.

Ik vind een inbreker al heel knap als ie in de gaten heeft dat mijn hek aan een CAN-bus hangt en er dan óók nog eens op een correcte manier op in weet te breken

Then again, dit kun je op andere manieren ook prima opvangen. Cryptografie is een crime om te implementeren in microcontrollers, en je wil ook niet elke deur open/dicht transactie gaan nakijken of het allemaal wel in orde is. Domotica is bedoeld voor het gemak, niet voor beveiliging, als ik wil dat niemand binnen komt dan draai ik de deur/hek gewoon _op slot_.

Elk lampje, knopje en motortje over IP gaan hangen is sowieso al niet praktisch, omdat het betekent dat je óveral Ethernet-bekabeling moet leggen en een loeier van een switch nodig hebt, die nauwelijks verkeer voor zijn kiezen krijgt. Een RS485-verbinding is makkelijker, je legt gewoon een CAT3 (ronde telefoonkabel) met power en bus-verbinding naar de nodes toe, en klaar is Kees. Nodes die meer stroom nodig hebben (zoals LED-aansturingen of motorschakelingen) kunnen hun eigen prik weer uit de dichstbijzijnde muur halen.

[mux]

Is het echt zo moeilijk?

Ik vind dat als je zoiets maakt - zeker met de complexiteit die het op zichzelf al met zich meebrengt - je het ook goed moet doen. AES encryptie is een peulenschilletje op een microcontroller en kan zelfs, als je dat wilt, helemaal automagisch met een hulpchippie. Ik heb zelfs in Javascripti software AES geimplementeerd in een weekendje. AES heeft ook maar ongeveer 2 blokken (van meestal 16x16 bytes) geheugen nodig, dus een tiny2313 kan het zelfs nog doen.

[LauPro]

SA007 schreef op vrijdag 16 april 2010 @ 23:40:
Ik ben het zelf er totaal niet over een dat je een lokaal can netwerk als veilig kunt beschouwen.

Daarom moet je meerdere beveiligingszones maken:
• Zone 1: deuropeners en elektrische sloten
• Zone 2: binnenverlichting + automatisering
• Zone 3: buitenverlichting + automatisering

Elke zone heeft dan bijv. een eigen CAN-bus (of welk protocol je ook gebruikt).

Eventuele paslezer aan een hek moet dan ook zijn eigen zone hebben en communicatie op zijn minst versleuteld zijn. Wat heel belangrijk is is dat er 'buiten' (om de fysieke beveiliging heen) geen beslissingsmakers zijn in je model.

[MisterData]

Kleine kick, maar sinds een paar dagen is mijn eigen DoIP-sofware open-source (LGPL) gegaan. Het bestaat uit een protocol suite gebaseerd op mDNS/DNS-SD (Bonjour), OSC en HTTP. Het idee is dat apparaten elkaar automatisch kunnen vinden aan de hand van de messages die deze ondersteunen. Naast een library om dit eenvoudig in je eigen C++ applicatie te integreren zijn er ook een aantal utilities (iPhone client, Mac client, Linux server voorbeelden) aanwezig.

Zie doip.org voor informatie en hier voor de broncode

[Verwijderd]

ssj3gohan schreef op maandag 19 april 2010 @ 11:43:
Is het echt zo moeilijk?

Ik vind dat als je zoiets maakt - zeker met de complexiteit die het op zichzelf al met zich meebrengt - je het ook goed moet doen. AES encryptie is een peulenschilletje op een microcontroller en kan zelfs, als je dat wilt, helemaal automagisch met een hulpchippie. Ik heb zelfs in Javascripti software AES geimplementeerd in een weekendje. AES heeft ook maar ongeveer 2 blokken (van meestal 16x16 bytes) geheugen nodig, dus een tiny2313 kan het zelfs nog doen.

Maar als je AES in een hulpchip stopt betekent dat ook dat je het signaal weer kan aftappen tussen de hulpchip en de micro in. Dit is een beetje hetzelfde probleem waar o.a. microsoft tegenaan liepen bij hun trusted computing modules. Dat betekent namelijk ook meteen dat je intrusion detection op de behuizing van je module moet gaan bouwen...
16x16 bytes... = 256 bytes.... da's dus het dubbele van de hoeveelheid ram in m'n MSP430 chipjes

[mux]

Nouja, ik ga er vanuit dat het doel van de encryptie is voorbijgestreefd zodra je fysiek toegang hebt tot de toestellen - dan ben je al ongewenst binnengekomen. Maar je hebt gelijk, als je zo'n toestelletje echt goed wilt beveiligen zul je encryptie en verwerking helemaal on-chip moeten doen.

@MisterData: mooi spul. Jammer dat het zo high-level is, anders was het zeker terecht gekomen in mijn domotica

[ Voor 16% gewijzigd door mux op 20-05-2010 14:29 ]