Quantcast

Re: Object Selectors on Web Interface

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users



------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users




------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users





------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users






------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users







------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users








------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users









------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users










------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users











------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users












------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
To get this visible in the web interface, json_server needs to be updated so that it exposes the scheduling data. You can see what information json_server provides on objects by using a tool like curl. For example for an object called test_light:


I’m going to be travelling for a bit, so it might be a bit before responding to emails.

What about using time_cron as the comparision in schedule.pm? It’s pretty flexible, and exposing just the time_cron string as ‘start’ and ‘stop’ data elements in the json_server might be simple and flexible for the future (ie. have something M,Tu,Th. Or January, Feb, June).

On Jul 29, 2016, at 3:52 PM, Wayne Gatlin <[hidden email]> wrote:

I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users













------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
I could move the scheduling data to the SCHEDULE object state, that way nothing would have to be modified. The ON/OFF could be moved to the start of the string. Would that work for you?

$SCHEDULE->set('ON-calendar-start,7,29,13,31-stop,7,29,13,32');


I didn't use time_cron because I would have to loop through the schedules on every pass to check them with time_cron which would not be a efficient as just matching the hash keys like I am doing now.

We can change it to the cron format and switch to time_cron if you want.

you would set like this:
$SCHEDULE->set('ON-start,31,13,29,7,*-stop,32,13,29,7,*');


I worked a good bit this weekend on getting the thermostat code in the schedule module, its requiring much more rewriting than I thought it would. I have most of it done, just need to start testing/debugging now.


_Wayne
 




On Sat, Jul 30, 2016 at 8:29 AM, H Plato <[hidden email]> wrote:
To get this visible in the web interface, json_server needs to be updated so that it exposes the scheduling data. You can see what information json_server provides on objects by using a tool like curl. For example for an object called test_light:


I’m going to be travelling for a bit, so it might be a bit before responding to emails.

What about using time_cron as the comparision in schedule.pm? It’s pretty flexible, and exposing just the time_cron string as ‘start’ and ‘stop’ data elements in the json_server might be simple and flexible for the future (ie. have something M,Tu,Th. Or January, Feb, June).

On Jul 29, 2016, at 3:52 PM, Wayne Gatlin <[hidden email]> wrote:

I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users














------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
I think a standard ON/OFF for the state might be best. Simple, and makes displaying the status straightforward.

I was more thinking of just augmenting the json data that is provided for this object type. Maybe an array with data in the time_cron format?

If you look at the subroutine json_object_detail , you can see how additional data is added to the json query. Maybe something like (I think I got the array wrong, but you get the idea)

{
   "data" : {
      "test_schedule" : {
         "category" : "items",
         "filename" : "items",
         "fp_location" : [],
         "html" : “...",
         "idle_time" : "33047357",
         "parents" : [
            "group1"
         ],
         "sort_order" : [],
         "state" : "off",
         "state_log" : [
            "07/13/15 07:29:44 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:50:05 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:47:09 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:47:04 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:56 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:46:53 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:45 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:43:01 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:40:13 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:40:09 PM off set_by=web [127.0.0.1]"
         ],
         "states" : [
            "on",
            "off",
         ],
         “schedules" : [
            [ “start”, “* * * 4 10 * *”],
    [ “stop”, “* * * 5 12 * *”]
  ],
         "type" : “Schedule” 
      }
   },
   "meta" : {
      "args" : {
         "items" : [
            "test_light"
         ]
      },
      "client_ip" : "127.0.0.1",
      "path" : [
         "objects"
      ],
      "time" : 1469884741127.45
   }
}


On Aug 1, 2016, at 11:30 AM, Wayne Gatlin <[hidden email]> wrote:

I could move the scheduling data to the SCHEDULE object state, that way nothing would have to be modified. The ON/OFF could be moved to the start of the string. Would that work for you?

$SCHEDULE->set('ON-calendar-start,7,29,13,31-stop,7,29,13,32');


I didn't use time_cron because I would have to loop through the schedules on every pass to check them with time_cron which would not be a efficient as just matching the hash keys like I am doing now.

We can change it to the cron format and switch to time_cron if you want.

you would set like this:
$SCHEDULE->set('ON-start,31,13,29,7,*-stop,32,13,29,7,*');


I worked a good bit this weekend on getting the thermostat code in the schedule module, its requiring much more rewriting than I thought it would. I have most of it done, just need to start testing/debugging now.


_Wayne
 




On Sat, Jul 30, 2016 at 8:29 AM, H Plato <[hidden email]> wrote:
To get this visible in the web interface, json_server needs to be updated so that it exposes the scheduling data. You can see what information json_server provides on objects by using a tool like curl. For example for an object called test_light:


I’m going to be travelling for a bit, so it might be a bit before responding to emails.

What about using time_cron as the comparision in schedule.pm? It’s pretty flexible, and exposing just the time_cron string as ‘start’ and ‘stop’ data elements in the json_server might be simple and flexible for the future (ie. have something M,Tu,Th. Or January, Feb, June).

On Jul 29, 2016, at 3:52 PM, Wayne Gatlin <[hidden email]> wrote:

I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users















------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

Wayne Gatlin
OK, I'm going to loop back around to the json and time_cron stuff. I just finished the thermostat code and uploaded it to git, its all in the SCHEDULE.pm file. I had to basically rewrite everything because this is so different from what I had before.

