bwssytems / domuslink Goto Github PK

Purpose of feature on this branch:
Have the ability to not show all items in the home/floorplan view in themes
as they may not be wanted to be displayed. i.e.: remote controls, security
sensors, etc.

Proposition for feature implementation:
Add a display selection for each floor plan creation. When displaying,
check flag to be displayed in home/floorplan view in themes.


When reviewing my code changes, please focus on:
location.class.php

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

Although when the page refreshes the text is back, I don't like how I am
able to erase the text on the buttons.

What steps will reproduce the problem?
1. Heyu page under settings
2.
3.

What is the expected output? What do you see instead?
Until domus.Link is ready to provide script creation tools, the heyu
configuration file should only return directives. It looks pretty nasty
when there is a long list of scripts. It looks even worse when you click
edit, as the edit seems to pull comment fields unlike the display. Also the
text boxes aren't really long enough to display script for editing anyway.
Also, some directives are not put in there by default, please add the
ability to add directives



What version of Heyu and domus.Link are you using? On what operating
system?

Heyu 2.8
dL 1.0.2
mac os x 10.6.2
firefox 3.6



Please provide any additional information below.

Purpose of feature on this branch:
Support X10 RCS TXB16 thermostat control.

Proposition for feature implementation:
Create module type and module display for RCS TXB16 that shows degree as
dim level. This module uses a house code to itself. Need to add checks for
use of house code in alias list if RCS TXB16 is present.

When reviewing my code changes, please focus on:


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

Purpose of feature on this branch:
New objectifying of schedule elements in V1.1 did not create detail objects
for triggers

Proposition for feature implementation:
Decompose triggers into labels, units, trigger command and trigger macro.
Units in triggers can be an alias name or a direct House/Unit code.

When reviewing my code changes, please focus on:
trigger.class.php

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

We need to make available all the heyu directives and their list of values
to our users. 

For adding directives:
Ideally it would be nice to have a drop down list of all directives, with a
mouseover of an excerpt from the man page describing what it is for, and
then when a directive is selected from the list the dropdown list next to
it will populate will all available options for that directive if possible.

If there are still directives which are required for proper operation of
dL, we need to make sure those can not be commented out or removed.

Looking to the future of dL; If dL is made modular then the appropriate
directives should be added with default values when a module is enabled,
also making them unable to be manually commented out or removed which would
happen automatically when the module is disabled/uninstalled.

Purpose of feature on this branch:
Modify the Trigger page to view and add triggers by macro. 

Proposition for feature implementation:
since heyu expects triggers to use only macros I have updated the display
to show the macro labels instead of the fabricated "on/off" labels from the
timer page that you created.

When reviewing my code changes, please focus on:
triggers.php, trigger tpl files

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

Purpose of feature on this branch:
Change type tab Irrigation to be Others. This will be more flexible when
adding new module types.

Proposition for feature implementation:
Change text labels from Irrigation to Others.
Create new image files for tab for Others.

When reviewing my code changes, please focus on:
layout.tpl

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

What steps will reproduce the problem?
1.Select about page link
2.Read text and see version is set to 1.0
3.

What is the expected output? What do you see instead?
About page has hard coded version number

Please use labels and text to provide additional information.
Version number should be grabbed from version.php

What steps will reproduce the problem?
1. install domuslink
2. using a x10config file which is not kept in /etc/heyu/
3.

What is the expected output? What do you see instead?
doesnt read config from where it is set in config.php still shows error-
Unable to find Heyu configuration file.

What steps will reproduce the problem?
1.Timers & Triggers page
2.
3.

What is the expected output? What do you see instead?

I feel that the status column should be renamed to say 'toggle' in the
English template as it is not showing the current status of that entry, but
more providing a button to toggle the entry on or off. 

Better yet, if it can be placed at the end under actions instead of having
its own column, that would be best.


What version of Heyu and domus.Link are you using? On what operating
system?

latest / linux


Please provide any additional information below.

no additional informaition

Purpose of feature on this branch:
New objectifying of schedule elements in V1.1 did not create detail objects
for macros

Proposition for feature implementation:
Decompose macros into label, delay and macro command.

When reviewing my code changes, please focus on:


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

For the shutters, we currently can only open/close them, while it should
be possible to partially open them. If we define them as Light module,
it works, but with the correct SW10 definition it should work as well
with the appropriate commands :
heyu help shutter

 [Shutter (Extended Type 0) direct commands  (H = Housecode, U = Units
list)]
  heyu  shopen  HU <level>     Open shutter to level (0-25) and cancel
limit
  heyu  shopenlim  HU <level>  Open shutter to level (0-25), enforce
