Difference between revisions of "Domoverse platform"
From Tmplab
m (→Project organization) |
|||
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
= Description = | = Description = | ||
− | This page is intended as placeholder for preparing the | + | This page is intended as placeholder for preparing the Domoverse platform project. |
− | It is a project whose aim is to explore the HMI capabilities of Metaverse-related technologies ( | + | It is a project whose aim is to explore the HMI capabilities of Metaverse-related technologies ([http://opensimulator.org/wiki/Fr OpenSim]/[http://www.openlifegrid.com/ OpenLife]/[http://www.opencroquet.org/index.php/Main_Page OpenCroquet]/[http://www.solipsis.org/ Solipsis]) in a domotics context (X10/Z-Wave, Gumstix, ZigBee...), as home server control and root web house. |
= Project organization = | = Project organization = | ||
− | # State of the art: metaverse platforms and domotics management systems | + | # [Current] State of the art: metaverse platforms and domotics management systems |
# Evaluation of metaverse and domotics management systems candidates | # Evaluation of metaverse and domotics management systems candidates | ||
# Implementation of a tmplab server for experimentation | # Implementation of a tmplab server for experimentation | ||
Line 13: | Line 13: | ||
# Implementation of XMLRPC-like server for services exposition (X10, ...) | # Implementation of XMLRPC-like server for services exposition (X10, ...) | ||
# Linking virtual objects' actions to XMLRPC calls | # Linking virtual objects' actions to XMLRPC calls | ||
− | # Gluing all together | + | # Gluing all together for first prototype |
+ | # Hardware integration on low-consumption devices (WRT?) | ||
+ | |||
+ | = Components = | ||
+ | |||
+ | * XML-RPC server: | ||
+ | ** keeps a list of all detected automation-related devices | ||
+ | ** gives access to underlying features | ||
+ | ** serves cross-world 3D models of real-life controlled items (e.g. light bulb, displays, ...) | ||
+ | * device_connectors: protocol-specific plugins | ||
+ | ** X10 | ||
+ | ** ZigBee | ||
+ | ** Z-Wave | ||
+ | * cross-world 3D models, scripting templates and coding resources | ||
+ | * world-specific interfacing modules | ||
+ | |||
+ | Ultimately, all device-specific information should reside in the devices themselves and answear to requests directly. | ||
= Resources = | = Resources = | ||
− | http://del.icio.us/fthiery/domoverse | + | * http://del.icio.us/fthiery/domoverse |
+ | * [http://community.webbricksystems.com/files/folders/manuals/entry15.aspx WebBrickSystems API example] | ||
+ | * [http://www.automatedhome.co.uk/New-Products/LinuxMCE-710-An-Overview.html LinuxMCE] supports [http://wiki.linuxmce.org/index.php/Category:Automation various home automation protocols] |
Latest revision as of 03:01, 15 June 2008
Description
This page is intended as placeholder for preparing the Domoverse platform project.
It is a project whose aim is to explore the HMI capabilities of Metaverse-related technologies (OpenSim/OpenLife/OpenCroquet/Solipsis) in a domotics context (X10/Z-Wave, Gumstix, ZigBee...), as home server control and root web house.
Project organization
- [Current] State of the art: metaverse platforms and domotics management systems
- Evaluation of metaverse and domotics management systems candidates
- Implementation of a tmplab server for experimentation
- 3D Replication of the lab and it's electronic devices
- Implementation of XMLRPC-like server for services exposition (X10, ...)
- Linking virtual objects' actions to XMLRPC calls
- Gluing all together for first prototype
- Hardware integration on low-consumption devices (WRT?)
Components
- XML-RPC server:
- keeps a list of all detected automation-related devices
- gives access to underlying features
- serves cross-world 3D models of real-life controlled items (e.g. light bulb, displays, ...)
- device_connectors: protocol-specific plugins
- X10
- ZigBee
- Z-Wave
- cross-world 3D models, scripting templates and coding resources
- world-specific interfacing modules
Ultimately, all device-specific information should reside in the devices themselves and answear to requests directly.