MisterHouse: Home Automation with Perl

To disable, simply blank out the web_refresh line, so it would be

web_refresh =

to change the time, change the 600 to something else... The 600 is
seconds so the example starts the screen saver in 10 minutes.


On 9/6/07, Michael Stovenour <michael@...> wrote:
> I am trying to disable the photo frame screen saver.
> Should the photo_time_startup mh.ini parameter work?  I can not find any
> reference to it in the mh files.  It appears that this mh.ini line actually
> controls the behavior:
> web_refresh = <meta http-equiv='Refresh'
> content="600;url=/misc/photos.shtml">
> What is the correct way to disable or change the time of the photo start
> time?
> Michael
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
>

OK, I thought it was that easy, but I saw references to the other parameter.

-----Original Message-----
From: misterhouse-users-bounces@...
[mailto:misterhouse-users-bounces@...] On Behalf Of Tom
Sent: Thursday, September 06, 2007 3:01 PM
To: The main list for the MisterHouse home automation program
Subject: Re: [mh] Changing Photo Frame start time

To disable, simply blank out the web_refresh line, so it would be

web_refresh =

to change the time, change the 600 to something else... The 600 is
seconds so the example starts the screen saver in 10 minutes.


On 9/6/07, Michael Stovenour <michael@...> wrote:
> I am trying to disable the photo frame screen saver.
> Should the photo_time_startup mh.ini parameter work?  I can not find any
> reference to it in the mh files.  It appears that this mh.ini line
actually
> controls the behavior:
> web_refresh = <meta http-equiv='Refresh'
> content="600;url=/misc/photos.shtml">
> What is the correct way to disable or change the time of the photo start
> time?
> Michael
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ________________________________________________________
> To unsubscribe from this list, go to:
http://sourceforge.net/mail/?group_id=1365
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
________________________________________________________
To unsubscribe from this list, go to:
http://sourceforge.net/mail/?group_id=1365

Hi All,

    Because a couple of people have been asking about status:

Whats done:
- I just got my PLM two days ago.
- I have generated a base class for the device based on the UPB code.

Whats to come:
- I will be trying to get X10 working this weekend.
- I have an old Insteon switch that I dug out of a customers home (wasnt 
really ever wired into their HA system) that I will try to test some basic 
Insteon commands with in the following weeks.
- Documentation / Wiki

Beta Testing:
- I will be commiting code to SVN as a checkpoint system in my 
development.   Anyone that is interested can pull down the latest code and 
try it out when I get to my first checkpoint.  I will not be able to 
respond to questions on how to use it for the short term, so please check 
out the code when it appears for usage examples etc.

Thanks for your interest,
-J

Well I just found out tonight that the CM11 doesnt play well with my PLM 
in the same socket.  I plugged the PLM into the back of the CM11.   Anyone 
else run into that?  Either that or my CM11 just gave out on its own. :(

On Thu, 6 Sep 2007, Jason Sharpee wrote:

>
> Hi All,
>
>    Because a couple of people have been asking about status:
>
> Whats done:
> - I just got my PLM two days ago.
> - I have generated a base class for the device based on the UPB code.
>
> Whats to come:
> - I will be trying to get X10 working this weekend.
> - I have an old Insteon switch that I dug out of a customers home (wasnt
> really ever wired into their HA system) that I will try to test some basic
> Insteon commands with in the following weeks.
> - Documentation / Wiki
>
> Beta Testing:
> - I will be commiting code to SVN as a checkpoint system in my
> development.   Anyone that is interested can pull down the latest code and
> try it out when I get to my first checkpoint.  I will not be able to
> respond to questions on how to use it for the short term, so please check
> out the code when it appears for usage examples etc.
>
> Thanks for your interest,
> -J
>
>
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
>
>

Jason Sharpee wrote:
> Hi All,
> 
>     Because a couple of people have been asking about status:
> 
> Whats done:
> - I just got my PLM two days ago.
> - I have generated a base class for the device based on the UPB code.
> 
> Whats to come:
> - I will be trying to get X10 working this weekend.
> - I have an old Insteon switch that I dug out of a customers home (wasnt 
> really ever wired into their HA system) that I will try to test some basic 
> Insteon commands with in the following weeks.
> - Documentation / Wiki
> 
> Beta Testing:
> - I will be commiting code to SVN as a checkpoint system in my 
> development.   Anyone that is interested can pull down the latest code and 
> try it out when I get to my first checkpoint.  I will not be able to 
> respond to questions on how to use it for the short term, so please check 
> out the code when it appears for usage examples etc.

Can you share the class? My new PLCs are on their way. BTW, the
PLM doesn't do Insteon extended commands (this is not a concern
for most Insteon use so don't panic). Bob's ilink code is
interesting unfortunately my software crippled PLCs are not
cooperating though I can write to the EEPROM now so I may be
able to resurrect them. I can easily talk to the USB with my
uread and uwrite functions.

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

Jason Sharpee wrote:
> Well I just found out tonight that the CM11 doesnt play well with my PLM 
> in the same socket.  I plugged the PLM into the back of the CM11.   Anyone 
> else run into that?  Either that or my CM11 just gave out on its own. :(

Nothing seems to work well with the pass through so don't use it.
The CM11A may not work well with the Insteon PLC as Insteon tends
to deaden the X10 signal.

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

On Thu, 6 Sep 2007, Neil Cherry wrote:

> Jason Sharpee wrote:
>> Hi All,
>>
>>     Because a couple of people have been asking about status:
>>
>> Whats done:
>> - I just got my PLM two days ago.
>> - I have generated a base class for the device based on the UPB code.
>>
>> Whats to come:
>> - I will be trying to get X10 working this weekend.
>> - I have an old Insteon switch that I dug out of a customers home (wasnt
>> really ever wired into their HA system) that I will try to test some basic
>> Insteon commands with in the following weeks.
>> - Documentation / Wiki
>>
>> Beta Testing:
>> - I will be commiting code to SVN as a checkpoint system in my
>> development.   Anyone that is interested can pull down the latest code and
>> try it out when I get to my first checkpoint.  I will not be able to
>> respond to questions on how to use it for the short term, so please check
>> out the code when it appears for usage examples etc.
>
> Can you share the class? My new PLCs are on their way. BTW, the

As soon as I get to a point where I can verify the serial I/O routines, i 
will check-in.

> PLM doesn't do Insteon extended commands (this is not a concern
> for most Insteon use so don't panic). Bob's ilink code is

Really? Not sure what an extended command is/does for insteon.  Im not 
sure why they make their protocol so complicated (trying to avoid patent 
on X10?)

Third bullet point on: http://www.smarthome.com/2412s.html

> interesting unfortunately my software crippled PLCs are not
> cooperating though I can write to the EEPROM now so I may be
> able to resurrect them. I can easily talk to the USB with my
> uread and uwrite functions.

I cringe at the thought of all the work I spent in trying to get my
PLC working years ago.  Im really not much interested in the Insteon
part of these devices (if they added a wireless PIR then that would be a 
different story).

Once I get X10 going, Im going to give the insteon command set another 
good 'ol college try, but I dont have much ambition if I run into trouble 
again.  My UPB systems are working really well especially with the new 
low-delay switches they came out with this year.

Jason Sharpee wrote:
> On Thu, 6 Sep 2007, Neil Cherry wrote:
> 
>> Jason Sharpee wrote:
>>> Hi All,
>>>
>>>     Because a couple of people have been asking about status:
>>>
>>> Whats done:
>>> - I just got my PLM two days ago.
>>> - I have generated a base class for the device based on the UPB code.
>>>
>>> Whats to come:
>>> - I will be trying to get X10 working this weekend.
>>> - I have an old Insteon switch that I dug out of a customers home (wasnt
>>> really ever wired into their HA system) that I will try to test some basic
>>> Insteon commands with in the following weeks.
>>> - Documentation / Wiki
>>>
>>> Beta Testing:
>>> - I will be commiting code to SVN as a checkpoint system in my
>>> development.   Anyone that is interested can pull down the latest code and
>>> try it out when I get to my first checkpoint.  I will not be able to
>>> respond to questions on how to use it for the short term, so please check
>>> out the code when it appears for usage examples etc.
>> Can you share the class? My new PLCs are on their way. BTW, the
> 
> As soon as I get to a point where I can verify the serial I/O routines, i 
> will check-in.
> 
>> PLM doesn't do Insteon extended commands (this is not a concern
>> for most Insteon use so don't panic). Bob's ilink code is
> 
> Really? Not sure what an extended command is/does for insteon.  Im not 
> sure why they make their protocol so complicated (trying to avoid patent 
> on X10?)
> 
> Third bullet point on: http://www.smarthome.com/2412s.html
> 
>> interesting unfortunately my software crippled PLCs are not
>> cooperating though I can write to the EEPROM now so I may be
>> able to resurrect them. I can easily talk to the USB with my
>> uread and uwrite functions.
> 
> I cringe at the thought of all the work I spent in trying to get my
> PLC working years ago.  Im really not much interested in the Insteon
> part of these devices (if they added a wireless PIR then that would be a 
> different story).
> 
> Once I get X10 going, Im going to give the insteon command set another 
> good 'ol college try, but I dont have much ambition if I run into trouble 
> again.  My UPB systems are working really well especially with the new 
> low-delay switches they came out with this year.

The dev docs are more thorough than previous but still lack lots of
details. Basically it seems like the usb likes no more than 8 bytes
at a time but it seems like 4 bytes at a time works very well. With
a 20ms delay (~5ms/byte). The serial works similarly, still an 8
byte buffer. Bob's work on the ilink seems to work (again not with
my setup).



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

Neil Cherry wrote:

> a 20ms delay (~5ms/byte). The serial works similarly, still an 8
> byte buffer. Bob's work on the ilink seems to work (again not with
> my setup).

Oops forgot the link:

http://www.bobsplace.com/ilinks/

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

whew. Im pretty excited!  After a good solid 4-5 hours I finally got my 
test X10 appliance module working and am receiving palmpad x10 data. (I 
even turned on an Insteon switchlinc.. shhh. dont tell anyone ;) ) Most 
of that time was re-understanding how MH treats serial objects (again)

