misterhouse-users Mailing List for MisterHouse: Home Automation with Perl

Quoting Jason Sharpee (9/30/07 2:26 PM):

> We were talking earlier last month on the list about the Device structure 
> in MH and ideas for improving it.  I want to start adding in some SOA into 
> MH and I think the best tool for the job is xAP.
> 
> Instead of making a PLM driver for MH, I would like to have made a generic 
> xAP driver for the PLM and allow MH to use that.   I have a lot of HA 
> code written in C/C++/C# now and would like to re-use the various 
> components I have in MH as well.

Are you familiar w/ the xAP BSC schema?  It wouldn't handle all of the
possible subtle lighting functions/events (e.g., ramp rate); but, would
handle the basics (e.g., on, off, xx%) and is already built-in to mh
(see BSC.pm).

Gregg

On Sat, 29 Sep 2007, Gregg Liming wrote:

> Quoting Jason Sharpee (9/29/07 9:43 AM):
>> I am going to start
>> looking into an xAP device type.
>
> This has my interest.  Would you mind elaborating as to what you have in
> mind?
>

We were talking earlier last month on the list about the Device structure 
in MH and ideas for improving it.  I want to start adding in some SOA into 
MH and I think the best tool for the job is xAP.

Instead of making a PLM driver for MH, I would like to have made a generic 
xAP driver for the PLM and allow MH to use that.   I have a lot of HA 
code written in C/C++/C# now and would like to re-use the various 
components I have in MH as well.

-J

On Sat, 29 Sep 2007, Gregg Liming wrote:

> Quoting Jason Sharpee (9/29/07 9:43 AM):
>
>> As I am not an Insteon user myself so I only intended the Insteon code to
>> kick off efforts in this realm by others that do use it.  I am not
>> planning on making any more changes to that code, so anyone is welcome to
>> make changes directly in SVN.  If anyone has questions on the
>> implementation feel free to contact me
>
> I looked briefly at your UPB_Link class and believe that it maps well to
> how ALL-Links might be handled--albeit w/ the insteon-specific codes,
> etc.  So, I'm tentatively thinking/planning on leveraging your UPB_Link
> code to create a Insteon_Link class unless you would rather I not.  One
> thing that I am curious about is how the refactoring you did on Scene.pm
> and your use of UPB_Link go together.  I'm guessing that you use Scene
> only for keep the members' of a link's state sync'd whereas UPB_Link
> handles the UPB-specifics?  Could you elaborate and/or tell me if I'm
> off base?
>

I know nothing about how Insteon Scene's/Links work but if it is similar 
to UPB_Link then I think you are on the right path.

X10_Scene and UPB_Link are the protocol specific versions of Scenes.  I 
wrote the Scene class to be a protocol inspecific Scene.  When I first 
started out with UPB, I had both UPB and X10 devices in my home.  I didnt 
bother using either X10_Scene or UPB_Link's and just added the individual 
heterogenus devices to my more global "Scene" in MH.  As time went on, my 
dependence on the Scene has shrunk and almost everything is triggered by 
UPB_Link's now.


> BTW: I should have led w/ a very huge thanks to you for getting this
> going as it was quite trivial for me to get the insteon portion of this
> going in no time.
>

Glad I could help.

Jason,

I've updated via SVN today, and gave the Insteon stuff a whirl again...

I still only have a fan and a lamp setup at this time...

The status update thing may be working. The buttons no longer say "unk"...

I don't know if that is because they're not brand new, or as a result of 
your efforts.

The lamp reported OFF, and it was...
The fan was on, and the button offered to BRIGHTEN...

Problem!

The fan is on a wall-switch, and it is an On/Off relay type device. An 
appliance module...

As opposed to a lamp module, which has On/Off/Dim/Bright...

I wonder if it has properly identified the module's type...

Oddly enough the tiny icon in the button appears to be that of a fan!

Let me know if I can help with another round of testing.

Sincerely,

Jack
:)


Jason Sharpee wrote:
> Gregg, thanks for the patch (I tossed too much out on my cleaup).  I 
> checked in support for receiving status requests, cleaned up the debug 
> messages, and added your patch.
>
> As I am not an Insteon user myself so I only intended the Insteon code to 
> kick off efforts in this realm by others that do use it.  I am not 
> planning on making any more changes to that code, so anyone is welcome to 
> make changes directly in SVN.  If anyone has questions on the 
> implementation feel free to contact me, however, I am going to start 
> looking into an xAP device type.
>
> Once again, I would like to thank everyone for their help in getting this 
> up and running!
>
> -J

