MisterHouse: Home Automation with Perl

On Mon, Nov 05, 2012 at 06:28:53PM -0600, John wrote:
> I was looking at the todo list here:
> 
>      http://misterhouse.wikispaces.com/Insteon+Redux
> 
> Which of those is considered something that needs to be addressed before 
> code is merged into master?  Impression is they are mostly not critical 
> but I thought there were functional gaps in insteon branch.

If you can get sync all links and delete orphan links to work reliably and
converge on a network with more than 10 items let's say, I would then say
the code is good enough to push.

Speaking of which, who is moderator of this list? The forced reply to that
tries to prevent replying to the author+the list is starting to piss me off
to be honest.

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 John,

On 11/05/2012 07:28 PM, John wrote:

> I was looking at the todo list here:
>
>       http://misterhouse.wikispaces.com/Insteon+Redux
>
> Which of those is considered something that needs to be addressed before
> code is merged into master?  Impression is they are mostly not critical
> but I thought there were functional gaps in insteon branch.

I'd say the link management stuff is the most important part to have 
working well before the branch can be merged into the trunk. It's not 
just practical to have to do link management manually.

Sorry I am not more specific but there is a lot of memory/link 
management items in that list! :-(

Cheers,

Eloy Paris.-

Hi Marc,

I don't believe this list is moderated by anyone.  I am one of the admins for the list and this isn't familiar to me.

-----Original Message-----
From: Marc MERLIN [mailto:marc_mh@...] 
Sent: Tuesday, November 06, 2012 1:14 AM
To: The main list for the MisterHouse home automation program
Subject: Re: [mh] Insteon Branch: Todo

On Mon, Nov 05, 2012 at 06:28:53PM -0600, John wrote:
> I was looking at the todo list here:
> 
>      http://misterhouse.wikispaces.com/Insteon+Redux
> 
> Which of those is considered something that needs to be addressed 
> before code is merged into master?  Impression is they are mostly not 
> critical but I thought there were functional gaps in insteon branch.

If you can get sync all links and delete orphan links to work reliably and converge on a network with more than 10 items let's say, I would then say the code is good enough to push.

Speaking of which, who is moderator of this list? The forced reply to that tries to prevent replying to the author+the list is starting to piss me off to be honest.

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/  

------------------------------------------------------------------------------
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center Diagnose problems and improve visibility into emerging IT issues Automate, monitor and manage. Do more in less time with Central http://p.sf.net/sfu/logmein12331_d2d
________________________________________________________
To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

> 
> If you can get sync all links and delete orphan links to work reliably and
> converge on a network with more than 10 items let's say, I would then say
> the code is good enough to push.
> 

Is Gregg planning to finish this?  Gregg, you listening?
This might be something I'd be willing to take on, if Gregg isn't interested.

Jim

On Tue, Nov 06, 2012 at 03:24:22PM +0000, Jim Duda wrote:
> > 
> > If you can get sync all links and delete orphan links to work reliably and
> > converge on a network with more than 10 items let's say, I would then say
> > the code is good enough to push.
> 
> Is Gregg planning to finish this?  Gregg, you listening?
> This might be something I'd be willing to take on, if Gregg isn't interested.

I talked to him a while ago, and the answer is most likely not.

He has had family things that have been much more important and last I
talked to him, he didn't sound like he was going to be able to finish
working on the code.
But just before that, he did work with me and added a lot of code that made
the insteon branch almost finished. I do think it's pretty close.

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 <marc_mh <at> merlins.org> writes:

>
> He has had family things that have been much more important and last I
> talked to him, he didn't sound like he was going to be able to finish
> working on the code.

Family trumps all for sure.  I'm thrilled with what he's given us so far.

> But just before that, he did work with me and added a lot of code that made
> the insteon branch almost finished. I do think it's pretty close.

Is this code checked into svn (or git) at this time?  What more needs to be done 
then?

Jim

On Nov 6, 2012 10:31 AM, "Jim Duda" <jim@...> wrote:

> Is this code checked into svn (or git) at this time?  What more needs to
be done
> then?

Reasonable assumption it is checked in based on thread so far.  Marc can
confirm.

Earlier in thread the robustness of syncing links and delete orphans with
more than 10 devices in system was raised.  I was going to look at this but
will have a very steep learning curve.  Maybe we can come up with way to
work together on it unless it's the kind of thing you think you can crank
out.

John

On Tue, Nov 06, 2012 at 11:39:58AM -0600, John wrote:
> On Nov 6, 2012 10:31 AM, "Jim Duda" <jim@...> wrote:
> 
> > Is this code checked into svn (or git) at this time?  What more needs to
> be done
> > then?
> 
> Reasonable assumption it is checked in based on thread so far.  Marc can
> confirm.
 
All the code that Gregg wrote that I know about is in svn and therefore git
in the insteon branch.

> Earlier in thread the robustness of syncing links and delete orphans with
> more than 10 devices in system was raised.  I was going to look at this but
> will have a very steep learning curve.  Maybe we can come up with way to
> work together on it unless it's the kind of thing you think you can crank
> out.

I have a complicated network with noise, so I'm great for finding bugs.
Gregg before signing out put a fair amount of work into fixing some problems
I saw as well as allowing delete orphans and sync all links.
Last I checked the code wasn't flawless but worked mostly.

We never got to a point where Gregg felt comfortable that I run delete
orphans and sync all links a few times in a row, when technically those are
supposed to be invariants once everything is synced.

If someone has time to work on the code, I'm happy to lend my house as a
test and provide detailled feedback at the expense of my links and stuff
working at home as long as you're somewhat available to act on the feedback
and help fix problems that are found :)
(my nightmare scenario is a sync that breaks a lot of things in my house and
would require over a full day of fixing everything manually)

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/

Gentlemen,

The other piece that is missing is the version 2 support.  Version 2
devices require they be linked to the PLM before it can control even a
simple on or off or basically talk to it in any meaningful way.  This
has been problematic and I have actually resorted to manually linking.

George


On Tue, 2012-11-06 at 09:54 -0800, Marc MERLIN wrote:
> On Tue, Nov 06, 2012 at 11:39:58AM -0600, John wrote:
> > On Nov 6, 2012 10:31 AM, "Jim Duda" <jim@...> wrote:
> > 
> > > Is this code checked into svn (or git) at this time?  What more needs to
> > be done
> > > then?
> > 
> > Reasonable assumption it is checked in based on thread so far.  Marc can
> > confirm.
>  
> All the code that Gregg wrote that I know about is in svn and therefore git
> in the insteon branch.
> 
> > Earlier in thread the robustness of syncing links and delete orphans with
> > more than 10 devices in system was raised.  I was going to look at this but
> > will have a very steep learning curve.  Maybe we can come up with way to
> > work together on it unless it's the kind of thing you think you can crank
> > out.
> 
> I have a complicated network with noise, so I'm great for finding bugs.
> Gregg before signing out put a fair amount of work into fixing some problems
> I saw as well as allowing delete orphans and sync all links.
> Last I checked the code wasn't flawless but worked mostly.
> 
> We never got to a point where Gregg felt comfortable that I run delete
> orphans and sync all links a few times in a row, when technically those are
> supposed to be invariants once everything is synced.
> 
> If someone has time to work on the code, I'm happy to lend my house as a
> test and provide detailled feedback at the expense of my links and stuff
> working at home as long as you're somewhat available to act on the feedback
> and help fix problems that are found :)
> (my nightmare scenario is a sync that breaks a lot of things in my house and
> would require over a full day of fixing everything manually)
> 
> Marc

John <john <at> tonebridge.com> writes:

> Earlier in thread the robustness of syncing links and delete orphans with more 
than 10 devices in system was raised.  I was going to look at this but will have 
a 
very steep learning curve.  Maybe we can come up with way to work together on it 
unless it's the kind of thing you think you can crank out.

I have a learning curve to, but I expect to be able to figure it out at some 
point.  I have interest in working on this, but certainly didn't want to step on 
anything Gregg was working on at the time.  

I cannot make any promises, but I will start studying how all of this works.

Jim

On Tue, Nov 06, 2012 at 10:11:25AM -0800, George Farris wrote:
> Gentlemen,
> 
> The other piece that is missing is the version 2 support.  Version 2
> devices require they be linked to the PLM before it can control even a
> simple on or off or basically talk to it in any meaningful way.  This
> has been problematic and I have actually resorted to manually linking.

That is not a blocker for replacing the old code with the new.

