Thread: [mh] Insteon: Created merged i2_aldb_support

I've created a merge of hollie/misterhouse/master and
mstovenour/misterhouse/i2_aldb_support.  The branch for the merge is
mstovenour/misterhouse/merge_i2_aldb_support
<https://github.com/mstovenour/misterhouse/tree/merge_i2_aldb_support> .  I would
appreciate if others could test it out and let me know 1) that the code actually works
correctly (at least as good as the original branch i2_aldb_support) and 2) that I merged
this the right way.  If all is well then I'll create a pull request for
hollie/misterhouse.

 

If anyone is wondering, this is the process I used:

Fetched / merged hollie/misterhouse/master into my local master

Checked out i2_aldb_support

Merged local master

Checked out master (as basis for next step)

Created branch merge_i2_aldb_support

Merged i2_aldb_support

Used difftool to review and make small cleanup

Committed changes

Pushed merge_i2_aldb_support to mstovenour/misterhouse

 

I have no idea if this is the right way to do this.  I merged master into my branch first
because I've been doing this periodically as I developed that branch.  If there is a
better process that I should have followed then I have no issues starting over.  Just let
me know how it would be best to merge this.

 

Thanks,

Michael

Michael Stovenour wrote
> I have no idea if this is the right way to do this.  I merged master into
> my branch first
> because I've been doing this periodically as I developed that branch.  If
> there is a
> better process that I should have followed then I have no issues starting
> over.  Just let
> me know how it would be best to merge this.

I have no idea either, but very cool we might have MH 3.0 soon.  =) 
However, you forgot to include my Network PLM modifications.  I'm sad!



--
View this message in context: http://misterhouse.10964.n7.nabble.com/Insteon-Created-merged-i2-aldb-support-tp17837p17843.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

On Sun, Apr 21, 2013 at 04:04:12PM -0700, Chris Dragon wrote:
> Michael Stovenour wrote
> > I have no idea if this is the right way to do this.  I merged master into
> > my branch first
> > because I've been doing this periodically as I developed that branch.  If
> > there is a
> > better process that I should have followed then I have no issues starting
> > over.  Just let
> > me know how it would be best to merge this.
> 
> I have no idea either, but very cool we might have MH 3.0 soon.  =) 
> However, you forgot to include my Network PLM modifications.  I'm sad!

I can't quite comment on what happened, and how, but considering the work
Michael put into the code and the limited free time most of us have, is it
easy/possible for you to help him out and merge back your code with his?

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Marc MERLIN-7 wrote
> I can't quite comment on what happened, and how, but considering the work
> Michael put into the code and the limited free time most of us have, is it
> easy/possible for you to help him out and merge back your code with his?

I'd be happy to, but how?  It says I have read-only access to the
merge_i2_aldb_support branch.  Unless you just mean to start another pull
request?  Otherwise, I think Michael would have to give me write access.  My
Smartlinc commits are on https://github.com/cdragon/misterhouse/



--
View this message in context: http://misterhouse.10964.n7.nabble.com/Insteon-Created-merged-i2-aldb-support-tp17837p17845.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

On Apr 21, 2013 6:04 PM Chris wrote,
> 
> Michael Stovenour wrote
> > I have no idea if this is the right way to do this.  I merged master into
> > my branch first because I've been doing this periodically as I developed 
> > that branch.  If there is a better process that I should have followed 
> > then I have no issues starting over.  Just let me know how it would be 
> > best to merge this.
> 
> I have no idea either, but very cool we might have MH 3.0 soon.  =)
> However, you forgot to include my Network PLM modifications.  I'm sad!

Chris, I have concerns trying to merge this code that I've listed below.  Can I suggest
that you issue a pull request against hollie/misterhouse/master "after" the new i2CS code
is merged?

1) There are several merge conflicts where you and Kevin have modified the same code in
different ways.  Not a big deal but I'd rather have you and Kevin workout the merge
conflicts.

2) IMO, the code you added to Insteon_PLM should be redesigned.  It does not follow
generally accepted object oriented concepts for Perl.  Gregg rewrote all of the Insteon
logic primarily so that it would follow OOP concepts like inheritance and data
encapsulation to isolate parts of the code from each other greatly improving the
supportability of the code in the long term.  Even though Gregg started out to apply OOP
best practices, the code has already evolved to an
http://perldesignpatterns.com/?ObjectOrgy.  I think this update has taken a step too far
backwards for my tastes.  I'm not implying that your code should not be included as is;
that is a decision for yourself and other developers.  I simply do not wish to be
responsible for it.

Sincerely,
Michael

Michael Stovenour wrote
> 2) IMO, the code you added to Insteon_PLM should be redesigned.  It does
> not follow
> generally accepted object oriented concepts for Perl.  Gregg rewrote all
> of the Insteon
> logic primarily so that it would follow OOP concepts like inheritance and
> data
> encapsulation to isolate parts of the code from each other greatly
> improving the
> supportability of the code in the long term.  Even though Gregg started
> out to apply OOP
> best practices, the code has already evolved to an
> http://perldesignpatterns.com/?ObjectOrgy.  I think this update has taken
> a step too far
> backwards for my tastes.  I'm not implying that your code should not be
> included as is;
> that is a decision for yourself and other developers.  I simply do not
> wish to be
> responsible for it.

Michael,

I understand your desire to keep the code clean, but I'm new to using
objects in Perl and don't feel I have the knowledge to redesign my changes
along the lines you're suggesting.  Even if I could somehow find the time to
learn and to redesign it, my Smartlinc has been returned and so I could not
test any alternate version of the code I came up with and I don't think
there's much use creating/releasing untestable code.