I changed start and stop to just 1 and 2, because I want to move the states to an array in the SCHEDULE_Generic object and they will be selected by number. Start and stop didn't fit in many cases anyway.

Another reason for using the array is because having 2 states with the thermostat schedule in a daily format would require 4 schedule objects to be created because you would need 1 state per day x 7. 2 states works fine for the weekday/weekend schedule.


Right now the occupany overrides only works for the SCHEDULE_Temp objects, but I am going to adapt it to work with the SCHEDULE_Generic and really it doesn't have to be a occupancy object, it can be any object.


This is my user code, I am going to put the documentation in the SCHEDULE.pm and clean up the logging once everything is squared away.

#The purpose of these objects are to give the user a way to change the scheduled dates/days/times in the web interface.
# the instance name ties the schedules together so the code knows that all of the objects are meant to work as 1.
# Generally an instance would tie to a thermostat. If you have multiple thermostats and want to schedule them differently
# then different schedule objects would be created with a different instance.
#
# For objects that are used for setback temperatures only such as $NightWinter, no schedule needs to be defined as we
# never want to switch to this setting on a timed basis.
# The user must configure the times for each schedule in the web interface before the schedule will operate. 
#
# SCHEDULE(<instance>)

$Night = new SCHEDULE('THERMO1');
$Normal = new SCHEDULE('THERMO1');
$Conserve = new SCHEDULE('THERMO1');
$NightWinter = new SCHEDULE('THERMO1');

# This is for testing only and should be set in the web interface, not the user code. This format will be changed to the cron format.
$Night->set_schedule('wdwe','1,weekday,22,0-2,weekend,23,0');
$Normal->set_schedule('wdwe','1,weekday,16,30-2,weekend,8,0');
$Conserve->set_schedule('wdwe','1,weekday,6,30');

#The purpose of these objects are to give the user a way to change the temperature settings for heat and cool for each schedule in the web interface.
#Each object has an UP/DOWN button in order to change the temperature setting in the web interface and these must be set before the schedule will operate.
#
#When any of the dates/days/times that are set in the defined schedule object are met,
#the <thermostat control object>-><thermostat control sub> is executed.  ie: $thermostat->cool_setpoint(70)
#This method will work with any thermostat configured in Misterhouse.
#
# SCHEDULE_Temp(<schedule object>,<cool or heat>,<thermostat control object>,<thermostat control sub>);

$NormalCool = new SCHEDULE_Temp($Normal,'cool',$thermostat,'cool_setpoint');
$NormalHeat = new SCHEDULE_Temp($Normal,'heat',$thermostat,'heat_setpoint');

$NightCool = new SCHEDULE_Temp($Night,'cool',$thermostat,'cool_setpoint');
$NightHeat = new SCHEDULE_Temp($Night,'heat',$thermostat,'heat_setpoint');

$NightWCool = new SCHEDULE_Temp($NightWinter,'cool',$thermostat,'cool_setpoint');
$NightWHeat = new SCHEDULE_Temp($NightWinter,'heat',$thermostat,'heat_setpoint');

$ConserveCool = new SCHEDULE_Temp($Conserve,'cool',$thermostat,'cool_setpoint');
$ConserveHeat = new SCHEDULE_Temp($Conserve,'heat',$thermostat,'heat_setpoint');


# This sets the occupancy tracking for the SCHEDULE_Temp object, the occupancy settings linked to the schedule object are only used when
# that schedule object is the “active” schedule.
#
# To be the active schedule, one of the dates/days/times have to be met that are set in the schedule and before a date/day/time has been met
# in another schedule. If $Normal is set to 6:00 am and $Night is set to 4:00 pm,  then at 6:00 am $Normal is set to the active schedule it will remain
# the active schedule until 4:00 pm when $Night becomes the active. During the time when $Normal is active and the occupancy object has a state of
# ‘home’ then the temperature settings linked to the $Normal object is used, if the state changes to ‘work’ then the temperature settings
# linked to the $Conserve object is used. By default $mode_occupied is used as the occupancy object, but it can be changed in the set_occpuancy sub.
#
# A set timer and setback timer is used to keep the settings from changing immediately, this is so if you walk outside for 1 min
# and back in the settings don’t switch instantly back and forth, therefore reducing a thrashing effect. The timers are set to 60 seconds
# by default, but change be modified in the set_occpuancy sub.
#
# <schedule object>->set_occpuancy(<normal occupancy state>,<set back occupancy state>,<set back occupancy object>, <normal delay>, <setback delay>, <occupancy tracked object>);

 #If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings
$Normal->set_occpuancy('home','work',$Conserve);
$Night->set_occpuancy('home','work',$Normal);
$Conserve->set_occpuancy('work','home',$Normal);


# Vacation mode. If you want to override your schedules using the vacation occupancy state.
# for this to work properly, you will need the vacation settings for every schedule object that you set a
# date/day/time for.
<schedule object>->set_vacation(<vacation schedule object>,  <vacation occupancy state >)
$Normal->set_vacation($Conserve,'vacation');
$Night->set_vacation($Conserve,'vacation');
$Conserve->set_vacation($Conserve,'vacation');



