Domotica-Owners Forum

Dit is idd mogelijk omdat de software gescheiden is van hardware of domotica-specifieke systemen.

Ik heb dit aangepakt door de U/I enkel over tcp/ip te laten communiceren. Dit kan op twee manieren, straight IP communicatie naar een server/service of via het http protocol en een web-service. Een leuke meerwaarde is dat de U/I ook remote werkt. Je kan die software gewoon op een laptop of andere computer draaien en remote alle functionaliteit uitvoeren.



In principe komt het erop neer dat de U/I over IP praat met een gateway (dus gescheiden lagen). Die gateway plaatst de uiteindelijke commando's op de bus (whatever die dan ook is) en geeft realtime feedback aan de requestor (zijnde de U/I software). Een gateway is in deze context niet meer dan een klein programmaatje dat connectie heeft tot de bus (typisch via een interface) en klaar staat om opdrachten van clients uit te voeren. Natuurlijk kan je meerdere van die gateways draaiende hebben. Zo heb ik een RF gateway, een powerline gateway, een irDA gateway en een audio distributie gateway.

Dit is wat ik eigenlijk bedoelde met te antwoorden op deze post (en idd niet de X10 of eender welke andere standaard), maar wel de integratie mogelijkheden en scheiding van presentatie (U/I) via software gateways. Ideaal - hence my point - zou alles van mij over IP mogen draaien. In dit geval zou je geen gateways nodig hebben.



Als ik morgen beslis om EIB of eender welke andere standaard te implementeren, ben ik er alvast zeker van dat de controle niet aangepast zal moeten worden. Mission accomplished!

Eigenlijk een vrij interesting onderwerp. Misschien moeten we eens een workgroep of zo oprichten en hier eens meer in detail naar kijken.

OK. We zijn het eens over voorgaande berichten.

Er zijn echter wel verscillen in de principiële aanpak van \"applicaties\" in de verschillende systemen. Hoe denk je die aan te pakken?
Wat ik bedoel is hetvolgende: in de communicatie-modellen heb je zaken als:
- client/server
- master/slave
- producer/consumer
- ...

In een client/server systeem zal bvb. de thermometer in de kamer de server zijn: hij stelt de dienst ter beschikking om de temperatuur te meten. Een client (thermostaat) moet de temperatuur gaan lezen. Meestal is het echter omgekeerd: producer/consomer: de temperatuurssensor stelt de temperatuurwaarde ter beschikking, ter consumptie van andere. Op een systeem als X10 wordt de waarde spontaan verstuurd. Als nu de communicatie-modellen niet dezelfde zijn, kan een thermostaat als client de temperatuur vragen, terwijl de sensor (in een ander model, als producer) momenteel helemaal geen geldige waarde heeft (het is bvb. een RF device, dat maar eens om de 15 min meet en doorsturt).
Dit is een simpele functie met input en ouput. Moeilijker wordt het in gecompliceerdere toepassingen (complete verwarmingsinstallatie, toegangscontrole, etc.) Als daar de modellen niet kloppen, heb je logische problemen die niet eenvoudig zijn op te lossen (proxies, etc.).
Om domotica een success te maken en \"engineering\" te verhinderen (nodig voor een doorbraak bij een groot publiek), moet ook dit op één manier opgelost worden.