limit
  heyu  shsetlim  HU <level>   Set limit (0-25) and open shutter to
limit
  heyu  shopenall  H           Open all shutters fully and cancel limit
  heyu  shcloseall  H          Close all shutters fully

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

What steps will reproduce the problem?
1. domus.Link module list
2.
3.

What is the expected output? What do you see instead?
the domus.Link module list looks like a list of modules based on a domulink
developer. Have this list generated by 'heyu modlist' to better reflect
heyu as a wrapper.


What version of Heyu and domus.Link are you using? On what operating
system?

latest/latest

Please provide any additional information below.

Purpose of feature on this branch:
Add Macro View/Add/Edit page - Since heyu schedules are based on macros, I
thought it would be best to be able to add very custom macros and also to
edit them. Unfortunately, I didn't create a macro builder that would keep
the heyu rules verified. So it is an advanced area that you enter the macro
line as you would in the schedule file directly. But at least it can be
done thru the web interface. This allows them to be selected in the trigger
page as well.

Proposition for feature implementation:
* heyusched.class.php - Ohhh. many changes here. I believe I have got this
to be section specific without regard to specific top to bottom section
location. I have changed the layout to use the heyu ignored "section"
directive to remove that obstacle. It does not matter where "macros",
"triggers" or "timers" areas are located as long as they are bounded by
"section [[end]triggers|[end]timers|[end]macros]" directives. In the future
this can be added to the x10conf file so that config, aliases and scenes
can be separated. I updated the x10.sched example file to show the difference.
* macro.func.php - I added this to consolidate all the macro checking
functions. As they are used by Timers, Timers by Macro, and Triggers to
validate the usage of a macro. 

When reviewing my code changes, please focus on:
macro.php macro tpl files, heyusched.class.php, nacro.func.php

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

Purpose of feature on this branch:


Proposition for feature implementation:


When reviewing my code changes, please focus on:


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

When editing an alias, it would be nice to see which scripts I have that
contain the alias.

When clicking 'edit' on an alias, could we have a warning displayed at the
bottom of the screen below the alias editing form that will display the
following:


Warning! Editing this alias will affect the following:

SCRIPT blah :: blah
SCRIPT foobar :: foobar

Just touch anything in the UI and it destroys every config and option.

Example this is my x10.conf after touching it via the UI

ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject
ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject
ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject
ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject
ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject
ObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectOb
jectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObje
ctObjectObjectObjectObjectObjectObjectObjectObjectObjectObjectObject


/b

Please review the way that objects are sorted on the layouts. 

dL 1.0.2, heyu 2.8

Using safari browser on mac os x snow leopard..it looks pretty unorganized
at times depending on the window size. 

See attached image.

Purpose of feature on this branch:
domus.Link requires that the heyu engine is started.

Proposition for feature implementation:
On check of heyu that it is running, domus will check that the engine is
started and if not, start the heyu engine. The engine contains the state
that domus uses to display the module states.

When reviewing my code changes, please focus on:


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

Add a diagnostic page. 

This page should check domus installation :
* check heyu base
* x10.sched file writable
* heyuexec is executable
* heyu is running 

Sort alias list by code when adding new alias

Purpose of feature on this branch:


Proposition for feature implementation:


When reviewing my code changes, please focus on:


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

An idea here:

Have the main screen protected by a pin pad layout which would enable
family members to login either on a touch screen tablet, a pc with mouse
clicks, or an iphone. From there protect the settings area with a regular
password for the home's 'HA administrator' so family members don't tamper
with it.

The main pin pad layout would also include a disarm button for quick access
when walking in or out of the house which would run 'heyu disarm' and also
unlock the gui, and also an Enter button to enter the GUI without the
disarm functionality.

When 'arming' from within the gui, it would 'logout' and put users at the
pin pad screen.

While the arm/disarm button and functionality could be added at a later
date, I feel that it would be easy to switch from password input to pin pad
input and make it into version 1.1

What steps will reproduce the problem?
1.click on 'Aliases'
2.enter a new label with a space character
3.fill other fields
4.click 'Add'
5.Reload homepage

What is the expected output?
 Alias created
What do you see instead?
 White page

 error in apage log : 