# This sets the winter mode, when the defined schedule object ($Night below) is the active object and the forecasted lows are at or the defined temperature
# then the temperature settings linked to $NightWinter are used. The forecasted temperatures are pulled from $Weather{Forecast Tonight}.
<schedule object>->set_winter(<winter schedule object>,  <winter temperature>)
$Night->set_winter($NightWinter,'50');


_Wayne




On Mon, Aug 1, 2016 at 9:33 PM, H Plato <[hidden email]> wrote:
I think a standard ON/OFF for the state might be best. Simple, and makes displaying the status straightforward.

I was more thinking of just augmenting the json data that is provided for this object type. Maybe an array with data in the time_cron format?

If you look at the subroutine json_object_detail , you can see how additional data is added to the json query. Maybe something like (I think I got the array wrong, but you get the idea)

{
   "data" : {
      "test_schedule" : {
         "category" : "items",
         "filename" : "items",
         "fp_location" : [],
         "html" : “...",
         "idle_time" : "33047357",
         "parents" : [
            "group1"
         ],
         "sort_order" : [],
         "state" : "off",
         "state_log" : [
            "07/13/15 07:29:44 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:50:05 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:47:09 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:47:04 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:56 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:46:53 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:45 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:43:01 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:40:13 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:40:09 PM off set_by=web [127.0.0.1]"
         ],
         "states" : [
            "on",
            "off",
         ],
         “schedules" : [
            [ “start”, “* * * 4 10 * *”],
    [ “stop”, “* * * 5 12 * *”]
  ],
         "type" : “Schedule” 
      }
   },
   "meta" : {
      "args" : {
         "items" : [
            "test_light"
         ]
      },
      "client_ip" : "127.0.0.1",
      "path" : [
         "objects"
      ],
      "time" : 1469884741127.45
   }
}


On Aug 1, 2016, at 11:30 AM, Wayne Gatlin <[hidden email]> wrote:

I could move the scheduling data to the SCHEDULE object state, that way nothing would have to be modified. The ON/OFF could be moved to the start of the string. Would that work for you?

$SCHEDULE->set('ON-calendar-start,7,29,13,31-stop,7,29,13,32');


I didn't use time_cron because I would have to loop through the schedules on every pass to check them with time_cron which would not be a efficient as just matching the hash keys like I am doing now.

We can change it to the cron format and switch to time_cron if you want.

you would set like this:
$SCHEDULE->set('ON-start,31,13,29,7,*-stop,32,13,29,7,*');


I worked a good bit this weekend on getting the thermostat code in the schedule module, its requiring much more rewriting than I thought it would. I have most of it done, just need to start testing/debugging now.


_Wayne
 




On Sat, Jul 30, 2016 at 8:29 AM, H Plato <[hidden email]> wrote:
To get this visible in the web interface, json_server needs to be updated so that it exposes the scheduling data. You can see what information json_server provides on objects by using a tool like curl. For example for an object called test_light:


I’m going to be travelling for a bit, so it might be a bit before responding to emails.

What about using time_cron as the comparision in schedule.pm? It’s pretty flexible, and exposing just the time_cron string as ‘start’ and ‘stop’ data elements in the json_server might be simple and flexible for the future (ie. have something M,Tu,Th. Or January, Feb, June).

On Jul 29, 2016, at 3:52 PM, Wayne Gatlin <[hidden email]> wrote:

I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users
















------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Object Selectors on Web Interface

H Plato
I’m just looking at this and a few things;

  We need a ‘get_schedule’ or some such function. We’ll use this to get the data to json_server to present to the web interface. Is there any significant to the numbers? Could ‘labels’ be used?

 I don’t quite know how to parse this:

$Night->set_schedule('wdwe','1,weekday,22,0-2,weekend,23,0');

So, If I wanted to set some schedules, I could see;