Now that my poc is finished I am still trying to think of how this should 
be used in MH.  My inclination is to use it just like the UPB PIM as a 
seperate interface all to its own (not integrated into the slipstream X10 
pipeline in MH).  If I continue on this path though you will need to 
"assign" X10_Items and Insteon_Items, etc to the PLM.  This is pretty 
necessary when UPB and Insteon arent anything like X10, however, for X10 
this could be more "integrated".  Im going to look at the X10_Item object 
a little more closely and see what can be done.

I must say this PLM is a heck of a lot nicer to deal with than the PLC.

Hopefully Ill have this worked out and have some code to share mid-end of 
this week.

-J

Jason Sharpee wrote:
> whew. Im pretty excited!  After a good solid 4-5 hours I finally got my 
> test X10 appliance module working and am receiving palmpad x10 data. (I 
> even turned on an Insteon switchlinc.. shhh. dont tell anyone ;) ) Most 
> of that time was re-understanding how MH treats serial objects (again)
> 
> Now that my poc is finished I am still trying to think of how this should 
> be used in MH.  My inclination is to use it just like the UPB PIM as a 
> seperate interface all to its own (not integrated into the slipstream X10 
> pipeline in MH).  If I continue on this path though you will need to 
> "assign" X10_Items and Insteon_Items, etc to the PLM.  This is pretty 
> necessary when UPB and Insteon arent anything like X10, however, for X10 
> this could be more "integrated".  Im going to look at the X10_Item object 
> a little more closely and see what can be done.
> 
> I must say this PLM is a heck of a lot nicer to deal with than the PLC.
> 
> Hopefully Ill have this worked out and have some code to share mid-end of 
> this week.

This could be a great week for me, I have my new PLCs (Serial and
USB). I've managed to get the Linux Device Driver example serial
drivers working (I need these to learn to write serial/tty drivers
for the USB devices), I can now ride my bicycle again (I've been
off for a month) and I may get sample code to play with! :-)

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

It appears the X10 Items have an interface selection already built into 
them, so I am intergrating via that method with some success.  Now 
I just have to translate the Xxxx codes and it will be finished.

Example In items.mht:
INSTEON_PLM, myPLM

X10SL, L5, x10_kitchen_light, , myPLM

So far I have modifications in:
read_table_A (checked in)
X10_Items (wip)
Insteon_PLM (wip)
Insteon_Device (wip)

Should I dump received X10 into the generic X10 pipeline 
&::parse_serial_data or just limit it to changing the objects affected?

-J

On Sun, 9 Sep 2007, Neil Cherry wrote:

> Jason Sharpee wrote:
>> whew. Im pretty excited!  After a good solid 4-5 hours I finally got my
>> test X10 appliance module working and am receiving palmpad x10 data. (I
>> even turned on an Insteon switchlinc.. shhh. dont tell anyone ;) ) Most
>> of that time was re-understanding how MH treats serial objects (again)
>>
>> Now that my poc is finished I am still trying to think of how this should
>> be used in MH.  My inclination is to use it just like the UPB PIM as a
>> seperate interface all to its own (not integrated into the slipstream X10
>> pipeline in MH).  If I continue on this path though you will need to
>> "assign" X10_Items and Insteon_Items, etc to the PLM.  This is pretty
>> necessary when UPB and Insteon arent anything like X10, however, for X10
>> this could be more "integrated".  Im going to look at the X10_Item object
>> a little more closely and see what can be done.
>>
>> I must say this PLM is a heck of a lot nicer to deal with than the PLC.
>>
>> Hopefully Ill have this worked out and have some code to share mid-end of
>> this week.
>
> This could be a great week for me, I have my new PLCs (Serial and
> USB). I've managed to get the Linux Device Driver example serial
> drivers working (I need these to learn to write serial/tty drivers
> for the USB devices), I can now ride my bicycle again (I've been
> off for a month) and I may get sample code to play with! :-)
>
> Thanks!
>

Jason Sharpee wrote:
> It appears the X10 Items have an interface selection already built into 
> them, so I am intergrating via that method with some success.  Now 
> I just have to translate the Xxxx codes and it will be finished.
> 
> Example In items.mht:
> INSTEON_PLM, myPLM
> 
> X10SL, L5, x10_kitchen_light, , myPLM
> 
> So far I have modifications in:
> read_table_A (checked in)
> X10_Items (wip)
> Insteon_PLM (wip)
> Insteon_Device (wip)
> 
> Should I dump received X10 into the generic X10 pipeline 
> &::parse_serial_data or just limit it to changing the objects affected?

I think you should dump it into the X10 pipeline. Wouldn't the
Insteon class just extend the X10 class? Sorry but this was one
of the points where my lack of knowledge of Perl's OO programming
confused me. I often wondered if I could extend SerialPort.pm
by using it as the parent class then just overload the functions
that needed the tty layer. That would simplify the USB problem
within Linux as my device drivers wouldn't need to be totally
rewritten.

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

Neil Cherry wrote:
> I think you should dump it into the X10 pipeline. Wouldn't the
> Insteon class just extend the X10 class? Sorry but this was one
> of the points where my lack of knowledge of Perl's OO programming
> confused me. I often wondered if I could extend SerialPort.pm
> by using it as the parent class then just overload the functions
> that needed the tty layer. That would simplify the USB problem
> within Linux as my device drivers wouldn't need to be totally
> rewritten.
> 

One of the items that made it into 2.103 was my restructuring of the device
classes to make this easier to accomplish.  I.e. support things that aren't
X10 and aren't serially connected.

As Jason has discovered, X10_Item already supports searching through a
selection of device types to find the right hardware interface so that basic
infrastructure is in place.

If you recall, quite a while ago I started an effort to go through phase 2
of the class redesign to clean up the relationships between classes.  There
are still too many assumptions of using X10 protocols and/or serial
connectivity.  I ran into a personal time crunch so nothing actually
happened but the related page is still on the wiki:

http://misterhouse.wikispaces.com/NewClasses

I personally think that it would be a good idea to first fix the class
structure so that a more logical place would exist before adding new
hardware and protocol support.  However, I don't want to push my agenda and
prevent new hardware support from being added - new hardware support is
awesome.  Consider this a friendly reminder of this stalled project.

Matt


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

Matthew Williams wrote:
> Neil Cherry wrote:

> http://misterhouse.wikispaces.com/NewClasses
> 
> I personally think that it would be a good idea to first fix the class
> structure so that a more logical place would exist before adding new
> hardware and protocol support.  However, I don't want to push my agenda and
> prevent new hardware support from being added - new hardware support is
> awesome.  Consider this a friendly reminder of this stalled project.

If I create a new module called DevicePort and I have 'use SerialPort'
will that make my module inherit from Serialport? If yes then I should
be able to replace SerialPort method new with my own so I can open
the device port accordingly. Assuming all else is equal I would then
be able to treat a device port like a SerialPort for Tx/Rx of data.
Does that sound correct?

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

Neil Cherry wrote:
> If I create a new module called DevicePort and I have 'use SerialPort'
> will that make my module inherit from Serialport? If yes then I should
> be able to replace SerialPort method new with my own so I can open
> the device port accordingly. Assuming all else is equal I would then
> be able to treat a device port like a SerialPort for Tx/Rx of data.
> Does that sound correct?
> 

You may instead want to have a "use Device_Item" as it will allow you to
open raw files and Device_Item.pm contains all of the methods that you
should require.  For testing purposes, I created a named pipe in the O/S and
the Device_Item happily read and wrote to the pipe.

Let me know if you run into any problems.  AFAIK, you'll be the first
person, besides myself, to extend Device_Item.

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

Matthew Williams wrote:
> Neil Cherry wrote:
>> If I create a new module called DevicePort and I have 'use SerialPort'
>> will that make my module inherit from Serialport? If yes then I should
>> be able to replace SerialPort method new with my own so I can open
>> the device port accordingly. Assuming all else is equal I would then
>> be able to treat a device port like a SerialPort for Tx/Rx of data.
>> Does that sound correct?
>>
> 
> You may instead want to have a "use Device_Item" as it will allow you to
> open raw files and Device_Item.pm contains all of the methods that you
> should require.  For testing purposes, I created a named pipe in the O/S and
> the Device_Item happily read and wrote to the pipe.
> 
> Let me know if you run into any problems.  AFAIK, you'll be the first
> person, besides myself, to extend Device_Item.
> 
> Matt

You'll have to pardon me, while I kind of understand OOPs I've not
applied it to Perl. I've only done Java and C++ (ick) so I'll be
asking lots of questions. Can I see you're sample code?

I have a tendency to learn by looking at others work and then trying
to extend it. I think I have a slightly better understanding of what
you were trying to accomplish last time. Then I was too clueless, I'm
still searching for that clue but I'm getting an idea of what it looks
like. :-)

Thanks


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

Neil Cherry wrote:
> 
> You'll have to pardon me, while I kind of understand OOPs I've not
> applied it to Perl. I've only done Java and C++ (ick) so I'll be
> asking lots of questions. Can I see you're sample code?

Sure!  The basic premise for inheritance for PERL is that if a method can't
be found within the current package, then it searches @ISA for other
packages until it finds a method.

Here's some code snipped from X10_Interface, which adds X10 functionality to
Device_Item:

package X10_Interface;

use Device_Item;

@X10_Interface::ISA=('Device_Item');

sub new {
    my ($class, $id, $state, $device_name)=@_;

    my $self = Device_Item->new($id, $state, $device_name);
    bless ($self, $class);
    return $self;
}

The key lines are "use Device_Item", setting @X10_Interface::ISA and then
creating $self using the Device_Item constructor.

Here's how I use Device_Item for my tests:

mh.ini:
test_device=/tmp/testpipe
test_device_datatype=record
test_device_mode=rw

code:

$testDevice= new Device_Item(undef,undef,'test');

if ($state = $testDevice->said) {
    &print_log("test device said $state");
}

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

