From: Eloy P. <pe...@ch...> - 2011-01-28 18:14:16
|
Hello, I have a PLM scene defined like this: INSTEON_ICONTROLLER, 10, upstairs_hallway_light, All_Scenes SCENE_MEMBER, upstairs_hallway_slav1_light, upstairs_hallway_light, on SCENE_MEMBER, upstairs_hallway_mast_light, upstairs_hallway_light, on SCENE_MEMBER, upstairs_hallway_slav2_light, upstairs_hallway_light, on When I turn the scene on with a command like this: set $upstairs_hallway_light ON members of the scene go to '100%' instead of 'on'. This causes the following code to fail: if (state_now $upstairs_hallway_mast_light eq ON) ... Since when the lights are turn on by other means the state of the lights go to 'on', with the way things work right now, my could would have to become: if (state_now $upstairs_hallway_mast_light eq ON || stat_now $upstairs_hallway_mast_light eq '100%') ... Since the scene members are defined with on_level = 'on', I wonder why things are being overridden to set the on_level to '100%'. I see this code in Insteon::BaseController::add(): if ($on_level =~ /^sur/i) { $on_level = '100%'; $$obj{surrogate} = $self; } elsif (lc $on_level eq 'on') { $on_level = '100%'; } elsif (lc $on_level eq 'off') { $on_level = '0%'; } $on_level = '100%' unless $on_level; $$self{members}{$obj}{on_level} = $on_level; Is there a reason why on_level is being changed to '100%' if it is defined as 'on'? (I am assuming this is what causes the state to go to '100%' instead of 'on'). Same comment for 'off' -> '0%'. By the way, I also noticed that when I scan the state of the devices that are in the '100%' state, when the response from the device comes back, the state gets changed to 'on'. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-01-28 18:26:17
|
Quoting Eloy Paris <pe...@ch...>: > Hello, > > I have a PLM scene defined like this: > > INSTEON_ICONTROLLER, 10, upstairs_hallway_light, All_Scenes > SCENE_MEMBER, upstairs_hallway_slav1_light, upstairs_hallway_light, on > SCENE_MEMBER, upstairs_hallway_mast_light, upstairs_hallway_light, on > SCENE_MEMBER, upstairs_hallway_slav2_light, upstairs_hallway_light, on > > When I turn the scene on with a command like this: > > set $upstairs_hallway_light ON > > members of the scene go to '100%' instead of 'on'. This causes the > following code to fail: > > if (state_now $upstairs_hallway_mast_light eq ON) ... > > Since when the lights are turn on by other means the state of the lights > go to 'on', with the way things work right now, my could would have to > become: > > if (state_now $upstairs_hallway_mast_light eq ON > || stat_now $upstairs_hallway_mast_light eq '100%') ... > > Since the scene members are defined with on_level = 'on', I wonder why > things are being overridden to set the on_level to '100%'. I see this > code in > > Insteon::BaseController::add(): > > if ($on_level =~ /^sur/i) { > $on_level = '100%'; > $$obj{surrogate} = $self; > } elsif (lc $on_level eq 'on') { > $on_level = '100%'; > } elsif (lc $on_level eq 'off') { > $on_level = '0%'; > } > $on_level = '100%' unless $on_level; > $$self{members}{$obj}{on_level} = $on_level; > > Is there a reason why on_level is being changed to '100%' if it is > defined as 'on'? (I am assuming this is what causes the state to go to > '100%' instead of 'on'). > > Same comment for 'off' -> '0%'. Yes, the very concept of "level" is percentile and not "on" or "off". > By the way, I also noticed that when I scan the state of the devices > that are in the '100%' state, when the response from the device comes > back, the state gets changed to 'on'. That's really a different issue. I'll (eventually) work towards aligning states to "on" or "off" if not a dim level. But, that will be pretty low on the priority list. > Cheers, > > Eloy Paris.- > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Eloy P. <pe...@ch...> - 2011-01-28 18:56:06
|
On 01/28/2011 01:26 PM, Gregg Liming wrote: [...] > Yes, the very concept of "level" is percentile and not "on" or "off". Ah okay. >> By the way, I also noticed that when I scan the state of the devices >> that are in the '100%' state, when the response from the device comes >> back, the state gets changed to 'on'. > > That's really a different issue. I'll (eventually) work towards > aligning states to "on" or "off" if not a dim level. But, that will > be pretty low on the priority list. Thanks Gregg! So in the future user code needs to check for '0%' and '100%' instead of OFF (or 'off') and ON (or 'on') and until then user code should be checking for both '0%' and OFF and '100%' and ON, correct? Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-01-28 19:15:21
|
Quoting Eloy Paris <pe...@ch...>: >>> By the way, I also noticed that when I scan the state of the devices >>> that are in the '100%' state, when the response from the device comes >>> back, the state gets changed to 'on'. >> >> That's really a different issue. I'll (eventually) work towards >> aligning states to "on" or "off" if not a dim level. But, that will >> be pretty low on the priority list. > > Thanks Gregg! > > So in the future user code needs to check for '0%' and '100%' instead of > OFF (or 'off') and ON (or 'on') and until then user code should be > checking for both '0%' and OFF and '100%' and ON, correct? Well, I hate to fully commit to exact implementation until I give it some more thought. But, definitely "relay" objects only have on levels of 0 and 100%. So, those will definitely get aligned to "on" and "off" (as on level doesn't make sense). But, whether dimmable devices get their state aligned will be TBD. At a minimum, perhaps I could add a "state_equals" method, where for dimmable devices: state = any on_level other than 0 and reference state = ON results in true state = ON and any reference state that is ON or non-zero level results in true state = 0% and reference state = OFF results in true state = OFF and reference state = 0% results in true otherwise, false As you can see, I don't want to automatically align some of the conditions above as it could result in outcomes that aren't as expected. But, I don't object to creating "helper" methods to reduce the overhead of extra user code. Lastly, some of the implementation is still carry over from the original trunk codebase--which didn't distinguish dimmable from non-dimmable devices. Also, some of the state alignment was the result of mapping the dim level for scenes in a way that made alignment for scene levels easier. Make sense? |
From: Eloy P. <pe...@ch...> - 2011-01-28 19:24:49
|
On 01/28/2011 02:15 PM, Gregg Liming wrote: > Quoting Eloy Paris<pe...@ch...>: > >>>> By the way, I also noticed that when I scan the state of the devices >>>> that are in the '100%' state, when the response from the device comes >>>> back, the state gets changed to 'on'. >>> >>> That's really a different issue. I'll (eventually) work towards >>> aligning states to "on" or "off" if not a dim level. But, that will >>> be pretty low on the priority list. >> >> Thanks Gregg! >> >> So in the future user code needs to check for '0%' and '100%' instead of >> OFF (or 'off') and ON (or 'on') and until then user code should be >> checking for both '0%' and OFF and '100%' and ON, correct? > > Well, I hate to fully commit to exact implementation until I give it > some more thought. But, definitely "relay" objects only have on > levels of 0 and 100%. So, those will definitely get aligned to "on" > and "off" (as on level doesn't make sense). But, whether dimmable > devices get their state aligned will be TBD. At a minimum, perhaps I > could add a "state_equals" method, where for dimmable devices: > > state = any on_level other than 0 and reference state = ON results in true > state = ON and any reference state that is ON or non-zero level > results in true > state = 0% and reference state = OFF results in true > state = OFF and reference state = 0% results in true > otherwise, false > > As you can see, I don't want to automatically align some of the > conditions above as it could result in outcomes that aren't as > expected. But, I don't object to creating "helper" methods to reduce > the overhead of extra user code. > > Lastly, some of the implementation is still carry over from the > original trunk codebase--which didn't distinguish dimmable from > non-dimmable devices. Also, some of the state alignment was the result > of mapping the dim level for scenes in a way that made alignment for > scene levels easier. > > Make sense? Yes, I think so, and thanks for the additional level of detail. I guess we'll have to wait to see what the implementation ends up being. By the way, I don't think it is relevant now that you've provided all the details above, but I forgot to mention that the devices I am dealing with are relays. That's why I originally was surprised to see the 100% level state. Thanks again. Cheers, Eloy Paris.- |
From: Chris E. <chr...@gm...> - 2011-01-29 04:08:01
|
> > Well, I hate to fully commit to exact implementation until I give it > some more thought. But, definitely "relay" objects only have on > levels of 0 and 100%. So, those will definitely get aligned to "on" > and "off" (as on level doesn't make sense). But, whether dimmable > devices get their state aligned will be TBD. At a minimum, perhaps I > could add a "state_equals" method, where for dimmable devices: > > So are you saying that code that uses state_now device would have to check both 100% and on if it doesn't want to have to understand what items are dimmable and which aren't ? Also if you have a mixture of X10/insteon in a group that you are iterating through would you have to make special checks? I personally don't have any X10 but it seems to me like state_now $obj eq ON not working across all device types is a break from the way things currently work. Or maybe I'm just not understanding it. I have noticed alot of discussion on the insteon branch almost making me want to switch over since that is all I have is insteon. Just too much other things going on at the moment. -- Chris |
From: Eloy P. <pe...@ch...> - 2011-01-29 01:02:03
|
Hi Gregg, Sorry for (possibly) beating a (possible) dead horse but I have (possible) additional information ;-) On 01/28/2011 01:26 PM, Gregg Liming wrote: > Quoting Eloy Paris<pe...@ch...>: > >> Hello, >> >> I have a PLM scene defined like this: >> >> INSTEON_ICONTROLLER, 10, upstairs_hallway_light, All_Scenes >> SCENE_MEMBER, upstairs_hallway_slav1_light, upstairs_hallway_light, on >> SCENE_MEMBER, upstairs_hallway_mast_light, upstairs_hallway_light, on >> SCENE_MEMBER, upstairs_hallway_slav2_light, upstairs_hallway_light, on >> >> When I turn the scene on with a command like this: >> >> set $upstairs_hallway_light ON >> >> members of the scene go to '100%' instead of 'on'. This causes the >> following code to fail: >> >> if (state_now $upstairs_hallway_mast_light eq ON) ... >> >> Since when the lights are turn on by other means the state of the lights >> go to 'on', with the way things work right now, my could would have to >> become: >> >> if (state_now $upstairs_hallway_mast_light eq ON >> || stat_now $upstairs_hallway_mast_light eq '100%') ... >> >> Since the scene members are defined with on_level = 'on', I wonder why >> things are being overridden to set the on_level to '100%'. I see this >> code in >> >> Insteon::BaseController::add(): >> >> if ($on_level =~ /^sur/i) { >> $on_level = '100%'; >> $$obj{surrogate} = $self; >> } elsif (lc $on_level eq 'on') { >> $on_level = '100%'; >> } elsif (lc $on_level eq 'off') { >> $on_level = '0%'; >> } >> $on_level = '100%' unless $on_level; >> $$self{members}{$obj}{on_level} = $on_level; >> >> Is there a reason why on_level is being changed to '100%' if it is >> defined as 'on'? (I am assuming this is what causes the state to go to >> '100%' instead of 'on'). >> >> Same comment for 'off' -> '0%'. > > Yes, the very concept of "level" is percentile and not "on" or "off". I have noticed that if I use the scene to control the lights the state of each light goes to "100%". However, if I control the individual lights, the state of the controlled light goes to "on". Is this expected; could this be explained by Insteon::SwitchLincRelay knowing that there are not dim levels versus Insteon::BaseController not knowing that that is the case? Additionally, off is always "off", i.e. never "0%", even when the lights are controlled via the scene. Hope all is well. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-01-30 20:46:56
|
On 1/28/2011 1:26 PM, Gregg Liming wrote: > Quoting Eloy Paris<pe...@ch...>: > >> Hello, >> >> I have a PLM scene defined like this: >> >> INSTEON_ICONTROLLER, 10, upstairs_hallway_light, All_Scenes >> SCENE_MEMBER, upstairs_hallway_slav1_light, upstairs_hallway_light, on >> SCENE_MEMBER, upstairs_hallway_mast_light, upstairs_hallway_light, on >> SCENE_MEMBER, upstairs_hallway_slav2_light, upstairs_hallway_light, on >> >> When I turn the scene on with a command like this: >> >> set $upstairs_hallway_light ON >> >> members of the scene go to '100%' instead of 'on'. This causes the >> following code to fail: >> >> if (state_now $upstairs_hallway_mast_light eq ON) ... >> >> Since when the lights are turn on by other means the state of the lights >> go to 'on', with the way things work right now, my could would have to >> become: >> >> if (state_now $upstairs_hallway_mast_light eq ON >> || stat_now $upstairs_hallway_mast_light eq '100%') ... >> >> Since the scene members are defined with on_level = 'on', I wonder why >> things are being overridden to set the on_level to '100%'. I see this >> code in >> >> Insteon::BaseController::add(): >> >> if ($on_level =~ /^sur/i) { >> $on_level = '100%'; >> $$obj{surrogate} = $self; >> } elsif (lc $on_level eq 'on') { >> $on_level = '100%'; >> } elsif (lc $on_level eq 'off') { >> $on_level = '0%'; >> } >> $on_level = '100%' unless $on_level; >> $$self{members}{$obj}{on_level} = $on_level; >> >> Is there a reason why on_level is being changed to '100%' if it is >> defined as 'on'? (I am assuming this is what causes the state to go to >> '100%' instead of 'on'). >> >> Same comment for 'off' -> '0%'. > > Yes, the very concept of "level" is percentile and not "on" or "off". > >> By the way, I also noticed that when I scan the state of the devices >> that are in the '100%' state, when the response from the device comes >> back, the state gets changed to 'on'. > > That's really a different issue. I'll (eventually) work towards > aligning states to "on" or "off" if not a dim level. But, that will > be pretty low on the priority list. I apologize for the delay in responding to so many excellent suggestions/arguments/comments. I've been giving them a lot of thought and have some ideas/comments. I'm not yet committing to implementation; but, the following is where I'm beginning to consider: 1) state and state_now values need not follow what is passed to set (e.g., obj->set(some_value)). Many objects follow this "blindly" and result in state vales that are pretty hard to argue as truly being state. A good example is "dim" or "brighten"; neither are state values but rather commands. So, realize that there are some set arguments that can result in state change and others that do not. 2) The concept of state can be awkward to encapsulate in a single dimension/property. For this reason, additional properties (let's call them "state modifiers") may be needed. So, for example, if lights have either an "off" state or an "on" (or not-off) state, then we would need a "level" modifier for dimmable lights. There has been some precedent for this sort of thinking--especially in some more complex objects (e.g., irrigation, etc.) However, historically, the original x10 switchlinc items merged the concept of on/off and dim level to state--and, I was following that tradition. I personally prefer the state plus state modifier concept as I think it's a bit cleaner (and, especially, now--more exactly aligns w/ the class hierarchy model). The implication is that obj->set('50%') would result in a state_now value of 'on' and a level value of '50%'. 3) Non-dimmable lights (relays) should never have a percentile state. They're state should be either "on" or "off". We'd still allow percentile values for set commands. So, $relay->set('50%') would result only in state_now of 'on'. Let me know if there are any objections to the above. Otherwise, I'll begin working in this direction. Gregg |
From: Jim D. <ji...@du...> - 2011-01-30 21:47:10
|
On 01/30/2011 03:46 PM, Gregg Liming wrote: > > > 3) Non-dimmable lights (relays) should never have a percentile state. > They're state should be either "on" or "off". We'd still allow > percentile values for set commands. So, $relay->set('50%') would result > only in state_now of 'on'. Insteon Outletlinc has this property (ON/OFF only) and we currently don't have one available as INSTEON_OUTLETLINC as an item. Maybe we need one? Thanks, Jim |
From: Eloy P. <pe...@ch...> - 2011-01-31 00:27:33
|
Hi Jim, On 01/30/2011 04:46 PM, Jim Duda wrote: > On 01/30/2011 03:46 PM, Gregg Liming wrote: >> >> >> 3) Non-dimmable lights (relays) should never have a percentile state. >> They're state should be either "on" or "off". We'd still allow >> percentile values for set commands. So, $relay->set('50%') would result >> only in state_now of 'on'. > > Insteon Outletlinc has this property (ON/OFF only) and we currently don't have one > available as INSTEON_OUTLETLINC as an item. Maybe we need one? There are other on/off-only devices, like the ApplianceLinc and the relay SwitchLinc. Are there any differences between the OutletLinc and these others? Not arguing about the need for an INSTEON_OUTLETLINC item; just trying to understand if there are any further differences with the other devices within the context of the recent 'on' versus '100%' discussion and Gregg's thoughts on possible solutions ;-) Cheers, Eloy Paris.- |
From: Matthew C. <dv...@gm...> - 2011-01-31 00:00:50
|
Gregg, This is a great idea, I agree that it makes much more logical sense. Before it is implemented what existing code (X10?) might it break once the Insteon branch gets folded back into the main trunk? Matt On Sun, Jan 30, 2011 at 12:46 PM, Gregg Liming <gr...@li...> wrote: > On 1/28/2011 1:26 PM, Gregg Liming wrote: >> Quoting Eloy Paris<pe...@ch...>: >> >>> Hello, >>> >>> I have a PLM scene defined like this: >>> >>> INSTEON_ICONTROLLER, 10, upstairs_hallway_light, All_Scenes >>> SCENE_MEMBER, upstairs_hallway_slav1_light, upstairs_hallway_light, on >>> SCENE_MEMBER, upstairs_hallway_mast_light, upstairs_hallway_light, on >>> SCENE_MEMBER, upstairs_hallway_slav2_light, upstairs_hallway_light, on >>> >>> When I turn the scene on with a command like this: >>> >>> set $upstairs_hallway_light ON >>> >>> members of the scene go to '100%' instead of 'on'. This causes the >>> following code to fail: >>> >>> if (state_now $upstairs_hallway_mast_light eq ON) ... >>> >>> Since when the lights are turn on by other means the state of the lights >>> go to 'on', with the way things work right now, my could would have to >>> become: >>> >>> if (state_now $upstairs_hallway_mast_light eq ON >>> || stat_now $upstairs_hallway_mast_light eq '100%') ... >>> >>> Since the scene members are defined with on_level = 'on', I wonder why >>> things are being overridden to set the on_level to '100%'. I see this >>> code in >>> >>> Insteon::BaseController::add(): >>> >>> if ($on_level =~ /^sur/i) { >>> $on_level = '100%'; >>> $$obj{surrogate} = $self; >>> } elsif (lc $on_level eq 'on') { >>> $on_level = '100%'; >>> } elsif (lc $on_level eq 'off') { >>> $on_level = '0%'; >>> } >>> $on_level = '100%' unless $on_level; >>> $$self{members}{$obj}{on_level} = $on_level; >>> >>> Is there a reason why on_level is being changed to '100%' if it is >>> defined as 'on'? (I am assuming this is what causes the state to go to >>> '100%' instead of 'on'). >>> >>> Same comment for 'off' -> '0%'. >> >> Yes, the very concept of "level" is percentile and not "on" or "off". >> >>> By the way, I also noticed that when I scan the state of the devices >>> that are in the '100%' state, when the response from the device comes >>> back, the state gets changed to 'on'. >> >> That's really a different issue. I'll (eventually) work towards >> aligning states to "on" or "off" if not a dim level. But, that will >> be pretty low on the priority list. > > I apologize for the delay in responding to so many excellent > suggestions/arguments/comments. I've been giving them a lot of thought > and have some ideas/comments. I'm not yet committing to implementation; > but, the following is where I'm beginning to consider: > > 1) state and state_now values need not follow what is passed to set > (e.g., obj->set(some_value)). Many objects follow this "blindly" and > result in state vales that are pretty hard to argue as truly being > state. A good example is "dim" or "brighten"; neither are state values > but rather commands. So, realize that there are some set arguments that > can result in state change and others that do not. > > 2) The concept of state can be awkward to encapsulate in a single > dimension/property. For this reason, additional properties (let's call > them "state modifiers") may be needed. So, for example, if lights have > either an "off" state or an "on" (or not-off) state, then we would need > a "level" modifier for dimmable lights. There has been some precedent > for this sort of thinking--especially in some more complex objects > (e.g., irrigation, etc.) However, historically, the original x10 > switchlinc items merged the concept of on/off and dim level to > state--and, I was following that tradition. I personally prefer the > state plus state modifier concept as I think it's a bit cleaner (and, > especially, now--more exactly aligns w/ the class hierarchy model). > > The implication is that obj->set('50%') would result in a state_now > value of 'on' and a level value of '50%'. > > 3) Non-dimmable lights (relays) should never have a percentile state. > They're state should be either "on" or "off". We'd still allow > percentile values for set commands. So, $relay->set('50%') would result > only in state_now of 'on'. > > Let me know if there are any objections to the above. Otherwise, I'll > begin working in this direction. > > Gregg > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > |
From: Gregg L. <gr...@li...> - 2011-01-31 00:45:29
|
On 1/30/2011 6:53 PM, Matthew Campbell wrote: > Before it is implemented what existing code (X10?) might it break once > the Insteon branch gets folded back into the main trunk? X10 would be unaffected because this applies to insteon objects only. The only thing that might be an issue is LOMP. But, many of us (myself included) that are running branch will see anything very quickly I suspect. |
From: Eloy P. <pe...@ch...> - 2011-01-31 00:23:12
|
Hi Gregg, On 01/30/2011 03:46 PM, Gregg Liming wrote: [...] > I apologize for the delay in responding to so many excellent > suggestions/arguments/comments. No problem! We all are busy; and it's the weekend :-) > I've been giving them a lot of thought > and have some ideas/comments. I'm not yet committing to implementation; > but, the following is where I'm beginning to consider: I see that Jim and Matt have responded, but I'll venture to respond without reading what they wrote so I can provide an unbiased opinion ;-) > 1) state and state_now values need not follow what is passed to set > (e.g., obj->set(some_value)). Many objects follow this "blindly" and > result in state vales that are pretty hard to argue as truly being > state. A good example is "dim" or "brighten"; neither are state values > but rather commands. So, realize that there are some set arguments that > can result in state change and others that do not. Agree 100%. > 2) The concept of state can be awkward to encapsulate in a single > dimension/property. For this reason, additional properties (let's call > them "state modifiers") may be needed. So, for example, if lights have > either an "off" state or an "on" (or not-off) state, then we would need > a "level" modifier for dimmable lights. There has been some precedent > for this sort of thinking--especially in some more complex objects > (e.g., irrigation, etc.) However, historically, the original x10 > switchlinc items merged the concept of on/off and dim level to > state--and, I was following that tradition. I personally prefer the > state plus state modifier concept as I think it's a bit cleaner (and, > especially, now--more exactly aligns w/ the class hierarchy model). > > The implication is that obj->set('50%') would result in a state_now > value of 'on' and a level value of '50%'. Agree 100%. This one actually makes a *lot* of sense to me. > 3) Non-dimmable lights (relays) should never have a percentile state. > They're state should be either "on" or "off". We'd still allow > percentile values for set commands. So, $relay->set('50%') would result > only in state_now of 'on'. Totally agree. Makes a ton of sense too. state_now of 'on' as well as level value of '100%'? I am not too sure; I guess level value of '50%' is good enough. I mean, garbage in, garbage out should apply here in my opinion, i.e. why on earth would you do $relay->set('50%') in user code? It's a relay; there's no such a thing as 50% open or close ;-) > Let me know if there are any objections to the above. Otherwise, I'll > begin working in this direction. No objections at all; I think it all makes perfect sense. Cheers! Eloy Paris.- |
From: Chris E. <chr...@gm...> - 2011-01-31 00:27:46
|
> The implication is that obj->set('50%') would result in a state_now > value of 'on' and a level value of '50%'. > > 3) Non-dimmable lights (relays) should never have a percentile state. > They're state should be either "on" or "off". We'd still allow > percentile values for set commands. So, $relay->set('50%') would result > only in state_now of 'on'. > > Let me know if there are any objections to the above. Otherwise, I'll > begin working in this direction. > > Gregg > > So does this line up with what you are proposing: $dimmer->set('50%'); results in state_now 'on' and level of '50%'; $dimmer->set('100%') or dimmer->set('on'); results in state_now 'on' and level of '100%'; $dimmer->set('0%') or dimmer->set('off'); results in state_now 'off' and level of '0%'; And then for a relay (on/off) device $relay->set('50%'); results in state_now 'on' and level of '100%'; $relay->set('100%') or $relay->set('on'); results in state_now 'on' and level of '100%'; $relay->set('0%') or $relay->set('off'); results in state_now 'off' and level of '0%'; So a relay and dimmer are somewhat consistent in that they both support the level modifier but a relay will only be 0% or 100% -- Chris |
From: Gregg L. <gr...@li...> - 2011-01-31 00:48:57
|
On 1/30/2011 7:27 PM, Chris Engel wrote: > So does this line up with what you are proposing: > $dimmer->set('50%'); > results in state_now 'on' and level of '50%'; yes > $dimmer->set('100%') or dimmer->set('on'); > results in state_now 'on' and level of '100%'; yes > $dimmer->set('0%') or dimmer->set('off'); > results in state_now 'off' and level of '0%'; yes > And then for a relay (on/off) device > $relay->set('50%'); > results in state_now 'on' and level of '100%'; Only objects that inherit from Insteon::DimmableLight have a level property. Relays don't. Otherwise, yes. > $relay->set('100%') or $relay->set('on'); > results in state_now 'on' and level of '100%'; Same comment. > $relay->set('0%') or $relay->set('off'); > results in state_now 'off' and level of '0%'; Same comment. > So a relay and dimmer are somewhat consistent in that they both support > the level modifier No. |
From: David N. <dno...@ya...> - 2011-01-31 03:10:36
|
On 1/30/2011 4:48 PM, Gregg Liming wrote: > On 1/30/2011 7:27 PM, Chris Engel wrote: > >> $dimmer->set('100%') or dimmer->set('on'); >> results in state_now 'on' and level of '100%'; > yes > I'm sorry if this was covered earlier in this thread and i missed it, but don't dimmable insteon devices support an "on level" that can be different than 100%? And, if you send an ON command to a device, it will come on at that level? Does the item "level" method respond with that (possibly not 100%) value? Does the item have methods for setting the on level and ramp rate? David |
From: Gregg L. <gr...@li...> - 2011-01-31 13:15:52
|
On 1/30/2011 10:10 PM, David Norwood wrote: > On 1/30/2011 4:48 PM, Gregg Liming wrote: >> On 1/30/2011 7:27 PM, Chris Engel wrote: >> >>> $dimmer->set('100%') or dimmer->set('on'); >>> results in state_now 'on' and level of '100%'; >> yes >> > > I'm sorry if this was covered earlier in this thread and i missed it, > but don't dimmable insteon devices support an "on level" that can be > different than 100%? And, if you send an ON command to a device, it > will come on at that level? Does the item "level" method respond with > that (possibly not 100%) value? > > Does the item have methods for setting the on level and ramp rate? Good points. Yes--there is an existing method called "local_onlevel(level)" that may be set (although simply setting the value doesn't mean that the physical device is set until it is explicitly written into device memory via update_local_properties()). And, the current "level" property does seek it's value when encountering an "on" state. However, I need to double check whether the physical device uses the local on level only when set on locally or also when set via powerline. Also, I need to confirm the same situations when on_fast occurs. Thanks for the reminders! Gregg |
From: Eloy P. <pe...@ch...> - 2011-01-29 15:22:21
|
Hi Chris, On 01/28/2011 11:07 PM, Chris Engel wrote: > Well, I hate to fully commit to exact implementation until I give it > some more thought. But, definitely "relay" objects only have on > levels of 0 and 100%. So, those will definitely get aligned to "on" > and "off" (as on level doesn't make sense). But, whether dimmable > devices get their state aligned will be TBD. At a minimum, perhaps I > could add a "state_equals" method, where for dimmable devices: > > > So are you saying that code that uses state_now device would have to > check both 100% and on if it doesn't want to have to understand what > items are dimmable and which aren't ? Also if you have a mixture of > X10/insteon in a group that you are iterating through would you have to > make special checks? > > I personally don't have any X10 but it seems to me like state_now $obj > eq ON not working across all device types is a break from the way things > currently work. > > Or maybe I'm just not understanding it. There are some things I still don't quite understand but I think that what you are saying regarding special checks currently holds. I actually finished coding a workaround in one of my user code files: ------------------------------------------------------------------ # Workaround possibility of light state being 100% instead # of 'on', at least in 1/29/2010 "insteon" branch code. my ($light_state_now, $light_state); $light_state_now = state_now $upstairs_hallway_mast_light; $light_state_now = ON if $light_state_now eq '100%'; $light_state = state $upstairs_hallway_mast_light; $light_state = ON if $light_state eq '100%'; if ( (!$Dark && $light_state_now eq ON) || (time_now $Time_Sunrise_Twilight && $light_state eq ON) ) { # It's either not dark and the light just got turned on, # or the light was on and the Sun rose. set $upstairs_hall_timer 5*60; } ------------------------------------------------------------------ Definitely not as easy as just testing once for "on", as we're used to. Gregg seems to have plans in this area, though, so we should wait for the actual implementation. I don't know if this would be feasible, but should we not store on/off status separately from dim level? I mean, anything > 1% dim level would be stored as 'on'. 0% would be 'off'. Then user code that checks for ON/OFF would not need to be changed, regardless of whether the device is dim-capable, and user code that needs to know dim level would need to be re-written to check using a different class method. > I have noticed alot of discussion on the insteon branch almost making me > want to switch over since that is all I have is insteon. Just too much > other things going on at the moment. I think it is working great. Of course there are a few quirks, like this thing with '100%' and 'on', but I have not found anything to be a deal breaker. There is no working link management but that can be done manually. But overall I think it is in pretty good shape. Cheers, Eloy Paris.- |
From: Mark K. <ae...@gm...> - 2011-01-30 02:09:15
|
Here's an idea that I think may have been mentioned or implied in some of the earlier parts of this discussion: add methods to the Light_Item (or wherever it makes the most sense) called is_now_on and is_now_off (and maybe is_on and is_off). Those methods would abstract the concept of "on" and "off" and decouple the object's internal state implementation from external dependancies like user code. It would be especially handy now while the design is still evolving. if(is_now_on $hall_light) do_something; --Mark On Sat, Jan 29, 2011 at 07:22, Eloy Paris <pe...@ch...> wrote: > Hi Chris, > > On 01/28/2011 11:07 PM, Chris Engel wrote: > > > Well, I hate to fully commit to exact implementation until I give it > > some more thought. But, definitely "relay" objects only have on > > levels of 0 and 100%. So, those will definitely get aligned to "on" > > and "off" (as on level doesn't make sense). But, whether dimmable > > devices get their state aligned will be TBD. At a minimum, perhaps I > > could add a "state_equals" method, where for dimmable devices: > > > > > > So are you saying that code that uses state_now device would have to > > check both 100% and on if it doesn't want to have to understand what > > items are dimmable and which aren't ? Also if you have a mixture of > > X10/insteon in a group that you are iterating through would you have to > > make special checks? > > > > I personally don't have any X10 but it seems to me like state_now $obj > > eq ON not working across all device types is a break from the way things > > currently work. > > > > Or maybe I'm just not understanding it. > > There are some things I still don't quite understand but I think that > what you are saying regarding special checks currently holds. I actually > finished coding a workaround in one of my user code files: > > ------------------------------------------------------------------ > # Workaround possibility of light state being 100% instead > # of 'on', at least in 1/29/2010 "insteon" branch code. > my ($light_state_now, $light_state); > $light_state_now = state_now $upstairs_hallway_mast_light; > $light_state_now = ON if $light_state_now eq '100%'; > $light_state = state $upstairs_hallway_mast_light; > $light_state = ON if $light_state eq '100%'; > > if ( (!$Dark && $light_state_now eq ON) > || (time_now $Time_Sunrise_Twilight && $light_state eq ON) ) { > # It's either not dark and the light just got turned on, > # or the light was on and the Sun rose. > set $upstairs_hall_timer 5*60; > } > ------------------------------------------------------------------ > > Definitely not as easy as just testing once for "on", as we're used to. > > Gregg seems to have plans in this area, though, so we should wait for > the actual implementation. > > I don't know if this would be feasible, but should we not store on/off > status separately from dim level? I mean, anything > 1% dim level would > be stored as 'on'. 0% would be 'off'. Then user code that checks for > ON/OFF would not need to be changed, regardless of whether the device is > dim-capable, and user code that needs to know dim level would need to be > re-written to check using a different class method. > > > I have noticed alot of discussion on the insteon branch almost making me > > want to switch over since that is all I have is insteon. Just too much > > other things going on at the moment. > > I think it is working great. Of course there are a few quirks, like this > thing with '100%' and 'on', but I have not found anything to be a deal > breaker. There is no working link management but that can be done > manually. But overall I think it is in pretty good shape. > > Cheers, > > Eloy Paris.- > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better > price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > |
From: Gregg L. <gr...@li...> - 2011-01-31 00:46:47
|
On 1/30/2011 7:23 PM, Eloy Paris wrote: > state_now of 'on' as well as level value of '100%'? I am not too sure; I > guess level value of '50%' is good enough. I mean, garbage in, garbage > out should apply here in my opinion, i.e. why on earth would you do > $relay->set('50%') in user code? It's a relay; there's no such a thing > as 50% open or close ;-) I'm never surprise by what seemingly intelligent people do w/ their user code. Just trying to show what the logic would do to "protect" the object. |
From: Joel D. <jr...@io...> - 2011-01-31 01:06:17
|
On Sun, 30 Jan 2011, it would appear that Gregg Liming wrote: > On 1/30/2011 7:23 PM, Eloy Paris wrote: > >> state_now of 'on' as well as level value of '100%'? I am not too sure; I >> guess level value of '50%' is good enough. I mean, garbage in, garbage >> out should apply here in my opinion, i.e. why on earth would you do >> $relay->set('50%') in user code? It's a relay; there's no such a thing >> as 50% open or close ;-) > > I'm never surprise by what seemingly intelligent people do w/ their user > code. Just trying to show what the logic would do to "protect" the object. True enough. If you try to make something foolproof nature just creates bigger fools. Seriously though, I've been watching the progress on this insteon project with some interest, as I expect at some point I'll be moving to insteon from x10. So far, I've had 20 years of great success and/ or luck with x10, but there are times the increased functionality of insteon is appealing. Thanks to everyone for their effort to make misterhouse a better, more capable program. Joel |