Neil Cherry wrote:
> calling $self->deframe resolves the problem! So if I'm trying to use
> code that exists in the same package as I am calling the method from
> I can just call the method (method(@buf)). But If I'm trying to call
> a method from outside my package (something I've inherited) I need
> to do $self->method(@buf). Of course I also need a ref $self.
> 

When you are with a "package", you are within its namespace.  That means
that you must explicitly tell perl which package the function comes from,
unless it's within the current package OR has been exported into the global
namespace by the package.

Now, with OO, things are slightly different.  There are two types of
functions within packages, those that operate on objects and those that are
just general purpose functions.

First, let's look at those that operate on objects.  The normal way to call
a method (OO function) is to use the $object->method syntax.  Let's say that
$fooobject is an instance of the class foo and that foo is a child of bar.
The method foofunc is defined in class foo and barfunc is defined in class bar.

$fooobject->foofunc makes PERL do this:
- first, it determines where foofunc is defined
- as $fooobject was blessed to be of class foo, PERL first looks in the foo
package.  In this case it finds it.
- as PERL has determined that foofunc is in class foo, it actually calls the
following:
&foo::foofunc($fooobject)
- In other words, it adds the appropriate package identifier and places the
object reference as the first parameter.  That's why all methods look
something like this:
my ($self)=@_;  OR  my $self=shift;
- $self contains a copy of the object reference so that you can call things
like:
$self->foofunc2

Although $self->foofunc2 is equivalent to &foo::foofunc2($self) or
&foofunc2($self) within that package, it's bad form to do that.  If another
child class inherits from foo and redefines &foofunc2, then the wrong
foofunc2 could be called.  In other words, to maximize code reuse and
flexibility, don't explicitly give package/class names within a class
package - let PERL figure it out.

Now, say we wrote this:
$fooobject->barfunc
- $fooobject is of class foo but PERL can't find barfunc in the foo package
- PERL then traverses the inheritance tree by looking at the packages named
in $foo::ISA.  It finds barfunc in bar as to tell PERL that foo inherits
from bar, we wrote @foo::ISA=('bar') within the foo package;
- PERL translates the call above as this:
&bar::barfunc($fooobject)

The other kind of function is one that is not meant to operate on an object.
    One example of these are called static functions.  These are often used
to manage the class itself.  For example: your class needs to keep track of
the number of instances of the class that have been created and then report
that through the log.  These functions are like normal PERL package
functions and usually don't start with "my ($self)=@_" as you don't call
them with the $object->method syntax.

Hope this clears things up.  Feel free to ask further questions either via
e-mail or IRC.

Matt
-- 
GPG Key ID: 722441BA
MisterHouse Wiki: http://misterhouse.wikispaces.com/

Quoting Jason Sharpee (9/29/07 9:43 AM):
> I am going to start 
> looking into an xAP device type.

This has my interest.  Would you mind elaborating as to what you have in
mind?

Gregg

Quoting Jason Sharpee (9/29/07 9:43 AM):

> As I am not an Insteon user myself so I only intended the Insteon code to 
> kick off efforts in this realm by others that do use it.  I am not 
> planning on making any more changes to that code, so anyone is welcome to 
> make changes directly in SVN.  If anyone has questions on the 
> implementation feel free to contact me

I looked briefly at your UPB_Link class and believe that it maps well to
how ALL-Links might be handled--albeit w/ the insteon-specific codes,
etc.  So, I'm tentatively thinking/planning on leveraging your UPB_Link
code to create a Insteon_Link class unless you would rather I not.  One
thing that I am curious about is how the refactoring you did on Scene.pm
and your use of UPB_Link go together.  I'm guessing that you use Scene
only for keep the members' of a link's state sync'd whereas UPB_Link
handles the UPB-specifics?  Could you elaborate and/or tell me if I'm
off base?

BTW: I should have led w/ a very huge thanks to you for getting this
going as it was quite trivial for me to get the insteon portion of this
going in no time.

Gregg

Greg

That's very cool. 

The more I learn about Misterhouse the more I'm beginning to realize how
powerful it is.

Thanks everyone for your input.

Garry

-----Original Message-----
From: mis...@li...
[mailto:mis...@li...] On Behalf Of Gregg
Liming
Sent: Friday, September 28, 2007 8:57 PM
To: The main list for the MisterHouse home automation program
Subject: Re: [mh] Timed Event

Quoting Gregg Liming (9/28/07 11:35 PM):

> The following is what I use for this very purpose as it will do "state 
> tracking based upon "hits".

I should give proper credit for some ideas "repurposed" from comments Jason
had provided some time ago.  In particular, I liked the notion of "barely
dimming" the outside light at the first motion detect and then backing off
if additional motion events were not detected.  As I recall, Jason was
concerned about not annoying neighbors w/ excess outside light events.  But,
I was thinking of it more like a snake rattling it's tail as a warning--any
would-be crook is likely to be a bit concerned about exterior lighting that
starts dim and becomes brighter as he/she lingers.  In my case, I also
deliberately wanted gradual dimming to avoid camera blooming (which could
cause secondary false positives).  As it turns out, guests like it the most
as their eyes may have become slightly accustomed to the dark and appreciate
the gradual increase as they approach.

Gregg

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
________________________________________________________
To unsubscribe from this list, go to:
http://sourceforge.net/mail/?group_id=1365

Jason Sharpee wrote:
> On Fri, 28 Sep 2007, Gregg Liming wrote:
> 
>> Hi Jason,
>>
>> Quoting Jason Sharpee (9/27/07 7:46 AM):
>>
>>> However, I am not translating the status_request result.  I tried it out
>>> just now on my test device and can easily see where it is responding with
>>> a command1 '00' and a command2 with a hex level '00-FF'.  Should be no
>>> more than a 5 minute change to the code and ill see if I can add that this
>>> weekend as well.
>> While you're making mods, would you consider applying the attached diff
>> (or something of comparable outcome) to Insteon_Device so that instances
>> "play nice" w/ your Light_Item.pm?  Note that I have m_write default to
>> 1 so that "transmit only" instances would have to: $obj->writable(0);
>> I'm not opposed to defaulting the other way so long as writable exists.
>>
>> On a related note, do you have plans for addressing/implementing the
>> Insteon-specific (non-x10) ALL-Linking capabilities?  I'm quite
>> interested in anything along these lines and would be happy to
>> contribute (code, test, etc.) anyway that would help.
>>
> 
> Gregg, thanks for the patch (I tossed too much out on my cleaup).  I 
> checked in support for receiving status requests, cleaned up the debug 
> messages, and added your patch.
> 
> As I am not an Insteon user myself so I only intended the Insteon code to 
> kick off efforts in this realm by others that do use it.  I am not 
> planning on making any more changes to that code, so anyone is welcome to 
> make changes directly in SVN.  If anyone has questions on the 
> implementation feel free to contact me, however, I am going to start 
> looking into an xAP device type.
> 
> Once again, I would like to thank everyone for their help in getting this 
> up and running!

I don't have a PLM so I don't know how I'll support it but I do have
the SDK (and I'm prepared to use it ;-). I spoke with the Insteon
folks and at the time they had no problem with me posting my code
with the information likely to be contained there in. To that
end I intend to add support for linking via a web interface along
with support for some other goodies that Insteon can support.

I really don't want to spend another $60 on the PLM (I've got
a bunch of PLCs already) as I could better spend that money on
more modules. :-)