$Night->set_schedule(’weekday start',’weekday’,’22,0’)
$Night->set_schedule(‘weekday stop',’weekday’,’24,0’)
$Night->set_schedule(’weekend start',’weekend’,’23,0’)
$Night->set_schedule(‘weekend stop',’weekend’,’24,0’)

so if there was a $Night->get_schedule, we’d see an array something like

[’weekday start',’weekday’,’22,0’]
[‘weekday stop',’weekday’,’24,0’]
[’weekend start',’weekend’,’23,0’]
[‘weekend stop',’weekend’,’24,0’]

Then we’d add an entry to json_server so that an object of this type would present this information as a ‘schedules’ array.

The actual ‘weekend’ and ‘weekday’ times might be more specific, I’ll have to see what the options are for the web interface.

Using your code, I printed the data structure for Night, but don’t quite know how to reformat it:

print Dumper $$self{'schedule'};

          'weekday' => {
                         '22' => {
                                   '0' => {
                                            'action' => '1'
                                          }
                                 }
                       },
          'type' => 'wdwe',
          'weekend' => {
                         '23' => {
                                   '0' => {
                                            'action' => '2'
                                          }
                                 }
                       }
        };

On Aug 3, 2016, at 11:18 AM, Wayne Gatlin <[hidden email]> wrote:

OK, I'm going to loop back around to the json and time_cron stuff. I just finished the thermostat code and uploaded it to git, its all in the SCHEDULE.pm file. I had to basically rewrite everything because this is so different from what I had before.

I changed start and stop to just 1 and 2, because I want to move the states to an array in the SCHEDULE_Generic object and they will be selected by number. Start and stop didn't fit in many cases anyway.

Another reason for using the array is because having 2 states with the thermostat schedule in a daily format would require 4 schedule objects to be created because you would need 1 state per day x 7. 2 states works fine for the weekday/weekend schedule.


Right now the occupany overrides only works for the SCHEDULE_Temp objects, but I am going to adapt it to work with the SCHEDULE_Generic and really it doesn't have to be a occupancy object, it can be any object.


This is my user code, I am going to put the documentation in the SCHEDULE.pm and clean up the logging once everything is squared away.

#The purpose of these objects are to give the user a way to change the scheduled dates/days/times in the web interface.
# the instance name ties the schedules together so the code knows that all of the objects are meant to work as 1.
# Generally an instance would tie to a thermostat. If you have multiple thermostats and want to schedule them differently
# then different schedule objects would be created with a different instance.
#
# For objects that are used for setback temperatures only such as $NightWinter, no schedule needs to be defined as we
# never want to switch to this setting on a timed basis.
# The user must configure the times for each schedule in the web interface before the schedule will operate. 
#
# SCHEDULE(<instance>)

$Night = new SCHEDULE('THERMO1');
$Normal = new SCHEDULE('THERMO1');
$Conserve = new SCHEDULE('THERMO1');
$NightWinter = new SCHEDULE('THERMO1');

# This is for testing only and should be set in the web interface, not the user code. This format will be changed to the cron format.
$Night->set_schedule('wdwe','1,weekday,22,0-2,weekend,23,0');
$Normal->set_schedule('wdwe','1,weekday,16,30-2,weekend,8,0');
$Conserve->set_schedule('wdwe','1,weekday,6,30');

#The purpose of these objects are to give the user a way to change the temperature settings for heat and cool for each schedule in the web interface.
#Each object has an UP/DOWN button in order to change the temperature setting in the web interface and these must be set before the schedule will operate.
#
#When any of the dates/days/times that are set in the defined schedule object are met,
#the <thermostat control object>-><thermostat control sub> is executed.  ie: $thermostat->cool_setpoint(70)
#This method will work with any thermostat configured in Misterhouse.
#
# SCHEDULE_Temp(<schedule object>,<cool or heat>,<thermostat control object>,<thermostat control sub>);

$NormalCool = new SCHEDULE_Temp($Normal,'cool',$thermostat,'cool_setpoint');
$NormalHeat = new SCHEDULE_Temp($Normal,'heat',$thermostat,'heat_setpoint');

$NightCool = new SCHEDULE_Temp($Night,'cool',$thermostat,'cool_setpoint');
$NightHeat = new SCHEDULE_Temp($Night,'heat',$thermostat,'heat_setpoint');

$NightWCool = new SCHEDULE_Temp($NightWinter,'cool',$thermostat,'cool_setpoint');
$NightWHeat = new SCHEDULE_Temp($NightWinter,'heat',$thermostat,'heat_setpoint');

$ConserveCool = new SCHEDULE_Temp($Conserve,'cool',$thermostat,'cool_setpoint');
$ConserveHeat = new SCHEDULE_Temp($Conserve,'heat',$thermostat,'heat_setpoint');


# This sets the occupancy tracking for the SCHEDULE_Temp object, the occupancy settings linked to the schedule object are only used when
# that schedule object is the “active” schedule.
#
# To be the active schedule, one of the dates/days/times have to be met that are set in the schedule and before a date/day/time has been met
# in another schedule. If $Normal is set to 6:00 am and $Night is set to 4:00 pm,  then at 6:00 am $Normal is set to the active schedule it will remain
# the active schedule until 4:00 pm when $Night becomes the active. During the time when $Normal is active and the occupancy object has a state of
# ‘home’ then the temperature settings linked to the $Normal object is used, if the state changes to ‘work’ then the temperature settings
# linked to the $Conserve object is used. By default $mode_occupied is used as the occupancy object, but it can be changed in the set_occpuancy sub.
#
# A set timer and setback timer is used to keep the settings from changing immediately, this is so if you walk outside for 1 min
# and back in the settings don’t switch instantly back and forth, therefore reducing a thrashing effect. The timers are set to 60 seconds
# by default, but change be modified in the set_occpuancy sub.
#
# <schedule object>->set_occpuancy(<normal occupancy state>,<set back occupancy state>,<set back occupancy object>, <normal delay>, <setback delay>, <occupancy tracked object>);

 #If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings
$Normal->set_occpuancy('home','work',$Conserve);
$Night->set_occpuancy('home','work',$Normal);
$Conserve->set_occpuancy('work','home',$Normal);


# Vacation mode. If you want to override your schedules using the vacation occupancy state.
# for this to work properly, you will need the vacation settings for every schedule object that you set a
# date/day/time for.
<schedule object>->set_vacation(<vacation schedule object>,  <vacation occupancy state >)
$Normal->set_vacation($Conserve,'vacation');
$Night->set_vacation($Conserve,'vacation');
$Conserve->set_vacation($Conserve,'vacation');



# This sets the winter mode, when the defined schedule object ($Night below) is the active object and the forecasted lows are at or the defined temperature
# then the temperature settings linked to $NightWinter are used. The forecasted temperatures are pulled from $Weather{Forecast Tonight}.
<schedule object>->set_winter(<winter schedule object>,  <winter temperature>)
$Night->set_winter($NightWinter,'50');


_Wayne




On Mon, Aug 1, 2016 at 9:33 PM, H Plato <[hidden email]> wrote:
I think a standard ON/OFF for the state might be best. Simple, and makes displaying the status straightforward.

I was more thinking of just augmenting the json data that is provided for this object type. Maybe an array with data in the time_cron format?

If you look at the subroutine json_object_detail , you can see how additional data is added to the json query. Maybe something like (I think I got the array wrong, but you get the idea)

{
   "data" : {
      "test_schedule" : {
         "category" : "items",
         "filename" : "items",
         "fp_location" : [],
         "html" : “...",
         "idle_time" : "33047357",
         "parents" : [
            "group1"
         ],
         "sort_order" : [],
         "state" : "off",
         "state_log" : [
            "07/13/15 07:29:44 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:50:05 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:47:09 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:47:04 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:56 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:46:53 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:46:45 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:43:01 PM off set_by=web [127.0.0.1]",
            "04/12/15 04:40:13 PM on set_by=web [127.0.0.1]",
            "04/12/15 04:40:09 PM off set_by=web [127.0.0.1]"
         ],
         "states" : [
            "on",
            "off",
         ],
         “schedules" : [
            [ “start”, “* * * 4 10 * *”],
    [ “stop”, “* * * 5 12 * *”]
  ],
         "type" : “Schedule” 
      }
   },
   "meta" : {
      "args" : {
         "items" : [
            "test_light"
         ]
      },
      "client_ip" : "127.0.0.1",
      "path" : [
         "objects"
      ],
      "time" : 1469884741127.45
   }
}


On Aug 1, 2016, at 11:30 AM, Wayne Gatlin <[hidden email]> wrote:

I could move the scheduling data to the SCHEDULE object state, that way nothing would have to be modified. The ON/OFF could be moved to the start of the string. Would that work for you?

$SCHEDULE->set('ON-calendar-start,7,29,13,31-stop,7,29,13,32');


I didn't use time_cron because I would have to loop through the schedules on every pass to check them with time_cron which would not be a efficient as just matching the hash keys like I am doing now.

We can change it to the cron format and switch to time_cron if you want.

you would set like this:
$SCHEDULE->set('ON-start,31,13,29,7,*-stop,32,13,29,7,*');


I worked a good bit this weekend on getting the thermostat code in the schedule module, its requiring much more rewriting than I thought it would. I have most of it done, just need to start testing/debugging now.


_Wayne
 




On Sat, Jul 30, 2016 at 8:29 AM, H Plato <[hidden email]> wrote:
To get this visible in the web interface, json_server needs to be updated so that it exposes the scheduling data. You can see what information json_server provides on objects by using a tool like curl. For example for an object called test_light:


I’m going to be travelling for a bit, so it might be a bit before responding to emails.

What about using time_cron as the comparision in schedule.pm? It’s pretty flexible, and exposing just the time_cron string as ‘start’ and ‘stop’ data elements in the json_server might be simple and flexible for the future (ie. have something M,Tu,Th. Or January, Feb, June).

On Jul 29, 2016, at 3:52 PM, Wayne Gatlin <[hidden email]> wrote:

I have the frame work done, I still have to add the thermostat scheduling logic I've already written. This is totally different than what I did for my thermostat code, but hopefully it wont be to bad to get it in there.

I'm also going to create a generic over rides object like I do with the occupancy and weather for the thermostat.

The "set_schedule" values would come from the web interface.
set_schedule(TYPE,'start,month,day,hour,min-stop,month,day,hour,min'); # for the calendar selector.

After looking at it I think we should change start and stop to state1 and state2 because they really just link to the 3rd and 4th arguments in the SCHEDULE_Generic object. I was also thinking that we could have more than just 2, but it really depends on the web part if it can be done. On my side we could put as many as you want with no issue.


For the schedule, you can put a start and a stop or you can put just a stop or just a start. I use a - to delimit the schedules, so the next state must start with a -.

For $SCHEDULE_TEST2 start schedules the time for the armed state for $mode_security and stop schedules the unarmed state for $mode_security.

I'm having issues inheriting the states from the child objects ( $mode_security ) in this case, I've tried several different ways but nothing seems to work so having no states set in the SCHEDULE_Generic will not work right now. What I want to happen is for the states of $mode_security to be listed for the states of $SCHEDULE_TEST2 then the user can select it in the web interface and that state will represent the "start" state or "state1" in the schedule, it doesn't give an option for 2 states but its good for situations where you would want to change the state from time to time in the web interface.

#noloop=start
use SCHEDULE;
$SCHEDULE = new SCHEDULE();
#$SCHEDULE->set_schedule('calendar','start,7,29,13,31-stop,7,29,13,32');
#$SCHEDULE->set_schedule('daily','start,fri,13,38-stop,fri,13,39');
#$SCHEDULE->set_schedule('wdwe','start,weekday,13,41-stop,weekday,13,42');
#$SCHEDULE->set_schedule('wdwe','start,weekday,14,38');
$SCHEDULE->set_schedule('time','start,15,20-stop,15,21');
$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied,'home','work');
#$SCHEDULE_TEST1 = new SCHEDULE_Generic($SCHEDULE,$mode_occupied);
$SCHEDULE_TEST2 = new SCHEDULE_Generic($SCHEDULE,$mode_security,'armed','unarmed');
#noloop=stop



I uploaded what I have so far to github, see the link below:
https://github.com/waynieack/misterhouse/blob/master/lib/SCHEDULE.pm



_Wayne

On Wed, Jul 27, 2016 at 10:31 PM, H Plato <[hidden email]> wrote:
Possibly, when the object’s ready I’ll see how those selectors can function.

The best I can figure is that this will require some user code. I don’t think a library file can expose a subroutine to the web interface.

If the object has a simple method, having a common code module with something like:

sub web_set_schedule {
my ($item,$value) = @_;
my $object = &get_object_by_name($item);
$object->set_schedule($value);
}

Will allow this type of URL to work:

http://mhip/sub?web_set_schedule($name,$value)

publishing methods via an object makes things much simpler for the usercode/web connection.

On Jul 27, 2016, at 3:33 PM, Wayne Gatlin <[hidden email]> wrote:

Those selectors look good. Can you modify it to make a Mon-Sun/Time selector?

If they don't select a end time or start time, you can just do nothing with it because I am going to link start to the state in the 3rd argument and stop to the state in the 4th.


How do you want to populate the hash? I can make a set_schedule sub and you can run it for each entry, I'm not sure how or what you can do on the web side so you will have to tell me how you want to do this.


With this hash structure I can loop through months, days, hours, or min if I need to (maybe check for missed action on startup in the future). Right now I am just going to check every min to see if the current month/day/hour/min is defined in the hash and run the action. The type will tell me what I need to check for so I don't have to make a routine to figure it out.

$schedule{'type'} = 'calendar' (for month/day/hour/min)
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$numeric_Month}{$numeric_Day}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Month}{$Mday}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'daily' (for day/hour/min)
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{lc($alpha_Day)}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{lc($Day)}{$Hour}{$Minute}{'action'})) { do stuff with $action }



we could also do a weekday/weekend if you want.
$schedule{'type'} = 'wdwe' (for weekdays_Weekends/hour/min)
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekday'}{$Hour}{$Min}{'action'} = 'stop'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{'weekend'}{$Hour}{$Min}{'action'} = 'stop'

my $Week;
if (Weekday) { $Week = 'weekday' }
elsif (Weekend) { $Week = 'weekend' }
if (defined(my $action = $schedule{'schedule'}{$Week}{$Day}{$Hour}{$Minute}{'action'})) { do stuff with $action }



$schedule{'type'} = 'time' (for just a start and end time)
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'start'
$schedule{'schedule'}{$Hour}{$Min}{'action'} = 'stop'

if (defined(my $action = $schedule{'schedule'}{$Hour}{$Minute}{'action'})) { do stuff with $action }


_Wayne

On Tue, Jul 26, 2016 at 10:28 PM, H Plato <[hidden email]> wrote:
That’s what I was thinking. End could always be optional, ie something like ‘--‘ could be ‘no end’.

Anyways, craft something up and I’ll look at putting a UI together. There are some nice open source bootstrap javascript time pickers out there, so this will look nice and should fit the responsive design:


On Jul 26, 2016, at 8:32 PM, Wayne Gatlin <[hidden email]> wrote:

OK, so thinking about how to code this:

ON OFF  >> this would be the parent object state
Start: XXX XXX XXX  >> these would be in a hash that I'll write a sub to populate in the parent object
End: XXX XXX XXX
UPDATE TIME   >> this would do the set of on or off for the parent object state


Is this what you mean?
When the start time is matched, the $child_object is set to locked?
When the end time is matched, the $child_object is set to unlocked?

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)