Matthew Williams wrote:
> Neil Cherry wrote:
>> You'll have to pardon me, while I kind of understand OOPs I've not
>> applied it to Perl. I've only done Java and C++ (ick) so I'll be
>> asking lots of questions. Can I see you're sample code?
> 
> Sure!  The basic premise for inheritance for PERL is that if a method can't
> be found within the current package, then it searches @ISA for other
> packages until it finds a method.
> 
> Here's some code snipped from X10_Interface, which adds X10 functionality to
> Device_Item:
> 
> package X10_Interface;
> 
> use Device_Item;
> 
> @X10_Interface::ISA=('Device_Item');
> 
> sub new {
>     my ($class, $id, $state, $device_name)=@_;
> 
>     my $self = Device_Item->new($id, $state, $device_name);
>     bless ($self, $class);
>     return $self;
> }
> 
> The key lines are "use Device_Item", setting @X10_Interface::ISA and then
> creating $self using the Device_Item constructor.
> 
> Here's how I use Device_Item for my tests:
> 
> mh.ini:
> test_device=/tmp/testpipe
> test_device_datatype=record
> test_device_mode=rw
> 
> code:
> 
> $testDevice= new Device_Item(undef,undef,'test');
> 
> if ($state = $testDevice->said) {
>     &print_log("test device said $state");
> }
> 

That code looks different that what I've been playing with. I'd
better get the latest and greatest. Should I go svn or 2.104?
I'm going to load this up on a second box so as not to mess up
the main box.

Thanks

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

Neil Cherry wrote:
> That code looks different that what I've been playing with. I'd
> better get the latest and greatest. Should I go svn or 2.104?
> I'm going to load this up on a second box so as not to mess up
> the main box.

Yeah, the Device_Item changes happened in 2.103.  I don't recommend 2.103 as
there has been a lot of work in svn since then.  I personally recommend
starting with the 2.104 branch as it is the most stable stuff today.  The
svn URL is:

https://misterhouse.svn.sourceforge.net/svnroot/misterhouse/branches/v2-104

thanks,
Matt

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

I have spent considerable amount of time on the architecture of the 
interface / device classes in mh the last couple of days.  There are 
still a fair mount of work involved in making all of the interfaces work 
generically, work that I am not sure is worth spending on this path.

Challenges that I think remain:
- Protocol (and interface) specific code hanging around in device classes.
- Multiple instances of the same interface or type of protocol.
- Multiprotocol devices (InsteonPLM does both X10 and Insteon)
- Proxy transparency (from what I am seeing there is quite a bit of 
hackish type of things in interfaces to support that)
- A lot of things give me "coding smells" ( re-use, hard coding, etc)

I think I have come to the conclusion that xAP/xPL is probably the best 
way to go for all native interfaces.  These folks have addressed this 
single issue for years and have a pretty nice solution.  Its hard to 
appreciate what they have done, until you try and do it yourself ;)

Unfortunately, I dont have an abundance of time to rewrite what I have 
already started, so I am going to continue down the same path.  I just 
wanted to point out that we should probably go to a distributed interface 
model such as xPL/xAP for all future efforts.  My next project will 
definitely center on this approach.


-J

I have been doing a lot of custom HA code now in C#/mono and xAP/PL would 
also be a great segway to leverage MH functionality.



On Tue, 11 Sep 2007, Matthew Williams wrote:

> Neil Cherry wrote:
>> I think you should dump it into the X10 pipeline. Wouldn't the
>> Insteon class just extend the X10 class? Sorry but this was one
>> of the points where my lack of knowledge of Perl's OO programming
>> confused me. I often wondered if I could extend SerialPort.pm
>> by using it as the parent class then just overload the functions
>> that needed the tty layer. That would simplify the USB problem
>> within Linux as my device drivers wouldn't need to be totally
>> rewritten.
>>
>
> One of the items that made it into 2.103 was my restructuring of the device
> classes to make this easier to accomplish.  I.e. support things that aren't
> X10 and aren't serially connected.
>
> As Jason has discovered, X10_Item already supports searching through a
> selection of device types to find the right hardware interface so that basic
> infrastructure is in place.
>
> If you recall, quite a while ago I started an effort to go through phase 2
> of the class redesign to clean up the relationships between classes.  There
> are still too many assumptions of using X10 protocols and/or serial
> connectivity.  I ran into a personal time crunch so nothing actually
> happened but the related page is still on the wiki:
>
> http://misterhouse.wikispaces.com/NewClasses
>
> I personally think that it would be a good idea to first fix the class
> structure so that a more logical place would exist before adding new
> hardware and protocol support.  However, I don't want to push my agenda and
> prevent new hardware support from being added - new hardware support is
> awesome.  Consider this a friendly reminder of this stalled project.
>
> Matt
>
>
>

Jason Sharpee wrote:
> I have spent considerable amount of time on the architecture of the 
> interface / device classes in mh the last couple of days.  There are 
> still a fair mount of work involved in making all of the interfaces work 
> generically, work that I am not sure is worth spending on this path.

I really can't comment on any of this as I'm not knowledgeable enough
to know what's going on. Your UPB code was pretty much over my head.

> Challenges that I think remain:
> - Protocol (and interface) specific code hanging around in device classes.
> - Multiple instances of the same interface or type of protocol.
> - Multiprotocol devices (InsteonPLM does both X10 and Insteon)

This has my head spinning most right now. I kind of know what to
do it but not how and no way can I spell it out. Doesn't the BHT
support X10 and other things so that may be of some use (or not).

> - Proxy transparency (from what I am seeing there is quite a bit of 
>   hackish type of things in interfaces to support that)
> - A lot of things give me "coding smells" ( re-use, hard coding, etc)

Code smells?

> I think I have come to the conclusion that xAP/xPL is probably the best 
> way to go for all native interfaces.  These folks have addressed this 
> single issue for years and have a pretty nice solution.  Its hard to 
> appreciate what they have done, until you try and do it yourself ;)

I have to agree a lot I just not there yet (stupid book).

> Unfortunately, I dont have an abundance of time to rewrite what I have 
> already started, so I am going to continue down the same path.  I just 
> wanted to point out that we should probably go to a distributed interface 
> model such as xPL/xAP for all future efforts.  My next project will 
> definitely center on this approach.

One more project for the project list. :-)

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

On Wed, 12 Sep 2007, Neil Cherry wrote:

> Jason Sharpee wrote:
>> I have spent considerable amount of time on the architecture of the
>> interface / device classes in mh the last couple of days.  There are
>> still a fair mount of work involved in making all of the interfaces work
>> generically, work that I am not sure is worth spending on this path.
>
> I really can't comment on any of this as I'm not knowledgeable enough
> to know what's going on. Your UPB code was pretty much over my head.
>

The UPB code isnt all that well designed either.  I was originally going 
to base the InsteonPLM off of that, but couldnt bring myself to repeat the 
same mistakes twice.  I was actually inspired to change by examination of 
what Matt was up to with the Device_Item.  When all is said and done 
though, MH was built upon the Cm11 and X10 and that shows through no 
matter the many coats of primer we have added since.

>> Challenges that I think remain:
>> - Protocol (and interface) specific code hanging around in device classes.
>> - Multiple instances of the same interface or type of protocol.
>> - Multiprotocol devices (InsteonPLM does both X10 and Insteon)
>
> This has my head spinning most right now. I kind of know what to
> do it but not how and no way can I spell it out. Doesn't the BHT
> support X10 and other things so that may be of some use (or not).

There are multiprotocol devices in MH, but most of it revolves around X10 
and xxxx.  It would be a fair bit of effort to support xxxx and yyyy on 
the same device.  And it would be hard to target one of two cm11's.  I 
actually have two UPB PIM's (one for each phase).

>
>> - Proxy transparency (from what I am seeing there is quite a bit of
>>   hackish type of things in interfaces to support that)
>> - A lot of things give me "coding smells" ( re-use, hard coding, etc)
>
> Code smells?
>

Things that make my spider sense tingle: 
http://en.wikipedia.org/wiki/Code_smell

Jason Sharpee wrote:
> On Wed, 12 Sep 2007, Neil Cherry wrote:
> 
>> Jason Sharpee wrote:
>>> I have spent considerable amount of time on the architecture of the
>>> interface / device classes in mh the last couple of days.  There are
>>> still a fair mount of work involved in making all of the interfaces work
>>> generically, work that I am not sure is worth spending on this path.
>> I really can't comment on any of this as I'm not knowledgeable enough
>> to know what's going on. Your UPB code was pretty much over my head.
>>
> 
> The UPB code isnt all that well designed either.  I was originally going 
> to base the InsteonPLM off of that, but couldnt bring myself to repeat the 
> same mistakes twice.  I was actually inspired to change by examination of 
> what Matt was up to with the Device_Item.  When all is said and done 
> though, MH was built upon the Cm11 and X10 and that shows through no 
> matter the many coats of primer we have added since.

Yup, but we might need to chip off the lead eventually.

>>> - Multiprotocol devices (InsteonPLM does both X10 and Insteon)
>> This has my head spinning most right now. I kind of know what to
>> do it but not how and no way can I spell it out. Doesn't the BHT
>> support X10 and other things so that may be of some use (or not).
> 
> There are multiprotocol devices in MH, but most of it revolves around X10 
> and xxxx.  It would be a fair bit of effort to support xxxx and yyyy on 
> the same device.  And it would be hard to target one of two cm11's.  I 
> actually have two UPB PIM's (one for each phase).

That I understand, I was think about that for the Insteon, someone
might have enough need to communicate with more than one phase but
I think I'll work on one thing at a time. I may not need much to
talk to the USB device. First I want to play with Matt's code. Once
I understand that I can move forward a bit more. I'm not an expert
programmer so I have to play before proceeding.

>>> - A lot of things give me "coding smells" ( re-use, hard coding, etc)

>> Code smells?

> Things that make my spider sense tingle: 
> http://en.wikipedia.org/wiki/Code_smell

Thanks, that makes more sense now.

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

On Wed, September 12, 2007 16:40, Neil Cherry said:

> That code looks different that what I've been playing with. I'd
> better get the latest and greatest. Should I go svn or 2.104?
> I'm going to load this up on a second box so as not to mess up
> the main box.

Wuss! :) Live life on the edge... piss off the wife!

--
Tim Sailer
Coastal Internet, Inc.
 http://www.buoy.com
631-399-2910

Tim Sailer wrote:
> On Wed, September 12, 2007 16:40, Neil Cherry said:
> 
>> That code looks different that what I've been playing with. I'd
>> better get the latest and greatest. Should I go svn or 2.104?
>> I'm going to load this up on a second box so as not to mess up
>> the main box.
> 
> Wuss! :) Live life on the edge... piss off the wife!