I suppose I'll have to issue a pull request after the big merge and see what
happens.



--
View this message in context: http://misterhouse.10964.n7.nabble.com/Insteon-Created-merged-i2-aldb-support-tp17837p17847.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

Hi Michael, Kevin,

Dumb question...

I just bought a couple of new INSTEON devices and am wondering if I must 
use the new merge_i2_aldb_support branch or nothing will work after I 
install the new devices.

I have been using hollie/misterhouse/master with no problems (I think 
because I have not done any link management in a long time). All my 
devices are I1 and I2, but I'd expect the new devices that I bought to 
be I2CS, so I wonder if I absolutely need to run the new branch if that 
is the case (I don't mind at all running whatever branch is needed; I 
just need to know what branch I must be running ;-) ).

I guess the problem I have is that I don't understand what was supported 
in Gregg's original code, what was missing, and what is now supported in 
Kevin and Michael's most recent work.

Thanks for the clarification!

Cheers,

Eloy Paris.-

On 04/21/2013 02:29 PM, Michael Stovenour wrote:

> I’ve created a merge of hollie/misterhouse/master and
> mstovenour/misterhouse/i2_aldb_support.  The branch for the merge is
> mstovenour/misterhouse/merge_i2_aldb_support
> <https://github.com/mstovenour/misterhouse/tree/merge_i2_aldb_support>.
> I would appreciate if others could test it out and let me know 1) that
> the code actually works correctly (at least as good as the original
> branch i2_aldb_support) and 2) that I merged this the right way.  If all
> is well then I’ll create a pull request for hollie/misterhouse.
>
> If anyone is wondering, this is the process I used:
>
> Fetched / merged hollie/misterhouse/master into my local master
>
> Checked out i2_aldb_support
>
> Merged local master
>
> Checked out master (as basis for next step)
>
> Created branch merge_i2_aldb_support
>
> Merged i2_aldb_support
>
> Used difftool to review and make small cleanup
>
> Committed changes
>
> Pushed merge_i2_aldb_support to mstovenour/misterhouse
>
> I have no idea if this is the right way to do this.  I merged master
> into my branch first because I’ve been doing this periodically as I
> developed that branch.  If there is a better process that I should have
> followed then I have no issues starting over.  Just let me know how it
> would be best to merge this.
>
> Thanks,
>
> Michael
>
>

On Wed, Apr 24, 2013 at 12:11:23PM -0400, Eloy Paris wrote:
> Hi Michael, Kevin,
> 
> Dumb question...
> 
> I just bought a couple of new INSTEON devices and am wondering if I must 
> use the new merge_i2_aldb_support branch or nothing will work after I 
> install the new devices.
 
If you do not use the new merge_i2_aldb_support branch:

The new devices will not allow any sync/scan to work unless you use the new
branch.
You can still send on/off/status commands after you manually link to them
(i.e. using the link button on the PLM).

So you should still be able to at least talk to them, but any link syncing
will not work, and your nightly scan all, if enabled, will fail every night.

Marc

> I have been using hollie/misterhouse/master with no problems (I think 
> because I have not done any link management in a long time). All my 
> devices are I1 and I2, but I'd expect the new devices that I bought to 
> be I2CS, so I wonder if I absolutely need to run the new branch if that 
> is the case (I don't mind at all running whatever branch is needed; I 
> just need to know what branch I must be running ;-) ).
> 
> I guess the problem I have is that I don't understand what was supported 
> in Gregg's original code, what was missing, and what is now supported in 
> Kevin and Michael's most recent work.
> 
> Thanks for the clarification!
> 
> Cheers,
> 
> Eloy Paris.-
> 
> On 04/21/2013 02:29 PM, Michael Stovenour wrote:
> 
> > I’ve created a merge of hollie/misterhouse/master and
> > mstovenour/misterhouse/i2_aldb_support.  The branch for the merge is
> > mstovenour/misterhouse/merge_i2_aldb_support
> > <https://github.com/mstovenour/misterhouse/tree/merge_i2_aldb_support>.
> > I would appreciate if others could test it out and let me know 1) that
> > the code actually works correctly (at least as good as the original
> > branch i2_aldb_support) and 2) that I merged this the right way.  If all
> > is well then I’ll create a pull request for hollie/misterhouse.
> >
> > If anyone is wondering, this is the process I used:
> >
> > Fetched / merged hollie/misterhouse/master into my local master
> >
> > Checked out i2_aldb_support
> >
> > Merged local master
> >
> > Checked out master (as basis for next step)
> >
> > Created branch merge_i2_aldb_support
> >
> > Merged i2_aldb_support
> >
> > Used difftool to review and make small cleanup
> >
> > Committed changes
> >
> > Pushed merge_i2_aldb_support to mstovenour/misterhouse
> >
> > I have no idea if this is the right way to do this.  I merged master
> > into my branch first because I’ve been doing this periodically as I
> > developed that branch.  If there is a better process that I should have
> > followed then I have no issues starting over.  Just let me know how it
> > would be best to merge this.
> >
> > Thanks,
> >
> > Michael
> >
> >
> 
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service 
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 

-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

On 04/24/2013 12:27 PM, Marc MERLIN wrote:

> On Wed, Apr 24, 2013 at 12:11:23PM -0400, Eloy Paris wrote:
>> Hi Michael, Kevin,
>>
>> Dumb question...
>>
>> I just bought a couple of new INSTEON devices and am wondering if I must
>> use the new merge_i2_aldb_support branch or nothing will work after I
>> install the new devices.
>
> If you do not use the new merge_i2_aldb_support branch:
>
> The new devices will not allow any sync/scan to work unless you use the new
> branch.
> You can still send on/off/status commands after you manually link to them
> (i.e. using the link button on the PLM).
>
> So you should still be able to at least talk to them, but any link syncing
> will not work, and your nightly scan all, if enabled, will fail every night.

