Make domus.Link a modular system

[GoogleCodeExporter]

Purpose of feature on this branch:
I would like to see dL become more modular in a sense based on systems
which can be enabled and disabled in the Frontend configuration screen.
These systems would be for example: Lighting, Appliances, Shutters,
Irrigation, Security, HVAC, etc...
The reason for this is that not all people have all systems in place and it
would reduce screen clutter for those that don't need the extras.

Each system may include their own directives, environment variables, and
macros which could be tied to single-click buttons on the UI. That being
said, I also think that each system should have their own configuration
pages for settings.

In a household where there are multiple instances of dL up on the browser
simultaneously on either a computer, smartphone, or wifi tablet; each
instance should be able to enable and disable modules separately. This way
you could have for example; a home security kiosk, an HVAC wall mounted
tablet, and multiple tablets on nightstands or end tables to control
lighting and appliances.


Proposition for feature implementation:
Due to the improvement in config file parsing, this may now be possible.

When reviewing my code changes, please focus on:
N/A

After the review, I'll merge this branch into:
future
/trunk

Original issue reported on code.google.com by brandtda...@gmail.com on 12 May 2010 at 6:19

• Blocking: Implement Heyu Home Security Features #32, Support of RCS TXB16 #35

[GoogleCodeExporter]

I have sort of implemented this with my hvac branch. It could be easily added 
on to the other systems.

The part I am not sure about is the last paragraph where I talk about each 
instance should be able to enable/disable separately. This may not be necessary 
in the default theme, and may be handled in separate themes.

Original comment by brandtda...@gmail.com on 5 Aug 2010 at 4:31

[GoogleCodeExporter]

I have started this and have implemented a group feature for the aliases. This 
allows the creation of custom groups and assign aliases to them. The groups can 
also be turned invisible. Along with the new security feature, you can assign 
modules to group and an access level and by the use of custom users with 
certain access levels you can control which aliases are presented to a user.
Also, I have implemented the ability to switch from the default domus.Link type 
view (lights, appliances, etc) to the group view on the fly in the main screen. 
And, if a group/type has no modules or user access level doesn't allow any of 
the modules, the group will not be shown.

Original comment by bwsamuels@gmail.com on 21 Feb 2011 at 1:51

• Changed state: Started
• Added labels: Milestone-v2.0

[GoogleCodeExporter]

This issue was closed by revision r834.

Original comment by bwsamuels@gmail.com on 23 Feb 2011 at 3:58

• Changed state: Fixed