My friends often comment that my wife is going to kill me for this
or that but death is not something I need to worry about. She's
promised to torture me for the rest of my life (which she has
promised will be a long one unless I'm worth more dead). I like
to ride my bicycle on Saturdays, I usual ride centuries (100 miles).
She has said that a century is no excuse for not doing the lawn or
doing her garden work. Just call me E-manual Labor. :-)

-- 
Linux Home Automation         Neil Cherry       ncherry@...
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:
>> You'll have to pardon me, while I kind of understand OOPs I've not
>> applied it to Perl. I've only done Java and C++ (ick) so I'll be
>> asking lots of questions. Can I see you're sample code?
> 
> Sure!  The basic premise for inheritance for PERL is that if a method can't
> be found within the current package, then it searches @ISA for other
> packages until it finds a method.
> 
> Here's some code snipped from X10_Interface, which adds X10 functionality to
> Device_Item:
> 
> package X10_Interface;
> 
> use Device_Item;
> 
> @X10_Interface::ISA=('Device_Item');
> 
> sub new {
>     my ($class, $id, $state, $device_name)=@_;
> 
>     my $self = Device_Item->new($id, $state, $device_name);
>     bless ($self, $class);
>     return $self;
> }

I'll be adding this to ~mh/lib/ but what is its file name in
relation to the rest of this information?

> The key lines are "use Device_Item", setting @X10_Interface::ISA and then
> creating $self using the Device_Item constructor.
> 
> Here's how I use Device_Item for my tests:
> 

> mh.ini:
> test_device=/tmp/testpipe
> test_device_datatype=record
> test_device_mode=rw

What does this do?

> code:
> 
> $testDevice= new Device_Item(undef,undef,'test');
> 
> if ($state = $testDevice->said) {
>     &print_log("test device said $state");
> }

I'll add this to my code directory as file: test_device.pl

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

Neil Cherry wrote:
> 
> I'll be adding this to ~mh/lib/ but what is its file name in
> relation to the rest of this information?

This is already in X10_Interface.pm.  I was only demonstrating how to extend
classes in Perl.

>> mh.ini:
>> test_device=/tmp/testpipe
>> test_device_datatype=record
>> test_device_mode=rw
> 
> What does this do?

This defines the location of the named pipe that the device "test" will be
using in the code below.  It also chooses the record (as opposed to raw)
datatype which wait for CR/LR combinations.  As well, the "mode" is set to
read/write so that the Device_Item will allow both reads and writes,
although I only test reads in the code below.

For your USB stuff, I assume that you are creating a character device file
in /dev.  Let's says its called /dev/neil.  You would point your device
definition to /dev/neil instead of /tmp/testpipe and set datatype to raw.
You could then, once you create the Device_Item, read/write to the USB
device through ->said and ->set.

> 
>> code:
>>
>> $testDevice= new Device_Item(undef,undef,'test');
>>
>> if ($state = $testDevice->said) {
>>     &print_log("test device said $state");
>> }
> 
> I'll add this to my code directory as file: test_device.pl
> 

To use the test device as defined in my original e-mail, you should create
/tmp/testpipe:

# mknod /tmp/testpipe p
# chmod 777 /tmp/testpipe

Then, whenever you write to this pipe, mh will respond with a log message:

# echo Hi there misterhouse > /tmp/testpipe

Matt

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

Matthew Williams wrote:
> Neil Cherry wrote:
>> I'll be adding this to ~mh/lib/ but what is its file name in
>> relation to the rest of this information?
> 
> This is already in X10_Interface.pm.  I was only demonstrating how to extend
> classes in Perl.

Got it, thanks, I've removed the file I created in ~mh/lib.

>>> mh.ini:
>>> test_device=/tmp/testpipe
>>> test_device_datatype=record
>>> test_device_mode=rw
>> What does this do?
> 
> This defines the location of the named pipe that the device "test" will be
> using in the code below.  It also chooses the record (as opposed to raw)
> datatype which wait for CR/LR combinations.  As well, the "mode" is set to
> read/write so that the Device_Item will allow both reads and writes,
> although I only test reads in the code below.

Got it!

> For your USB stuff, I assume that you are creating a character device file
> in /dev.  Let's says its called /dev/neil.  You would point your device
> definition to /dev/neil instead of /tmp/testpipe and set datatype to raw.
> You could then, once you create the Device_Item, read/write to the USB
> device through ->said and ->set.

Got it, I've got some work to do here wrt the usb Perl code..

>>> code:
>>>
>>> $testDevice= new Device_Item(undef,undef,'test');
>>>
>>> if ($state = $testDevice->said) {
>>>     &print_log("test device said $state");
>>> }
>> I'll add this to my code directory as file: test_device.pl
>>
> 
> To use the test device as defined in my original e-mail, you should create
> /tmp/testpipe:
> 
> # mknod /tmp/testpipe p
> # chmod 777 /tmp/testpipe
> 
> Then, whenever you write to this pipe, mh will respond with a log message:
> 
> # echo Hi there misterhouse > /tmp/testpipe

MH sees it but it doesn't read anything from the pipe.

I'm running 2.104, I've added the lines to my ini file. Here's
the startup output:

creating generic device test on /tmp/testpipe

When I do:

# echo Hi there misterhouse > /tmp/testpipe

or

# echo -e "Hi there misterhouse\n" > /tmp/testpipe

I get nothing from the MH print log.

# ls -l /tmp/testpipe
prwxrwxrwx 1 njc njc 0 Sep 14 20:16 /tmp/testpipe

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

Neil Cherry wrote:
> Matthew Williams wrote:
>> Neil Cherry wrote:
>>> I'll be adding this to ~mh/lib/ but what is its file name in
>>> relation to the rest of this information?
>> This is already in X10_Interface.pm.  I was only demonstrating how to extend
>> classes in Perl.
> 
> Got it, thanks, I've removed the file I created in ~mh/lib.
> 
>>>> mh.ini:
>>>> test_device=/tmp/testpipe
>>>> test_device_datatype=record
>>>> test_device_mode=rw
>>> What does this do?
>> This defines the location of the named pipe that the device "test" will be
>> using in the code below.  It also chooses the record (as opposed to raw)
>> datatype which wait for CR/LR combinations.  As well, the "mode" is set to
>> read/write so that the Device_Item will allow both reads and writes,
>> although I only test reads in the code below.
> 
> Got it!
> 
>> For your USB stuff, I assume that you are creating a character device file
>> in /dev.  Let's says its called /dev/neil.  You would point your device
>> definition to /dev/neil instead of /tmp/testpipe and set datatype to raw.
>> You could then, once you create the Device_Item, read/write to the USB
>> device through ->said and ->set.
> 
> Got it, I've got some work to do here wrt the usb Perl code..
> 
>>>> code:
>>>>
>>>> $testDevice= new Device_Item(undef,undef,'test');
>>>>
>>>> if ($state = $testDevice->said) {
>>>>     &print_log("test device said $state");
>>>> }
>>> I'll add this to my code directory as file: test_device.pl
>>>
>> To use the test device as defined in my original e-mail, you should create
>> /tmp/testpipe:
>>
>> # mknod /tmp/testpipe p
>> # chmod 777 /tmp/testpipe
>>
>> Then, whenever you write to this pipe, mh will respond with a log message:
>>
>> # echo Hi there misterhouse > /tmp/testpipe
> 
> MH sees it but it doesn't read anything from the pipe.
> 
> I'm running 2.104, I've added the lines to my ini file. Here's
> the startup output:
> 
> creating generic device test on /tmp/testpipe
> 
> When I do:
> 
> # echo Hi there misterhouse > /tmp/testpipe
> 
> or
> 
> # echo -e "Hi there misterhouse\n" > /tmp/testpipe
> 
> I get nothing from the MH print log.
> 
> # ls -l /tmp/testpipe
> prwxrwxrwx 1 njc njc 0 Sep 14 20:16 /tmp/testpipe
> 

Hmm, works with:

test_device_datatype = raw

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

Neil Cherry wrote:
> Hmm, works with:
> 
> test_device_datatype = raw
> 

Sorry, forgot that the default "break" that signals the end of records is
"\r\n".  Set the datatype back to record and the following should work:

# echo -en "hello there\r\n" > /tmp/testpipe

Now, with the datatype set to raw the Device_Item will immediately report
data through ->said without waiting for the break sequence.  Raw gives you
more control, but you'll have to have your own logic to break up the data
stream into messages or to combine several -> said results into a message.

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

Now I'm happier:

09/14/07 10:06:38 PM iplc device said 
0102000000000000014500000000000001080000000000000102000000000000034a002200000000010200000000000002450800000000000102000000000000024a0100000000000123000000000000

I know that's ugly but it is correct

0102000000000000
0145000000000000
0108000000000000
0102000000000000
034a002200000000
0102000000000000
0245080000000000
0102000000000000
024a010000000000
0123000000000000

02 45 08    => X10 Event
02 4a 00 22 => Addr C3
02 45 08    => X10 Event
02 4a 01 23 => Cmd  COff

Not bad! Now if I can only figure out the Iplc_Item.pm. MH is
looking for 'Can't locate object method "property_changed"'.

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

Neil Cherry wrote:
> Now I'm happier:
> 
> 09/14/07 10:06:38 PM iplc device said 
> 0102000000000000014500000000000001080000000000000102000000000000034a002200000000010200000000000002450800000000000102000000000000024a0100000000000123000000000000
> 
> I know that's ugly but it is correct
> 
> 0102000000000000
> 0145000000000000
> 0108000000000000
> 0102000000000000
> 034a002200000000
> 0102000000000000
> 0245080000000000
> 0102000000000000
> 024a010000000000
> 0123000000000000
> 
> 02 45 08    => X10 Event
> 02 4a 00 22 => Addr C3
> 02 45 08    => X10 Event
> 02 4a 01 23 => Cmd  COff
> 
> Not bad! Now if I can only figure out the Iplc_Item.pm. MH is
> looking for 'Can't locate object method "property_changed"'.
> 

Fixed, I still have lot to learn.

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

Hi All,

Another update.

Last week:
- I spent an unexpectedly large amount of time making the interface work 
with existing X10 objects.
- My perl binary knowledge had faded a bit and was struggling with that 
for a while.  (What I wouldnt give sometimes for a strongly typed perl!)
- I finally have properly formated X10 commands being sent to the 
interface from MH

