67
« on: November 10, 2012, 11:04:59 am »
ago control is written from scratch, so it currently lacks a lot of the features offered by LinuxMCE. This is the major drawback right now. On the win side, there is the following from a "core" perspective:
- much easier to understand code base with modern architecture
- does not use DCE/DCERouter for messaging but the AMQP protocol via the apache qpid daemon. This provides enterprise class messaging with things like authentication, fail over (high availability), encryption, very easy integration into many languages like c++, python, Java and more. Messages use english language like 'message["command"] = "on"'. So you don't need to know that command id 192 means on like in DCE. Do you know the parameter number for set level? In ago control it is 'message["level"] = ..'
- loose coupling between components, so no central database with ugly things like sqlCVS or sql2cpp. If you restart a single component, you don't have to restart everything (like when quick reloading the DCERouter in LinuxMCE). Device schema is held in a yaml structure so user interfaces know easily what controls to provide to the user. No hard dependencies on components and easy replacement of them. No need for "plugins" that share the DCERouter memory space, everything is just another daemon. You don't have to rely on services like the "resolver", it is just helpful to map device UUID to name and such.
- very leightweight, runs on many embedded systems like the raspberry or a plug computer
- cloud features, you can log in to the ago control cloud and control your devices even when you're not at home. Without any complex VPN configuration
In my dreams this will become LinuxMCE 3.0. It has the potential. Of course there is a huge amount of work to do to get feature parity with the current LMCE 2.0. Currently there is no such thing as an orbiter, the user interface options are:
1) Web admin
2) access via cloud
3) simple android app, much work needs to be done in this area, but it allows on/off control of devices and scenarios
4) meloware iphone app
On the home automation side there is a scenario handler and an event handler. So you can make "command groups" via scenarios, and also add delay in between commands. You can respond to events like sunset, device level change or do timed events. They can be edited via the web admin. Needs some polishing but basic functionality is there. Next step will be enrichment of event criteria, like states of other devices and "global" state like day/night.
On the device support side the things are improving daily. Z-Wave support via OpenZWave (much cleaner design than the LinuxMCE driver, better support for enhanced protocol features), KNX support will be ready in a few days (via eibd, so running in parallel with lmce works fine), EnOcean is under construction, about 50% done. 1wire works fine for temp, humidity, brigthness and I/O sensors. Chromoflex USP3 is also supported. Onkyo EISCP just needs a few more lines of code to implement more than on/off.
There also exists a bridge from LinuxMCE to agocontrol. It still needs some work to automatically announce devices to LinuxMCE and support more commands than on/off/setlevel. This will allow you to run LinuxMCE and agocontrol in concert. You might ask yourself "why?" - e.g. you could use ago control for basic automation and only power on your LinuxMCE system when you need media. This will save a lot of energy when you're running ago control on a low power ARM computer.
So much for a short overview. Volunteers for coding, testing, and using? ;=)
Show Posts