Priority #1 is to have a unified tree.

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 Tue, 2012-11-06 at 14:21 -0800, Marc MERLIN wrote:
> On Tue, Nov 06, 2012 at 10:11:25AM -0800, George Farris wrote:
> > Gentlemen,
> > 
> > The other piece that is missing is the version 2 support.  Version 2
> > devices require they be linked to the PLM before it can control even a
> > simple on or off or basically talk to it in any meaningful way.  This
> > has been problematic and I have actually resorted to manually linking.
> 
> That is not a blocker for replacing the old code with the new.
> 
> Priority #1 is to have a unified tree.
> 
> Marc

I think you are talking about the Git Branch thread Marc, I was
referring to the Insteon Todo thread.

George

On 11/06/12 16:48, George Farris wrote:
> On Tue, 2012-11-06 at 14:21 -0800, Marc MERLIN wrote:
>> On Tue, Nov 06, 2012 at 10:11:25AM -0800, George Farris wrote:
>>> Gentlemen,
>>>
>>> The other piece that is missing is the version 2 support.  Version 2
>>> devices require they be linked to the PLM before it can control even a
>>> simple on or off or basically talk to it in any meaningful way.  This
>>> has been problematic and I have actually resorted to manually linking.
>>
>> That is not a blocker for replacing the old code with the new.
>>
>> Priority #1 is to have a unified tree.
>>
>> Marc
>
> I think you are talking about the Git Branch thread Marc, I was
> referring to the Insteon Todo thread.

For Todo, it makes sense that we focus on what is needed to merge 
insteon branch back in to master no matter what version control system 
is used.  Once we get that base exposure to a larger group we can extend 
it with another branch to address v2.  Of course if someone can start 
looking at design changes needed to add v2 that will help get a jump on 
things.

John

Op 7-nov.-2012, om 00:05 heeft John <john@...> het volgende geschreven:

> On 11/06/12 16:48, George Farris wrote:
>> On Tue, 2012-11-06 at 14:21 -0800, Marc MERLIN wrote:
>>> On Tue, Nov 06, 2012 at 10:11:25AM -0800, George Farris wrote:
>>>> Gentlemen,
>>>> 
>>>> The other piece that is missing is the version 2 support.  Version 2
>>>> devices require they be linked to the PLM before it can control even a
>>>> simple on or off or basically talk to it in any meaningful way.  This
>>>> has been problematic and I have actually resorted to manually linking.
>>> 
>>> That is not a blocker for replacing the old code with the new.
>>> 
>>> Priority #1 is to have a unified tree.
>>> 
>>> Marc
>> 
>> I think you are talking about the Git Branch thread Marc, I was
>> referring to the Insteon Todo thread.
> 
> For Todo, it makes sense that we focus on what is needed to merge 
> insteon branch back in to master no matter what version control system 
> is used.

I agree completely. A single master branch where people can contribute code to is much more efficient to maintain.

Lieven.

Hello all,

Op 7-nov.-2012, om 00:05 heeft John <john@...> het volgende geschreven:

> 
> For Todo, it makes sense that we focus on what is needed to merge 
> insteon branch back in to master no matter what version control system 
> is used.

As a first step in merge preparation: as you can see here
https://github.com/hollie/misterhouse/branches

insteon branch is 33 commits behind master. This means there were 33 operations in the master branch that did not make it into insteon. The effect of this is that if people want to commit a change to the two branches, they need to manually apply that change to the two branches. See the mail with Jim on his changes to android_server.pl. This way of working is totally not cool/efficient and it is a problem that needs to be solved regardless of the VCS we use. The advantage of git is that we're able to see what the status of the branches is compared to each other and that we can try to merge the changes nicely. (Who knew insteon was 33 commits behind master when we were using SVN?)

My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch?

To do this, we should bring those changes to the insteon branch. This is easily done with a command, but of course there are some merge conflicts:

$ git status
# On branch insteon
nothing to commit (working directory clean)
$ git merge master
Auto-merging web/bin/items.pl
CONFLICT (content): Merge conflict in web/bin/items.pl
Auto-merging lib/xPL_Items.pm
CONFLICT (content): Merge conflict in lib/xPL_Items.pm
Auto-merging lib/Generic_Item.pm
Auto-merging bin/mh.ini
Auto-merging bin/mh
Automatic merge failed; fix conflicts and then commit the result.