Currently:
- I am over running the interface! :(   Each action on X10 comprises 
usually of multiple X10 protocol commands.  I am sending all of those 
multipart commands immediately and it appears to be overrunning the 
device and getting an error.
- Forutnately the UPB PIM had the same issue so I am starting to re-use 
some of the queuing code there
- Once I get an X10 light turning on / off from MH, I will do the first 
checkin.

-J

Jason Sharpee wrote:
 > Hi All,
 >
 > Another update.
 >
 > Last week:

 > - I spent an unexpectedly large amount of time making the interface
 >   work with existing X10 objects.

 > - My perl binary knowledge had faded a bit and was struggling with
 >   that for a while.  (What I wouldnt give sometimes for a strongly
 >   typed perl!)

To go from binary (ie serial data) to Perl I like to use:

my @buf = unpack('(C2)*', $data); # Convert raw to valid Perl 'string' ^A => 1

I had been using:

my $bytes = pack('H*',"46016680F7"); # Convert a hex string to raw

 > - I finally have properly formated X10 commands being sent to the
 >   interface from MH

 > Currently: - I am over running the interface! :( Each action on X10
 > comprises usually of multiple X10 protocol commands.  I am sending
 > all of those multipart commands immediately and it appears to be
 > overrunning the device and getting an error. - Forutnately the UPB
 > PIM had the same issue so I am starting to re-use some of the
 > queuing code there - Once I get an X10 light turning on / off from
 > MH, I will do the first checkin.

Are you waiting 1/2 a second between each message (A1 wait 1/2 a second
AON)? The Insteon PLC can't buffer the X10 in between. You end up stepping
on the X10 to transmit.

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

On Sun, 16 Sep 2007, Neil Cherry wrote:

> Jason Sharpee wrote:
> > Hi All,
> >
> > Another update.
> >
> > Last week:
>
> > - I spent an unexpectedly large amount of time making the interface
> >   work with existing X10 objects.
>
> > - My perl binary knowledge had faded a bit and was struggling with
> >   that for a while.  (What I wouldnt give sometimes for a strongly
> >   typed perl!)
>
> To go from binary (ie serial data) to Perl I like to use:
>
> my @buf = unpack('(C2)*', $data); # Convert raw to valid Perl 'string' ^A => 1
>
> I had been using:
>
> my $bytes = pack('H*',"46016680F7"); # Convert a hex string to raw

Thanks for the tip. I had been using pack, but have been unable to do a 
binary OR operation on two packed bytes to combine nibbles. 
Perl seems to be intrinsicly making it some other data type in its 
scalar var.  Really frustrating, but in the end decided to deal with 
everything as a hex string and just pack it into binary right before the 
interface calls.

>
> > - I finally have properly formated X10 commands being sent to the
> >   interface from MH
>
> > Currently: - I am over running the interface! :( Each action on X10
> > comprises usually of multiple X10 protocol commands.  I am sending
> > all of those multipart commands immediately and it appears to be
> > overrunning the device and getting an error. - Forutnately the UPB
> > PIM had the same issue so I am starting to re-use some of the
> > queuing code there - Once I get an X10 light turning on / off from
> > MH, I will do the first checkin.
>
> Are you waiting 1/2 a second between each message (A1 wait 1/2 a second
> AON)? The Insteon PLC can't buffer the X10 in between. You end up stepping
> on the X10 to transmit.

I was before and it was returning errors.  I didnt realize it was 500ms! 
I have the commands queued now and it seems to work, but not consistently. 
Dont know if it is just noisy powerline or what ( I have been using UPB 
for over a year now and god knows what X10 signal sucker is in my house by 
now)  It may be that I am still stepping on the signal or the devices can 
listen that fast.  I will definitely crank it up to 500ms in between 
commands and give it another go.. Thanks Neil!

On Sun, 16 Sep 2007, Neil Cherry wrote:

> Are you waiting 1/2 a second between each message (A1 wait 1/2 a second
> AON)? The Insteon PLC can't buffer the X10 in between. You end up stepping
> on the X10 to transmit.

Works beautifully with 500ms.  Bummer I have to slow up the communication 
on it though.  Thanks again, Neil!

Well I have finally swapped out my CM11 with the Insteon PLM on my main 
home system and all seems to be working well so far in MH.  Ill kick the 
tires on it at home (with the couple of odd X10 devices I still have) for 
the next couple of days and with luck will officially check in support to 
MH this weekend.  BTW: This PLM kicks out an X10 signal that exceeds the 
5V scale on my cheap-o X10 signal meter.. Very nice!

The Insteon protocol is pretty easy on this as well and will start on that 
this weekend. I just wired my Insteon switch into my office lights for 
continued testing.  I wasnt sure what direction the Insteon_Item.pm class 
was heading in, so I have created an Insteon_Device.pm class.  Let me know 
if any different ideas anyone has on this.

Thanks again to all those who have been providing help / documentation!

-J

Been a few months since I last asked and am praying a newcomer may have 
something.  Anyone have any access to _public_ documentation on any of the 
Z-wave serial interface commands?  I know pluto has support but I would 
like to cleanly implement based on public documentation/information.

Interface I am looking at:
ZCS000 - Serial Interface
http://www.automatedoutlet.com/product.php?productid=528&cat=235&page=1

And would love to get this working on MH:
Z-Wave PIR
http://www.automatedoutlet.com/product.php?productid=990&cat=235&page=1

Jason Sharpee wrote:
> Been a few months since I last asked and am praying a newcomer may have 
> something.  Anyone have any access to _public_ documentation on any of the 
> Z-wave serial interface commands?  I know pluto has support but I would 
> like to cleanly implement based on public documentation/information.
> 
> Interface I am looking at:
> ZCS000 - Serial Interface
> http://www.automatedoutlet.com/product.php?productid=528&cat=235&page=1

So far I've found nothing, the Pluto code is Open Source but I
think what you mean is you'd like documentation that is available
in the public, same here. I have the Z-Wave USB stick but found
out afterwards it's not yet supported by anything other than
control 4 (?) using .Net 2.0 (Mono under Linux). Sorry I don't
have much else (except the Pluto code).

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

Jason Sharpee wrote:
> The Insteon protocol is pretty easy on this as well and will start on that
> this weekend. I just wired my Insteon switch into my office lights for
> continued testing.  I wasnt sure what direction the Insteon_Item.pm class
> was heading in, so I have created an Insteon_Device.pm class.  Let me know
> if any different ideas anyone has on this.

I recommend you keep the Insteon PLM module as dumb as possible.  Right now, 
every single x10 interface module has duplicate code for on, off, dim, 
brighten, direct dim, etc.  When you consider the Insteon protocol supports 
something like 256 commands, this will get out of hand quickly.  It makes 
more sense to put this code in your Insteon_Device classes.  The PLM code 
shouldn't even know what an "on" is.  You might also need an Insteon_Group 
class, though I have to admit I don't really understand those.

David

On Fri, 21 Sep 2007, David Norwood wrote:

> Jason Sharpee wrote:
>> The Insteon protocol is pretty easy on this as well and will start on that
>> this weekend. I just wired my Insteon switch into my office lights for
>> continued testing.  I wasnt sure what direction the Insteon_Item.pm class
>> was heading in, so I have created an Insteon_Device.pm class.  Let me know
>> if any different ideas anyone has on this.
>
> I recommend you keep the Insteon PLM module as dumb as possible.  Right now,
> every single x10 interface module has duplicate code for on, off, dim,
> brighten, direct dim, etc.  When you consider the Insteon protocol supports
> something like 256 commands, this will get out of hand quickly.  It makes
> more sense to put this code in your Insteon_Device classes.  The PLM code
> shouldn't even know what an "on" is.  You might also need an Insteon_Group
> class, though I have to admit I don't really understand those.
>

That is exactly the model that I used for the UPB support.  UPB_Link is a 
"Group" as well.  The PLM is still a little higher level than the UPB PIM 
and needs me to break up the Insteon commands into special "PLM" commands 
which requires some knowledge of the protocol unfortunately.  The UPB PIM 
just had a simple "send/receive UPB message" which did it all and thats 
all it needed to know (a very elegant and well thought out design, IMO). 
Which is why again I advocate using UPB instead of Insteon when possible.

Im all about code re-use, but I prefer to re-factor in code-reuse when 
the opportunity arises (I design by TDD mentality mostly)  This is why it 
takes me so long to check in my working code, because even though I have 
Insteon working with the PLM right now in my MH, I am on my fourth 
re-factoring effort and probably will have four more.   I dont want to 
check in and have people start basing code off of something that hasnt 
been refactored to my satisfaction.  In the end, the use of the objects 
appears to be consistent to the user so at least there is a good level of 
abstraction there.

Counter intuitively I had to beef up the Insteon_PLM class to understand 
what X10 is, in order to get it to work with the existing X10 objects. 
Mostly a X10 translation because MH speaks a different X10 "language" than 
the binary that is really used behind the scenes.  Im sure that are many 
ways to improve the X10 support design in the Insteon_PLM, however, I 
didnt want to spend so much time on it that it would never get done. Most 
of that time would be to understand how X10 works in MH as a whole, which 
I still dont have more than a 20% understanding of.  Hopefully someone 
with more knowledge will be able to improve it.

This is why I love and advocate open source and welcome any feedback / 
code contributions  ;)

Matthew Williams wrote:
> Neil Cherry wrote:
>> Hmm, works with:
>>
>> test_device_datatype = raw
>>
> 
> Sorry, forgot that the default "break" that signals the end of records is
> "\r\n".  Set the datatype back to record and the following should work:
> 
> # echo -en "hello there\r\n" > /tmp/testpipe
> 
> Now, with the datatype set to raw the Device_Item will immediately report
> data through ->said without waiting for the break sequence.  Raw gives you
> more control, but you'll have to have your own logic to break up the data
> stream into messages or to combine several -> said results into a message.
> 
> Matt

Hi Matt, thanks for all the pointers so far. I had to dump said as
it wasn't going to cut it in the long run for the PLC. I've created
a class called Insteon_PLU (we can fix the name later). I now have MH
talking to the device (via the Insteon_PLU_device = /dev/iplc1 in my
.ini file) and I've added the check_for_data to the MainLoop_pre_add_hook
and I'm in the process of figuring out how to process the data. I have
to figure out how I'm going to break down the raw data:

2 69 15 2 69 253 2 69 254 2 69 253 2 69 254 2 69 8 2 74 0 72 2 69 8 2 74 1 67

to

2 69 15 (Event, Timer Midnight)
2 69 253 (Event, unknown)
2 69 254 (Event, unknown)
2 69 253 (Event, unknown)
2 69 254 (Event, unknown)
2 69 8 (Event, X10)
2 74 0 72 (X10, addr, o 13)
2 69 8 (Event, X10)
2 74 1 67 (X10, cmd,  o Off)

to

XODOK

The parens are just for description, I don't know what to do with
the Events yet. The more complicated part is that each poll may not
return a full command. I may only get half the command on the first
poll and more on the next.

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

On Sun, 23 Sep 2007, Neil Cherry wrote:

> Matthew Williams wrote:
>> Neil Cherry wrote:
>
> The parens are just for description, I don't know what to do with
> the Events yet. The more complicated part is that each poll may not
> return a full command. I may only get half the command on the first
> poll and more on the next.

Im having similar issues with the PLM.  I am toying with the idea of 
having command templates to seperate the traffic.   The PLM has a start 
character which unfortunately can be used in the data part of the message 
as well and no end character.   I find that on my test Insteon device it 
will actually send back its response within milliseconds of the command 
sent to it, which jumbles the data from the PLM to MH.

-J

Neil Cherry wrote:
> The parens are just for description, I don't know what to do with
> the Events yet. The more complicated part is that each poll may not
> return a full command. I may only get half the command on the first
> poll and more on the next.
> 

Take a look at mh/lib/Weather_daviswm2.pm.  It's a module that I put
together based on someone else's standalone code.  A similar situation
occurs in that the module may not have a complete message in order to proceed.

&update is called once per loop and grabs any data available from the serial
port's input buffer.  &process then takes that data and looks to see if it
can find a valid message.  In the daviswm2 case, a valid message starts with
a hex 1, is 18 bytes long and ends with a valid CRC16.  Any data found
before this valid message is discarded.  Any remaining data in the buffer is
returned back to &update which shoves the remaining data back into the
serial input buffer for the next loop.

The trick is to figure out how to identify a valid message within the large
buffer.  In your case, it looks like a message is always 3 bytes starting
with a hex 2.  Of course, you'll also have to decide how many messages to
process per loop.  Too many and you may slow mh down in other areas.  Too
few and Insteon responsiveness will suffer.  May I suggest initially making
this a programmable parameter and then have the module report how many times
 1,2,...,n messages are available in a single loop.

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

Matthew Williams wrote:
> Neil Cherry wrote:
>> The parens are just for description, I don't know what to do with
>> the Events yet. The more complicated part is that each poll may not
>> return a full command. I may only get half the command on the first
>> poll and more on the next.
>>
> 
> Take a look at mh/lib/Weather_daviswm2.pm.  It's a module that I put
> together based on someone else's standalone code.  A similar situation
> occurs in that the module may not have a complete message in order to proceed.
> 
> &update is called once per loop and grabs any data available from the serial
> port's input buffer.  &process then takes that data and looks to see if it
> can find a valid message.

I'll take a look, thanks.

> The trick is to figure out how to identify a valid message within the large
> buffer.  In your case, it looks like a message is always 3 bytes starting
> with a hex 2.  Of course, you'll also have to decide how many messages to
> process per loop.  Too many and you may slow mh down in other areas.  Too
> few and Insteon responsiveness will suffer.  May I suggest initially making
> this a programmable parameter and then have the module report how many times
>  1,2,...,n messages are available in a single loop.

The 2 is an STX, the next byte is the cmd and the rest is variable.
Including a nasty STX <CMD> <data0> ... <dataN> <ETX>. What we
shouldn't see is a command pop up in the middle of the existing
command. A more difficult problem is getting a NAK. The older PLCs
were a bit inconsistent with where the NAK would arrive. I'm pretty
sure that's no longer the case.

BTW, I'll have to go through this exercise again with the Serial
PLC as the only difference between the 2 is the read and write
routines. The USB requires the read and writes to be 'framed'.
While the Serial is unframed.

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

Hi All,

 	I checked in my initial Insteon Support for the Insteon PLM 
module.   AFAIK, this should support sending and receiving most Insteon 
commands (At least it has been working for a few days at my home).  I 
technically dont have public documentation for anything more advanced than 
the ON/OFF/DIM/BRIGHT/etc core commands.  Outside of some bugfixing and 
removal of debug messages this effort to support the PLM (X10/Insteon) is 
pretty much done.

 	I also did some bugfixing and added better handling of fragmented 
messages to the core engine.

Files Affected:
Insteon_PLM.pm, Insteon_Device.pm, read_table_A.pl

Usage:
     $ip_patio_light = new Insteon_Device($myPLM,"33.44.55");

     $ip_patio_light->set("ON");

-J

Oops, forgot to mention.. You can also define them in the items.mht file 
like so:

#Interface
INSTEON_PLM, myPLM

#Light switch
IPLD,   ipld_office, myPLM, "00.11.FF"

Let me know of any problems (or patches ;) )

-J


On Sun, 23 Sep 2007, Jason Sharpee wrote:

> Hi All,
>
> 	I checked in my initial Insteon Support for the Insteon PLM
> module.   AFAIK, this should support sending and receiving most Insteon
> commands (At least it has been working for a few days at my home).  I
> technically dont have public documentation for anything more advanced than
> the ON/OFF/DIM/BRIGHT/etc core commands.  Outside of some bugfixing and
> removal of debug messages this effort to support the PLM (X10/Insteon) is
> pretty much done.
>
> 	I also did some bugfixing and added better handling of fragmented
> messages to the core engine.
>
> Files Affected:
> Insteon_PLM.pm, Insteon_Device.pm, read_table_A.pl
>
> Usage:
>     $ip_patio_light = new Insteon_Device($myPLM,"33.44.55");
>
>     $ip_patio_light->set("ON");
>
> -J
>
>
> -------------------------------------------------------------------------
> 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
>
>
>

Hey Neil, etc all

 	I tried to make the Insteon_Device generic (ie it generates its 
own Insteon command string) apart from the Insteon_PLM flow control over 
rs232.  However, this was only a guess on my part not knowing anything 
about the PLC commands in the newest version.  Im am willing to make some 
changes to accomodate other insteon capable devices.

For instance:

Hex string Insteon Send: "ssccd1d2d3ffc1c2"

Interface specific? (Is this the same on the other devices PLC Serial/USB)
ss = start (02)
cc = Command (62)

Protocol generic?
d1,d2,d3 = insteon destination
ff = flags
c1,c2 = insteon command bytes

-J

Jason Sharpee wrote:
> Hey Neil, etc all
> 
>  	I tried to make the Insteon_Device generic (ie it generates its 
> own Insteon command string) apart from the Insteon_PLM flow control over 
> rs232.  However, this was only a guess on my part not knowing anything 
> about the PLC commands in the newest version.  Im am willing to make some 
> changes to accomodate other insteon capable devices.
> 
> For instance:
> 
> Hex string Insteon Send: "ssccd1d2d3ffc1c2"
> 
> Interface specific? (Is this the same on the other devices PLC Serial/USB)
> ss = start (02)
> cc = Command (62)
> 
> Protocol generic?
> d1,d2,d3 = insteon destination
> ff = flags
> c1,c2 = insteon command bytes

Oops forgot to respond. At the high levels that looks correct but
for the USB you need to convert that string into this:

02 ss cc 00 00 00 00 00
03 d1 d2 d3 00 00 00 00 (20 ms wait)
03 ff c1 c2 00 00 00 00 (20 ms wait)

The reason for this is that the USB sites between Linux and the
Insteon device like a pipe that needs everything framed in 8 byte
frames. From the users perspective I intend to use the exact same
functions we've used all along (set, send, said ...) but the next
level is different too. To send an X10 command I need to write
the X10 <HC:UC> to 0x165, then mask 0x166, then write the X10 <HC:CC>
to 0x165, then mask 0x166. Insteon is similar in it's command
structure but I think I only need to write and mask once.

The serial PLC is similar but no framing.

BTW, what is a 'said'? What is it supposed to do?

And lastly, which modules did you update with the new Insteon code?

Thanks

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

I second Neil's request that the order of the fields for an Insteon device 
in the mht file match the x10 order.  Most items generally follow this order 
and it's very confusing to have one that is different.  The order is:

type, address, name, groups, interface, options

Also, is interface optional?  With x10, misterhouse will default to one of 
the active x10 interfaces (most people have just one).

David

----- Original Message ----- 
From: "Jason Sharpee" <jason@...>
To: "The main list for the MisterHouse home automation program" 
<misterhouse-users@...>
Sent: Sunday, September 23, 2007 5:02 PM
Subject: Re: [mh] Insteon PLM (Insteon Protocol Support) added


>
> Oops, forgot to mention.. You can also define them in the items.mht file
> like so:
>
> #Interface
> INSTEON_PLM, myPLM
>
> #Light switch
> IPLD,   ipld_office, myPLM, "00.11.FF"
>
> Let me know of any problems (or patches ;) )
>
> -J
>
>
> On Sun, 23 Sep 2007, Jason Sharpee wrote:
>
>> Hi All,
>>
>> I checked in my initial Insteon Support for the Insteon PLM
>> module.   AFAIK, this should support sending and receiving most Insteon
>> commands (At least it has been working for a few days at my home).  I
>> technically dont have public documentation for anything more advanced 
>> than
>> the ON/OFF/DIM/BRIGHT/etc core commands.  Outside of some bugfixing and
>> removal of debug messages this effort to support the PLM (X10/Insteon) is
>> pretty much done.
>>
>> I also did some bugfixing and added better handling of fragmented
>> messages to the core engine.
>>
>> Files Affected:
>> Insteon_PLM.pm, Insteon_Device.pm, read_table_A.pl
>>
>> Usage:
>>     $ip_patio_light = new Insteon_Device($myPLM,"33.44.55");
>>
>>     $ip_patio_light->set("ON");
>>
>> -J
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>>
>>
>
> -------------------------------------------------------------------------
> 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
>