Okay, thanks Marc. I do not think not being able to sync would be an 
issue for me right now (I would just link the new devices to the PLM 
manually). Scan links I think it's good to have, although I disabled the 
nightly scan a long time ago when I switched to Gregg's "insteon" branch.

So, I'll just use merge_i2_aldb_support and help with the testing.

On an unrelated note, Marc, one of my new devices is a KeypadLinc. I 
have never used one of these before but one of my goals with it is to 
reflect the status (open or close) of my garage door in one of the KPL's 
LED. I understand I need to use a "surrogate" option... would you happen 
to have an example of the configuration syntax? The example in the wiki 
still shows the old syntax.

I'm curious to know how this will play out because I interface to my 
garage door using 1-Wire, not INSTEON... MisterHouse knows when the door 
is open or closed by reading a 1-Wire device, and opens/closes the door 
by writing to a 1-Wire device. My thought was to have a KPL button 
initiate, through MH, a write to the 1-Wire device to activate the door, 
and to have MH write to a KPL button LED to reflect the status of the 
door. Hopefully this will be possible...

Cheers,

Eloy Paris.-

On 04/26/2013 06:47 PM, Eloy Paris wrote:

[...]

> Does anyone know what this "link_cleanup_report" message is supposed to
> do? Perhaps it needs similar treatment to the one that a "cleanup"
> message type gets?

Actually, Chris Dragon is also running into the same problem... could it 
be that new devices are sending these "link_cleanup_report" messages and 
that we are not handling them properly? Here's Chris' post:

http://misterhouse.10964.n7.nabble.com/Can-5-Insteon-scene-members-block-the-all-link-cleanup-message-to-PLM-td17733.html#a17766

Chris is seeing this with a RemoteLinc, and I am seeing it with a 
KeypadLinc.

Kevin's theory was that perhaps the RemoteLinc "doesn't have a 
controller record to the PLM in its database" but in the case of my 
KeypadLinc I have a record:

[Insteon::AllLinkDatabase] [0x0fe7] contlr(03) record to $PLM (03), 
(d1:ff, d2:00, d3:03)

Cheers,

Eloy Paris.-

I have seen the alllink_cleanup_reports recently too and I agree they seem
to be sent by by very new devices (remotelinc for me).  I could have let
the genie out of the box by changing something in the code which previously
ignored these.

I should able to fix these relatively easy.


On Fri, Apr 26, 2013 at 3:58 PM, Eloy Paris <pe...@ch...> wrote:

> On 04/26/2013 06:47 PM, Eloy Paris wrote:
>
> [...]
>
> > Does anyone know what this "link_cleanup_report" message is supposed to
> > do? Perhaps it needs similar treatment to the one that a "cleanup"
> > message type gets?
>
> Actually, Chris Dragon is also running into the same problem... could it
> be that new devices are sending these "link_cleanup_report" messages and
> that we are not handling them properly? Here's Chris' post:
>
>
> http://misterhouse.10964.n7.nabble.com/Can-5-Insteon-scene-members-block-the-all-link-cleanup-message-to-PLM-td17733.html#a17766
>
> Chris is seeing this with a RemoteLinc, and I am seeing it with a
> KeypadLinc.
>
> Kevin's theory was that perhaps the RemoteLinc "doesn't have a
> controller record to the PLM in its database" but in the case of my
> KeypadLinc I have a record:
>
> [Insteon::AllLinkDatabase] [0x0fe7] contlr(03) record to $PLM (03),
> (d1:ff, d2:00, d3:03)
>
> Cheers,
>
> Eloy Paris.-
>
>
>
> ------------------------------------------------------------------------------
> Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
> ________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365
>
>

Eloy Paris wrote
> Actually, Chris Dragon is also running into the same problem... could it 
> be that new devices are sending these "link_cleanup_report" messages and 
> that we are not handling them properly? Here's Chris' post:
> 
> http://misterhouse.10964.n7.nabble.com/Can-5-Insteon-scene-members-block-the-all-link-cleanup-message-to-PLM-td17733.html#a17766
> 
> [Insteon::AllLinkDatabase] [0x0fe7] contlr(03) record to $PLM (03), 
> (d1:ff, d2:00, d3:03)

I wasn't talking about all-link cleanup problems in the above post.  I think
I've seen cleanup report messages but haven't noticed any problems, unless
they're what's causing some double calls to state_changed in some cases. 
I've worked around that by adding my own variables that are set to
state_changed the first time state_changed changes.

But the fact you've got d1:ff means your device won't send a direct cleanup
message to the plm, which DOES cause problems.  See
https://github.com/mstovenour/misterhouse/issues/16  You can fix it by
pressing button 3 on your device, then hold the set button on your device
till it beeps and then hold the set button on the plm until both beep. 
After that, d1 should end up set to 03 which means up to 3 retries of the
direct cleanup message.



--
View this message in context: http://misterhouse.10964.n7.nabble.com/Insteon-Created-merged-i2-aldb-support-tp17837p17887.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

Hi Craig,

On 04/30/2013 06:16 PM, Craig wrote:

> On Thu, Apr 25, 2013 at 2:50 PM, Eloy Paris <pe...@ch...
> <mailto:pe...@ch...>> wrote:
>
>     Here's a summary of what I did, in case anyone is interested:
>
>     items.mht:
>
>     -------------------------------------------
>     INSTEON_KEYPADLINCRELAY, 22.91.ed:01, garage_light, All_Lights
>     INSTEON_KEYPADLINCRELAY, 22.91.ed:03, kpl_garage_scene_a, buttons
>
>     INSTEON_ICONTROLLER, 11, kpl_scene_a_light, All_Scenes
>     SCENE_MEMBER, kpl_garage_scene_a, kpl_scene_a_light, on
>     -------------------------------------------
>
> I'm curius why you chose INSTEON_KEYPADLINCRELAY for those buttons. I
> have been trying to implement something similiar to your setup, but I
> had my 8 button keypad configured as an INSTEON_KEYPADLINC. Or do you
> have button one set as a keypadlinc and the others as a relay (which
> sort of makes sense since button one is dimmable  and the others are
> just on/off LEDs?

I used INSTEON_KEYPADLINCRELAY instead of INSTEON_KEYPADLINC just 
because my KeypadLinc is the relay version, not the dimmer version. But 
now that I think about it, I am not positive this is correct because the 
relay only applies to button one, and I suppose the other buttons can be 
used to dim other devices.

I setup all buttons in the same way. Here's the full definition:

INSTEON_KEYPADLINCRELAY, 22.91.ed:01, garage_light, 
All_Lights|Garage|Outside
INSTEON_KEYPADLINCRELAY, 22.91.ed:03, kpl_garage_button_a, hidden
INSTEON_KEYPADLINCRELAY, 22.91.ed:04, kpl_garage_button_b, hidden
INSTEON_KEYPADLINCRELAY, 22.91.ed:05, kpl_garage_button_c, hidden
INSTEON_KEYPADLINCRELAY, 22.91.ed:06, kpl_garage_button_d, hidden

I suppose it's more accurate to use INSTEON_KEYPADLINC for the A, B, C, 
and D buttons...

> Thank you for posting your code. The Insteon learning curve has been
> incredibly steep and the examples here have been invaluable.

Sure thing; glad to help! Hang in there -- it's indeed a steep learning 
curve but assistance here in the list is great.

Cheers,

Eloy Paris.-

On Tue, Apr 30, 2013 at 11:47:41PM -0400, Eloy Paris wrote:
> I used INSTEON_KEYPADLINCRELAY instead of INSTEON_KEYPADLINC just 
> because my KeypadLinc is the relay version, not the dimmer version. But 
> now that I think about it, I am not positive this is correct because the 
> relay only applies to button one, and I suppose the other buttons can be 
> used to dim other devices.

Yes, but keep in mind that relay vs dim is so that MH knows whether it can
send dim commands to the device.
Secondary buttons on a PLM cannot be dimmed, whether it's a dimmer switch or
a relay switch, so it doesn't really matter.
I'm going to assume that the parser is happier if you define
INSTEON_KEYPADLINCRELAY for all the buttons of a given device, so should not
only be fine, but correct.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

On Wed, Apr 24, 2013 at 12:40:29PM -0400, Eloy Paris wrote:
> Okay, thanks Marc. I do not think not being able to sync would be an 
> issue for me right now (I would just link the new devices to the PLM 
> manually). Scan links I think it's good to have, although I disabled the 
> nightly scan a long time ago when I switched to Gregg's "insteon" branch.
> 
> So, I'll just use merge_i2_aldb_support and help with the testing.
> 
> On an unrelated note, Marc, one of my new devices is a KeypadLinc. I 
> have never used one of these before but one of my goals with it is to 
> reflect the status (open or close) of my garage door in one of the KPL's 
> LED. I understand I need to use a "surrogate" option... would you happen 
> to have an example of the configuration syntax? The example in the wiki 
> still shows the old syntax.
 
I don't use the surrogate syntax, I just have normal scenes. You can try
surrogate but if you're not sure how to, just make a normal PLM scene
and then have MH toggle that scene.

> I'm curious to know how this will play out because I interface to my 
> garage door using 1-Wire, not INSTEON... MisterHouse knows when the door 

I did the same :)
(2 wires on top of the microswitch for the door, going to a 1-wire relay
board)

> is open or closed by reading a 1-Wire device, and opens/closes the door 
> by writing to a 1-Wire device. My thought was to have a KPL button 
> initiate, through MH, a write to the 1-Wire device to activate the door, 
> and to have MH write to a KPL button LED to reflect the status of the 
> door. Hopefully this will be possible...

This is what I already do, I just don't have the door open/close status on a
KPL button.
Note however that mh will not know the state of the door for 2 reasons:
1) most doors take 1 toggle for open, 1 toggle for stop open, and 1 toggle
for close. Given that, a toggle could mean stop open or close depending on
current state

2) your garage door closing might fail for various reasons, and you need to
know that.

I solved this with:
1) X10 sensor that actually checks if the door is fully closed or not
2) One webcam to let me visually inspect the door just in case.

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

Hi Marc,

On 04/24/2013 01:10 PM, Marc MERLIN wrote:


> I don't use the surrogate syntax, I just have normal scenes. You can try
> surrogate but if you're not sure how to, just make a normal PLM scene
> and then have MH toggle that scene.

Okay, thanks, I'll play with this.

>> I'm curious to know how this will play out because I interface to my
>> garage door using 1-Wire, not INSTEON... MisterHouse knows when the door
>
> I did the same :)
> (2 wires on top of the microswitch for the door, going to a 1-wire relay
> board)

Nice.

In my case I have a single AVR ATmega-based board that I designed. It 
has one relay (to activate the door) and one digital input that reads a 
Reed switch on the door.