Your UI will work. A start and end would be better for a lot of stuff. For things like thermostat schedules that just switch between several states I can just not set the end time and let the next schedule start change the temps.


_Wayne




On Tue, Jul 26, 2016 at 8:32 PM, H Plato <[hidden email]> wrote:
I was thinking about a custom modal substate page. With instead of buttons to press for states,the modal would have on/off to enable/disable the schedule along with the ability to see and set the time (an UPDATE TIME) button.


ON OFF
Start: XXX XXX XXX
End: XXX XXX XXX
UPDATE TIME

The Start and End would be dropdowns or a calendar picker, or something similar.

What about adapting the SCHEDULE_GENERIC so that you can define the triggers, ie

$object = new SCHEDULE_GENERIC($scheduler, $child_object, ‘locked’, ‘unlocked’)

This could be used to control a lock on a schedule.

Nothing in IA7 reacts to  set_web_style('url’). In fact this is the first time I’ve seen it. grepping the MH code, it seems like it’s in generic_item, and that will set a hash value. http_server nor mh look at that attribute, so I’m guessing it was an idea that was available for custom IA5 scripts.


On Jul 26, 2016, at 5:54 PM, Wayne Gatlin <[hidden email]> wrote:

Sorry it takes me so long to reply, I've been slammed at work.

My thought for the UI part was not to build it specifically for the scheduler code, but to make it generic so anyone can easily use it. Maybe add additional set_web_style types like weekdays_time, time, calendar_time to generic_item. No custom states would be here, only a day/time selector, just time, or month/day/time depending on the selector type.



$MyTimes1 = new SCHEDULE();   # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM # The user selected these times in the web UI and stored in the object hash as days and times. When its set the object state can be changes to something different than the current value to tell the other code that the schedule has changed.
$MyTimes1->set_web_style(weekdays_time);  # Tells the web IU to use the Mon-Fri selector
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM
$MyTimes2->set_web_style(weekdays_time);




The objects below would be displayed in the web like a normal object is. I would inherit the states from  $ControlledObject to $MyTimes1_$ControlledObject_State1, so the user can set the state that he wants the $ControlledObject to be set to (in the web as you do for any other object) when the times (or days/times or months/days/times) selected for $MyTimes1 are met.

$MyTimes1_ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);