I have no opinion on the order and will change it to be consistent.

I doubt it can be used as a default interface right now.  I find the X10 
pipeline in MH confusing, so it is not as well integrated as the other 
devices.  I would be willing to work with anyone that has a better 
knowledge of how that works.

Jack and I worked out the last of his X10 problems tonight as well, so I 
will probably be removing the debug messages along with the definition 
parameter order change, this weekend.

Thanks for the suggestion.




On Wed, 26 Sep 2007, David Norwood wrote:

> I second Neil's request that the order of the fields for an Insteon device
> in the mht file match the x10 order.  Most items generally follow this order
> and it's very confusing to have one that is different.  The order is:
>
> type, address, name, groups, interface, options
>
> Also, is interface optional?  With x10, misterhouse will default to one of
> the active x10 interfaces (most people have just one).
>
> David
>
> ----- Original Message -----
> From: "Jason Sharpee" <jason@...>
> To: "The main list for the MisterHouse home automation program"
> <misterhouse-users@...>
> Sent: Sunday, September 23, 2007 5:02 PM
> Subject: Re: [mh] Insteon PLM (Insteon Protocol Support) added
>
>
>>
>> Oops, forgot to mention.. You can also define them in the items.mht file
>> like so:
>>
>> #Interface
>> INSTEON_PLM, myPLM
>>
>> #Light switch
>> IPLD,   ipld_office, myPLM, "00.11.FF"
>>
>> Let me know of any problems (or patches ;) )
>>
>> -J
>>
>>
>> On Sun, 23 Sep 2007, Jason Sharpee wrote:
>>
>>> Hi All,
>>>
>>> I checked in my initial Insteon Support for the Insteon PLM
>>> module.   AFAIK, this should support sending and receiving most Insteon
>>> commands (At least it has been working for a few days at my home).  I
>>> technically dont have public documentation for anything more advanced
>>> than
>>> the ON/OFF/DIM/BRIGHT/etc core commands.  Outside of some bugfixing and
>>> removal of debug messages this effort to support the PLM (X10/Insteon) is
>>> pretty much done.
>>>
>>> I also did some bugfixing and added better handling of fragmented
>>> messages to the core engine.
>>>
>>> Files Affected:
>>> Insteon_PLM.pm, Insteon_Device.pm, read_table_A.pl
>>>
>>> Usage:
>>>     $ip_patio_light = new Insteon_Device($myPLM,"33.44.55");
>>>
>>>     $ip_patio_light->set("ON");
>>>
>>> -J
>>>
>>>
>>> -------------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
>
>
> -------------------------------------------------------------------------
> 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:
> I have no opinion on the order and will change it to be consistent.
> 
> I doubt it can be used as a default interface right now.  I find the X10 
> pipeline in MH confusing, so it is not as well integrated as the other 
> devices.  I would be willing to work with anyone that has a better 
> knowledge of how that works.
> 
> Jack and I worked out the last of his X10 problems tonight as well, so I 
> will probably be removing the debug messages along with the definition 
> parameter order change, this weekend.