> This is what I already do, I just don't have the door open/close status on a
> KPL button.
> Note however that mh will not know the state of the door for 2 reasons:
> 1) most doors take 1 toggle for open, 1 toggle for stop open, and 1 toggle
> for close. Given that, a toggle could mean stop open or close depending on
> current state
>
> 2) your garage door closing might fail for various reasons, and you need to
> know that.

Right, right; I am not "calculating" the state of the door based on what 
the user does, or the state of some MH variable. Doing that is bound for 
failure because of the factors that you describe.

> I solved this with:
> 1) X10 sensor that actually checks if the door is fully closed or not
> 2) One webcam to let me visually inspect the door just in case.

Yup, I have the same, but in my case, (1) is a 1-Wire device. But the 
end result is the same -- by reading this sensor MisterHouse can know 
whether the door is fully closed.

I'll send an update if I can figure out how to reflect the open/closed 
state of the door on one of the KeypadLinc's button LEDs.

Cheers,

Eloy Paris.-

Hi Chris,

On 04/26/2013 09:54 PM, Chris Dragon wrote:

> Eloy Paris wrote
>> Actually, Chris Dragon is also running into the same problem... could it
>> be that new devices are sending these "link_cleanup_report" messages and
>> that we are not handling them properly? Here's Chris' post:
>>
>> http://misterhouse.10964.n7.nabble.com/Can-5-Insteon-scene-members-block-the-all-link-cleanup-message-to-PLM-td17733.html#a17766
>>
>> [Insteon::AllLinkDatabase] [0x0fe7] contlr(03) record to $PLM (03),
>> (d1:ff, d2:00, d3:03)
>
> I wasn't talking about all-link cleanup problems in the above post.

I thought one of the problems that were affecting you was the seemingly 
invalid state that current code is setting when it receives one of these 
link_cleanup_report messages:

[Insteon::BaseObject] $kpl_garage_button_a::set(link_cleanup_report, 
$kpl_garage_button_a)

> I think
> I've seen cleanup report messages but haven't noticed any problems, unless
> they're what's causing some double calls to state_changed in some cases.

This is the case we currently have when we first set the state to 'off' 
and then to 'link_cleanup_report', right?

> I've worked around that by adding my own variables that are set to
> state_changed the first time state_changed changes.

Yes, I could try to work around the problem via user code.

> But the fact you've got d1:ff means your device won't send a direct cleanup
> message to the plm, which DOES cause problems.  See
> https://github.com/mstovenour/misterhouse/issues/16  You can fix it by
> pressing button 3 on your device, then hold the set button on your device
> till it beeps and then hold the set button on the plm until both beep.
> After that, d1 should end up set to 03 which means up to 3 retries of the
> direct cleanup message.

Yes, I missed the rest of your discussion with Kevin, but I finally read 
all of it and saw what you did. I then reset my KeypadLinc to factory 
settings and started from scratch, this time linking manually instead of 
using MH's sync links. Now the link table looks like this:

04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] Link table for 
$garage_light health: good
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fc7] is empty
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fcf] rspndr(03) 
record to $PLM (11): onlevel=on and ramp=none (d3:03)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fd7] contlr(06) 
record to $PLM (06), (d1:03, d2:1c, d3:06)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fdf] contlr(03) 
record to $PLM (03), (d1:03, d2:1c, d3:03)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fe7] contlr(05) 
record to $PLM (05), (d1:03, d2:1c, d3:05)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fef] contlr(04) 
record to $PLM (04), (d1:03, d2:1c, d3:04)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0ff7] rspndr(01) 
record to $PLM (01): onlevel=off and ramp=none (d3:01)
04/26/13 10:42:37 PM [Insteon::AllLinkDatabase] [0x0fff] contlr(01) 
record to $PLM (01), (d1:03, d2:1c, d3:01)

So d1 is now 0x03 in all entries and am now seeing the direct cleanup 
messages:

04/26/13 09:54:58 PM [Insteon::BaseInterface] DEBUG2: Message received 
with 2 hops left, delaying next transmit to avoid collisions with 
remaining hops.
04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from: 
$kpl_garage_button_b; command: off; type: alllink; group: 04
04/26/13 09:54:58 PM [Insteon::BaseObject] 
$kpl_garage_button_b::set(off, $kpl_garage_button_b)
04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from: 
$kpl_garage_button_b; command: off; type: alllink; group: 04
04/26/13 09:54:58 PM [Insteon::BaseObject] 
$kpl_garage_button_b::set(off, $kpl_garage_button_b)
04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from: 
$kpl_garage_button_b; command: off; type: cleanup; group: 04
04/26/13 09:54:58 PM [Insteon::BaseObject] Ignoring Received Direct 
AllLink Cleanup Message for $kpl_garage_button_b since AllLink Broadcast 
Message was Received.
04/26/13 09:54:59 PM [Insteon::BaseInterface] DEBUG2: Message received 
with 2 hops left, delaying next transmit to avoid collisions with 
remaining hops.
04/26/13 09:54:59 PM [Insteon::BaseInterface] Received message from: 
$kpl_garage_button_b; command: link_cleanup_report; type: alllink; group: 04
04/26/13 09:54:59 PM [Insteon::BaseObject] 
$kpl_garage_button_b::set(link_cleanup_report, $kpl_garage_button_b)

However, the KeypadLinc also sends the link_cleanup_report message, and 
MH sets the state to "link_cleanup_report". That's one thing that is 
causing me problems.