Lets just say $ControlledObject has states ON and OFF (although it could be anything).

The user wants $ControlledObject to be ON on Fri at 1 PM and OFF on Sat 1 PM.

The user would create the 4 objects above because we want to change between 2 states

The user would set $MyTimes1 to Fri 1 PM in the web UI. (The user could select multiple days/times if needed)
The user would set $MyTimes2 to Sat 1 PM in the web UI.


The user would set $MyTimes1_ControlledObject_State1 to the ON state in the web UI.
The user would set $MyTimes2_ControlledObject_State2 to the OFF state in the web UI.


It works like tie_time, but moves the time and state selection to the web UI instead of being hard coded in the user code and gives much more flexible scheduling. Its not very useful to have the $MyTimes2_ControlledObject_State1 object states selectable from the web UI when the states are ON and OFF, but in the case of a thermostat where the states are a certain temperature it becomes useful.



I think what you were describing was having the states on the calendar or day/time selector unless I am misunderstanding you? Also a dedicated page where all the scheduling would be that would show the schedule objects and have the schedule selectors built into the page?

A dedicated page may be able to have a better work flow, I could see that my proposed method above could get pretty complicated in situations. 


I'll let you know when I am done with my code and its uploaded. I haven't had much time to work on it lately. Sorry if we are talking about the same thing, and I am not getting it. 