If we can fix the conflicts (I have no time to look into them right now and I don't have insteon hardware to test) then we have master and insteon again in one-way sync and then if Jim want to add a feature to android_server,pl he can do this in master, commit it and to a 

git checkout insteon
git merge master

To bring his changes to the insteon branch.

This is way cooler than having to change the same file in the same way in the two branches as it needs to be done now.

The next step would then be of course merging insteon back into master when the code is stable enough.

Kind regards,
 Lieven.

On 11/07/12 02:11, Lieven Hollevoet wrote:
> Hello all,
>
> Op 7-nov.-2012, om 00:05 heeft John <john@...> het volgende geschreven:
>
>>
>> For Todo, it makes sense that we focus on what is needed to merge
>> insteon branch back in to master no matter what version control system
>> is used.
>
> As a first step in merge preparation: as you can see here
> https://github.com/hollie/misterhouse/branches
>
> insteon branch is 33 commits behind master. This means there were 33 operations in the master branch that did not make it into insteon. The effect of this is that if people want to commit a change to the two branches, they need to manually apply that change to the two branches. See the mail with Jim on his changes to android_server.pl. This way of working is totally not cool/efficient and it is a problem that needs to be solved regardless of the VCS we use. The advantage of git is that we're able to see what the status of the branches is compared to each other and that we can try to merge the changes nicely. (Who knew insteon was 33 commits behind master when we were using SVN?)

Thanks for pointing this out.  In addition to the extra effort needed to 
commit changes, it would probably also be the case that those using 
insteon branch aren't testing with a version that reflects how things 
will be when we merge the insteon changes back into master.  Sorry if 
this is obvious but I have been a manager type for a long time now.

> My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch?

I can spend some time doing this.  Probably makes sense to have those 
that are working on this commit changes often so we don't duplicate our 
work.   Also, thanks for providing the workflow steps.

John

On Wed, Nov 07, 2012 at 09:11:17AM +0100, Lieven Hollevoet wrote:
> My first proposal for starting to bring the branches closer together again is: could somebody involved in the insteon branch test if the changes to master are OK for the insteon branch?
 
I don't mind, after they've been merged, even if I don't use all the
hardware that's in mh.
I did a manual merge with svn a long time ago, so thanks for doing this one.

> The next step would then be of course merging insteon back into master when the code is stable enough.

So, all of us have been a bit worried about doing this, because the insteon
branch isn't technically finished, but at the same time many of us are
running the insteon branch now.
At the same time, the master branch's insteon code isn't stellar either in
other ways.

Considering that we have svn left behind now, I actually think that it
would be ok to collapse the two branches and make the new insteon code the
master code.
If it somehow breaks someone, they're not dead in the water because they can
still fall back to the old code in svn, report the problem, and hopefully
someone can help fix this in the new code.

So while I can't call myself the backup insteon maintainer, I think it's
time to fold both branches at least in git since the possible problems
this might cause are likely far outweighed by the cost of those 2 branches.


There is also the problem if all that insteon documentation I wrote that
uses the old syntax.
If someone feels inspired to update it with the new syntax, you have my
blessing as long as for now we only update the syntax to use.
After that if you want to further improve the insteon wiki, that can be done 
separately.
If there are no volunteers, I'll see if I can make some time to do it.

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 <marc_mh <at> merlins.org> writes:

 
> Considering that we have svn left behind now, I actually think that it
> would be ok to collapse the two branches and make the new insteon code the
> master code.
> If it somehow breaks someone, they're not dead in the water because they can
> still fall back to the old code in svn, report the problem, and hopefully
> someone can help fix this in the new code.
> 

I agree 100%.  I haven't used the trunk in a long time.  I find the insteon
branch very stable.  I myself don't need the automatic link management as the
number of times I add a new Insteon device is rather rare.

I say we cut-the-cord on the older insteon implementation, move forward 
with the insteon branch, and add the missing pieces required, falling back
on SVN with the necessary code references to port.

Regards,

Jim

On 11/07/2012 09:35 AM, Marc MERLIN wrote:

[...]

> Considering that we have svn left behind now, I actually think that it
> would be ok to collapse the two branches and make the new insteon code the
> master code.

I would agree with this.

> If it somehow breaks someone, they're not dead in the water because they can
> still fall back to the old code in svn, report the problem, and hopefully
> someone can help fix this in the new code.
>
> So while I can't call myself the backup insteon maintainer, I think it's
> time to fold both branches at least in git since the possible problems
> this might cause are likely far outweighed by the cost of those 2 branches.

Yes.

Also, exposing the INSTEON stack in the insteon branch to a wider 
audience will hopefully help to iron out bugs and issues.

Cheers,

Eloy Paris.-

Hi,

I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.

https://github.com/hollie/misterhouse/pull/12

I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?

git clone git@...
cd misterhouse
git checkout -b branch_merge_phase1 origin/branch_merge_phase1

test and report back please

If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.

Hope this branch works without big problems, then the merging operation is almost complete.

I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 

Kind regards,
 Lieven.

Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:

> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
> 
> [...]
> 
>> Considering that we have svn left behind now, I actually think that it
>> would be ok to collapse the two branches and make the new insteon code the
>> master code.
> 
> I would agree with this.
> 
>> If it somehow breaks someone, they're not dead in the water because they can
>> still fall back to the old code in svn, report the problem, and hopefully
>> someone can help fix this in the new code.
>> 
>> So while I can't call myself the backup insteon maintainer, I think it's
>> time to fold both branches at least in git since the possible problems
>> this might cause are likely far outweighed by the cost of those 2 branches.
> 
> Yes.
> 
> Also, exposing the INSTEON stack in the insteon branch to a wider 
> audience will hopefully help to iron out bugs and issues.
> 
> Cheers,
> 
> Eloy Paris.-
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>

On 11/07/12 15:20, Lieven Hollevoet wrote:
> test and report back please

Thanks!

On first start of mh, there were no insteon debug messages indicating 
device scan.   However, lights on/off worked.  On restart I got what I 
expected.  For example:

11/07/12 05:53:39 PM [Insteon::BaseObject] received status for $backyard 
with on-level: 0%, hops left: 0

However, I recall this happening with insteon branch previously and I 
attributed it to how things are (and beyond my current understanding).

Tested: lircd interface turning on Insteon scene on/off (works)
Tested: Serial Weeder interface (works)
Tested: receive xpl message (works)

After this I ran through things on plm and devices like syncing links. 
To be honest, it is not clear to me what these do.  Stuff seems to work 
without those steps so maybe there is something persistent from last 
version and my testing is not conclusive.  If there is docs that 
describe this let me know otherwise I will continue to go through the code.

Nothing seems out of ordinary in logs.

I will continue to work with it and report back if anything comes up.

John

On 11/07/2012 04:20 PM, Lieven Hollevoet wrote:
> Hi,
>
> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
>
> https://github.com/hollie/misterhouse/pull/12
>
> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
>
> git clone git@...
> cd misterhouse
> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
>
> test and report back please
>
> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
>
> Hope this branch works without big problems, then the merging operation is almost complete.
>
> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish.

I am up and running on this version.  So far so good.

Jim

Wow, don't check in for a few days and lot occurs.

I am in inadvertently on the old branch and running a lfs version of
linux.  From a NOOB status, can I assume:

that I need to download git and compile it from source

then use the commands further up the thread to checkout the new branch
we are working on.

Make the symlink change to point to the new branch

Update my insteon.mht to a newer format?

My network is not huge yet, but pushing 18 switches, devices, and
moving onto the 20's soon.  Should give it a bit of a shake out as
well.

On 11/07/2012 08:05 PM, Jim Duda wrote:

>
> I am up and running on this version.  So far so good.

I had to stop using this version.  It appears something is wrong with 
xAP messages.  I don't use much xAP, but some.  One of my modules which 
listens for xAP messages is not getting them.  I returned to the 
original insteon branch from git, and I'm getting xAP messages.

I can debug in more detail at a later time.

Maybe someone with more xAP requirements should test too.

Regards,

Jim

On 11/07/12 19:05, Alan Womack wrote:
> Wow, don't check in for a few days and lot occurs.
>
> I am in inadvertently on the old branch and running a lfs version of
> linux.  From a NOOB status, can I assume:
>
> that I need to download git and compile it from source
>
> then use the commands further up the thread to checkout the new branch
> we are working on.

If you just want to test, you do not need to use git.   From the github 
site, you can select the branch "branch_merge_phase1" and then hit the 
ZIP button.  You can extract that in a location you can point your 
symlink to.

>
> Make the symlink change to point to the new branch
>
> Update my insteon.mht to a newer format?

Yes, you will want to update your Insteon items.   You can refer to the 
wiki page for details on this.  For sure back up your existing mht file 
first.

Jim,

On Thu, Nov 8, 2012 at 3:11 AM, Jim Duda <jim@...> wrote:

> On 11/07/2012 08:05 PM, Jim Duda wrote:
>
> >
> > I am up and running on this version.  So far so good.
>
> I had to stop using this version.  It appears something is wrong with
> xAP messages.  I don't use much xAP, but some.  One of my modules which
> listens for xAP messages is not getting them.  I returned to the
> original insteon branch from git, and I'm getting xAP messages.
>
>
There was an update in mh.ini with new xAP-related settings. Amongst
others, the built-in xAP hub is disabled by default.
https://github.com/hollie/misterhouse/commit/8dba1524fcfa531be63affd46c64046862c71f7b

You might need to look in that direction.

Kind regards,
 Lieven.

On 11/08/2012 03:13 AM, Lieven Hollevoet wrote:
> 
> There was an update in mh.ini with new xAP-related settings. Amongst others, the built-in xAP hub is disabled by default.
> https://github.com/hollie/misterhouse/commit/8dba1524fcfa531be63affd46c64046862c71f7b
> 
> You might need to look in that direction.
> 
> Kind regards,
>   Lieven.
> 

Lieven,

Yes indeed, that was the issue.  I am back up and running live on branch_merge_phase1
My xAP messages are restored with the internal hub turned on.

linux> git branch -v
* insteon 8dba152 [ahead 42] Merge branch 'master' into branch_merge_phase1
  master  a08416e Merge pull request #11 from hollie/fix_issue_10

Regards,

Jim

We need to prepare everyone for when we merge the insteon branch to 
become the master.  Folks are going to have to convert their MHT files. 
  Maybe we should find a few to beta the conversion such that we can get 
the kinks out of the process?

Regards,

Jim

When you merge, anyone using the Insteon thermostat module will be broken.
 I think there is another module as well that has not been ported.
I am working on the thermostat module now, but it may be a couple of
weeks before I get enough time to complete it.

Are we aware of any other devices that will not function after the merge?


On Thu, Nov 8, 2012 at 8:16 PM, Jim Duda <jim@...> wrote:

> We need to prepare everyone for when we merge the insteon branch to
> become the master.  Folks are going to have to convert their MHT files.
>   Maybe we should find a few to beta the conversion such that we can get
> the kinks out of the process?
>
> Regards,
>
> Jim
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> ________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365
>
>

On Wed, Nov 07, 2012 at 08:27:57PM -0600, John wrote:
> > Update my insteon.mht to a newer format?
> 
> Yes, you will want to update your Insteon items.   You can refer to the 
> wiki page for details on this.  For sure back up your existing mht file 
> first.

On Thu, Nov 08, 2012 at 08:16:06PM -0500, Jim Duda wrote:
> We need to prepare everyone for when we merge the insteon branch to 
> become the master.  Folks are going to have to convert their MHT files. 
>   Maybe we should find a few to beta the conversion such that we can get 
> the kinks out of the process?

For both those Emails.

You can use my convertion script:
http://misterhouse.svn.sourceforge.net/viewvc/misterhouse/branches/insteon/lib/Insteon/convert_insteon_config?revision=1958

It's not foolproof, and totally relies on you using my commenting format at
the end of each line (as per the examples I wrote on the wiki), but it'll
do most of the work or at least help you convert your config.

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/

HiAll,

I notice that the InlineLinc does not appear in the list of device tags.  I suppose is it functionally similar to a LampLinc.  Has anyone tried it?

Regards,
Tom

On 2012-11-08, at 11:43 PM, Marc MERLIN <marc_mh@...> wrote:

> On Wed, Nov 07, 2012 at 08:27:57PM -0600, John wrote:
>>> Update my insteon.mht to a newer format?
>> 
>> Yes, you will want to update your Insteon items.   You can refer to the 
>> wiki page for details on this.  For sure back up your existing mht file 
>> first.
> 
> On Thu, Nov 08, 2012 at 08:16:06PM -0500, Jim Duda wrote:
>> We need to prepare everyone for when we merge the insteon branch to 
>> become the master.  Folks are going to have to convert their MHT files. 
>>  Maybe we should find a few to beta the conversion such that we can get 
>> the kinks out of the process?
> 
> For both those Emails.
> 
> You can use my convertion script:
> http://misterhouse.svn.sourceforge.net/viewvc/misterhouse/branches/insteon/lib/Insteon/convert_insteon_config?revision=1958
> 
> It's not foolproof, and totally relies on you using my commenting format at
> the end of each line (as per the examples I wrote on the wiki), but it'll
> do most of the work or at least help you convert your config.
> 
> 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/  
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

On Tue, Nov 13, 2012 at 09:23:26PM -0500, Thomas MacLean wrote:
> HiAll,
> 
> I notice that the InlineLinc does not appear in the list of device tags.  I suppose is it functionally similar to a LampLinc.  Has anyone tried it?

Wait, doesn't it come with a switch? If so it should be a switchlinc.

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/

No, it's doesn't have a user switch.  It has a button, like the (old) LampLinc.


On 2012-11-13, at 9:31 PM, Marc MERLIN <marc_mh@...> wrote:

> On Tue, Nov 13, 2012 at 09:23:26PM -0500, Thomas MacLean wrote:
>> HiAll,
>> 
>> I notice that the InlineLinc does not appear in the list of device tags.  I suppose is it functionally similar to a LampLinc.  Has anyone tried it?
> 
> Wait, doesn't it come with a switch? If so it should be a switchlinc.
> 
> 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/  
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

On Tue, Nov 13, 2012 at 09:42:51PM -0500, Thomas MacLean wrote:
> No, it's doesn't have a user switch.  It has a button, like the (old) LampLinc.
 
Then Lamplinc is probably is. You can try both if that was wrong :)