The other is the setting of the same state when we receive the same 
alllink message in short succession, as shown above for the "off" 
command. That can be worked around in user code, as you mention, but we 
probably should handle this situation in the stack itself, just as we do 
for RemoteLincs and montion sensors:

         # motion sensors seem to get multiple fast reports; don't 
trigger on both
[...]
         if (not defined($self->get_idle_time) or $self->get_idle_time > 
1 or $self->state ne $p_state) {
[...]
         } else {
                 &::print_log("[Insteon::MotionSensor] " . 
$self->get_object_name()
                         . "::set_receive($p_state, $setby_name) 
deferred due to repeat within 1 second")
                         if $main::Debug{insteon};
         }

Cheers,

Eloy Paris.-

Eloy Paris wrote
> I thought one of the problems that were affecting you was the seemingly 
> invalid state that current code is setting when it receives one of these 
> link_cleanup_report messages:
> 
> [Insteon::BaseObject] $kpl_garage_button_a::set(link_cleanup_report, 
> $kpl_garage_button_a)
> 
>> I think
>> I've seen cleanup report messages but haven't noticed any problems,
>> unless
>> they're what's causing some double calls to state_changed in some cases.
> 
> This is the case we currently have when we first set the state to 'off' 
> and then to 'link_cleanup_report', right?

Hi Eloy,

That sounds like a good theory.  I hadn't realized
::set(link_cleanup_report... meant it was setting the state to
'link_cleanup_report'.  All I've noticed is that I see state_changed() set
equal to 'on' or 'off' twice in some cases.  I described one case of that
behavior here:
http://misterhouse.10964.n7.nabble.com/state-now-defined-twice-second-time-after-long-running-process-completes-tt17798.html
So it seems that everyone (including me) has been too busy to try to track
down what causes that problem and so I resorted to using my own variable,
but yes, it would certainly be nice if state_changed / state_now was
reliable.

I've also come to realize it would probably be better to report these
problems as issues in the git branch you're using rather than reporting them
here where they're hard to find.


Eloy Paris wrote
> Yes, I missed the rest of your discussion with Kevin, but I finally read 
> all of it and saw what you did. I then reset my KeypadLinc to factory 
> settings and started from scratch, this time linking manually instead of 
> using MH's sync links. Now the link table looks like this:

No need to reset to factory.  You can just hold the set buttons on both
devices and they'll overwrite the ALDB contrlr record that MH created.


Eloy Paris wrote
> 04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from: 
> $kpl_garage_button_b; command: off; type: alllink; group: 04
> 04/26/13 09:54:58 PM [Insteon::BaseObject] 
> $kpl_garage_button_b::set(off, $kpl_garage_button_b)
> 04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from: 
> $kpl_garage_button_b; command: off; type: alllink; group: 04
> ...
> The other is the setting of the same state when we receive the same 
> alllink message in short succession, as shown above for the "off" 
> command. That can be worked around in user code, as you mention, but we 
> probably should handle this situation in the stack itself, just as we do 
> for RemoteLincs and montion sensors:

I haven't noticed a doubled message like that in my system, so far.  I've
read that can happen if you have a bigger network or a lot of wireless
devices.  I feel like the devices themselves should still be smart enough to
filter those out since the whole foundation of Insteon is repeating
messages, but I guess if they get through then MH has to provide its own
filter.  I also wonder if repeated messages are a sign of a glitch in a
particular device.



--
View this message in context: http://misterhouse.10964.n7.nabble.com/Insteon-Created-merged-i2-aldb-support-tp17837p17889.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

Hi Chris,

On 04/26/2013 11:45 PM, Chris Dragon wrote:

> Eloy Paris wrote
>> I thought one of the problems that were affecting you was the seemingly
>> invalid state that current code is setting when it receives one of these
>> link_cleanup_report messages:
>>
>> [Insteon::BaseObject] $kpl_garage_button_a::set(link_cleanup_report,
>> $kpl_garage_button_a)
>>
>>> I think
>>> I've seen cleanup report messages but haven't noticed any problems,
>>> unless
>>> they're what's causing some double calls to state_changed in some cases.
>>
>> This is the case we currently have when we first set the state to 'off'
>> and then to 'link_cleanup_report', right?
>
> Hi Eloy,
>
> That sounds like a good theory.  I hadn't realized
> ::set(link_cleanup_report... meant it was setting the state to
> 'link_cleanup_report'.  All I've noticed is that I see state_changed() set
> equal to 'on' or 'off' twice in some cases.  I described one case of that
> behavior here:
> http://misterhouse.10964.n7.nabble.com/state-now-defined-twice-second-time-after-long-running-process-completes-tt17798.html
> So it seems that everyone (including me) has been too busy to try to track
> down what causes that problem and so I resorted to using my own variable,
> but yes, it would certainly be nice if state_changed / state_now was
> reliable.
>
> I've also come to realize it would probably be better to report these
> problems as issues in the git branch you're using rather than reporting them
> here where they're hard to find.

I usually start with a discussion in the mailing list to see if someone 
has any suggestions because sometimes the problem could be 
misconfiguration or bad user code and not a bug, but you are right -- if 
the issue seems like a bug then it should be reported as such. Old 
habits die hard too, I guess -- for a long time there was no issue 
tracking system and some of us became used to reporting issues here in 
the mailing list.

Anyway, I've just created issue #168 for MH setting an invalid state 
"link_cleanup_report" when an alllink/link_cleanup_report message is 
received.

I will create a separate issue for MH setting the same state for 
(apparently) each duplicate message that it receives after pressing once 
a button on a KeypadLinc (the "INSTEON mesh network" thread in the 
mailing list).

Cheers,

Eloy Paris.-

> Eloy Paris wrote
>> Yes, I missed the rest of your discussion with Kevin, but I finally read
>> all of it and saw what you did. I then reset my KeypadLinc to factory
>> settings and started from scratch, this time linking manually instead of
>> using MH's sync links. Now the link table looks like this:
>
> No need to reset to factory.  You can just hold the set buttons on both
> devices and they'll overwrite the ALDB contrlr record that MH created.
>
>
> Eloy Paris wrote
>> 04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from:
>> $kpl_garage_button_b; command: off; type: alllink; group: 04
>> 04/26/13 09:54:58 PM [Insteon::BaseObject]
>> $kpl_garage_button_b::set(off, $kpl_garage_button_b)
>> 04/26/13 09:54:58 PM [Insteon::BaseInterface] Received message from:
>> $kpl_garage_button_b; command: off; type: alllink; group: 04
>> ...
>> The other is the setting of the same state when we receive the same
>> alllink message in short succession, as shown above for the "off"
>> command. That can be worked around in user code, as you mention, but we
>> probably should handle this situation in the stack itself, just as we do
>> for RemoteLincs and montion sensors:
>
> I haven't noticed a doubled message like that in my system, so far.  I've
> read that can happen if you have a bigger network or a lot of wireless
> devices.  I feel like the devices themselves should still be smart enough to
> filter those out since the whole foundation of Insteon is repeating
> messages, but I guess if they get through then MH has to provide its own
> filter.  I also wonder if repeated messages are a sign of a glitch in a
> particular device.
>

On Wed, Apr 24, 2013 at 01:24:50PM -0400, Eloy Paris wrote:
> I'll send an update if I can figure out how to reflect the open/closed 
> state of the door on one of the KeypadLinc's button LEDs.

If you just use the scene syntax, it really is trivial.
Make a PLM scene that only contains the button(s) you want to switch.
Sync the new scene to the PLM

Then you can say garagestate->set(ON) from perl code.

That's it, that simple, no fuss :)

Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
                                      .... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  

On 04/24/2013 01:28 PM, Marc MERLIN wrote:

> On Wed, Apr 24, 2013 at 01:24:50PM -0400, Eloy Paris wrote:
>> I'll send an update if I can figure out how to reflect the open/closed
>> state of the door on one of the KeypadLinc's button LEDs.
>
> If you just use the scene syntax, it really is trivial.
> Make a PLM scene that only contains the button(s) you want to switch.
> Sync the new scene to the PLM
>
> Then you can say garagestate->set(ON) from perl code.
>
> That's it, that simple, no fuss :)

Great; will try this.

Thanks a bunch.

Eloy Paris.-

Hi Marc,

On 04/24/2013 01:28 PM, Marc MERLIN wrote:

> On Wed, Apr 24, 2013 at 01:24:50PM -0400, Eloy Paris wrote:
>> I'll send an update if I can figure out how to reflect the open/closed
>> state of the door on one of the KeypadLinc's button LEDs.
>
> If you just use the scene syntax, it really is trivial.
> Make a PLM scene that only contains the button(s) you want to switch.
> Sync the new scene to the PLM
>
> Then you can say garagestate->set(ON) from perl code.
>
> That's it, that simple, no fuss :)

I am testing your suggestion, and it does not seem to work because when 
I do garagestate->set(ON) to just turn on the LED associated with the 
button, that causes MisterHouse to think that the button was actually 
pressed, which causes MisterHouse to send a command to activate the 
door. I can control the LED, but when I control the LED it has the side 
effect of activating the door, which I don't want.

Just to make sure I am not missing anything, here's what I have:

items.mht:

------------------------------------------
INSTEON_KEYPADLINCRELAY, 22.91.ed:01, garage_light, 
All_Lights|Garage|Outside
INSTEON_KEYPADLINCRELAY, 22.91.ed:03, kpl_garage_scene_a, buttons

INSTEON_ICONTROLLER, 11, kpl_scene_a_light, All_Scenes
SCENE_MEMBER, kpl_garage_scene_a, kpl_scene_a_light, on
------------------------------------------

User code:

------------------------------------------
# Handle KeypadLinc scene A button press
if ($kpl_garage_scene_a->state_now() ) {
     $garage_centurion->set("dob", 1); # $garage_centurion is an 
Owfs_Item. This toggles the garage door
}

if ($state = state_changed $garage_door) {
     # Update indicator in KeypadLinc by the garage entrance
     $kpl_scene_a_light->set($state eq "open" ? ON : OFF, 
"garage_door.pl"); ---> Does not work because it'll cause the door to be 
toggled above
}
------------------------------------------

Cheers,

Eloy Paris.-

On Thu, Apr 25, 2013 at 7:46 AM, Eloy Paris <pe...@ch...> wrote:

> User code:
>
> ------------------------------------------
> # Handle KeypadLinc scene A button press
> if ($kpl_garage_scene_a->state_now() ) {
>      $garage_centurion->set("dob", 1); # $garage_centurion is an
> Owfs_Item. This toggles the garage door
> }
>

You just need to add a test to see who set the kpl button.  Change the
first line to this:

 if ($kpl_garage_scene_a->state_now() && ref
$kpl_garage_scene_a->get_set_by && $kpl_garage_scene_a->get_set_by eq
$kpl_garage_scene_a) {

The two additional tests ask:
1. Was the KPL Button set by an object?
2. Was that object the KPL Button itself?
Only if these two things are true, will the garage door open.

I can't claim complete ownership of this solution, the idea was spurred a
ling time ago by:

http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#Blending
Local Control and Automation

Hi Kevin,

On 04/25/2013 12:33 PM, Kevin Robert Keegan wrote:

> On Thu, Apr 25, 2013 at 7:46 AM, Eloy Paris <pe...@ch...
> <mailto:pe...@ch...>> wrote:
>
>     User code:
>
>     ------------------------------------------
>     # Handle KeypadLinc scene A button press
>     if ($kpl_garage_scene_a->state_now() ) {
>           $garage_centurion->set("dob", 1); # $garage_centurion is an
>     Owfs_Item. This toggles the garage door
>     }
>
>
> You just need to add a test to see who set the kpl button.  Change the
> first line to this:
>
>   if ($kpl_garage_scene_a->state_now() && ref
> $kpl_garage_scene_a->get_set_by && $kpl_garage_scene_a->get_set_by eq
> $kpl_garage_scene_a) {
>
> The two additional tests ask:
> 1. Was the KPL Button set by an object?
> 2. Was that object the KPL Button itself?
> Only if these two things are true, will the garage door open.
>
> I can't claim complete ownership of this solution, the idea was spurred
> a ling time ago by:
>
> http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#Blending
> Local Control and Automation

Funny you should mention this since this is exactly what I am trying to 
do right now, i.e. use set_by(). I had started to code it up and then 
saw your message. I had seen the "Blending Local Control and Automation" 
section but it was a long time ago, and didn't recall anything about it 
until you mentioned it.

Having said that, what I coded before seeing your email is not working 
so I'll take another look based on what you write above; thanks a bunch!

I'll report back...

Eloy Paris.-

Kevin, Marc, and anyone following this thread:

On 04/25/2013 12:33 PM, Kevin Robert Keegan wrote:

> On Thu, Apr 25, 2013 at 7:46 AM, Eloy Paris <pe...@ch...
> <mailto:pe...@ch...>> wrote:
>
>     User code:
>
>     ------------------------------------------
>     # Handle KeypadLinc scene A button press
>     if ($kpl_garage_scene_a->state_now() ) {
>           $garage_centurion->set("dob", 1); # $garage_centurion is an
>     Owfs_Item. This toggles the garage door
>     }
>
>
> You just need to add a test to see who set the kpl button.  Change the
> first line to this:
>
>   if ($kpl_garage_scene_a->state_now() && ref
> $kpl_garage_scene_a->get_set_by && $kpl_garage_scene_a->get_set_by eq
> $kpl_garage_scene_a) {
>
> The two additional tests ask:
> 1. Was the KPL Button set by an object?
> 2. Was that object the KPL Button itself?
> Only if these two things are true, will the garage door open.
>
> I can't claim complete ownership of this solution, the idea was spurred
> a ling time ago by:
>
> http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#Blending
> Local Control and Automation

This worked like a charm; thanks a lot for sharing. What an elegant 
solution!

Here's a summary of what I did, in case anyone is interested:

items.mht:

-------------------------------------------
INSTEON_KEYPADLINCRELAY, 22.91.ed:01, garage_light, All_Lights
INSTEON_KEYPADLINCRELAY, 22.91.ed:03, kpl_garage_scene_a, buttons

INSTEON_ICONTROLLER, 11, kpl_scene_a_light, All_Scenes
SCENE_MEMBER, kpl_garage_scene_a, kpl_scene_a_light, on
-------------------------------------------

(So, definitions for the garage light controlled by the KPL [group 01], 
the button I chose to control the garage door and monitor its status 
[group 03, Scene A button on the KPL], and a PLM scene that I'll use to 
turn ON or OFF the LED associated with the button that I chose.)

User code:

-------------------------------------------
# Keeps track of the garage door state, i.e. open or closed.
$garage_door = new Generic_Item; # noloop

# Handle KeypadLinc scene A button press
if ($kpl_garage_scene_a->state_now()
     && ref $kpl_garage_scene_a->get_set_by()
     && $kpl_garage_scene_a->get_set_by() eq $kpl_garage_scene_a) {
     # KeypadLinc button was pressed; activate (toggle) garage door
     $garage_centurion->set("dob", 1);
}

# Read Digital Input channel A (sensor on garage door)
if (new_second(30) ) {
     set $garage_door ($garage_centurion->get("dia") == 0 ? "closed" : 
"open");
}

if ($state = state_changed $garage_door) {
     net_mail_send to => 'pe...@ch...', subject => "Garage door is 
now $state<EOM>";

     # Update indicator in KeypadLinc by the garage entrance
     $kpl_scene_a_light->set($state eq "open" ? ON : OFF, "garage_door.pl");
}
-------------------------------------------

The end result is this:

1. When the garage door changes state (open -> close, or close -> open), 
the LED associated with one button of the KPL will turn on (door is 
open), or off (door is closed).

2. Pressing that button in the KPL will toggle the door (same thing as 
pressing the button in the garage door opener attached to the wall in 
the garage, or in one of the remotes in our cars, with the difference 
that this KPL is on the inside of the house, right next to the door that 
gives access to the garage).

I like this arrangement a lot because it will allow us to see if we 
forgot to close the garage door by taking a quick look at the KPL from 
our kitchen, without having to open the door to the garage and taking a 
peek (yeah, we're that lazy, but we do exercise ;-) ).

There's a few seconds delay between the time the door fully closes and 
the time the KPL LED reflects the new door state because the garage door 
sensor is a 1-Wire device that has to be polled (because that's how the 
1-Wire bus works), but I absolutely can live with that.

Thanks again to you and Marc for the help and suggestions.

Cheers,

Eloy Paris.-