Also (unless you fixed them in the newest version) the radio and URL methods don't work in ia7. I don't use them, but I was playing with the test code today when looking into the scheduling stuff.

set_web_style(style)

    Contols the style of we form used when displaying states of this item on a web page. Can be 'dropdown', 'radio', or 'url'. See mh/code/examples/test_web_styles.pl


_Wayne

On Mon, Jul 25, 2016 at 11:13 PM, H Plato <[hidden email]> wrote:
so in essence, the SCHEDULE object is just a time based trigger, with start_time and stop_time like methods, and the object state would be on or off? Any child object associated with the SCHEDULE object would be set to on when active and off when inactive?

The substate modal would know that a SCHEDULE object is special and display a start: DD HH:MM and end: DD HH:MM interface. What about month? Does schedule work with recurrence, like ‘every’ day?

While I think unique states coded into the javascript per item can be unwieldy, it seems like the SCHEDULE idea could be as common as voice_cmds. 

If you upload the code to github I’ll pull it down and take a run at creating this in the UI.

On Jul 25, 2016, at 8:38 PM, Wayne Gatlin <[hidden email]> wrote:

 I guess it could be used to schedule anything, now that I look at it. The temp objects are separate and I could rename the parent THERMOSCHEDULE to just SCHEDULER or something like that and make a SCHEDULER_GENERIC. I'll make it where you can tie the SCHEDULE_GENERIC to an object and it could inherit the states where they are listed in the web interface or you could set them statically (like I set the default temps) when you create the object. 

It would work like this:

These would be set in the web interface
$MyTimes1 = new SCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$MyTimes2 = new SCHEDULE();     # Mon-Fri=06:20 AM, Sat-Sun=5:00 PM


The states of $ControlledObject would be listed in the web interface for the objects
the user would set the state for $MyTimes1_$ControlledObject_State1 in the web interface
then the days/times set in $MyTimes1 would trigger the state set for $MyTimes1_$ControlledObject_State1.

$MyTimes1_$ControlledObject_State1 = new SCHEDULE_GENERIC($MyTimes1,$ControlledObject);
$MyTimes1_$ControlledObject_State2 = new SCHEDULE_GENERIC($MyTimes2,$ControlledObject);


This would make MH more user friendly as you only need generic objects created and all the scheduling and settings could then be done in the web interface.


About the display of the Mon-Sun selector in the web interface. I'm not a web designer, but I was thinking that you could click on the main object, it would pop out like it normally does with the state buttons, except each button would have the day code on it, when you click on a day button, you would get 2 drop downs (hours and mins). The user could then set the time for each day and each "state" button would then show the day and time that was set. Of course you couldn't show all that on the main button, the user would have to click the main object button to see what was set or to update them in the future. For the calendar, could you just pop out to a calendar when the main button is pushed? The main object buttons would be the $Normal $Conserve and $Night as normal and each of the object times would have to be set individually. It keeps with the same Misterhouse scheme and would allow any other code to utilize them. What do you think?