PHP Fatal error:  Uncaught exception 'Exception' with message 'Config Line 53: 
Invalid module model 'I2'' in 
/var/www/domus.Link/lib/func/cmd.func.php:42\nStack trace:\n#0 
/var/www/domus.Link/lib/func/cmd.func.php(199): execute_cmd('/usr/bin/heyu 
f...')\n#1 /var/www/domus.Link/lib/classes/location.class.php(145): 
on_state('I2')\n#2 /var/www/domus.Link/lib/classes/location.class.php(101): 
location->buildModuleTable(Object(Alias))\n#3 
/var/www/domus.Link/lib/classes/location.class.php(60): 
location->buildLocationTable('Cuisine', Array, 'typed')\n#4 
/var/www/domus.Link/index.php(104): location->buildLocations('Shutter', 
'typed')\n#5 {main}\n  thrown in /var/www/domus.Link/lib/func/cmd.func.php on 
line 42

Please use labels and text to provide additional information.

Purpose of feature on this branch:
Allow the use of dawn/dusk values in timers.

Proposition for feature implementation:
Modify timer add/edit and timer macro add/edit to use the heyu constructs
for dawn/dusk.

dawn/dusk support entails adding the values "dawn" and "dusk" to the tpl
pages. Also dawn/dusk can contain modifiers for minutes before or after the
commands. i.e. dawn+10 or dusk-10. Also the timer security feature can be
added to any timer time value by appending "s" to the time.

Dawn/Dusk also have options to limit by a constant time. These are DAWNLT,
DAWNGT, DUSKLT and DUSKGT. These are appended to the end of the timer line
as DAWNGT 05:00 as an example. The modifiers are used in conjunction with
the appropriate dawn/dusk timer value.

When reviewing my code changes, please focus on:
timer.php, timer_macro.php, timer tpl files and timer_macro tpl files.
schedfile class.

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

What steps will reproduce the problem?
1. Go to ./admin/utility.php
2. Don't select any command anddon't write any argumment
3. Click execute

What is the expected output? What do you see instead?
The expect output should be an error inside the output box but instead it
redirects to error.php

What version of the product are you using? On what operating system?
1.0.2

Please provide any additional information below.
Its not a big deal but should be fixed anyway

When heyu is stopped via the command line, and then one clicks stop on the
gui, there is an 'exec error' whereas one would expect the heyu start screen.

Purpose of feature on this branch:
So that user's floorplan's don't get overwritten with upgrades.

Proposition for feature implementation:
Have a default db/floorplan-dist which domus.Link should use only if a
db/floorplan file doesnt exist

When reviewing my code changes, please focus on:


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

With some devices I do not wish to have an on/off toggle provided. Such
devices that I would like to monitor without being able to turn on/off
would be a garage door n/o contact wired to a powerflash, dusk sensors on
ms14a's, ds10a door/window sensors.

Purpose of feature on this branch:
Create an Android application natively to control thru domus.

Proposition for feature implementation:
Create a REST API for web service based applications to control domus. This 
will allow any program to access heyu through an API.

When reviewing my code changes, please focus on:
testing and security

After the review, I'll merge this branch into:
TBD

Purpose of feature on this branch:

Add heyu home security functionality to dL in small steps.

Proposition for feature implementation:

For the first round can we assume people will manually add security scripts
to the config file and then give the ability to add a security tab to dL
with only the buttons: Arm Home, Arm Away, and Disarm   That will send the
related command to heyu.

We can add functionality to monitor security device status' later on.


When reviewing my code changes, please focus on:


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

Purpose of feature on this branch:
Allow the use of "null" in timers as per heyu.

Proposition for feature implementation:
Add null checkbox selections to timer tpl pages
Change sched file handling code to be aware of null when building timers

When reviewing my code changes, please focus on:
timer tpl pages
timer/macro tpl pages
sched file class

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

What steps will reproduce the problem?
1. Install domus.link
2. That's all


What version of Heyu and domus.Link are you using? On what operating
system?
Version of Heyu : Version:2.8.0
Version of domus.Link : v1.1.1
Version of OS : Ubuntu 10.04
Version of PHP : PHP 5.3.2-1ubuntu4.2 with Suhosin-Patch (cli) (built: May 13 
2010 20:01:00)
Version of Apache : Server version: Apache/2.2.14 (Ubuntu)
Server built:   Apr 13 2010 19:28:27

On every page I have this error :
Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/index.php on line 80

Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/include.php on line 33

Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/include.php on line 68

Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/lib/func/timer.func.php on line 43

Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/lib/classes/location.class.php on line 78

Deprecated: Assigning the return value of new by reference is deprecated in 
/var/www/domus.Link/lib/classes/location.class.php on line 116

When I'm logged in, on the home page I've got the error in log file attached to 
this issue.


Thanks

Purpose of feature on this branch:
Add Timers by Macro page - This allows you to add timers by any macros that
are created. Since the naming convention of some macros don't fit the way
they are created on the Timer Page. This allows you to select the custom
macros built on the Macro Page for use in timers.

Proposition for feature implementation:
timer.func.php - I added this file to consolidate the weekday function that
was used now by the 2 timer pages. 

When reviewing my code changes, please focus on:
timermacro.php, timer_macro tpl files, timer.func.php

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

There is no way to edit the delay

Purpose of feature on this branch:

A client UI for the Nokia Internet Tablets running the MicroB user agent:
Nokia 770, N800, N810, N900

They all have 800x480 resolution in wide-screen format.



Proposition for feature implementation:

Would like to see buttons big enough for a fat finger tip, this would
require the screens in the UI be broken down more than just home, lights,
appliances...etc....it would have to be broken down by room under the
parent section.

A beautiful example of a UI for the N-Series is the Insteon software
'InterfaceGO':

http://www.interfacego.com/
http://www.interfacego.com/products/nk8.html

Firstly thanks for opensourcing this, it's a great product!

What steps will reproduce the problem?
Use the webinterface on an iPod Touch 8GB

What is the expected output? What do you see instead?
The sliding animation is very sluggish and happens after any device button 
press, which is very annoying and makes the screen jump to the top. The "+" 
dim button doesn't seem to work if the light is already on.


What version of the product are you using? On what operating system?
Tried 1.0.1 and SVN checkout from here.


Thanks!

I don't want the world to be able to stop and start my instance of heyu

Purpose of feature on this branch:
Allow the utility function to execute heyu logtail

Proposition for feature implementation:
Remove the restriction for logtail execution.
Add logtail to the list of default commands.

When reviewing my code changes, please focus on:
utility.php

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

Purpose of feature on this branch:
Heyu configuration does not require the use of a schedule file. domus.Link
currently (v1.1.1 and before) requires a schedule file to be defined and
present.
Allow domus.Link to disregard not having a schedule file defined.

Proposition for feature implementation:
If there is no schedule file, error the timer/macro/trigger pages stating
thus. Also, dynamically add the capability to define a schedule file if
none defined in the heyu config.

When reviewing my code changes, please focus on:
heyu.php, heyuconf_view.tpl, marcos.php timers/timermacros/macros/triggers
.php, global_class.php

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

Purpose of feature on this branch:
Implement heyu handling of multiple configuration directories for handling
multiple controllers or the use of multiple config and schedule files.

Proposition for feature implementation:
Use the heyu definitions of alternate config directories of /0 thru /9 to
handle multiple config/schedule definitions. This will allow multiple
configs/scheds to be used or the multiple controller usage. Limitations
will be that only one of the directories will be active at a time to be
displayed and monitored in domus.Link. It will be necessary to switch
between the views with a config/schedule management function in domus.Link.

When reviewing my code changes, please focus on:
New schedule management implementation files for the management.


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

What steps will reproduce the problem?
1. install domuslink
2. using a x10config file which is not kept in /etc/heyu/
3.

What is the expected output? What do you see instead?
doesnt read config from where it is set in config.php still shows error-
Unable to find Heyu configuration file.

instead of specifying a time to refresh, is there a way to monitor heyu and
refresh domus.Link when an event occurs? This would be a very good feature.

Purpose of feature on this branch:
Heyu webhook will allow for better parsing of the config file which will allow:
1. The user to maintain a custom organized config file
2. Allow dL to parse ALIAS entries correctly in case of extra AUX type fields.
3. We may be able to organize units in the floorplan based on [sections] in
the config file.
4. Prevent commented config entries from being parsed.
5. Allow the user to edit the config file on a more sectional basis which
would allow for better interactive editing.

The infrastructure change brought on by the implementation of webhook will
allow for a more transparent integration with Heyu, a better end-user
experience, and open the doors for more feature support down the road.


Proposition for feature implementation:

Need to research. Please feel free to comment on this.

From my understanding the utility tool has a list box of commands that are
benign and will not cause any problems with dL. However I am able to not
select anything in that box and type anything I want in the arguments box
such as 'logtail 10000'

This box should be disabled until a command is selected from the command box.

Purpose of feature on this branch:
Implement AJAX using the jQuery API


Proposition for feature implementation:
This will allow for better layout modification, and object refresh without
page refresh.


When reviewing my code changes, please focus on:


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

What steps will reproduce the problem?
1. Timers page
2.
3.

What is the expected output? What do you see instead?

English template: On the drop down lists on the timers page: please make
them wider under dates and times where there are the number lists. I see
them being cut off. 


What version of Heyu and domus.Link are you using? On what operating
system?

heyu - latest
latest - latest
os - Mac OS X Snow Leopard
Browser - Firefox 3.6



Please provide any additional information below.

Purpose of feature on this branch:
Update default theme info request to show the status graphics as well as
the info information

Proposition for feature implementation:
Update the default theme to combine the status and info tpl views into one
info view.

When reviewing my code changes, please focus on:
index.php status.tpl info.tpl

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