Actually the last time I worked on the iplcs code I had it as the
default x10. I changed one parameter in the .ini file. It's going
to take me a little while to remember this stuff.

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

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Jason,<br>
<br>
The X10 works completely, AFAIK.<br>
<br>
Insteon has both On <u><i>and</i></u> Off...<br>
<br>
Let me know when you're ready to tackle <b>Dimming</b>...<br>
<br>
Also, what about polling for status - so the buttons show the device's
current state. Is that the way X10 works?<br>
<br>
Finally; did you make any changes to the IA5 Edit Items to allow the
creation of an Insteon device? Like the myriad of other devices I can
make into an item...??<br>
<br>
Thanks, again.<br>
<br>
Jack<br>
:)<br>
<br>
</body>
</html>

I tried to make X10 feature complete as that is well documented everywhere 
on the internet:
- on/off/dim/bright/status/presetdim/etc

With Insteon, I made it as complete as I had 'public' documentation for:
- on/off
- Dim/Bright
- Status_Request: $ipld_office-set('status_request');
- Preset Dim: $ipld_office->set('50%');

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.

Thanks again for your help with testing,
-J



On Thu, 27 Sep 2007, Jack Edin wrote:

> Jason,
> 
> The X10 works completely, AFAIK.
> 
> Insteon has both On and Off...
> 
> Let me know when you're ready to tackle Dimming...
> 
> Also, what about polling for status - so the buttons show the device's current state. Is
> that the way X10 works?
> 
> Finally; did you make any changes to the IA5 Edit Items to allow the creation of an
> Insteon device? Like the myriad of other devices I can make into an item...??
> 
> Thanks, again.
> 
> Jack
> :)
> 
> 
>

On Thu, 27 Sep 2007, Jack Edin wrote:

> Also, what about polling for status - so the buttons show the device's current state. Is
> that the way X10 works?

Im not quite sure how the Insteon switchlinc works (I didnt have the 
manual for it and was too lazy to pull the one online), but I would assume 
it works like the UPB devices in that you can somehow set the switch to 
report back status on a change in state.  Otherwise you can poll the 
deivce with a status_request and get the state (as I mentioned I need to 
change the code a little to handle the response)

> Finally; did you make any changes to the IA5 Edit Items to allow the creation of an
> Insteon device? Like the myriad of other devices I can make into an item...??

Ill try and have a look at that again.  I need to change it again anyway 
to switch around the parameters in items.mht

-J

Jason Sharpee wrote:
> On Thu, 27 Sep 2007, Jack Edin wrote:
> 
>> Also, what about polling for status - so the buttons show the device's current state. Is
>> that the way X10 works?
> 
> Im not quite sure how the Insteon switchlinc works (I didnt have the 
> manual for it and was too lazy to pull the one online), but I would assume 
> it works like the UPB devices in that you can somehow set the switch to 
> report back status on a change in state.  Otherwise you can poll the 
> deivce with a status_request and get the state (as I mentioned I need to 
> change the code a little to handle the response)
> 
>> Finally; did you make any changes to the IA5 Edit Items to allow the creation of an
>> Insteon device? Like the myriad of other devices I can make into an item...??
> 
> Ill try and have a look at that again.  I need to change it again anyway 
> to switch around the parameters in items.mht
> 
> -J

Two things, congrats, you wrote code that works for both Windows
and *nix (I suspect that any of the unix family will work fine :-)
and the second thing:

   # Change /dev/ttyM7 to whatever serial port you are using
   @ Insteon Stuff, just the serial stuff for right now
   iplcs_port=/dev/ttyM7

   # From Serial_Item - I think this makes iplcs the default interface!
   iplcs_module=X10_IPLCS
   x10_interface=iplcs

These where the lines I used to change the MH X10 interface to
the serial Insteon PLC last year (before my code went boom). I
wouldn't jump into it just yet but there's something there.

I need to review my old code and my new code. With my new found
knowledge of extending Device_Item and my old working code I'll
figure this out.

Thanks!

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

Jason Sharpee wrote:
> I doubt it can be used as a default interface right now.  I find the X10 
> pipeline in MH confusing, so it is not as well integrated as the other 
> devices.  I would be willing to work with anyone that has a better 
> knowledge of how that works.

Jason,

I would be happy to help you out with integrating your work into the current
X10 pipeline.  I should have the best handle on it as it is is mostly my
work (the new class structure, that is, not the main functionality).  I
don't have any Insteon stuff so I'll only be able to advise you on what
needs to be done.

Feel free to contact me off-list or perhaps others might benefit from our
discussions on-list - your choice.

thanks,
Matt

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

Matthew Williams wrote:
> Jason Sharpee wrote:
>> I doubt it can be used as a default interface right now.  I find the X10 
>> pipeline in MH confusing, so it is not as well integrated as the other 
>> devices.  I would be willing to work with anyone that has a better 
>> knowledge of how that works.
> 
> Jason,
> 
> I would be happy to help you out with integrating your work into the current
> X10 pipeline.  I should have the best handle on it as it is is mostly my
> work (the new class structure, that is, not the main functionality).  I
> don't have any Insteon stuff so I'll only be able to advise you on what
> needs to be done.
> 
> Feel free to contact me off-list or perhaps others might benefit from our
> discussions on-list - your choice.

On list please or at least include me. :-)

Okay, I've got the input side working okay but now I'm trying to get
the X10 set associated with the PLU. How do I associate the new
object with the already open interface?

I've got (mh.private.ini):

Insteon_PLU_device          = /dev/iplc1
Insteon_PLU_device_datatype = raw
Insteon_PLU_device_mode     = rw

then I've got (~mh/code/Insteon.pl):

if ($Reload || $Startup) {
     # Need to create a new Insteon_PLU object then add it's check_for_data to
     # the MainLoop_pre_add_hook but only once, add_hook takes care of that
     #  This should allow the support of more than one PLC
     if(!defined($Insteon_PLU)) {
         &::print_log("User code test_iplc.pl");
         $Insteon_PLU = new Insteon_PLU('b', undef, 'Insteon_PLU');
     } else {
         &::print_log("new Insteon_PLU exists");
     }
     $Insteon_PLU->add_hook();
}

but I can't use the 'Insteon_PLU' in the x10.mht:

X10I,     P16,      xP16,                  Test|P,		Insteon_PLU,

What's the secret?

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

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

Hello,

I have a 1 way SwitchLinc switch that I would like to set the primary on
level for.  I defined it as X10SL in Items.mht.  I see that there's a state
called 'setonlevel' but I'm not sure how I would use that to set it to a
specific value.  I need the light to come on to one brightness during the
day and another at night.  I know it's possible to do something similar by
putting a sitck-a-switch next to the light and using preset dims, but I'd
prefer to use the ability of the switchlinc.

Thanks,

Dan

Gregg Liming wrote:

> 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.

ALL-Linking definition:

ALL-Linking allows any INSTEON Controller device to operate any
INSTEON Responder device, even if the Controller does not know any of
the Direct Commands that the Responder can execute. The principle is
simple, during ALL-Linking to a button on a Controller, a Responder
memorizes the state that it is in at the time.  After ALL-Linking,
pushing that button on the Controller causes the Responder to go back
into the state that it memorized when it ALL-Linked.

When a button on a Controller ALL-Links to a Responder, the Controller
creates an ALL-Link Group, which the Responder joins. Multiple
Responders can join the same ALL-Link Group, so it is possible for a
single button push to cause an entire ensemble of devices to recall
their memorized states.