Marc
 
> On 2012-11-13, at 9:31 PM, Marc MERLIN <marc_mh@...> wrote:
> 
> > On Tue, Nov 13, 2012 at 09:23:26PM -0500, Thomas MacLean wrote:
> >> HiAll,
> >> 
> >> I notice that the InlineLinc does not appear in the list of device tags.  I suppose is it functionally similar to a LampLinc.  Has anyone tried it?
> > 
> > Wait, doesn't it come with a switch? If so it should be a switchlinc.
> > 
> > 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/  
> > 
> > ------------------------------------------------------------------------------
> > Monitor your physical, virtual and cloud infrastructure from a single
> > web console. Get in-depth insight into apps, servers, databases, vmware,
> > SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pricing starts from $795 for 25 servers or applications!
> > http://p.sf.net/sfu/zoho_dev2dev_nov
> > ________________________________________________________
> > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> 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/

Hi Lieven,

not to confuse the matter too much , but...  can you explain how I should pull your "branch_merge_phase1" from your repo into my fork?

I had managed to re-synch up with:

git remote add original https://github.com/hollie/misterhouse.git
git pull original master
git push origin master

but then I got a bit lost trying to get your branch into my fork.

One bad route is:  git pull original branch_merge_phase1 .. this pulled your branch into my master.  It complained about a bad merge for xPL_Items.pm.
I think I'd rather have branch that matches yours, no?

Thanks for any guidance.

Regards,
Tom


On 2012-11-07, at 4:20 PM, Lieven Hollevoet <lieven@...> wrote:

> Hi,
> 
> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
> 
> https://github.com/hollie/misterhouse/pull/12
> 
> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
> 
> git clone git@...
> cd misterhouse
> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
> 
> test and report back please
> 
> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
> 
> Hope this branch works without big problems, then the merging operation is almost complete.
> 
> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 
> 
> Kind regards,
> Lieven.
> 
> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:
> 
>> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
>> 
>> [...]
>> 
>>> Considering that we have svn left behind now, I actually think that it
>>> would be ok to collapse the two branches and make the new insteon code the
>>> master code.
>> 
>> I would agree with this.
>> 
>>> If it somehow breaks someone, they're not dead in the water because they can
>>> still fall back to the old code in svn, report the problem, and hopefully
>>> someone can help fix this in the new code.
>>> 
>>> So while I can't call myself the backup insteon maintainer, I think it's
>>> time to fold both branches at least in git since the possible problems
>>> this might cause are likely far outweighed by the cost of those 2 branches.
>> 
>> Yes.
>> 
>> Also, exposing the INSTEON stack in the insteon branch to a wider 
>> audience will hopefully help to iron out bugs and issues.
>> 
>> Cheers,
>> 
>> Eloy Paris.-
>> 
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>> 
> 
> 
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

It's just like a wall switch, even has the stumps of the on/off buttons 
inside.

Greg

On 2012-11-13 8:23 PM, Thomas MacLean wrote:
> HiAll,
>
> I notice that the InlineLinc does not appear in the list of device tags.  I suppose is it functionally similar to a LampLinc.  Has anyone tried it?
>
> Regards,
> Tom
>
> On 2012-11-08, at 11:43 PM, Marc MERLIN <marc_mh@...> wrote:
>
>> On Wed, Nov 07, 2012 at 08:27:57PM -0600, John wrote:
>>>> Update my insteon.mht to a newer format?
>>> Yes, you will want to update your Insteon items.   You can refer to the
>>> wiki page for details on this.  For sure back up your existing mht file
>>> first.
>> On Thu, Nov 08, 2012 at 08:16:06PM -0500, Jim Duda wrote:
>>> We need to prepare everyone for when we merge the insteon branch to
>>> become the master.  Folks are going to have to convert their MHT files.
>>>   Maybe we should find a few to beta the conversion such that we can get
>>> the kinks out of the process?
>> For both those Emails.
>>
>> You can use my convertion script:
>> http://misterhouse.svn.sourceforge.net/viewvc/misterhouse/branches/insteon/lib/Insteon/convert_insteon_config?revision=1958
>>
>> It's not foolproof, and totally relies on you using my commenting format at
>> the end of each line (as per the examples I wrote on the wiki), but it'll
>> do most of the work or at least help you convert your config.
>>
>> 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/
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_d2d_nov
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>

Hello Tom,

sure. So, what you basically did if I follow the flow of the commands you listed:

> git remote add original https://github.com/hollie/misterhouse.git

1) you added a link to my repo, which is ok
> git pull original master

2) you get all the changes from my master branch and merge them into your local master (-> this is what 'pull' does. pull=fetch+merge)
> git push origin master

3) you published the changes applied in step 2 to your remote fork.

Up to here all is fine.

> One bad route is:  git pull original branch_merge_phase1 .. this pulled your branch into my master.  It complained about a bad merge for xPL_Items.pm.
> I think I'd rather have branch that matches yours, no?

But the next command is indeed not the way to go as you noticed. Basically what you did with the command is: you ask git to take my proposed new version of the insteon branch (=insteon+ all changes that were made to master since the branch between master and insteon) and you asked to to merge it into your master branch.

If you followed the insteon/master merge thread you noticed I proposed to first bring insteon up to date with master (phase1) and only in a second stage we could then apply the up-to-date insteon back into master (phase2). I do indeed expect some conflicts to occur there, and I'm willing to take a shot at merging, but I would first like that more people test out the modified insteon branch.

Sorry for all this text, but I'm trying to give you the context so that you see why the operation you tried to do did not work out as you expected.

Now the cool thing with git is that I can try exactly the same commands as you are going to execute them on your pc, so I can duplicate your working environment to help you further.

There are two ways to go: you can make a new clone and start from there, or you can fix the current clone you have (the one that has the merge changes in it).

I'll explain the first way to go (so starting from scratch) as this will also help other mailing list members if they want to get the 'phase1' branch on their computer.

1) get a clone of your fork
git clone git@...
cd misterhouse

Note 1: On my computer I use the read-only access link to your repo of course (git://github.com/tmaclean/misterhouse.git)
Note 2: people who only want to try out the new insteon branch, there is an easy way just for testing that is descibed below *)

2) add the link to the upstream repo where you want to fetch changes from
git remote add upstream git://github.com/hollie/misterhouse.git

3) get all changes from upstream but do not merge them
git fetch upstream

You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.

4) now create the branch you want to create in your local clone:
git checkout -b branch_merge_phase1 upstream/branch_merge_phase1

Optionally commit it to your remote fork if you're happy with the results. 
git push origin branch_merge_phase1

There are some steps, but they are only required because you have your fork and you want to keep it up to date.



*) For people who just want to test out the new inteon branch merged with master changes, you only need to execute 2 commands:

1) git clone git://github.com/hollie/misterhouse.git misterhouse_testbranch
2) git checkout -b test_phase1 origin/branch_merge_phase1

I hope this helps you further.


As a question to all: when will we decide branch_merge_phase1 has been tested enough to go for an actual merge with insteon? I would like to do this first before spending time in merging the updated insteon with master.


Kind regards,
 Lieven.
 

Op 14-nov.-2012, om 04:19 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:

> Hi Lieven,
> 
> not to confuse the matter too much , but...  can you explain how I should pull your "branch_merge_phase1" from your repo into my fork?
> 
> I had managed to re-synch up with:
> 
> 
> but then I got a bit lost trying to get your branch into my fork.
> 
> 
> Thanks for any guidance.
> 
> Regards,
> Tom
> 
> 
> On 2012-11-07, at 4:20 PM, Lieven Hollevoet <lieven@...> wrote:
> 
>> Hi,
>> 
>> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
>> 
>> https://github.com/hollie/misterhouse/pull/12
>> 
>> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
>> 
>> git clone git@...
>> cd misterhouse
>> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
>> 
>> test and report back please
>> 
>> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
>> 
>> Hope this branch works without big problems, then the merging operation is almost complete.
>> 
>> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 
>> 
>> Kind regards,
>> Lieven.
>> 
>> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:
>> 
>>> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
>>> 
>>> [...]
>>> 
>>>> Considering that we have svn left behind now, I actually think that it
>>>> would be ok to collapse the two branches and make the new insteon code the
>>>> master code.
>>> 
>>> I would agree with this.
>>> 
>>>> If it somehow breaks someone, they're not dead in the water because they can
>>>> still fall back to the old code in svn, report the problem, and hopefully
>>>> someone can help fix this in the new code.
>>>> 
>>>> So while I can't call myself the backup insteon maintainer, I think it's
>>>> time to fold both branches at least in git since the possible problems
>>>> this might cause are likely far outweighed by the cost of those 2 branches.
>>> 
>>> Yes.
>>> 
>>> Also, exposing the INSTEON stack in the insteon branch to a wider 
>>> audience will hopefully help to iron out bugs and issues.
>>> 
>>> Cheers,
>>> 
>>> Eloy Paris.-
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>> Stay in control, update software, and manage PCs from one command center
>> Diagnose problems and improve visibility into emerging IT issues
>> Automate, monitor and manage. Do more in less time with Central
>> http://p.sf.net/sfu/logmein12331_d2d
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>

Hi Lieven,

Thanks for your advice.  I;m still getting stuck.  I started from a clean clone of my fork, as you suggested.  I also did the "git pull upstream insteon", but there I ran into trouble:

tmaclean@... trunk]$ git remote add upstream git://github.com/hollie/misterhouse.git
[tmaclean@... trunk]$ git fetch upstream
tmaclean@... trunk]$ git pull upstream insteon
From git://github.com/hollie/misterhouse
 * branch            insteon    -> FETCH_HEAD
Auto-merging bin/mh
Auto-merging bin/mh.ini
Removing code/common/insteon_item_commands.pl
Auto-merging lib/Generic_Item.pm
Removing lib/Insteon_Device.pm
Removing lib/Insteon_Link.pm
Auto-merging lib/xPL_Items.pm
CONFLICT (content): Merge conflict in lib/xPL_Items.pm
Auto-merging web/bin/items.pl
CONFLICT (content): Merge conflict in web/bin/items.pl
Automatic merge failed; fix conflicts and then commit the result.

Do I really want to pull your Insteon into my master?
How do I fix failed merges?

Thanks (and sorry for all the questions),
Tom M.


On 2012-11-14, at 4:57 AM, Lieven Hollevoet <lieven@...> wrote:

> Hello Tom,
> 
> sure. So, what you basically did if I follow the flow of the commands you listed:
> 
>> git remote add original https://github.com/hollie/misterhouse.git
> 
> 1) you added a link to my repo, which is ok
>> git pull original master
> 
> 2) you get all the changes from my master branch and merge them into your local master (-> this is what 'pull' does. pull=fetch+merge)
>> git push origin master
> 
> 3) you published the changes applied in step 2 to your remote fork.
> 
> Up to here all is fine.
> 
>> One bad route is:  git pull original branch_merge_phase1 .. this pulled your branch into my master.  It complained about a bad merge for xPL_Items.pm.
>> I think I'd rather have branch that matches yours, no?
> 
> But the next command is indeed not the way to go as you noticed. Basically what you did with the command is: you ask git to take my proposed new version of the insteon branch (=insteon+ all changes that were made to master since the branch between master and insteon) and you asked to to merge it into your master branch.
> 
> If you followed the insteon/master merge thread you noticed I proposed to first bring insteon up to date with master (phase1) and only in a second stage we could then apply the up-to-date insteon back into master (phase2). I do indeed expect some conflicts to occur there, and I'm willing to take a shot at merging, but I would first like that more people test out the modified insteon branch.
> 
> Sorry for all this text, but I'm trying to give you the context so that you see why the operation you tried to do did not work out as you expected.
> 
> Now the cool thing with git is that I can try exactly the same commands as you are going to execute them on your pc, so I can duplicate your working environment to help you further.
> 
> There are two ways to go: you can make a new clone and start from there, or you can fix the current clone you have (the one that has the merge changes in it).
> 
> I'll explain the first way to go (so starting from scratch) as this will also help other mailing list members if they want to get the 'phase1' branch on their computer.
> 
> 1) get a clone of your fork
> git clone git@...
> cd misterhouse
> 
> Note 1: On my computer I use the read-only access link to your repo of course (git://github.com/tmaclean/misterhouse.git)
> Note 2: people who only want to try out the new insteon branch, there is an easy way just for testing that is descibed below *)
> 
> 2) add the link to the upstream repo where you want to fetch changes from
> git remote add upstream git://github.com/hollie/misterhouse.git
> 
> 3) get all changes from upstream but do not merge them
> git fetch upstream
> 
> You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.
> 
> 4) now create the branch you want to create in your local clone:
> git checkout -b branch_merge_phase1 upstream/branch_merge_phase1
> 
> Optionally commit it to your remote fork if you're happy with the results. 
> git push origin branch_merge_phase1
> 
> There are some steps, but they are only required because you have your fork and you want to keep it up to date.
> 
> 
> 
> *) For people who just want to test out the new inteon branch merged with master changes, you only need to execute 2 commands:
> 
> 1) git clone git://github.com/hollie/misterhouse.git misterhouse_testbranch
> 2) git checkout -b test_phase1 origin/branch_merge_phase1
> 
> I hope this helps you further.
> 
> 
> As a question to all: when will we decide branch_merge_phase1 has been tested enough to go for an actual merge with insteon? I would like to do this first before spending time in merging the updated insteon with master.
> 
> 
> Kind regards,
> Lieven.
> 
> 
> Op 14-nov.-2012, om 04:19 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:
> 
>> Hi Lieven,
>> 
>> not to confuse the matter too much , but...  can you explain how I should pull your "branch_merge_phase1" from your repo into my fork?
>> 
>> I had managed to re-synch up with:
>> 
>> 
>> but then I got a bit lost trying to get your branch into my fork.
>> 
>> 
>> Thanks for any guidance.
>> 
>> Regards,
>> Tom
>> 
>> 
>> On 2012-11-07, at 4:20 PM, Lieven Hollevoet <lieven@...> wrote:
>> 
>>> Hi,
>>> 
>>> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
>>> 
>>> https://github.com/hollie/misterhouse/pull/12
>>> 
>>> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
>>> 
>>> git clone git@...
>>> cd misterhouse
>>> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
>>> 
>>> test and report back please
>>> 
>>> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
>>> 
>>> Hope this branch works without big problems, then the merging operation is almost complete.
>>> 
>>> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 
>>> 
>>> Kind regards,
>>> Lieven.
>>> 
>>> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:
>>> 
>>>> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
>>>> 
>>>> [...]
>>>> 
>>>>> Considering that we have svn left behind now, I actually think that it
>>>>> would be ok to collapse the two branches and make the new insteon code the
>>>>> master code.
>>>> 
>>>> I would agree with this.
>>>> 
>>>>> If it somehow breaks someone, they're not dead in the water because they can
>>>>> still fall back to the old code in svn, report the problem, and hopefully
>>>>> someone can help fix this in the new code.
>>>>> 
>>>>> So while I can't call myself the backup insteon maintainer, I think it's
>>>>> time to fold both branches at least in git since the possible problems
>>>>> this might cause are likely far outweighed by the cost of those 2 branches.
>>>> 
>>>> Yes.
>>>> 
>>>> Also, exposing the INSTEON stack in the insteon branch to a wider 
>>>> audience will hopefully help to iron out bugs and issues.
>>>> 
>>>> Cheers,
>>>> 
>>>> Eloy Paris.-
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>> Stay in control, update software, and manage PCs from one command center
>>>> Diagnose problems and improve visibility into emerging IT issues
>>>> Automate, monitor and manage. Do more in less time with Central
>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>> ________________________________________________________
>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>> Stay in control, update software, and manage PCs from one command center
>>> Diagnose problems and improve visibility into emerging IT issues
>>> Automate, monitor and manage. Do more in less time with Central
>>> http://p.sf.net/sfu/logmein12331_d2d
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>> 
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>> 
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

Hi Tom,

maybe the sequence of instructions I sent you was misleading. The

>> You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.

was not meant to be executed in-line with the other commands. If you want to pull the changes from insteon you first need to go for a 'git checkout insteon'. Sorry for the confusion, I focussed on (and tested) only the instructions that will get you to a branch containing the changes in merge_branch_phase1.

So basically just execute the commands like this:

>> git clone git@...
>> cd misterhouse
>> git remote add upstream git://github.com/hollie/misterhouse.git
>> git fetch upstream
>> git checkout -b branch_merge_phase1 upstream/branch_merge_phase1


This should cause you to have an exact copy of the branch_merge_phase1 in the clone on your computer to test further on.

> Thanks (and sorry for all the questions),

No problem, I'm glad you're open to experimenting with git :-)

Kind regards,
 Lieven.


Op 14-nov.-2012, om 15:22 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:

> Hi Lieven,
> 
> Thanks for your advice.  I;m still getting stuck.  I started from a clean clone of my fork, as you suggested.  I also did the "git pull upstream insteon", but there I ran into trouble:
> 
> tmaclean@... trunk]$ git remote add upstream git://github.com/hollie/misterhouse.git
> [tmaclean@... trunk]$ git fetch upstream
> tmaclean@... trunk]$ git pull upstream insteon
>> From git://github.com/hollie/misterhouse
> * branch            insteon    -> FETCH_HEAD
> Auto-merging bin/mh
> Auto-merging bin/mh.ini
> Removing code/common/insteon_item_commands.pl
> Auto-merging lib/Generic_Item.pm
> Removing lib/Insteon_Device.pm
> Removing lib/Insteon_Link.pm
> Auto-merging lib/xPL_Items.pm
> CONFLICT (content): Merge conflict in lib/xPL_Items.pm
> Auto-merging web/bin/items.pl
> CONFLICT (content): Merge conflict in web/bin/items.pl
> Automatic merge failed; fix conflicts and then commit the result.
> 
> Do I really want to pull your Insteon into my master?
> How do I fix failed merges?
> 
> Thanks (and sorry for all the questions),
> Tom M.
> 
> 
> On 2012-11-14, at 4:57 AM, Lieven Hollevoet <lieven@...> wrote:
> 
>> Hello Tom,
>> 
>> sure. So, what you basically did if I follow the flow of the commands you listed:
>> 
>>> git remote add original https://github.com/hollie/misterhouse.git
>> 
>> 1) you added a link to my repo, which is ok
>>> git pull original master
>> 
>> 2) you get all the changes from my master branch and merge them into your local master (-> this is what 'pull' does. pull=fetch+merge)
>>> git push origin master
>> 
>> 3) you published the changes applied in step 2 to your remote fork.
>> 
>> Up to here all is fine.
>> 
>>> One bad route is:  git pull original branch_merge_phase1 .. this pulled your branch into my master.  It complained about a bad merge for xPL_Items.pm.
>>> I think I'd rather have branch that matches yours, no?
>> 
>> But the next command is indeed not the way to go as you noticed. Basically what you did with the command is: you ask git to take my proposed new version of the insteon branch (=insteon+ all changes that were made to master since the branch between master and insteon) and you asked to to merge it into your master branch.
>> 
>> If you followed the insteon/master merge thread you noticed I proposed to first bring insteon up to date with master (phase1) and only in a second stage we could then apply the up-to-date insteon back into master (phase2). I do indeed expect some conflicts to occur there, and I'm willing to take a shot at merging, but I would first like that more people test out the modified insteon branch.
>> 
>> Sorry for all this text, but I'm trying to give you the context so that you see why the operation you tried to do did not work out as you expected.
>> 
>> Now the cool thing with git is that I can try exactly the same commands as you are going to execute them on your pc, so I can duplicate your working environment to help you further.
>> 
>> There are two ways to go: you can make a new clone and start from there, or you can fix the current clone you have (the one that has the merge changes in it).
>> 
>> I'll explain the first way to go (so starting from scratch) as this will also help other mailing list members if they want to get the 'phase1' branch on their computer.
>> 
>> 1) get a clone of your fork
>> git clone git@...
>> cd misterhouse
>> 
>> Note 1: On my computer I use the read-only access link to your repo of course (git://github.com/tmaclean/misterhouse.git)
>> Note 2: people who only want to try out the new insteon branch, there is an easy way just for testing that is descibed below *)
>> 
>> 2) add the link to the upstream repo where you want to fetch changes from
>> git remote add upstream git://github.com/hollie/misterhouse.git
>> 
>> 3) get all changes from upstream but do not merge them
>> git fetch upstream
>> 
>> You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.
>> 
>> 4) now create the branch you want to create in your local clone:
>> git checkout -b branch_merge_phase1 upstream/branch_merge_phase1
>> 
>> Optionally commit it to your remote fork if you're happy with the results. 
>> git push origin branch_merge_phase1
>> 
>> There are some steps, but they are only required because you have your fork and you want to keep it up to date.
>> 
>> 
>> 
>> *) For people who just want to test out the new inteon branch merged with master changes, you only need to execute 2 commands:
>> 
>> 1) git clone git://github.com/hollie/misterhouse.git misterhouse_testbranch
>> 2) git checkout -b test_phase1 origin/branch_merge_phase1
>> 
>> I hope this helps you further.
>> 
>> 
>> As a question to all: when will we decide branch_merge_phase1 has been tested enough to go for an actual merge with insteon? I would like to do this first before spending time in merging the updated insteon with master.
>> 
>> 
>> Kind regards,
>> Lieven.
>> 
>> 
>> Op 14-nov.-2012, om 04:19 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:
>> 
>>> Hi Lieven,
>>> 
>>> not to confuse the matter too much , but...  can you explain how I should pull your "branch_merge_phase1" from your repo into my fork?
>>> 
>>> I had managed to re-synch up with:
>>> 
>>> 
>>> but then I got a bit lost trying to get your branch into my fork.
>>> 
>>> 
>>> Thanks for any guidance.
>>> 
>>> Regards,
>>> Tom
>>> 
>>> 
>>> On 2012-11-07, at 4:20 PM, Lieven Hollevoet <lieven@...> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
>>>> 
>>>> https://github.com/hollie/misterhouse/pull/12
>>>> 
>>>> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
>>>> 
>>>> git clone git@...
>>>> cd misterhouse
>>>> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
>>>> 
>>>> test and report back please
>>>> 
>>>> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
>>>> 
>>>> Hope this branch works without big problems, then the merging operation is almost complete.
>>>> 
>>>> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 
>>>> 
>>>> Kind regards,
>>>> Lieven.
>>>> 
>>>> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:
>>>> 
>>>>> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
>>>>> 
>>>>> [...]
>>>>> 
>>>>>> Considering that we have svn left behind now, I actually think that it
>>>>>> would be ok to collapse the two branches and make the new insteon code the
>>>>>> master code.
>>>>> 
>>>>> I would agree with this.
>>>>> 
>>>>>> If it somehow breaks someone, they're not dead in the water because they can
>>>>>> still fall back to the old code in svn, report the problem, and hopefully
>>>>>> someone can help fix this in the new code.
>>>>>> 
>>>>>> So while I can't call myself the backup insteon maintainer, I think it's
>>>>>> time to fold both branches at least in git since the possible problems
>>>>>> this might cause are likely far outweighed by the cost of those 2 branches.
>>>>> 
>>>>> Yes.
>>>>> 
>>>>> Also, exposing the INSTEON stack in the insteon branch to a wider 
>>>>> audience will hopefully help to iron out bugs and issues.
>>>>> 
>>>>> Cheers,
>>>>> 
>>>>> Eloy Paris.-
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>>> Stay in control, update software, and manage PCs from one command center
>>>>> Diagnose problems and improve visibility into emerging IT issues
>>>>> Automate, monitor and manage. Do more in less time with Central
>>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>>> ________________________________________________________
>>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>>>> 
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>> Stay in control, update software, and manage PCs from one command center
>>>> Diagnose problems and improve visibility into emerging IT issues
>>>> Automate, monitor and manage. Do more in less time with Central
>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>> ________________________________________________________
>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Monitor your physical, virtual and cloud infrastructure from a single
>>> web console. Get in-depth insight into apps, servers, databases, vmware,
>>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>>> Pricing starts from $795 for 25 servers or applications!
>>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>

Hi Lieven,

Thanks.   Your instructions worked for me, and I think I might even understand them.

ALL: 
How are other people finding the new Insteon code?  

In the old code my "hops left" were always(?) 2.  Now I see a mixture of 2's and 0's.

I have a few of these: "BUG! set_by loop detected with these objects: $Stairs_Light_KP_1, $Hall_Upstairs_KP_1"
and one of these: "WARN: deviceid of active message != received message source ($Bedroom_Lamp). IGNORING received message!!"

Is this codebase so much more "robust" it properly detects errors, or are these the result of bugs?

Regards,
Tom M.


On 2012-11-14, at 9:34 AM, Lieven Hollevoet <lieven@...> wrote:

> Hi Tom,
> 
> maybe the sequence of instructions I sent you was misleading. The
> 
>>> You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.
> 
> was not meant to be executed in-line with the other commands. If you want to pull the changes from insteon you first need to go for a 'git checkout insteon'. Sorry for the confusion, I focussed on (and tested) only the instructions that will get you to a branch containing the changes in merge_branch_phase1.
> 
> So basically just execute the commands like this:
> 
>>> git clone git@...
>>> cd misterhouse
>>> git remote add upstream git://github.com/hollie/misterhouse.git
>>> git fetch upstream
>>> git checkout -b branch_merge_phase1 upstream/branch_merge_phase1
> 
> 
> This should cause you to have an exact copy of the branch_merge_phase1 in the clone on your computer to test further on.
> 
>> Thanks (and sorry for all the questions),
> 
> No problem, I'm glad you're open to experimenting with git :-)
> 
> Kind regards,
> Lieven.
> 
> 
> Op 14-nov.-2012, om 15:22 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:
> 
>> Hi Lieven,
>> 
>> Thanks for your advice.  I;m still getting stuck.  I started from a clean clone of my fork, as you suggested.  I also did the "git pull upstream insteon", but there I ran into trouble:
>> 
>> tmaclean@... trunk]$ git remote add upstream git://github.com/hollie/misterhouse.git
>> [tmaclean@... trunk]$ git fetch upstream
>> tmaclean@... trunk]$ git pull upstream insteon
>>> From git://github.com/hollie/misterhouse
>> * branch            insteon    -> FETCH_HEAD
>> Auto-merging bin/mh
>> Auto-merging bin/mh.ini
>> Removing code/common/insteon_item_commands.pl
>> Auto-merging lib/Generic_Item.pm
>> Removing lib/Insteon_Device.pm
>> Removing lib/Insteon_Link.pm
>> Auto-merging lib/xPL_Items.pm
>> CONFLICT (content): Merge conflict in lib/xPL_Items.pm
>> Auto-merging web/bin/items.pl
>> CONFLICT (content): Merge conflict in web/bin/items.pl
>> Automatic merge failed; fix conflicts and then commit the result.
>> 
>> Do I really want to pull your Insteon into my master?
>> How do I fix failed merges?
>> 
>> Thanks (and sorry for all the questions),
>> Tom M.
>> 
>> 
>> On 2012-11-14, at 4:57 AM, Lieven Hollevoet <lieven@...> wrote:
>> 
>>> Hello Tom,
>>> 
>>> sure. So, what you basically did if I follow the flow of the commands you listed:
>>> 
>>>> git remote add original https://github.com/hollie/misterhouse.git
>>> 
>>> 1) you added a link to my repo, which is ok
>>>> git pull original master
>>> 
>>> 2) you get all the changes from my master branch and merge them into your local master (-> this is what 'pull' does. pull=fetch+merge)
>>>> git push origin master
>>> 
>>> 3) you published the changes applied in step 2 to your remote fork.
>>> 
>>> Up to here all is fine.
>>> 
>>>> One bad route is:  git pull original branch_merge_phase1 .. this pulled your branch into my master.  It complained about a bad merge for xPL_Items.pm.
>>>> I think I'd rather have branch that matches yours, no?
>>> 
>>> But the next command is indeed not the way to go as you noticed. Basically what you did with the command is: you ask git to take my proposed new version of the insteon branch (=insteon+ all changes that were made to master since the branch between master and insteon) and you asked to to merge it into your master branch.
>>> 
>>> If you followed the insteon/master merge thread you noticed I proposed to first bring insteon up to date with master (phase1) and only in a second stage we could then apply the up-to-date insteon back into master (phase2). I do indeed expect some conflicts to occur there, and I'm willing to take a shot at merging, but I would first like that more people test out the modified insteon branch.
>>> 
>>> Sorry for all this text, but I'm trying to give you the context so that you see why the operation you tried to do did not work out as you expected.
>>> 
>>> Now the cool thing with git is that I can try exactly the same commands as you are going to execute them on your pc, so I can duplicate your working environment to help you further.
>>> 
>>> There are two ways to go: you can make a new clone and start from there, or you can fix the current clone you have (the one that has the merge changes in it).
>>> 
>>> I'll explain the first way to go (so starting from scratch) as this will also help other mailing list members if they want to get the 'phase1' branch on their computer.
>>> 
>>> 1) get a clone of your fork
>>> git clone git@...
>>> cd misterhouse
>>> 
>>> Note 1: On my computer I use the read-only access link to your repo of course (git://github.com/tmaclean/misterhouse.git)
>>> Note 2: people who only want to try out the new insteon branch, there is an easy way just for testing that is descibed below *)
>>> 
>>> 2) add the link to the upstream repo where you want to fetch changes from
>>> git remote add upstream git://github.com/hollie/misterhouse.git
>>> 
>>> 3) get all changes from upstream but do not merge them
>>> git fetch upstream
>>> 
>>> You might want to do a 'git pull upstream insteon' here as your fork is not up to date with the upstream repo.
>>> 
>>> 4) now create the branch you want to create in your local clone:
>>> git checkout -b branch_merge_phase1 upstream/branch_merge_phase1
>>> 
>>> Optionally commit it to your remote fork if you're happy with the results. 
>>> git push origin branch_merge_phase1
>>> 
>>> There are some steps, but they are only required because you have your fork and you want to keep it up to date.
>>> 
>>> 
>>> 
>>> *) For people who just want to test out the new inteon branch merged with master changes, you only need to execute 2 commands:
>>> 
>>> 1) git clone git://github.com/hollie/misterhouse.git misterhouse_testbranch
>>> 2) git checkout -b test_phase1 origin/branch_merge_phase1
>>> 
>>> I hope this helps you further.
>>> 
>>> 
>>> As a question to all: when will we decide branch_merge_phase1 has been tested enough to go for an actual merge with insteon? I would like to do this first before spending time in merging the updated insteon with master.
>>> 
>>> 
>>> Kind regards,
>>> Lieven.
>>> 
>>> 
>>> Op 14-nov.-2012, om 04:19 heeft Thomas MacLean <tmaclean@...> het volgende geschreven:
>>> 
>>>> Hi Lieven,
>>>> 
>>>> not to confuse the matter too much , but...  can you explain how I should pull your "branch_merge_phase1" from your repo into my fork?
>>>> 
>>>> I had managed to re-synch up with:
>>>> 
>>>> 
>>>> but then I got a bit lost trying to get your branch into my fork.
>>>> 
>>>> 
>>>> Thanks for any guidance.
>>>> 
>>>> Regards,
>>>> Tom
>>>> 
>>>> 
>>>> On 2012-11-07, at 4:20 PM, Lieven Hollevoet <lieven@...> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> I just commited a branch that starts from insteon and that contains all changes of the master that were not in insteon.
>>>>> 
>>>>> https://github.com/hollie/misterhouse/pull/12
>>>>> 
>>>>> I had to merge 2 files manually. I did not try to run the code. Can an insteon developer test it please?
>>>>> 
>>>>> git clone git@...
>>>>> cd misterhouse
>>>>> git checkout -b branch_merge_phase1 origin/branch_merge_phase1
>>>>> 
>>>>> test and report back please
>>>>> 
>>>>> If things don't work out and you can provide fixed then you need to go around your own fork so that you can create a pull request to me.
>>>>> 
>>>>> Hope this branch works without big problems, then the merging operation is almost complete.
>>>>> 
>>>>> I'm signing off for today, so I won't be able to follow-up on this until tomorrow evening-ish. 
>>>>> 
>>>>> Kind regards,
>>>>> Lieven.
>>>>> 
>>>>> Op 7-nov.-2012, om 16:05 heeft Eloy Paris <peloy@...> het volgende geschreven:
>>>>> 
>>>>>> On 11/07/2012 09:35 AM, Marc MERLIN wrote:
>>>>>> 
>>>>>> [...]
>>>>>> 
>>>>>>> Considering that we have svn left behind now, I actually think that it
>>>>>>> would be ok to collapse the two branches and make the new insteon code the
>>>>>>> master code.
>>>>>> 
>>>>>> I would agree with this.
>>>>>> 
>>>>>>> If it somehow breaks someone, they're not dead in the water because they can
>>>>>>> still fall back to the old code in svn, report the problem, and hopefully
>>>>>>> someone can help fix this in the new code.
>>>>>>> 
>>>>>>> So while I can't call myself the backup insteon maintainer, I think it's
>>>>>>> time to fold both branches at least in git since the possible problems
>>>>>>> this might cause are likely far outweighed by the cost of those 2 branches.
>>>>>> 
>>>>>> Yes.
>>>>>> 
>>>>>> Also, exposing the INSTEON stack in the insteon branch to a wider 
>>>>>> audience will hopefully help to iron out bugs and issues.
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> Eloy Paris.-
>>>>>> 
>>>>>> 
>>>>>> ------------------------------------------------------------------------------
>>>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>>>> Stay in control, update software, and manage PCs from one command center
>>>>>> Diagnose problems and improve visibility into emerging IT issues
>>>>>> Automate, monitor and manage. Do more in less time with Central
>>>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>>>> ________________________________________________________
>>>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>>>>> 
>>>>> 
>>>>> 
>>>>> ------------------------------------------------------------------------------
>>>>> LogMeIn Central: Instant, anywhere, Remote PC access and management.
>>>>> Stay in control, update software, and manage PCs from one command center
>>>>> Diagnose problems and improve visibility into emerging IT issues
>>>>> Automate, monitor and manage. Do more in less time with Central
>>>>> http://p.sf.net/sfu/logmein12331_d2d
>>>>> ________________________________________________________
>>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>>> 
>>>> 
>>>> ------------------------------------------------------------------------------
>>>> Monitor your physical, virtual and cloud infrastructure from a single
>>>> web console. Get in-depth insight into apps, servers, databases, vmware,
>>>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>>>> Pricing starts from $795 for 25 servers or applications!
>>>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>>> ________________________________________________________
>>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Monitor your physical, virtual and cloud infrastructure from a single
>>> web console. Get in-depth insight into apps, servers, databases, vmware,
>>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>>> Pricing starts from $795 for 25 servers or applications!
>>> http://p.sf.net/sfu/zoho_dev2dev_nov
>>> ________________________________________________________
>>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>> 
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>> 
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

On 11/14/12 19:52, Thomas MacLean wrote:
> Hi Lieven,
>
> Thanks.   Your instructions worked for me, and I think I might even understand them.
>
> ALL:
> How are other people finding the new Insteon code?
>
> In the old code my "hops left" were always(?) 2.  Now I see a mixture of 2's and 0's.
>
> I have a few of these: "BUG! set_by loop detected with these objects: $Stairs_Light_KP_1, $Hall_Upstairs_KP_1"
> and one of these: "WARN: deviceid of active message != received message source ($Bedroom_Lamp). IGNORING received message!!"
I get the loop detected error on at least one set of my linked switches 
(from pretty much beginning of the new insteon code).  I did some 
searching on this error and but didn't pursue it further.

John

On 11/14/2012 08:58 PM, John wrote:

> I get the loop detected error on at least one set of my linked switches
> (from pretty much beginning of the new insteon code).  I did some
> searching on this error and but didn't pursue it further.
>

I too get these message occasionally, but nothing wrong seems to happen
with lighting or scenes as a result.  
 
Jim

Perhaps a dumb question....

I also notice there is no trigger to do the _Get_next_linkscan() in the middle of the night.  Does this still happen by another method, or should one manually add the link?

Thanks,
Tom

On 2012-11-15, at 8:25 PM, Jim Duda <jim@...> wrote:

> On 11/14/2012 08:58 PM, John wrote:
> 
>> I get the loop detected error on at least one set of my linked switches
>> (from pretty much beginning of the new insteon code).  I did some
>> searching on this error and but didn't pursue it further.
>> 
> 
> I too get these message occasionally, but nothing wrong seems to happen
> with lighting or scenes as a result.  
> 
> Jim
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

Hello All,

Just FYI, I checked my logs for last night, and there is no sign of the "Scan All Links" having occurred.  I guess it must be added to the "Triggers" table manually.

Regards,
Tom

On 2012-11-15, at 9:14 PM, Thomas MacLean <tmaclean@...> wrote:

> 
> Perhaps a dumb question....
> 
> I also notice there is no trigger to do the _Get_next_linkscan() in the middle of the night.  Does this still happen by another method, or should one manually add the link?
> 
> Thanks,
> Tom
> 
> On 2012-11-15, at 8:25 PM, Jim Duda <jim@...> wrote:
> 
>> On 11/14/2012 08:58 PM, John wrote:
>> 
>>> I get the loop detected error on at least one set of my linked switches
>>> (from pretty much beginning of the new insteon code).  I did some
>>> searching on this error and but didn't pursue it further.
>>> 
>> 
>> I too get these message occasionally, but nothing wrong seems to happen
>> with lighting or scenes as a result.  
>> 
>> Jim
>> 
>> 
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 
> 
> ------------------------------------------------------------------------------
> Monitor your physical, virtual and cloud infrastructure from a single
> web console. Get in-depth insight into apps, servers, databases, vmware,
> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> Pricing starts from $795 for 25 servers or applications!
> http://p.sf.net/sfu/zoho_dev2dev_nov
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365

On 11/16/2012 08:46 AM, Thomas MacLean wrote:
> 
> Hello All,
> 
> Just FYI, I checked my logs for last night, and there is no sign of the "Scan All Links" having occurred.  I guess it must be added to the "Triggers" table manually.
> 
> Regards,
> Tom
> 

I have it in my triggers list, and I didn't put it there manually.  I don't know at what point it gets added to the list.

Jim

On 11/16/2012 08:29 PM, Jim Duda wrote:

> On 11/16/2012 08:46 AM, Thomas MacLean wrote:
>>
>> Hello All,
>>
>> Just FYI, I checked my logs for last night, and there is no sign of the "Scan All Links" having occurred.  I guess it must be added to the "Triggers" table manually.
>>
>> Regards,
>> Tom
>>
>
> I have it in my triggers list, and I didn't put it there manually.  I don't know at what point it gets added to the list.

In the "insteon" branch it gets added by lib/Insteon.pm:init(). The 
trigger code is "&Insteon::scan_all_linktables()". This function is also 
defined in lib/Insteon.pm.

The name of the trigger is "scan insteon link tables". Don't know why 
Tom doesn't have it because it always gets added (but it will not be 
re-enabled if the user chooses to not have it run).

Cheers,

Eloy Paris.-

On 11/16/12 23:45, Eloy Paris wrote:
> In the "insteon" branch it gets added by lib/Insteon.pm:init(). The
> trigger code is "&Insteon::scan_all_linktables()". This function is also
> defined in lib/Insteon.pm.
>
> The name of the trigger is "scan insteon link tables". Don't know why
> Tom doesn't have it because it always gets added (but it will not be
> re-enabled if the user chooses to not have it run).
>
> Cheers,
>

I attempted to reverse engineer parts of the insteon branch.   The 
intent was to assist me in getting better understanding of the code:

     https://github.com/hollie/misterhouse/wiki/Design-details

We could probably use overview that contains information like what you 
provided.

John

On Thu, Nov 15, 2012 at 08:25:58PM -0500, Jim Duda wrote:
> On 11/14/2012 08:58 PM, John wrote:
> 
> > I get the loop detected error on at least one set of my linked switches
> > (from pretty much beginning of the new insteon code).  I did some
> > searching on this error and but didn't pursue it further.
> 
> I too get these message occasionally, but nothing wrong seems to happen
> with lighting or scenes as a result.  

I get it too once in a while, and I got it with the old insteon code too.

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 Sat, Nov 17, 2012 at 08:55:10AM -0600, John wrote:
> On 11/16/12 23:45, Eloy Paris wrote:
> > In the "insteon" branch it gets added by lib/Insteon.pm:init(). The
> > trigger code is "&Insteon::scan_all_linktables()". This function is also
> > defined in lib/Insteon.pm.
> >
> > The name of the trigger is "scan insteon link tables". Don't know why
> > Tom doesn't have it because it always gets added (but it will not be
> > re-enabled if the user chooses to not have it run).
> >
> > Cheers,
> >
> 
> I attempted to reverse engineer parts of the insteon branch.   The 
> intent was to assist me in getting better understanding of the code:
> 
>      https://github.com/hollie/misterhouse/wiki/Design-details
> 
> We could probably use overview that contains information like what you 
> provided.

Thank you for writing this. I linked it on
http://misterhouse.wikispaces.com/Insteon+Redux
(which I slightly reorganized in the process)

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/