For the slider, that would be useful in many cases, one would be the temp setting to start instead of a UP/Down button. Maybe give it a start and end number in the object settings?


I trust google to always be up, but I don't trust Cox to always be up :). I like to have all my settings local for my home automation stuff.


I already have all core functionality written as I am currently using it to control my thermostat, I'll complete the object code and just use a manually created hash in my user code to create the schedule. When/If you get around to creating the UI part I'll have the rest of the code ready.


Let me know your thoughts..


_Wayne  



On Sun, Jul 24, 2016 at 8:37 AM, H Plato <[hidden email]> wrote:
Neat. I’ve been thinking about this since a fixed calendar doesn’t work too well in the spring and fall here with heating and cooling, and with large variations in outside temps.

Just so I’m clear, "I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this. “. So almost like a 8 column grid:

M Tu W Th F Sa Su
Normal
Conserve
Night

Achievable, but that would be 24 objects, so might be a little clunky. It also doesn’t account for months. There is some ‘data table’ functionality I added into IA7, if it allowed for controls, that might work. Having a scheduling framework would be valuable, I can see this also useful for irrigation, light scheduling.

One other idea you could use in the interim, is the ical ‘control calendar’. A while back I added in the ability to create an ical calendar (ie google calendar) and have it control objects. So you’d have a thermostat calendar, and then your normal, conserve, and night objects could be activated at whatever time you choose. I’d have to relook at the code to remember how it worked. Not a good long term solution (since I don’t like relying on cloud services for anything that can control critical objects), but maybe this might be a good temporary step?

On a similar note, I’ve been thinking that a slider UI would be a nice enhancement. Problem I see is that it breaks the current simple grid layout. Could be something to pursue if there is a lot of interest. There is a nice ready-made bootstrap compatible slider that looks like it would work. I like the range slider as this would work nicely for setpoints: http://seiyria.com/bootstrap-slider/



On Jul 23, 2016, at 11:19 PM, Wayne Gatlin <[hidden email]> wrote:

I wrote a thermostat scheduler and right now I have the times set in the ini file. I would like to change that to objects so I can modify it easily from the web interface. The problem I am having is that there is no way (that I have found) to easily do this natively without making many objects. I was thinking that if I could set something in my code to change the object selector in the web interface then that would solve this.

Maybe have selectors like:
  • Mon-Sun with a time range for each day, a single time for each day, or the normal object states listed for each day.
  • Calendar with the same options as Mon-Sun above for each day.
  • Single time selector
  • Time range selector
  • multi drop down, could have 2 or more sets of states
 
There may already be a way to do this or another option already in place, so I'm open to that. But with the above I could just make an object for each schedule type like so:

#set the web interface to use the Mon-Sun selector and a single time for each day (I would set this in the module code)
$Normal{webselector}{Daily} = 'SingleTime';
$Conserve{webselector}{Daily} = 'SingleTime';
$Night{webselector}{Daily} = 'SingleTime';

Each object could be set to a hash with each day of the week and a time for each day.



Full user code would look like this:

use THERMOSCHEDULE;
$Normal = new THERMOSCHEDULE();     # Mon-Fri=04:30 PM, Sat-Sun=08:00 AM
$Conserve = new THERMOSCHEDULE();  # Mon-Fri=06:20 AM, Sat-Sun=
$Night = new THERMOSCHEDULE();        # Mon-Fri=10:00 PM, Sat-Sun=11:00 PM

$NormalCool = new THERMOSCHEDULE_TEMP($Normal,'73'); # Tie the temp to the Normal schedule object above. set the default temp and have an UP and DOWN states to change the temp in the web interface
$NormalHeat = new THERMOSCHEDULE_TEMP($Normal,'70');

$NightCool = new THERMOSCHEDULE_TEMP($Night,'71');
$NightHeat = new THERMOSCHEDULE_TEMP($Night'67');
# Winter temp override
$NightWCool = new THERMOSCHEDULE_TEMP($Night,'74','Winter','50'); # Forcasted temps equal or below this (50) cause the winter temps to be used. Pulled from $Weather{Forecast Tonight}.
$NightWHeat = new THERMOSCHEDULE_TEMP($Night,'71','Winter','50');

$ConserveCool = new THERMOSCHEDULE_TEMP($Conserve,'77');
$ConserveHeat = new THERMOSCHEDULE_TEMP($Conserve,'66');

# Occupancy Override (optional, I track occupancy by checking to see if my cell is connected to wifi) 
$NormalOccupancy = new THERMOSCHEDULE_OCC($Normal,'home','work',$Conserve); # Tie the $Normal object temps to this object. If the $mode_occupied state is home use the $Normal object temps, if the $mode_occupied state changes to work change the temp settings to the $Conserve settings

$NightOccupancy = new THERMOSCHEDULE_OCC($Night,'home','work',$Normal);

$ConserveOccupancy = new THERMOSCHEDULE_OCC($Conserve,'home','work',$Conserve,'Vacation'); # I don't change the temps based on occupancy for the conserve mode. We will use the conserve temps any time the $mode_occupied is set to Vacation no matter what schedule time we are currently on.


 
_Wayne


------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

















------------------------------------------------------------------------------

________________________________________________________
To unsubscribe from this list, go to: https://lists.sourceforge.net/lists/listinfo/misterhouse-users

Loading...