All of the Responder devices in the ALL-Link Group will recall their
memorized states simultaneously, because when the Controller's button
is pushed, the Controller first sends out an ALL-Link Broadcast
message to all of the Group members at once, followed by individual
ALL-Link Cleanup messages to each Group member in turn.

-- 
Linux Home Automation         Neil Cherry       ncherry@...
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

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       ncherry@...
http://www.linuxha.com/                         Main site
http://linuxha.blogspot.com/                    My HA Blog
Author of:    	Linux Smart Homes For Dummies

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

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

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

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.

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

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 Sun, 30 Sep 2007, Gregg Liming wrote:

> 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).
>

Yep,  that is my inspiration once I realized xAP was probably the better 
route for I/RPC.   I have been idling going through the BSC.pm code for 
the last couple of weeks.

I have a new MH project house im starting on next week and afterwards 
will dive back into this idea.

Quoting Jason Sharpee (9/19/07 11:44 PM):
> On Sun, 16 Sep 2007, Neil Cherry wrote:
> 
>> Are you waiting 1/2 a second between each message (A1 wait 1/2 a second
>> AON)? The Insteon PLC can't buffer the X10 in between. You end up stepping
>> on the X10 to transmit.
> 
> Works beautifully with 500ms.  Bummer I have to slow up the communication 
> on it though.  Thanks again, Neil!

FYI - I just committed a number of mods to extend insteon-specific
support for Insteon_PLM.pm and Insteon_Device.pm.  Among them includes
an ability to adjust the delays by overriding the x10 and non-x10 delays
(and selected as a function of message type).  I'm able to ratchet down
the non-x10 (i.e., insteon-only) delay to 0 w/o problems and the
switching speed is *noticeably* fast!

Gregg

Gregg Liming wrote:
> Quoting Jason Sharpee (9/19/07 11:44 PM):
>> On Sun, 16 Sep 2007, Neil Cherry wrote:
>>
>>> Are you waiting 1/2 a second between each message (A1 wait 1/2 a second
>>> AON)? The Insteon PLC can't buffer the X10 in between. You end up stepping
>>> on the X10 to transmit.
>> Works beautifully with 500ms.  Bummer I have to slow up the communication 
>> on it though.  Thanks again, Neil!
> 
> FYI - I just committed a number of mods to extend insteon-specific
> support for Insteon_PLM.pm and Insteon_Device.pm.  Among them includes
> an ability to adjust the delays by overriding the x10 and non-x10 delays
> (and selected as a function of message type).  I'm able to ratchet down
> the non-x10 (i.e., insteon-only) delay to 0 w/o problems and the
> switching speed is *noticeably* fast!

I'll take a look at those, they should be interesting. You do have
to be careful with sending information to the Insteon PLC (Modem,
Serial, USB) devices as they have a limited buffer but it sounds
like your adjusting something else. It also sounds like a good
thing. :-) I'll grab a copy right now.

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

Quoting Neil Cherry (10/3/07 12:52 PM):

> You do have
> to be careful with sending information to the Insteon PLC (Modem,
> Serial, USB) devices as they have a limited buffer but it sounds
> like your adjusting something else. 

Yes.  Jason's implementation prevented overrunning the buffer by
observing the serial NAK response.  I do notice at startup (when I
overwhelm the PLC) that serial NAKs are received and the commmand buffer
in Insteon_PLM begins to fill until the PLM can take it.

The delays that I was referring to were deliberate additional timing
delays that Jason added in to ensure that x10 is sent ok.  As it turns
out, this appears to be very specific to x10 (and hence the 0.5 default
delay).  I started wondering about this; so, I added the overrides.  The
default code override is somewhat more conservative than my 0 insteon
delay.  But, I've been blasting it pretty heavily and am not seeing any
problems.

> It also sounds like a good
> thing. :-) I'll grab a copy right now.

FYI -- other stuff added: (1) ability to receive and process insteon
messages (comprehensive message parsing), (2) ability to handle ALL-Link
messages directed back to the PLM--to include the use of the new group
id in the address field (so as to support keypadlincs, controllincs),
(3) ability to detect manual change adjusts (like manually controlling
a switchlinc) and automatically syncing the on-level on completing the
manual change (needed so that mh always accurately knows the device state).

Additions that I would like to see still happen (and will implement
unless someone beats me to them): (1) ability to programatically set a
device's ramp rate and default onlevel, (2) improved ALL-Linking support
(e.g., remote responder state tracking), (3) automatic device config
scan (so that Insteon_Device knows the device type by asking rather than
requiring any user "tweaks").

Full all-link enrollment seems to be beyond me at the moment; so,
support is for "assisted" enrollment vice full link creation/mod/deletion.

Gregg

Hi All,

     I just stumbled onto this, which is the best public documentation I 
have found to date on the Zwave interface.  Im dying for a better wireless 
PIR solution to MH.

http://www.embedded.com/columns/technicalinsights/193101000?_requestid=507150

     With this I am a whole lot more confident in figuring out the serial 
protocol for the interface, but would like to see first hand how it works. 
Does anyone have a zwave serial interface, remote, and light module 
collecting dust, they wouldnt mind lending me briefly?  I'd hate 
to buy all this stuff just to find the protocol is more complicated then 
it appears.

     Or, if anyone has the devices and the capacity to do some serial dumps 
let me know.

Thanks,
-J

Jason Sharpee wrote:
> Hi All,
> 
>      I just stumbled onto this, which is the best public documentation I 
> have found to date on the Zwave interface.  Im dying for a better wireless 
> PIR solution to MH.
> 
> http://www.embedded.com/columns/technicalinsights/193101000?_requestid=507150
> 
>      With this I am a whole lot more confident in figuring out the serial 
> protocol for the interface, but would like to see first hand how it works. 
> Does anyone have a zwave serial interface, remote, and light module 
> collecting dust, they wouldnt mind lending me briefly?  I'd hate 
> to buy all this stuff just to find the protocol is more complicated then 
> it appears.
> 
>      Or, if anyone has the devices and the capacity to do some serial dumps 
> let me know.

You might be able to figure out the information from the C++ code
in the HA package Pluto but this is for the ACT interface (no longer
being sold). I have the new HA22 which appears not to be compatible.
:-/

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

Well, it looks like Z-Wave can be easily implemented using this adapter:
http://www.leviton.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=22201&minisite=10024

Look, an actual RS232 protcol document with examples!
http://www.leviton.com/OA_HTML/ibcGetAttachment.jsp?cItemId=63825&label=IBE&appName=IBE&JServSessionIdrootlxln0001=c0yg88za41.p7vGpx0Ka34Ip6jQolfJpwTDpAaUp7vGpx0Ka34Ip6jQolfJpwTDpAaUahmKa30-&LCPROD=JBFHjawnpSVvQvqvNKzBsvbe:S&LCPROD_pses=LCPROD%3DJBFHjawnpSVvQvqvNKzBsvbe%253AS%7E



On Wed, 3 Oct 2007, Neil Cherry wrote:

> Jason Sharpee wrote:
>> Hi All,
>>
>>      I just stumbled onto this, which is the best public documentation I
>> have found to date on the Zwave interface.  Im dying for a better wireless
>> PIR solution to MH.
>>
>> http://www.embedded.com/columns/technicalinsights/193101000?_requestid=507150
>>
>>      With this I am a whole lot more confident in figuring out the serial
>> protocol for the interface, but would like to see first hand how it works.
>> Does anyone have a zwave serial interface, remote, and light module
>> collecting dust, they wouldnt mind lending me briefly?  I'd hate
>> to buy all this stuff just to find the protocol is more complicated then
>> it appears.
>>
>>      Or, if anyone has the devices and the capacity to do some serial dumps
>> let me know.
>
> You might be able to figure out the information from the C++ code
> in the HA package Pluto but this is for the ACT interface (no longer
> being sold). I have the new HA22 which appears not to be compatible.
> :-/
>
>

Jason Sharpee wrote:
> Well, it looks like Z-Wave can be easily implemented using this adapter:
> http://www.leviton.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=22201&minisite=10024
> 
> Look, an actual RS232 protcol document with examples!
> http://www.leviton.com/OA_HTML/ibcGetAttachment.jsp?cItemId=63825&label=IBE&appName=IBE&JServSessionIdrootlxln0001=c0yg88za41.p7vGpx0Ka34Ip6jQolfJpwTDpAaUp7vGpx0Ka34Ip6jQolfJpwTDpAaUahmKa30-&LCPROD=JBFHjawnpSVvQvqvNKzBsvbe:S&LCPROD_pses=LCPROD%3DJBFHjawnpSVvQvqvNKzBsvbe%253AS%7E

Okay, now you're onto something, "Leviton RZC0P-1LW - Vizia-RF
Plug-In RS-232 Interface for PC's/Automation Controllers - $58.67

http://www.asihome.com/ASIshop/product_info.php?cPath=50_51_521&products_id=2485

Thamks!

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

Neil Cherry wrote:
> Jason Sharpee wrote:
>> Well, it looks like Z-Wave can be easily implemented using this adapter:
>> http://www.leviton.com/OA_HTML/ibeCCtpSctDspRte.jsp?section=22201&minisite=10024
>>
>> Look, an actual RS232 protcol document with examples!
>> http://www.leviton.com/OA_HTML/ibcGetAttachment.jsp?cItemId=63825&label=IBE&appName=IBE&JServSessionIdrootlxln0001=c0yg88za41.p7vGpx0Ka34Ip6jQolfJpwTDpAaUp7vGpx0Ka34Ip6jQolfJpwTDpAaUahmKa30-&LCPROD=JBFHjawnpSVvQvqvNKzBsvbe:S&LCPROD_pses=LCPROD%3DJBFHjawnpSVvQvqvNKzBsvbe%253AS%7E
> 
> Okay, now you're onto something, "Leviton RZC0P-1LW - Vizia-RF
> Plug-In RS-232 Interface for PC's/Automation Controllers - $58.67
> 
> http://www.asihome.com/ASIshop/product_info.php?cPath=50_51_521&products_id=2485

Jason, I did a little more looking around on the Leviton site and
found that they have quite a product line: Fan speed control, dimmers
switches, appliance and lamp modules. That's pretty impressive and
if Leviton's backing it I would expect some pretty good quality.

Thanks for the find.

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