Weird the PLM development guide can be found on Google quite
easily. See:

http://www.techmall.com/topic.asp?TOPIC_ID=1659&whichpage=2

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

Stu

That did it for me.

$motion_timer = new Timer;
if (state_now $motion_front_porch eq 'on')
{
        if (state_now $motion_front_porch eq 'on' and inactive
$motion_timer) {
        	print_log "There is motion at the front door.";
	        $sensor_message = "I've detected motion at the front door";
        	&say_message;
		set $motion_timer 30;
}
} 

Thanks for your help.

Garry

-----Original Message-----
From: Stu Wells [mailto:st...@bl...] 
Sent: Friday, September 28, 2007 4:46 PM
To: gar...@sh...; The main list for the MisterHouse home
automation program
Subject: Re: [mh] Timed Event

Garry,

  I set a timer to ignore new motion once it's been tripped - below is a
snip of code I use.  I also use zones to decide what to do with the motion
events, so you can feel free to ignore that part or adopt it. 

 Hope this helps :-)

Stu

my $ig2_timer = new Timer;
if (state_now $drive_sensor eq "motion" and inactive $ig2_timer and
$zone1 ne "inactive") {
  set $ig2_timer 30;  #ignore motion from this sensor for 30 second

Garry Doucette wrote:
> Hi Guys
>
> I have a sensor to detect motion at my front door. I have MH announce 
> there's motion when the detector is triggered.
>
> The problem is if there is a person standing there the sensor will 
> trigger several times over with repeated announcements.
>
> I was trying to figure out how I could have the event time out after 
> triggered and only make an announcement if there is motion after say 
> every 5 or 10 seconds.
>
> I tried the get_idle_time and the time_idle($time) methods but they 
> didn't seem to work.
>
> What would be the best approach to deal with this in code?
>
> Garry
>
>
> ----------------------------------------------------------------------
> --- This SF.net email is sponsored by: Microsoft Defy all challenges. 
> Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ________________________________________________________
> To unsubscribe from this list, go to: 
> http://sourceforge.net/mail/?group_id=1365
>
>   

Neil Cherry wrote:
> Matthew Williams wrote:
>> Neil Cherry wrote:

> #------------------------------------------------------------------
> package Insteon_base;
> 
> use X10_Interface;
> @Insteon_PLU::ISA = ('X10_Interface');
> 
> sub parse_scmds {
> 	:  # Code goes here
> }
> return 1;
> 
> #------------------------------------------------------------------
> # USB version:
> package Insteon_PLU;
> 
> use Insteon_base;
> @Insteon_PLU::ISA = ('Insteon_base');
> 
> check_for_data() {
>    $data = $::Generic_Devices{$port_name}{data}; # It's a USB device
>    @buf = unpack('(C2)*', $data);
>    @d = deframe(@buf); # not done is Serial
>    parse_scmds(@d);
> }

> If I use code similar to the above I get:
> 
> Undefined subroutine &Insteon_PLU::deframe called at /usr/local/mh/bin/../lib/Insteon_PLU.pm line 161.
> 
> I think Gregg was telling me that I had to reference the object
> (such as using $self) to resolve this.

calling $self->deframe resolves the problem! So if I'm trying to use
code that exists in the same package as I am calling the method from
I can just call the method (method(@buf)). But If I'm trying to call
a method from outside my package (something I've inherited) I need
to do $self->method(@buf). Of course I also need a ref $self.

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

Matthew Williams wrote:
> Neil Cherry wrote:
>> I have a bunch of sub's that are exactly the same in two of my modules.
>>
>> PLU 			PLS
>> -----------------------	-----------------------
>> inherit X10_Interface	Inherit Generic_Item
>> package Event_queue	package Event_queue	<- Exact same code
>> Insteon_Interface code	Insteon_Interface code	<- Exact same code
>> PLU dependent code	PLS dependent code
>> -----------------------	-----------------------
> 
> The OO way of looking after this is to have a single class, perhaps called
> Insteon_Base, that contains all of the methods/data that are common between
> the two interfaces.  Two additional classes would inherit from Insteon_Base
> and add the interface specific stuff.

I follow but I don't follow. I understand the Insteon_base portion.
The &Parse_scmds would be in there. Is the following what you are
suggesting? (consider this pseudo code):

#------------------------------------------------------------------
package Insteon_base;

use X10_Interface;
@Insteon_PLU::ISA = ('X10_Interface');

sun parse_scmds {
	:  # Code goes here
}
return 1;

#------------------------------------------------------------------
# USB version:
package Insteon_PLU;

use Insteon_base;
@Insteon_PLU::ISA = ('Insteon_base');

check_for_data() {
   $data = $::Generic_Devices{$port_name}{data}; # It's a USB device
   @buf = unpack('(C2)*', $data);
   @d = deframe(@buf); # not done is Serial
   parse_scmds(@d);
}

#------------------------------------------------------------------
# Serial version:
package Insteon_PLS;

use Insteon_base;
@Insteon_PLS::ISA = ('Insteon_base');

Check_for_data() {
   $data = $main::Serial_Ports{iplcs}{data}; # It's a Serial device
   @buf = unpack('(C2)*', $data);
   parse_scmds(@d);
}

#------------------------------------------------------------------

If I use code similar to the above I get:

Undefined subroutine &Insteon_PLU::deframe called at /usr/local/mh/bin/../lib/Insteon_PLU.pm line 161.

I think Gregg was telling me that I had to reference the object
(such as using $self) to resolve this.

BTW, what does this do?

@Insteon_PLS::ISA = ('Insteon_base');

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

On Fri, 28 Sep 2007, Gregg Liming wrote:

> Hi Jason,
>
> Quoting Jason Sharpee (9/27/07 7:46 AM):
>
>> However, I am not translating the status_request result.  I tried it out
>> just now on my test device and can easily see where it is responding with
>> a command1 '00' and a command2 with a hex level '00-FF'.  Should be no
>> more than a 5 minute change to the code and ill see if I can add that this
>> weekend as well.
>
> While you're making mods, would you consider applying the attached diff
> (or something of comparable outcome) to Insteon_Device so that instances
> "play nice" w/ your Light_Item.pm?  Note that I have m_write default to
> 1 so that "transmit only" instances would have to: $obj->writable(0);
> I'm not opposed to defaulting the other way so long as writable exists.
>
> On a related note, do you have plans for addressing/implementing the
> Insteon-specific (non-x10) ALL-Linking capabilities?  I'm quite
> interested in anything along these lines and would be happy to
> contribute (code, test, etc.) anyway that would help.
>

Gregg, thanks for the patch (I tossed too much out on my cleaup).  I 
checked in support for receiving status requests, cleaned up the debug 
messages, and added your patch.

As I am not an Insteon user myself so I only intended the Insteon code to 
kick off efforts in this realm by others that do use it.  I am not 
planning on making any more changes to that code, so anyone is welcome to 
make changes directly in SVN.  If anyone has questions on the 
implementation feel free to contact me, however, I am going to start 
looking into an xAP device type.

Once again, I would like to thank everyone for their help in getting this 
up and running!

-J

Neil Cherry wrote:
> I have a bunch of sub's that are exactly the same in two of my modules.
> 
> PLU 			PLS
> -----------------------	-----------------------
> inherit X10_Interface	Inherit Generic_Item
> package Event_queue	package Event_queue	<- Exact same code
> Insteon_Interface code	Insteon_Interface code	<- Exact same code
> PLU dependent code	PLS dependent code
> -----------------------	-----------------------

The OO way of looking after this is to have a single class, perhaps called
Insteon_Base, that contains all of the methods/data that are common between
the two interfaces.  Two additional classes would inherit from Insteon_Base
and add the interface specific stuff.

Is &Parse_scmds specific to Insteon?  If so, then it should go in
Insteon_Base.  If it is a general purpose function, then it should go in a
general utility library.

Matt

-- 
GPG Key ID: 722441BA
MisterHouse Wiki: http://misterhouse.wikispaces.com/

> >> While off topic I'd be interested to hear what's available in other
> >> parts of the world. Always useful information!
> >
> > I'm in Australia.  I've purchased a heap of battery-powered X10 RF
> devices
> > (mainly MS-13, DS-10, SS-13 and a palm-pad) from the UK because both
> > countries use 433Mhz for the RF communications.
> >
> > As for the mains side of things, Australia uses 240VAC @ 50MHz and the
> UK
> > uses something similar but the plugs a physically different so I've
> never
> > bothered with them.
> 
> Do you have any other HA protocols there? Example Europe has EIB.
> 
> BTW, I think EIB has been renamed but I can't remember what name
> off the top of my head (it's KNX).
> 
> Thanks

C-bus is around and there's at least one company that sells KNX/EIB here.

I'm not aware of any one selling Insteon systems.

Quoting Neil Cherry (9/29/07 12:39 AM):
> Gregg Liming wrote:
>> Quoting Neil Cherry (9/28/07 6:37 PM):
>>> I just ordered a RemoteLinc Starter kit. Looks like Insteon has
>>> RF support. I think I know how to make the RF device work with
>>> MH like the X10 RF (just link the RemoteLinc to the PLC). I did
>>> something like that with my friends ControLinc and his PLC.
>>>
>>> I know the RemoteLinc and the SignaLinc (the RF bridge) don't
>>> work together. The kit has 2 Access Points (looks like the
>>> SignaLinc) to support the RemoteLinc. Insteon here I come!
>> AFAIK, detecting transmits from the remotelinc will require an ALL-link
>> (or whatever it's called in the PLC world) where the remotelinc is a
>> sender and the PLC/PLM is a (or one of the) responder(s).  Otherwise,
>> there's no guarantee of reception much like any other non-PLC/PLM
>> generated event.
> 
> My understanding is that the Remote link requires an extended
> command that is not supported by the SignaLinc, that's OK. I
> just hope that the SignaLincs can still be used in some other
> way.

Right--that's why they had a trade-in program to trade the SignaLincs
for "access points"--which are supposed to do the same thing.  FWIW: I
just received my plm today and have been aggressively resetting all
current insteon devices to factory to wipe out their x10 settings and be
insteon only.  So far, the access points are doing their job wrt
repeating as needed across the mains.  The speed/reliability of what I
was accustomed to (x10) and now insteon is very noticeable.

Gregg

Gregg Liming wrote:
> Quoting Neil Cherry (9/28/07 6:37 PM):
>> I just ordered a RemoteLinc Starter kit. Looks like Insteon has
>> RF support. I think I know how to make the RF device work with
>> MH like the X10 RF (just link the RemoteLinc to the PLC). I did
>> something like that with my friends ControLinc and his PLC.
>>
>> I know the RemoteLinc and the SignaLinc (the RF bridge) don't
>> work together. The kit has 2 Access Points (looks like the
>> SignaLinc) to support the RemoteLinc. Insteon here I come!
> 
> AFAIK, detecting transmits from the remotelinc will require an ALL-link
> (or whatever it's called in the PLC world) where the remotelinc is a
> sender and the PLC/PLM is a (or one of the) responder(s).  Otherwise,
> there's no guarantee of reception much like any other non-PLC/PLM
> generated event.

My understanding is that the Remote link requires an extended
command that is not supported by the SignaLinc, that's OK. I
just hope that the SignaLincs can still be used in some other
way. I'll get my hands on the device in a week or so. I hope
by then I can send Insteon commands. I can receive Insteon
commands but I'm not really interpreting the full command
yet. Worse comes to worse I should be able to rip apart the
SignaLinc and use it as a hardware Dev. Kit.

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

Quoting Neil Cherry (9/28/07 6:37 PM):
> I just ordered a RemoteLinc Starter kit. Looks like Insteon has
> RF support. I think I know how to make the RF device work with
> MH like the X10 RF (just link the RemoteLinc to the PLC). I did
> something like that with my friends ControLinc and his PLC.
> 
> I know the RemoteLinc and the SignaLinc (the RF bridge) don't
> work together. The kit has 2 Access Points (looks like the
> SignaLinc) to support the RemoteLinc. Insteon here I come!

AFAIK, detecting transmits from the remotelinc will require an ALL-link
(or whatever it's called in the PLC world) where the remotelinc is a
sender and the PLC/PLM is a (or one of the) responder(s).  Otherwise,
there's no guarantee of reception much like any other non-PLC/PLM
generated event.

Gregg

Quoting Gregg Liming (9/28/07 11:35 PM):

> The following is what I use for this very purpose as it will do "state
> tracking based upon "hits". 

I should give proper credit for some ideas "repurposed" from comments
Jason had provided some time ago.  In particular, I liked the notion of
"barely dimming" the outside light at the first motion detect and then
backing off if additional motion events were not detected.  As I recall,
Jason was concerned about not annoying neighbors w/ excess outside light
events.  But, I was thinking of it more like a snake rattling it's tail
as a warning--any would-be crook is likely to be a bit concerned about
exterior lighting that starts dim and becomes brighter as he/she
lingers.  In my case, I also deliberately wanted gradual dimming to
avoid camera blooming (which could cause secondary false positives).  As
it turns out, guests like it the most as their eyes may have become
slightly accustomed to the dark and appreciate the gradual increase as
they approach.

Gregg

Quoting Neil Cherry (9/28/07 11:34 PM):

> I was wonder if a simple:
> 
> package xyz;
> 
> my $blah;
> 
> is private to the inheriting name space (Insteon_PLU and Insteon_PLS)

yes; # my is mine; not yours

> or
> whether it visible through out the MH program?

our $blah; # freely gives blah to everyone

> I remember a little about my OOP but Perl is a bit confusing.

There are lots of "convenience features" in mh that hide such.  IMO,
learning OOP in mh/perl is more a challenge than learning OOP perl.
It's also possibly fair to think of it (Perl as a whole) as being more
"object like" than "object oriented" (unless you ignore most of the
modern languages).

Gregg

Gregg Liming wrote:
> Quoting Neil Cherry (9/28/07 11:21 PM):
> 
>> This sound like I can move the parse_scmds sub outside the package
>> and then could call it like a normal function. Parse_scmds is
>> not a method. You pass it a buffer and then call other sub's.
> 
> Yes--this sounds like what one might refer to as "static" in other
> languages i.e., not specific to any instance/object.  There are lots of
> usages w/i mh of this.

Excellent, I have a couple of books on OOP for Perl but I'll get to
that later. HA code is more important now! :-) (Oh that's going to
leave a mark ;-).

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

Quoting Garry Doucette (9/28/07 6:54 PM):
> Hi Guys
> 
> I have a sensor to detect motion at my front door. I have MH announce
> there's motion when the detector is triggered. 
> 
> The problem is if there is a person standing there the sensor will trigger
> several times over with repeated announcements.

I had a similar problem--but slightly worse: the first trigger might be
a false positive (blowing "stuff"; cat; etc.)

> I was trying to figure out how I could have the event time out after
> triggered and only make an announcement if there is motion after say every 5
> or 10 seconds.
> 
> I tried the get_idle_time and the time_idle($time) methods but they didn't
> seem to work.
> 
> What would be the best approach to deal with this in code?
> 

The following is what I use for this very purpose as it will do "state
tracking based upon "hits".  Unfortunately, it might be more than you
want and isn't commented.  It does remind me that I want/need to do
something more generalized that also allows for "sensor fusion" (e.g.,
hits for the same space but from other sensors (e.g., PIRs and
zoneminder camera hits).  The Occupancy/Motion/Presence code could also
be used; but was insufficient for my specific case (here) as I wanted
control over the thresholds in transitioning between acquisition/detect
states.  FWIW: I am a very big fan/user of the OMP code--so, the above
comment is very much an exception.

Gregg

---------- code example ------------


$motion_detector=new Generic_Item;
$enable_visitor_notification = new Generic_Item;

my ($acquire_timeout, $inactive_timeout, $departure_timeout, $acquire_hits);
if ($Reload) {


$motion_detector->set_states('inactive','acquiring','firstactive','continuedactive','departure_block');
   $motion_detector->set('inactive');
   $motion_detector->hidden(1);
   $motion_detector->tie_event('print "front porch detector state set to
$state\n"');
   $acquire_timeout=60;
   $inactive_timeout=60;
   $departure_timeout=420;
   $acquire_hits=1;
   $enable_visitor_notification->set(ON);
}

$visitor_notification_vc = new Voice_Cmd 'Turn visitor notification
[on,off]';
if (defined($state = said $visitor_notification_vc)) {
        $enable_visitor_notification->set(ON) if $state eq 'on';
        $enable_visitor_notification->set_with_timer(OFF, 3600, ON) if
$state eq 'off';
}

$inquire_visitor_notification_vc = new Voice_Cmd 'Inquire visitor
notification';
if (defined($state = said $inquire_visitor_notification_vc)) {
        respond "Visitor notification is on" if
$enable_visitor_notification->state eq ON;
        respond "Visitor notification is off" if
$enable_visitor_notification->state eq OFF;
}

$motion_detector->tie_event('&announce_visitor() if $state eq
"firstactive"');
#$motion_detector->tie_event('$front_porch_light->set_with_timer(ON,
120, OFF) if (($duskdawn_photocell->state eq "dark") and ($state eq
"inactive") and !($Startup or $Reload))');

if ($front_door->state_now eq 'open') {
        print "Setting motion_detector state to departure_block for the
next $departure_timeout seconds\n";
        $motion_detector->set_with_timer('departure_block',
$departure_timeout, 'inactive');
}

if (($front_porch_x10_sensor->state_now eq "motion") &&
($motion_detector->state ne 'departure_block')) {
        if ($motion_detector->state() eq 'inactive') {

$motion_detector->set_with_timer('acquiring',$acquire_timeout, 'inactive');
                $motion_detector->set_count(1);
                if ($duskdawn_photocell->state eq 'dark') {
print "turning on front_porch_light on 20%\n";
                        $front_porch_light->set('20%') if
$front_porch_light->state eq OFF;
                }
        } elsif ($motion_detector->state() eq 'acquiring') {
                $motion_detector->incr_count();
                my $local_count = $motion_detector->get_count();
                if ($local_count > $acquire_hits) {
                        $motion_detector->set('firstactive');
                        if ($duskdawn_photocell->state eq 'dark') {
                                set $front_porch_light '100%';
                        }
                }
        } else {

$motion_detector->set_with_timer('continuedactive',$inactive_timeout,'inactive');
        }
} elsif ($motion_detector->state_now eq 'inactive') {
   if ($front_porch_light->state ne OFF) {
      $front_porch_light->set_with_timer($front_porch_light->state, 120,
OFF);
   }
}

sub announce_visitor {
        my $parms = @_;
        if ($enable_visitor_notification->state eq ON) {
                speak "A visitor has arrived at the front door";
        }
}

Gregg Liming wrote:
> Quoting Neil Cherry (9/28/07 5:35 PM):
>> I'm working on fixing the iplcs code (since it's mostly written
>> and mostly working why not). Since the Insteon Serial and USB PLCs
>> share a lot of the same code I thought I'd create a shared module.
>> What if I want a local variable that is persistent between function
>> calls? 
> 
> Persistence should be handled by a method (that looks like a property)
> of the class.  So, something like $obj->my_property = 'someval' can
> allow $obj->my_property to be used across successive calls provided that
> the ref to $obj isn't dropped/trashed.

Thanks, that's what I expected. I'll add it to th object and add
methods to access it.

>> Do I just type my $blah and both PLCs will have they're own
>> local copy or do I need to keep a copy in the PLC object so I don't
>> collide?
> 
> I don't quite understand the question.  Is sounds like whether you're
> concerned about whether the property is specific to the object or is
> static to the class (like a Singleton pattern).  Assuming the former,
> then ensure that the class always refs the property via $self; if the
> latter, then ensure that the property is properly initialized at startup
> and refs to $self don't apply.

I was wonder if a simple:

package xyz;

my $blah;

is private to the inheriting name space (Insteon_PLU and Insteon_PLS) or
whether it visible through out the MH program?

I remember a little about my OOP but Perl is a bit confusing. I
still have to learn how OOP works with Perl. I've used C++ (not
my favorite) and Java (much better).

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

Quoting Neil Cherry (9/28/07 11:21 PM):

> This sound like I can move the parse_scmds sub outside the package
> and then could call it like a normal function. Parse_scmds is
> not a method. You pass it a buffer and then call other sub's.

Yes--this sounds like what one might refer to as "static" in other
languages i.e., not specific to any instance/object.  There are lots of
usages w/i mh of this.

Gregg

Gregg Liming wrote:
> Quoting Neil Cherry (9/28/07 10:25 PM):
>> I have a bunch of sub's that are exactly the same in two of my modules.
>>
>> PLU 			PLS
>> -----------------------	-----------------------
>> inherit X10_Interface	Inherit Generic_Item
>> package Event_queue	package Event_queue	<- Exact same code
>> Insteon_Interface code	Insteon_Interface code	<- Exact same code
>> PLU dependent code	PLS dependent code
>> -----------------------	-----------------------
>>
>> I've got:
>>
>> package Insteon_PLU;
>>
>> @Insteon_PLU::ISA = ('X10_Interface')
>> use Insteon_Interface; # contains sub parse_cmds
>>
>> when I run the code I get this:
>>
>> Undefined subroutine &Insteon_PLU::parse_scmds called
>>      at /usr/local/mh/bin/../lib/Insteon_PLU.pm line 286.
> 
> Is parse_cmds a method of an Insteon_Interface object or is it just a
> utility method?  If the former, then a ref to the object is require;
> but, if the latter, then a fully qualified ref to the namespace is
> required: &Insteon_Interface::parse_scmds.  Likewise, if the former is
> truly desired to be common (and therefore inherited across multiple
> classes/packages) then you should inherit Insteon_PLU from
> Insteon_Interface (which should likewise inherit from X10_Interface).
> The obvious rule is that if parse_scmds depend on $self, then it must
> observe an inheritance policy.

This sound like I can move the parse_scmds sub outside the package
and then could call it like a normal function. Parse_scmds is
not a method. You pass it a buffer and then call other sub's.

Thanks

-- 
Linux Home Automation         Neil Cherry       nc...@li...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies