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

Tom MacLean wrote:
> My goal in using tie_items to link the keypad and the inline module is to
> keep the states consistent.  Ideally, in the MH web interface, I would want
> only a single object to represent each light.  I have hidden the module so
> that now only the keypad button represents the light state.

That will not be guaranteed to be accurate.  Only the module should 
reflect the light state.

>  (The keypad
> itself does not control any load.)  It did mean that when I change the state
> of the "light" (kp button) in the web interface though, the module didn't
> follow.
> 
> I guess another goal is to avoid having additional scenes that don't
> correspond to a physical button (i.e. plm scenes) -- to keep the physical to
> logical mapping as clear as possible to non-programmers.

Not possible.

> How would you have done this (with these constraints)?

You can't.

>  Expose only the
> module item and hide the KP button?

I would definitely do that.

> If this isn't the proper use of tie_items(), what is it for?
> -tom
> 
> 
> -----Original Message-----
> From: Gregg Liming [mailto:gr...@li...] 
> Sent: Monday, September 29, 2008 9:04 PM
> To: tma...@sa...
> Subject: Re: [mh] insteon weirdness
> 
> Tom MacLean wrote:
>  > Gregg pointed out that I didn't include enough information... so here 
> we are:
>  >
>  > I'm using a recent svn version:  1505 (Sep 13, 2008)
>  >
>  > My (only) table and code files are attached.
>  >
>  > I don't have access to my logs right now.  They're scrolling on the 
> terminal at home, and as far as I can tell, not being logged to a file. 
>   The snippet when I press the Sink Light controller and all the other 
> lights come on is in the email below.  A logfile with all the log links 
> output is attached.
> 
> This info helps a good deal.  However, seeing the command(s) that is 
> sent in advance of the spew of "15"s is needed.  More comments below:
> 
> 
>  > Just yesterday I had an electrician in to install some potslights and 
> pendant lights in my kitchen.  In order to facilitate independant 
> control of the two, I removed the old switch (hard wiring the circuit 
> ON) and replaced it with a keypad link.  I then used two inline dimmer 
> modules to control the potlights and pendants seperately.  I had 
> previously linked them to the keypad using misterhouse -- and they 
> seemed to work.  In fact, once installed, it all seemed to work.  There 
> was one glitch that when I updated the switch condition from the web, 
> the module didn't also update.
> 
> That doesn't make sense to even attempt.  These "switch"(es) 
> ($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
> rationally attempt to control their state from the web (even though it 
> is possible to try).  Their definitions (as you have included in the 
> insteon.mht) assume that the buttons are locally pushed (i.e., via a 
> human--not via mh and it's web interface).  So, of course there won't be 
> any updating of your responders (the "modules") because the actual 
> device (button) was not being depressed.  If you want an equivalent 
> scene, then you will have to separately create new scenes where the plm 
> is the controller (vice one of the keypadlinc buttons).
> 
>  > I added
>  >
>  > $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
>  > $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
>  >
>  > to my insteon.pl code file ... and I think that fixed that little 
> detail.
> 
> That is going to backfire on you.  Possibly, it's a part of the problem 
> that you are experiencing.  While it seemed to resolve what you 
> perceived as a problem, the real problem is that you were trying to 
> abuse keypadlinc buttons in ways that aren't intended and can't work. 
> Instead, use plm-controlled scenes if you want to control things via a 
> web interface.
> 
> My suggestion is that you immediately get rid of the above tie_items code.
> 
>  > I notice the modules use a slower ramp rate than I expected (when 
> updated from the web), but that doesn't concern me.
> 
> That makes perfect sense.  The scene definitions w/ the shorter ramp 
> rate weren't being used--as discussed above.  Instead, the tie items 
> code took over and issued direct commands which honor the local ramp 
> rate (whatever it is set to).  Again, ditch the tie items code and don't 
> try to set keypadlinc buttons from the web interface.
> 
>  > This morning weirdness broke out...
>  >
>  > I also have a dimmer on a light over my kitchen sink.  It's not 
> linked to anything, except the PLM.  I turned on the Sink light this 
> morning and all the potlights and pendants came on too! I notice the 
> slower ramp rate occurs here too.  I have no idea why the Sink light 
> controller is turning everything on!
> 
>  From your link logs, I don't yet see any "smoking gun".  But, I do want 
> you to get rid of your insteon.pl code and do a full restart (not a 
> reload).  Then, see if you can repeat the problem by turning on the sink 
> light.  Be sure to include the entire log from mh startup (as you had 
> recently included) up to the point of the problem (actually, a few 
> seconds later).
> 
>  > In the logs I see lots of "Interface Extremely Busy"
> 
> It seems as though your other lights are being coupled in and the 
> tie_items code is going to queue commands real fast--which doesn't help 
> anything.
> 
>  > and then my "command:13; type:alllink; group: 01" -- this doesn't 
> look familiar to me.
> 
> That actually does look correct as it is the received scene command that 
> your sink switch is sending back to the plm.  It's everything else which 
> seems a bit off.
> 
> Gregg
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
> 

My goal in using tie_items to link the keypad and the inline module is to
keep the states consistent.  Ideally, in the MH web interface, I would want
only a single object to represent each light.  I have hidden the module so
that now only the keypad button represents the light state.  (The keypad
itself does not control any load.)  It did mean that when I change the state
of the "light" (kp button) in the web interface though, the module didn't
follow.

I guess another goal is to avoid having additional scenes that don't
correspond to a physical button (i.e. plm scenes) -- to keep the physical to
logical mapping as clear as possible to non-programmers.

How would you have done this (with these constraints)?  Expose only the
module item and hide the KP button?

If this isn't the proper use of tie_items(), what is it for?

-tom


-----Original Message-----
From: Gregg Liming [mailto:gr...@li...] 
Sent: Monday, September 29, 2008 9:04 PM
To: tma...@sa...
Subject: Re: [mh] insteon weirdness

Tom MacLean wrote:
 > Gregg pointed out that I didn't include enough information... so here 
we are:
 >
 > I'm using a recent svn version:  1505 (Sep 13, 2008)
 >
 > My (only) table and code files are attached.
 >
 > I don't have access to my logs right now.  They're scrolling on the 
terminal at home, and as far as I can tell, not being logged to a file. 
  The snippet when I press the Sink Light controller and all the other 
lights come on is in the email below.  A logfile with all the log links 
output is attached.

This info helps a good deal.  However, seeing the command(s) that is 
sent in advance of the spew of "15"s is needed.  More comments below:


 > Just yesterday I had an electrician in to install some potslights and 
pendant lights in my kitchen.  In order to facilitate independant 
control of the two, I removed the old switch (hard wiring the circuit 
ON) and replaced it with a keypad link.  I then used two inline dimmer 
modules to control the potlights and pendants seperately.  I had 
previously linked them to the keypad using misterhouse -- and they 
seemed to work.  In fact, once installed, it all seemed to work.  There 
was one glitch that when I updated the switch condition from the web, 
the module didn't also update.

That doesn't make sense to even attempt.  These "switch"(es) 
($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
rationally attempt to control their state from the web (even though it 
is possible to try).  Their definitions (as you have included in the 
insteon.mht) assume that the buttons are locally pushed (i.e., via a 
human--not via mh and it's web interface).  So, of course there won't be 
any updating of your responders (the "modules") because the actual 
device (button) was not being depressed.  If you want an equivalent 
scene, then you will have to separately create new scenes where the plm 
is the controller (vice one of the keypadlinc buttons).

 > I added
 >
 > $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
 > $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
 >
 > to my insteon.pl code file ... and I think that fixed that little 
detail.

That is going to backfire on you.  Possibly, it's a part of the problem 
that you are experiencing.  While it seemed to resolve what you 
perceived as a problem, the real problem is that you were trying to 
abuse keypadlinc buttons in ways that aren't intended and can't work. 
Instead, use plm-controlled scenes if you want to control things via a 
web interface.

My suggestion is that you immediately get rid of the above tie_items code.

 > I notice the modules use a slower ramp rate than I expected (when 
updated from the web), but that doesn't concern me.

That makes perfect sense.  The scene definitions w/ the shorter ramp 
rate weren't being used--as discussed above.  Instead, the tie items 
code took over and issued direct commands which honor the local ramp 
rate (whatever it is set to).  Again, ditch the tie items code and don't 
try to set keypadlinc buttons from the web interface.

 > This morning weirdness broke out...
 >
 > I also have a dimmer on a light over my kitchen sink.  It's not 
linked to anything, except the PLM.  I turned on the Sink light this 
morning and all the potlights and pendants came on too! I notice the 
slower ramp rate occurs here too.  I have no idea why the Sink light 
controller is turning everything on!

 From your link logs, I don't yet see any "smoking gun".  But, I do want 
you to get rid of your insteon.pl code and do a full restart (not a 
reload).  Then, see if you can repeat the problem by turning on the sink 
light.  Be sure to include the entire log from mh startup (as you had 
recently included) up to the point of the problem (actually, a few 
seconds later).

 > In the logs I see lots of "Interface Extremely Busy"

It seems as though your other lights are being coupled in and the 
tie_items code is going to queue commands real fast--which doesn't help 
anything.

 > and then my "command:13; type:alllink; group: 01" -- this doesn't 
look familiar to me.

That actually does look correct as it is the received scene command that 
your sink switch is sending back to the plm.  It's everything else which 
seems a bit off.

Gregg

I had to use black electrical tape on my Insteon switches too.  They lit up
the whole room at night! 

My solution for keypads was to use white on black labels instead of black on
white.  That cut down the brightness acceptably.  I'm hoping the black
version of the keypad will be generally more opaque than the white one, but
I don't have one yet to see.

I'm excited to hear there may be a way to turn off the backlight.  What I
found in the user manual was only a way to switch the backlight from high to
low intensity, but not to turn it off.  Ideally, I would have the switch go
to "sleep" -- turn all LEDs at a certain time, unless a button was pressed.
That way one could get some decent darkness in the house. [Lack of proper
darkness at night is correlated to breast cancer in some studies.]

-tom m.

-----Original Message-----
From: Gregg Liming [mailto:gr...@li...] 
Sent: Tuesday, September 30, 2008 8:43 AM
To: The main list for the MisterHouse home automation program
Subject: Re: [mh] Living with Insteon

Dave Stenhouse wrote:
> Hey Insteon users- I'm considering the purchase of a KeypadLinc with 
> enclosure to put in the bedrom, but I am very leery of this due to what 
> I see on Smart Home's forum about those #&%! LEDs that are brighter than 
> day.  Not just the backlights for the various scene buttons, but every 
> flippin' Insteon device has the linking LED, right?  I covered all my 
> plug-in modules with black vinyl tape. and it doesn't really take care 
> of the problem well, and obviously that's not a good solution for 
> something I have to look at from time to time.
> So what do those of you that have lots of Insteon gear do about these 
> LEDs?  How effective is whatever you do? 

Personally, the lights have never bothered me.  After reviewing the 
command tables doc, it appears that there is an ability to remotely set 
the backlighting (on/off) and "linking" LED (on/off) via operating 
flags.  I could investigate adding support; but, it won't make the 105 
branch cut-off (today or tomorrow).  From memory, it seems like some of 
this is also manually setable via the device; but, I don't recall specifics.

Gregg


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
________________________________________________________
To unsubscribe from this list, go to:
http://sourceforge.net/mail/?group_id=1365

Dave Stenhouse wrote:
> Hey Insteon users- I'm considering the purchase of a KeypadLinc with 
> enclosure to put in the bedrom, but I am very leery of this due to what 
> I see on Smart Home's forum about those #&%! LEDs that are brighter than 
> day.  Not just the backlights for the various scene buttons, but every 
> flippin' Insteon device has the linking LED, right?  I covered all my 
> plug-in modules with black vinyl tape. and it doesn't really take care 
> of the problem well, and obviously that's not a good solution for 
> something I have to look at from time to time.
> So what do those of you that have lots of Insteon gear do about these 
> LEDs?  How effective is whatever you do? 

Personally, the lights have never bothered me.  After reviewing the 
command tables doc, it appears that there is an ability to remotely set 
the backlighting (on/off) and "linking" LED (on/off) via operating 
flags.  I could investigate adding support; but, it won't make the 105 
branch cut-off (today or tomorrow).  From memory, it seems like some of 
this is also manually setable via the device; but, I don't recall specifics.

Gregg

Ralf Klüber wrote:
> Guys,
> 
> I have a bunch of changes to contribute but now clue how to do that
> efficiently. Would svn be the right way? If so, could someon point me
> to a simple HowTo, or point me in the right direction.

Ralf,

I don't think that we have time to get you up to speed with svn commits before
tonight's branch.  The next best thing is to supply unified diff files as
attachments (not cut and paste) to an e-mail to the list.  You can include new
files as simple attachments (not diffs) but be sure to tell us where they go.

General principal:

1. Checkout a copy of trunk.  You don't need write access to do this.  See
http://misterhouse.wikispaces.com/subversion

2. Generate a unified diff for each file you have modified.
diff -u <file from tunk> <your modified file> > diff_file_to_create

3. Get the e-mail to the list by 5pm EDT (UTC-4).

4. Profit!

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

A friendly reminder that I'll be branching off 2.105 after work today (Eastern
Time Zone).  Our firm rule is that only bug/security fixes will be allowed to
make it to 2.105 after that point.  I'll send out a follow-up e-mail once the
branch is made.  Expect the RC tarball and zip files to follow on shortly
after the branch is made.

Matt

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

Guys,

I have a bunch of changes to contribute but now clue how to do that
efficiently. Would svn be the right way? If so, could someon point me
to a simple HowTo, or point me in the right direction.

My changes I can offer:

- pretty stable iphone skin
Example see http://ralfathome.dyndns.org/apache2-default/iphoneskin.html
Should work with firefox and safari, sorry, no IE and interface is in
German. However you could get the idea.

- some home automation icons
see http://ralf.klueber.googlepages.com/icons.png

- some changes in Groups.pm to enable a group of groups and _dont_
sort the items re their names
Is someone expecting some side effects here?

- some changes in http_server.pm to be able to use MH behind a reverse proxy

- some changes in EIB_Items.pm
Additional EIB Items:
package EIB9_Item;
package EIB10_Item;
package EIB11_Item;
package EIB11S_Item;
package EIB15_Item;
package EIBW_Item; aditional class for windows (two EIB1 Items
combined) delivering

Dont know which one of these were already in the 2.104. I will check.

Looking forward to your advise.

KR

PS: 3rd try. Got an error message from nabble.com

Hey Insteon users- I'm considering the purchase of a KeypadLinc with 
enclosure to put in the bedrom, but I am very leery of this due to what 
I see on Smart Home's forum about those #&%! LEDs that are brighter than 
day.  Not just the backlights for the various scene buttons, but every 
flippin' Insteon device has the linking LED, right?  I covered all my 
plug-in modules with black vinyl tape. and it doesn't really take care 
of the problem well, and obviously that's not a good solution for 
something I have to look at from time to time.
So what do those of you that have lots of Insteon gear do about these 
LEDs?  How effective is whatever you do? 

Gregg Liming wrote:
> Tom MacLean wrote:
>> Gregg pointed out that I didn't include enough information... so here we 
>> are:
> 
> FYI - I've tried repeatedly to respond via sf's list and no joy.  So, 
> I'll try to send you responses from here out to your private email.  If 
> that works, then at least it will benefit you.

I see how the incredible sf content filters work... do not attempt to 
use a common phrase that begins with "smoking" and ends with a device 
that shoots bullets.  Go figure.

Gregg

For some reason, the first attempt to respond didn't make it through to 
the list.  So, here goes again...

Tom MacLean wrote:
 > Gregg pointed out that I didn't include enough information... so here 
we are:
 >
 > I'm using a recent svn version:  1505 (Sep 13, 2008)
 >
 > My (only) table and code files are attached.
 >
 > I don't have access to my logs right now.  They're scrolling on the 
terminal at home, and as far as I can tell, not being logged to a file. 
  The snippet when I press the Sink Light controller and all the other 
lights come on is in the email below.  A logfile with all the log links 
output is attached.

This info helps a good deal.  However, seeing the command(s) that is 
sent in advance of the spew of "15"s is needed.  More comments below:


 > Just yesterday I had an electrician in to install some potslights and 
pendant lights in my kitchen.  In order to facilitate independant 
control of the two, I removed the old switch (hard wiring the circuit 
ON) and replaced it with a keypad link.  I then used two inline dimmer 
modules to control the potlights and pendants seperately.  I had 
previously linked them to the keypad using misterhouse -- and they 
seemed to work.  In fact, once installed, it all seemed to work.  There 
was one glitch that when I updated the switch condition from the web, 
the module didn't also update.

That doesn't make sense to even attempt.  These "switch"(es) 
($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
rationally attempt to control their state from the web (even though it 
is possible to try).  Their definitions (as you have included in the 
insteon.mht) assume that the buttons are locally pushed (i.e., via a 
human--not via mh and it's web interface).  So, of course there won't be 
any updating of your responders (the "modules") because the actual 
device (button) was not being depressed.  If you want an equivalent 
scene, then you will have to separately create new scenes where the plm 
is the controller (vice one of the keypadlinc buttons).

 > I added
 >
 > $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
 > $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
 >
 > to my insteon.pl code file ... and I think that fixed that little detail.

That is going to backfire on you.  Possibly, it's a part of the problem 
that you are experiencing.  While it seemed to resolve what you 
perceived as a problem, the real problem is that you were trying to 
abuse keypadlinc buttons in ways that aren't intended and can't work. 
Instead, use plm-controlled scenes if you want to control things via a 
web interface.

My suggestion is that you immediately get rid of the above tie_items code.

 > I notice the modules use a slower ramp rate than I expected (when 
updated from the web), but that doesn't concern me.

That makes perfect sense.  The scene definitions w/ the shorter ramp 
rate weren't being used--as discussed above.  Instead, the tie items 
code took over and issued direct commands which honor the local ramp 
rate (whatever it is set to).  Again, ditch the tie items code and don't 
try to set keypadlinc buttons from the web interface.

 > This morning weirdness broke out...
 >
 > I also have a dimmer on a light over my kitchen sink.  It's not 
linked to anything, except the PLM.  I turned on the Sink light this 
morning and all the potlights and pendants came on too! I notice the 
slower ramp rate occurs here too.  I have no idea why the Sink light 
controller is turning everything on!

 From your link logs, I don't yet see anything unusual.  But, I do want 
you to get rid of your insteon.pl code and do a full restart (not a 
reload).  Then, see if you can repeat the problem by turning on the sink 
light.  Be sure to include the entire log from mh startup (as you had 
recently included) up to the point of the problem (actually, a few 
seconds later).

 > In the logs I see lots of "Interface Extremely Busy"

It seems as though your other lights are being coupled in and the 
tie_items code is going to queue commands real fast--which doesn't help 
anything.

 > and then my "command:13; type:alllink; group: 01" -- this doesn't 
look familiar to me.

That actually does look correct as it is the received scene command that 
your sink switch is sending back to the plm.  It's everything else which 
seems a bit off.

Gregg

well, I ended up purchasing a EEE Box as the core MH server. I picked 
up a used one on ebay for only ~ $150 which was a great deal.

It's running XP Home, which I stuck with to keep the box licensed 
right sice my other MH implementation is also on windows.  I'm 
running headless with TightVNC installed. I hate the refresh for VNC, 
but XP Home doesn't run RDP unless you hack it (stupid MSFT). 
Fortunately most of what I need to do I can accomplish with file 
access and web access, so no real major issues.

I've got MH all up and running with no major snags. Performance is 
pretty good, with the OS + MH = ~ 200 MB ram of the 1GB on board. 
I've got 2 USB to serial cables in it with the 1-wire and W800 
running. The CM17 is still running in proxy on the old machine since 
I'm out of USB to serial cables (on order tho).  The NetCallerID is 
down until I get the new USB to Serial, but that's only a couple of 
days. (long days with all of the political calls we seem to get that 
won't be being announced).

This resolves several problems tho:
a) the IP to serial device I was using with the VMs just wasn't 
reliable so I kept occasionally losing the serial devices.
b) the vm I'd last migrated MH to (from a physical machine) was 
always at the whims of me rebooting my workstation. rare but it happens.
c) it looks cool
d) it moves the core server to a generally central point in the 
house, which should up the reliability of the CM17
e) with the server central, I should be able to get 100% bluetooth 
house coverage, so I can use my usb headset to control MH via voice 
when I'm at home - "Computer, living room lights ON" is to me the 
ultimate in home automation geekyness.
f) I can mostly leave my workstation powered off, in theory saving power
g) it mounts to the wall (see "c")

Rick


At 07:28 PM 9/20/2008, mis...@co... wrote:

>Well, one of the things I would like is for the PC to be quiet. Fanless helps.
>
>Also I'd like it to be low power consumption. Low power generally =
>low heat which also tends to not require a fan.
>
>non-fanless PCs would, I suppose, also meet most of the bill if they
>were quiet enough i can't hear them!
>
>Rick
>
>
>At 05:50 PM 9/20/2008, Brad Yarotsky wrote:
> >Why does you PC need to be fanless?
> >
> >Brad
> >
> > >
> > >
> > >
> > > Well, my overall experiment to run MH in a VM (vmware) has mostly
> > > been a failure, for a variety of reasons, so I'm looking to pick up a
> > > small fanless PC to run things in (with serial over USB).
> > >
> > > Questions:
> > > What USB to serial devices are people using with success
> > > What's the lowest MHz/CPU that I can get ok performance (under
> > > windows, running a proxy and server)
> > > What particular fanless PCs are people running?
> > >
> > > Thx
> > >
> > > rick
> > >
> > >
> > >
> > >
> > > Rick Steeves
> > > ri...@si...                             http://www.sinister.net
> > >
> > > "The journey is the destination"
> > >
> > >
> > > -------------------------------------------------------------------------
> > > This SF.Net email is sponsored by the Moblin Your Move
> > Developer's challenge
> > > Build the coolest Linux based applications with Moblin SDK & win
> > great prizes
> > > Grand prize is a trip for two to an Open Source event anywhere 
> in the world
> > > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > > ________________________________________________________
> > > To unsubscribe from this list, go to:
> > http://sourceforge.net/mail/?group_id=1365
> > >
> > >
> >
> >
> >
> >-------------------------------------------------------------------------
> >This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> >Build the coolest Linux based applications with Moblin SDK & win 
> great prizes
> >Grand prize is a trip for two to an Open Source event anywhere in the world
> >http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >________________________________________________________
> >To unsubscribe from this list, go to:
> >http://sourceforge.net/mail/?group_id=1365
>
>
>
>
>-------------------------------------------------------------------------
>This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>Build the coolest Linux based applications with Moblin SDK & win great prizes
>Grand prize is a trip for two to an Open Source event anywhere in the world
>http://moblin-contest.org/redirect.php?banner_id=100&url=/
>________________________________________________________
>To unsubscribe from this list, go to: 
>http://sourceforge.net/mail/?group_id=1365

Thomas Maclean wrote:
> In another experiment, I notice that the Sink Light turns on/off all the
> lights even if MH isn't running.

Well, that pretty much sounds like the link databases for your devices 
are not what you expect.  You might try scanning the link table for--at 
a minimum--the sink light.  Also, try the others that are affected. 
Doing a log link table only shows what mh understands.  It is always 
possible to impact the device link table external from mh and mh not see 
it unless it rescans the tables.

> Is the output with "type:alllink" normal?  I don't think I have seen this
> with other switches.

Yes--it is very normal and will always be seen when a switch is linked 
back to the plm (where the plm is the controller).

Gregg

p.s. Crossing fingers that sf hasn't munged this response as well.

Tom MacLean wrote:
> Gregg pointed out that I didn't include enough information... so here we 
> are:

FYI - I've tried repeatedly to respond via sf's list and no joy.  So, 
I'll try to send you responses from here out to your private email.  If 
that works, then at least it will benefit you.

Gregg

For some reason, the first attempt to respond didn't make it through to 
the list.  So, here goes again...

Tom MacLean wrote:
 > Gregg pointed out that I didn't include enough information... so here 
we are:
 >
 > I'm using a recent svn version:  1505 (Sep 13, 2008)
 >
 > My (only) table and code files are attached.
 >
 > I don't have access to my logs right now.  They're scrolling on the 
terminal at home, and as far as I can tell, not being logged to a file. 
  The snippet when I press the Sink Light controller and all the other 
lights come on is in the email below.  A logfile with all the log links 
output is attached.

This info helps a good deal.  However, seeing the command(s) that is 
sent in advance of the spew of "15"s is needed.  More comments below:


 > Just yesterday I had an electrician in to install some potslights and 
pendant lights in my kitchen.  In order to facilitate independant 
control of the two, I removed the old switch (hard wiring the circuit 
ON) and replaced it with a keypad link.  I then used two inline dimmer 
modules to control the potlights and pendants seperately.  I had 
previously linked them to the keypad using misterhouse -- and they 
seemed to work.  In fact, once installed, it all seemed to work.  There 
was one glitch that when I updated the switch condition from the web, 
the module didn't also update.

That doesn't make sense to even attempt.  These "switch"(es) 
($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
rationally attempt to control their state from the web (even though it 
is possible to try).  Their definitions (as you have included in the 
insteon.mht) assume that the buttons are locally pushed (i.e., via a 
human--not via mh and it's web interface).  So, of course there won't be 
any updating of your responders (the "modules") because the actual 
device (button) was not being depressed.  If you want an equivalent 
scene, then you will have to separately create new scenes where the plm 
is the controller (vice one of the keypadlinc buttons).

 > I added
 >
 > $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
 > $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
 >
 > to my insteon.pl code file ... and I think that fixed that little 
detail.

That is going to backfire on you.  Possibly, it's a part of the problem 
that you are experiencing.  While it seemed to resolve what you 
perceived as a problem, the real problem is that you were trying to 
abuse keypadlinc buttons in ways that aren't intended and can't work. 
Instead, use plm-controlled scenes if you want to control things via a 
web interface.

My suggestion is that you immediately get rid of the above tie_items code.

 > I notice the modules use a slower ramp rate than I expected (when 
updated from the web), but that doesn't concern me.

That makes perfect sense.  The scene definitions w/ the shorter ramp 
rate weren't being used--as discussed above.  Instead, the tie items 
code took over and issued direct commands which honor the local ramp 
rate (whatever it is set to).  Again, ditch the tie items code and don't 
try to set keypadlinc buttons from the web interface.

 > This morning weirdness broke out...
 >
 > I also have a dimmer on a light over my kitchen sink.  It's not 
linked to anything, except the PLM.  I turned on the Sink light this 
morning and all the potlights and pendants came on too! I notice the 
slower ramp rate occurs here too.  I have no idea why the Sink light 
controller is turning everything on!

 From your link logs, I don't yet see any "smoking gun".  But, I do want 
you to get rid of your insteon.pl code and do a full restart (not a 
reload).  Then, see if you can repeat the problem by turning on the sink 
light.  Be sure to include the entire log from mh startup (as you had 
recently included) up to the point of the problem (actually, a few 
seconds later).

 > In the logs I see lots of "Interface Extremely Busy"

It seems as though your other lights are being coupled in and the 
tie_items code is going to queue commands real fast--which doesn't help 
anything.

 > and then my "command:13; type:alllink; group: 01" -- this doesn't 
look familiar to me.

That actually does look correct as it is the received scene command that 
your sink switch is sending back to the plm.  It's everything else which 
seems a bit off.

Gregg

I had to factory-reset the switch and relink it to the controller. 
Previously I had tried "Unlink from interface" and then "scan links", "log
links" (output of which I took to mean the device was not linked to
anything), but the unit continued to control other devices it was not
linked to.

-tom m.

09/29/08 07:31:42 PM [Insteon_PLM] Processing message for $Kitchen_Sink
09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data:
02500c6736000001cb1100
09/29/08 07:31:50 PM [Insteon_Device] command:11; type:alllink; group: 01
09/29/08 07:31:50 PM [Insteon_Device] found: on
09/29/08 07:31:50 PM [Insteon_PLM] Processing message for $Kitchen_Sink
09/29/08 07:31:50 PM [Insteon_Device] $Kitchen_Sink::set(on,
Insteon_Link=HASH(0x9781928))
09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data: 02500c673605e8a9
09/29/08 07:31:50 PM [Insteon_PLM] Prepending prior data fragment:
02500c673605e8a9
09/29/08 07:31:50 PM [Insteon_PLM] Parsing serial data:
02500c673605e8a9411101
09/29/08 07:31:50 PM [Insteon_Device] command:11; type:cleanup; group: 01
09/29/08 07:31:50 PM [Insteon_Device] found: on



>
> In another experiment, I notice that the Sink Light turns on/off all the
> lights even if MH isn't running.
>
> Is the output with "type:alllink" normal?  I don't think I have seen this
> with other switches.
>
> -Tom M.
>
>> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group:
>> 01
>
>
>> Gregg pointed out that I didn't include enough information... so here we
>> are:
>>
>> I'm using a recent svn version:  1505 (Sep 13, 2008)
>>
>> My (only) table and code files are attached.
>>
>> I don't have access to my logs right now.  They're scrolling on the
>> terminal
>> at home, and as far as I can tell, not being logged to a file.  The
>> snippet
>> when I press the Sink Light controller and all the other lights come on
>> is
>> in the email below.  A logfile with all the log links output is
>> attached.
>>
>> Thanks,
>>
>> Tom MacLean
>>
>>   _____
>>
>> From: Tom MacLean [mailto:tma...@sa...]
>> Sent: Monday, September 29, 2008 10:31 AM
>> To: mis...@li...
>> Subject: [mh] insteon weirdness
>>
>>
>> Greetings!
>>
>> Sigh.  Me again. More help please!
>>
>> Just yesterday I had an electrician in to install some potslights and
>> pendant lights in my kitchen.  In order to facilitate independant
>> control
>> of
>> the two, I removed the old switch (hard wiring the circuit ON) and
>> replaced
>> it with a keypad link.  I then used two inline dimmer modules to control
>> the
>> potlights and pendants seperately.  I had previously linked them to the
>> keypad using misterhouse -- and they seemed to work.  In fact, once
>> installed, it all seemed to work.  There was one glitch that when I
>> updated
>> the switch condition from the web, the module didn't also update.  I
>> added
>>
>> $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
>> $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
>>
>> to my insteon.pl code file ... and I think that fixed that little
>> detail.
>> I
>> notice the modules use a slower ramp rate than I expected (when updated
>> from
>> the web), but that doesn't concern me.
>>
>> This morning weirdness broke out...
>>
>> I also have a dimmer on a light over my kitchen sink.  It's not linked
>> to
>> anything, except the PLM.  I turned on the Sink light this morning and
>> all
>> the potlights and pendants came on too! I notice the slower ramp rate
>> occurs
>> here too.  I have no idea why the Sink light controller is turning
>> everything on!  In the logs I see lots of "Interface Extremely Busy" and
>> then my "command:13; type:alllink; group: 01" -- this doesn't look
>> familiar
>> to me.
>>
>> Can anyone suggest what I might have done wrong?
>>
>> Thanks,
>>
>> Tom M.
>>
>>
>> 09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15
>> 09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending
>> command after delaying for 1 second
>> 09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15
>> 09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending
>> command after delaying for 1 second
>> 09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515
>> 09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending
>> command after delaying for 1 second
>> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data:
>> 02500c6736000001cb1300
>> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group:
>> 01
>> 09/29/08 08:44:05 AM [Insteon_Device] found: off
>> 09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink
>> 09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off,
>> Insteon_Link=HASH(0xb2dc2ac))
>> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data:
>> 02620d66bb0f130006
>> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data:
>> 02620d66bb0f130006
>> 09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15
>> 09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending
>> command after delaying for 1 second
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/________________________________________________________
>> To unsubscribe from this list, go to:
>> http://sourceforge.net/mail/?group_id=1365
>>
>>
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365
>

In another experiment, I notice that the Sink Light turns on/off all the
lights even if MH isn't running.

Is the output with "type:alllink" normal?  I don't think I have seen this
with other switches.

-Tom M.

> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01


> Gregg pointed out that I didn't include enough information... so here we
> are:
>
> I'm using a recent svn version:  1505 (Sep 13, 2008)
>
> My (only) table and code files are attached.
>
> I don't have access to my logs right now.  They're scrolling on the
> terminal
> at home, and as far as I can tell, not being logged to a file.  The
> snippet
> when I press the Sink Light controller and all the other lights come on is
> in the email below.  A logfile with all the log links output is attached.
>
> Thanks,
>
> Tom MacLean
>
>   _____
>
> From: Tom MacLean [mailto:tma...@sa...]
> Sent: Monday, September 29, 2008 10:31 AM
> To: mis...@li...
> Subject: [mh] insteon weirdness
>
>
> Greetings!
>
> Sigh.  Me again. More help please!
>
> Just yesterday I had an electrician in to install some potslights and
> pendant lights in my kitchen.  In order to facilitate independant control
> of
> the two, I removed the old switch (hard wiring the circuit ON) and
> replaced
> it with a keypad link.  I then used two inline dimmer modules to control
> the
> potlights and pendants seperately.  I had previously linked them to the
> keypad using misterhouse -- and they seemed to work.  In fact, once
> installed, it all seemed to work.  There was one glitch that when I
> updated
> the switch condition from the web, the module didn't also update.  I added
>
> $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
> $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
>
> to my insteon.pl code file ... and I think that fixed that little detail.
> I
> notice the modules use a slower ramp rate than I expected (when updated
> from
> the web), but that doesn't concern me.
>
> This morning weirdness broke out...
>
> I also have a dimmer on a light over my kitchen sink.  It's not linked to
> anything, except the PLM.  I turned on the Sink light this morning and all
> the potlights and pendants came on too! I notice the slower ramp rate
> occurs
> here too.  I have no idea why the Sink light controller is turning
> everything on!  In the logs I see lots of "Interface Extremely Busy" and
> then my "command:13; type:alllink; group: 01" -- this doesn't look
> familiar
> to me.
>
> Can anyone suggest what I might have done wrong?
>
> Thanks,
>
> Tom M.
>
>
> 09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15
> 09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending
> command after delaying for 1 second
> 09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15
> 09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending
> command after delaying for 1 second
> 09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515
> 09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending
> command after delaying for 1 second
> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data:
> 02500c6736000001cb1300
> 09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01
> 09/29/08 08:44:05 AM [Insteon_Device] found: off
> 09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink
> 09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off,
> Insteon_Link=HASH(0xb2dc2ac))
> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006
> 09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006
> 09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15
> 09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending
> command after delaying for 1 second
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365
>
>

Tom MacLean wrote:
> Gregg pointed out that I didn't include enough information... so here we 
> are:
>  
> I'm using a recent svn version:  1505 (Sep 13, 2008)
>  
> My (only) table and code files are attached.
>  
> I don't have access to my logs right now.  They're scrolling on the 
> terminal at home, and as far as I can tell, not being logged to a file.  
> The snippet when I press the Sink Light controller and all the other 
> lights come on is in the email below.  A logfile with all the log links 
> output is attached.

This info helps a good deal.  However, seeing the command(s) that is 
sent in advance of the spew of "15"s is needed.  More comments below:


> Just yesterday I had an electrician in to install some potslights and 
> pendant lights in my kitchen.  In order to facilitate independant 
> control of the two, I removed the old switch (hard wiring the circuit 
> ON) and replaced it with a keypad link.  I then used two inline dimmer 
> modules to control the potlights and pendants seperately.  I had 
> previously linked them to the keypad using misterhouse -- and they 
> seemed to work.  In fact, once installed, it all seemed to work.  There 
> was one glitch that when I updated the switch condition from the web, 
> the module didn't also update.

That doesn't make sense to even attempt.  These "switch"(es) 
($Kitchen_Pendants and $Kitchen_Potlights) are both buttons.  You can't 
rationally attempt to control their state from the web (even though it 
is possible to try).  Their definitions (as you have included in the 
insteon.mht) assume that the buttons are locally pushed (i.e., via a 
human--not via mh and it's web interface).  So, of course there won't be 
any updating of your responders (the "modules") because the actual 
device (button) was not being depressed.  If you want an equivalent 
scene, then you will have to separately create new scenes where the plm 
is the controller (vice one of the keypadlinc buttons).

> I added
>  
> $Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
> $Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
>  
> to my insteon.pl code file ... and I think that fixed that little 
> detail. 

That is going to backfire on you.  Possibly, it's a part of the problem 
that you are experiencing.  While it seemed to resolve what you 
perceived as a problem, the real problem is that you were trying to 
abuse keypadlinc buttons in ways that aren't intended and can't work. 
Instead, use plm-controlled scenes if you want to control things via a 
web interface.

My suggestion is that you immediately get rid of the above tie_items code.

> I notice the modules use a slower ramp rate than I expected 
> (when updated from the web), but that doesn't concern me.

That makes perfect sense.  The scene definitions w/ the shorter ramp 
rate weren't being used--as discussed above.  Instead, the tie items 
code took over and issued direct commands which honor the local ramp 
rate (whatever it is set to).  Again, ditch the tie items code and don't 
try to set keypadlinc buttons from the web interface.

> This morning weirdness broke out...
>  
> I also have a dimmer on a light over my kitchen sink.  It's not linked 
> to anything, except the PLM.  I turned on the Sink light this morning 
> and all the potlights and pendants came on too! I notice the slower ramp 
> rate occurs here too.  I have no idea why the Sink light controller is 
> turning everything on! 

 From your link logs, I don't yet see any "smoking gun".  But, I do want 
you to get rid of your insteon.pl code and do a full restart (not a 
reload).  Then, see if you can repeat the problem by turning on the sink 
light.  Be sure to include the entire log from mh startup (as you had 
recently included) up to the point of the problem (actually, a few 
seconds later).

> In the logs I see lots of "Interface Extremely 
> Busy"

It seems as though your other lights are being coupled in and the 
tie_items code is going to queue commands real fast--which doesn't help 
anything.

> and then my "command:13; type:alllink; group: 01" -- this doesn't 
> look familiar to me.

That actually does look correct as it is the received scene command that 
your sink switch is sending back to the plm.  It's everything else which 
seems a bit off.

Gregg

Guys,

I have a bunch of changes to contribute but now clue how to do that
efficiently. Would svn be the right way? If so, could someon point me to a
simple HowTo, or point me in the right direction.

My changes I can offer:

- pretty stable iphone skin
see http://ralfathome.dyndns.org/apache2-default/iphoneskin.html
Should work with firefox and safari, sorry, no IE and interface is in
German. However you could get the idea.

- some home automation icons
see http://ralf.klueber.googlepages.com/icons.png

- some changes in Groups.pm to enable a group of groups

- some changes in http_server.pm to be able to use MH behind a reverse proxy

- some changes in EIB_Items.pm 
aditional class for windows (two EIB1 Items combined) delivering 
Additional EIB Items:
package EIB9_Item;
package EIB10_Item;
package EIB11_Item;
package EIB11S_Item;
package EIB15_Item;
package EIBW_Item;
Dont know which one of these were already in the 2.104. I iwill check.

Looking forward to your advise.

KR
-- 
View this message in context: http://www.nabble.com/2.105---are-we-ready--tp19626633p19729573.html
Sent from the Misterhouse - User mailing list archive at Nabble.com.

Hi,

I'm trying to get pocketsphinx working out of perl scripts (for proof of 
concept first).... I've downloaded and installed latest SphinxBase 0.4 and 
PocketSphinx 0.5, but it seems that pockesphinx dies with segfault.... 
probably when trying to open sound device...

0.5 version doesn't have -live anymore, but does adcdev (I left it to 
default alsa device - I've compiled sphinxbase with alsa option). Also funny 
thing is that arecord works but arecord -D hw:0,0 doesn't (although 0.0 is 
default device)...

What version of sphinxbase and pockestphinx did you use ? Did you try latest 
versions ?

And since you're probably using your solution, reading about your 
experiences with it is always interesting....

Thanks in advance,

regards,

Bulek.




/usr/local/bin/pocketsphinx_continuous         -adcdev 
        -bestpath yes         -cmn none         -agc emax         -lm 
/usr/local/share/pocketsphinx/model/app/current.lm         -dict 
/usr/local/share/pocketsphinx/model/app/current.dic         -hmm 
/usr/local/share/pocketsphinx/model/hmm/wsj1
INFO: cmd_ln.c(459): Parsing command line:
/usr/local/bin/pocketsphinx_continuous \
        -adcdev default \
        -bestpath yes \
        -cmn none \
        -agc emax \
        -lm /usr/local/share/pocketsphinx/model/app/current.lm \
        -dict /usr/local/share/pocketsphinx/model/app/current.dic \
        -hmm /usr/local/share/pocketsphinx/model/hmm/wsj1

Current configuration:
[NAME]          [DEFLT]         [VALUE]
-adcdev                         default
-agc            none            emax
-agcthresh      2.0             2.000000e+00
-alpha          0.97            9.700000e-01
-ascale         20.0            2.000000e+01
-backtrace      no              no
-beam           1e-48           1.000000e-48
-bestpath       yes             yes
-bestpathlw     9.5             9.500000e+00
-cep2spec       no              no
-ceplen         13              13
-cmn            current         none
-cmninit        8.0             8.0
-compallsen     no              no
-dict 
/usr/local/share/pocketsphinx/model/app/current.dic
-dictcase       no              no
-dither         no              no
-doublebw       no              no
-ds             1               1
-fdict
-feat           1s_c_d_dd       1s_c_d_dd
-featparams
-fillprob       1e-8            1.000000e-08
-frate          100             100
-fsg
-fsgusealtpron  yes             yes
-fsgusefiller   yes             yes
-fwdflat        yes             yes
-fwdflatbeam    1e-64           1.000000e-64
-fwdflatefwid   4               4
-fwdflatlw      8.5             8.500000e+00
-fwdflatsfwin   25              25
-fwdflatwbeam   7e-29           7.000000e-29
-fwdtree        yes             yes
-hmm                            /usr/local/share/pocketsphinx/model/hmm/wsj1
-input_endian   little          little
-jsgf
-kdmaxbbi       -1              -1
-kdmaxdepth     0               0
-kdtree
-latsize        5000            5000
-lda
-ldadim         0               0
-lifter         0               0
-lm 
/usr/local/share/pocketsphinx/model/app/current.lm
-lmctl
-lmname         default         default
-logbase        1.0001          1.000100e+00
-logspec        no              no
-lowerf         133.33334       1.333333e+02
-lpbeam         1e-40           1.000000e-40
-lponlybeam     7e-29           7.000000e-29
-lw             6.5             6.500000e+00
-maxhistpf      100             100
-maxhmmpf       -1              -1
-maxnewoov      20              20
-maxwpf         -1              -1
-mdef
-mean
-mixw
-mixwfloor      0.0000001       1.000000e-07
-mmap           yes             yes
-ncep           13              13
-nfft           512             512
-nfilt          40              40
-nwpen          1.0             1.000000e+00
-pbeam          1e-48           1.000000e-48
-pip            1.0             1.000000e+00
-remove_dc      no              no
-round_filters  yes             yes
-samprate       16000           1.600000e+04
-sdmap
-seed           -1              -1
-sendump
-silprob        0.005           5.000000e-03
-smoothspec     no              no
-spec2cep       no              no
-svspec
-tmat
-tmatfloor      0.0001          1.000000e-04
-topn           4               4
-toprule
-transform      legacy          legacy
-unit_area      yes             yes
-upperf         6855.4976       6.855498e+03
-usewdphones    no              no
-uw             1.0             1.000000e+00
-var
-varfloor       0.0001          1.000000e-04
-varnorm        no              no
-verbose        no              no
-warp_params
-warp_type      inverse_linear  inverse_linear
-wbeam          7e-29           7.000000e-29
-wip            0.65            6.500000e-01
-wlen           0.025625        2.562500e-02

INFO: cmd_ln.c(459): Parsing command line:
 \
        -lowerf 1 \
        -upperf 4000 \
        -nfilt 20 \
        -transform dct \
        -round_filters no \
        -remove_dc yes \
        -feat s2_4x

Current configuration:
[NAME]          [DEFLT]         [VALUE]
-agc            none            emax
-agcthresh      2.0             2.000000e+00
-alpha          0.97            9.700000e-01
-cep2spec       no              no
-ceplen         13              13
-cmn            current         none
-cmninit        8.0             8.0
-dither         no              no
-doublebw       no              no
-feat           1s_c_d_dd       s2_4x
-frate          100             100
-input_endian   little          little
-lda
-ldadim         0               0
-lifter         0               0
-logspec        no              no
-lowerf         133.33334       1.000000e+00
-ncep           13              13
-nfft           512             512
-nfilt          40              20
-remove_dc      no              yes
-round_filters  yes             no
-samprate       16000           1.600000e+04
-seed           -1              -1
-smoothspec     no              no
-spec2cep       no              no
-svspec
-transform      legacy          dct
-unit_area      yes             yes
-upperf         6855.4976       4.000000e+03
-varnorm        no              no
-verbose        no              no
-warp_params
-warp_type      inverse_linear  inverse_linear
-wlen           0.025625        2.562500e-02

INFO: acmod.c(76): Parsed model-specific feature parameters from 
/usr/local/share/pocketsphinx/model/hmm/wsj1/feat.params
INFO: mdef.c(520): Reading model definition: 
/usr/local/share/pocketsphinx/model/hmm/wsj1/mdef
INFO: mdef.c(531): Found byte-order mark BMDF, assuming this is a binary 
mdef file
INFO: bin_mdef.c(301): Reading binary model definition: 
/usr/local/share/pocketsphinx/model/hmm/wsj1/mdef
INFO: bin_mdef.c(480): 44 CI-phone, 66516 CD-phone, 5 emitstate/phone, 220 
CI-sen, 5220 Sen, 18660 Sen-Seq
INFO: tmat.c(204): Reading HMM transition probability matrices: 
/usr/local/share/pocketsphinx/model/hmm/wsj1/transition_matrices
INFO: acmod.c(108): Attempting to use SCGMM computation module
INFO: s2_semi_mgau.c(985): Reading S3 mixture gaussian file 
'/usr/local/share/pocketsphinx/model/hmm/wsj1/means'
INFO: s2_semi_mgau.c(1084): 1 mixture Gaussians, 256 components, 4 feature 
streams, veclen 51
INFO: s2_semi_mgau.c(985): Reading S3 mixture gaussian file 
'/usr/local/share/pocketsphinx/model/hmm/wsj1/variances'
INFO: s2_semi_mgau.c(1084): 1 mixture Gaussians, 256 components, 4 feature 
streams, veclen 51
INFO: s2_semi_mgau.c(748): Loading senones from dump file 
/usr/local/share/pocketsphinx/model/hmm/wsj1/sendump
INFO: s2_semi_mgau.c(768): BEGIN FILE FORMAT DESCRIPTION
INFO: s2_semi_mgau.c(797): Rows: 256, Columns: 5220
INFO: s2_semi_mgau.c(805): Using memory-mapped I/O for senones
INFO: kdtree.c(231): Reading tree for feature 0
INFO: kdtree.c(249): n_density 256 n_comp 12 n_level 8 threshold 0.200000
INFO: kdtree.c(186): Read 255 nodes
INFO: kdtree.c(231): Reading tree for feature 1
INFO: kdtree.c(249): n_density 256 n_comp 24 n_level 8 threshold 0.200000
INFO: kdtree.c(186): Read 255 nodes
INFO: kdtree.c(231): Reading tree for feature 2
INFO: kdtree.c(249): n_density 256 n_comp 3 n_level 8 threshold 0.200000
INFO: kdtree.c(186): Read 255 nodes
INFO: kdtree.c(231): Reading tree for feature 3
INFO: kdtree.c(249): n_density 256 n_comp 12 n_level 8 threshold 0.200000
INFO: kdtree.c(186): Read 255 nodes
INFO: feat.c(849): Initializing feature stream to type: 's2_4x', ceplen=13, 
CMN='none', VARNORM='no', AGC='emax'
INFO: agc.c(132): AGCEMax: max= 10.00
Segmentation fault (core dumped)


----- Original Message ----- 
From: "Jim Duda" <ji...@du...>
To: <mis...@li...>
Sent: Monday, April 21, 2008 2:06 AM
Subject: [mh] Misterhouse Asterisk + Pocketsphinx HOWTO


> The purpose of this posting is to describe my method for integrating
> pocketsphinx and asterisk together.
>
....
http://sourceforge.net/mail/?group_id=1365
>
> 

Command: mh 
Pgm  path   : .
Pgm  version: mh 2.104 R1505  Last updated: Tue Sep  2 08:07:46 2008
Perl version: 5.008008
OS   version: linux linux  
Other       : user=mh pid=9162 box=sonya.sandbox.ca cpu=-

Read parameter files: ./mh.ini ./mh.private.ini /home/mh/mh.private.ini
Debugging for insteon turned on
Code Directories:
 - /home/mh/code
 - ./../code/common
Loading other modules
Starting setup
 - using simple Text distance function
 - reading previous log files
 - archiving previous /home/mh/data/logs/*.log files ....
 - read 2 trigger entries
 - creating http            on tcp   8080 buffered
 - creating server mhsend   on tcp   8084 buffered
 - creating server telnet   on tcp   1234 raw
 - creating xap_send        on udp  3639 send
 - creating xap_hub_listen  on udp  3639 listen
 - mh in xAP Hub mode
 - creating xap_listen_core on udp 49152 listen
 - creating xap_send_49152  on udp 49152 send
 - creating xpl_send        on udp  3865 send
 - creating xpl_listen      on udp 49153 listen
 - creating xpl_hub_listen  on udp  3865 listen
 - mh in xPL Hub mode
 - creating xpl_send_49153  on udp 49153 send
09/29/08 01:05:02 PM [Insteon_PLM] serial:/dev/ttyS0:19200
 - creating Insteon PLM port on /dev/ttyS0
 - process id 9162 written to /home/mh/data/mh.pid
 - external command file (xcmd_file): ./../house_cmd.txt
 - HTML file     : ./../web/ia5/index.shtml
Done with setup

09/29/08 01:05:02 PM Reading /home/mh/mh.private.ini and mh.ini
   html_alias alias /rrd dir does not exist, dir=/home/mh/data/rrd
Voice names: female, male1, male2, male3
Read 4 entries from ./../data/pronouncable_words.list
09/29/08 01:05:02 PM Reading 1 .mht table files: insteon.mht
09/29/08 01:05:02 PM Translating insteon.mht -> /home/mh/code/insteon.mhp
09/29/08 01:05:02 PM Initialized read_table_A.pl
Reading code_dirs: /home/mh/code ./../code/common
09/29/08 01:05:02 PM Reading 17 code files
09/29/08 01:05:02 PM Evaluating user code
09/29/08 01:05:02 PM [Insteon_PLM] setting default xmit delay to: 0.25
09/29/08 01:05:02 PM [Insteon_PLM] setting x10 xmit delay to: 0.5

Good code saved
running: play ./../sounds/sound_click1.wav
Restoring object states
Object states restored
Activating voice commands
Starting monitor commands loop

Latitude: 44.0817,  Longitude: -92.5038,  Time Zone: -6
sunrise=7:06 AM sunset=6:53 PM
sunrise twilight=6:37 AM sunset twilight=7:22 PM
The moon is New, 0% bright, and 0 days old
The next full moon is on Thursday, November 13th
09/29/08 01:05:03 PM [Insteon_PLM] Parsing serial data: 026005e8a903055206
09/29/08 01:05:03 PM [Insteon_PLM] PLM id: 05e8a9 firmware: 52
09/29/08 01:05:03 PM Generating Voice commands for all Insteon objects
09/29/08 01:05:03 PM Rereading .menu code files.
Display call with tk disabled (-tk 0).  Text=MisterHouse restarted unexpectedly! 0
09/29/08 01:05:03 PM Organizer: Calendar matches target schema and does not require upgrading
09/29/08 01:05:03 PM Organizer: Todo matches target schema and does not require upgrading
09/29/08 01:05:03 PM Organizer: Reading updated organizer calendar file now
09/29/08 01:05:03 PM Evaluating code organizer_events
09/29/08 01:05:03 PM Organizer: Reading updated organizer todo file
09/29/08 01:05:03 PM Evaluating code organizer_tasks
09/29/08 01:06:00 PM: Saving object states ... done
09/29/08 01:07:00 PM: Saving object states ... done
09/29/08 01:07:45 PM menu_run: g=mh m=Insteon i=9 s=4 => action: myPLM 'log links'
09/29/08 01:07:45 PM Running: myPLM log links
09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Sink(01) (d1=00, d2=00, d3=00)
09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Potlights(01) (d1=00, d2=00, d3=00)
09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_Pendants(03) (d1=00, d2=00, d3=00)
09/29/08 01:07:45 PM [Insteon_PLM] responder record to $Kitchen_KP_4(04) (d1=00, d2=00, d3=00)
09/29/08 01:07:45 PM [Insteon_PLM] cntlr(a0) record to $Kitchen_Pendants (d1=01, d2=00, d3=03)
09/29/08 01:07:45 PM [Insteon_PLM] cntlr(a1) record to $Kitchen_KP_4 (d1=01, d2=00, d3=04)
09/29/08 01:08:00 PM: Saving object states ... done
09/29/08 01:08:19 PM menu_run: g=mh m=Insteon i=5 s=7 => action: Kitchen Sink 'log links'
09/29/08 01:08:19 PM Running: Kitchen Sink log links
09/29/08 01:08:19 PM [Insteon_Device] link table for $Kitchen_Sink (devcat: 0101):
09/29/08 01:08:19 PM [Insteon_Device] aldb 05e8a9011 [0x0FF8] contlr(01) record to $myPLM(01), (d1:fe, d2:1f, d3:00)
09/29/08 01:08:19 PM [Insteon_Device] adlb [0x0FF0] is empty
09/29/08 01:08:49 PM menu_run: g=mh m=Insteon i=4 s=7 => action: Kitchen Potlights 'log links'
09/29/08 01:08:49 PM Running: Kitchen Potlights log links
09/29/08 01:08:49 PM [Insteon_Device] link table for $Kitchen_Potlights (devcat: 0109):
09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9011 [0x0FF8] contlr(01) record to $myPLM(01), (d1:fe, d2:1f, d3:01)
09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a903103 [0x0FF0] contlr(03) record to $myPLM(03), (d1:fe, d2:1f, d3:03)
09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a904104 [0x0FE8] contlr(04) record to $myPLM(04), (d1:fe, d2:1f, d3:04)
09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9a0003 [0x0FE0] rspndr(03) record to $myPLM(a0): onlevel=on and ramp=none (d3:03)
09/29/08 01:08:49 PM [Insteon_Device] aldb 05e8a9a1004 [0x0FD8] rspndr(04) record to $myPLM(a1): onlevel=on and ramp=none (d3:04)
09/29/08 01:08:49 PM [Insteon_Device] aldb 0d6906031 [0x0FD0] contlr(03) record to $Kitchen_Pendants_module(01), (d1:ff, d2:1f, d3:01)
09/29/08 01:08:49 PM [Insteon_Device] adlb [0x0FC8] is empty
09/29/08 01:09:00 PM: Saving object states ... done
09/29/08 01:09:12 PM menu_run: g=mh m=Insteon i=3 s=10 => action: Kitchen Potlights module 'log links'
09/29/08 01:09:12 PM Running: Kitchen Potlights module log links
09/29/08 01:09:12 PM [Insteon_Device] link table for $Kitchen_Potlights_module (devcat: 0102):
09/29/08 01:09:12 PM [Insteon_Device] aldb 0e2dec010 [0x0FF8] rspndr(01) record to $Kitchen_Potlights(01): onlevel=100% and ramp=0.1s (d3:00)
09/29/08 01:09:12 PM [Insteon_Device] adlb [0x0FF0] is empty
09/29/08 01:10:00 PM: Saving object states ... done
09/29/08 01:10:19 PM menu_run: g=mh m=Insteon i=1 s=10 => action: Kitchen Pendants module 'log links'
09/29/08 01:10:19 PM Running: Kitchen Pendants module log links
09/29/08 01:10:19 PM [Insteon_Device] link table for $Kitchen_Pendants_module (devcat: 0102):
09/29/08 01:10:19 PM [Insteon_Device] aldb 0e2dec0301f [0x0FF8] rspndr(1f) record to $Kitchen_Potlights(03): onlevel=100% and ramp=0.1s (d3:1f)
09/29/08 01:10:19 PM [Insteon_Device] adlb [0x0FE8] is empty
09/29/08 01:10:19 PM [Insteon_Device] adlb [0x0FF0] is empty
09/29/08 01:10:25 PM menu_run: g=mh m=Insteon i=1 s=8 => action: Kitchen Pendants module 'status'
09/29/08 01:10:25 PM Running: Kitchen Pendants module status
09/29/08 01:10:25 PM [Insteon_PLM] Parsing serial data: 02620d69060f190006
09/29/08 01:10:26 PM [Insteon_PLM] Parsing serial data: 02500d690605e8a92b0000
09/29/08 01:10:26 PM [Insteon_PLM] Processing message for $Kitchen_Pendants_module
09/29/08 01:10:26 PM [Insteon_Device] received status request report for $Kitchen_Pendants_module with on-level: 0%, hops left: 2
09/29/08 01:11:00 PM: Saving object states ... done
09/29/08 01:12:00 PM: Saving object states ... done

Tom MacLean wrote:
> Sigh.  Me again. More help please!
http://misterhouse.wikispaces.com/Insteon+Devices+-+Quirks+and+Hints#gettinghelp

Greetings!
 
Sigh.  Me again. More help please!
 
Just yesterday I had an electrician in to install some potslights and
pendant lights in my kitchen.  In order to facilitate independant control of
the two, I removed the old switch (hard wiring the circuit ON) and replaced
it with a keypad link.  I then used two inline dimmer modules to control the
potlights and pendants seperately.  I had previously linked them to the
keypad using misterhouse -- and they seemed to work.  In fact, once
installed, it all seemed to work.  There was one glitch that when I updated
the switch condition from the web, the module didn't also update.  I added 
 
$Kitchen_Pendants->tie_items($Kitchen_Pendants_module); # noloop
$Kitchen_Potlights->tie_items($Kitchen_Potlights_module); # noloop
 
to my insteon.pl code file ... and I think that fixed that little detail.  I
notice the modules use a slower ramp rate than I expected (when updated from
the web), but that doesn't concern me.
 
This morning weirdness broke out...
 
I also have a dimmer on a light over my kitchen sink.  It's not linked to
anything, except the PLM.  I turned on the Sink light this morning and all
the potlights and pendants came on too! I notice the slower ramp rate occurs
here too.  I have no idea why the Sink light controller is turning
everything on!  In the logs I see lots of "Interface Extremely Busy" and
then my "command:13; type:alllink; group: 01" -- this doesn't look familiar
to me.

Can anyone suggest what I might have done wrong?
 
Thanks,
 
Tom M.
 
 
09/29/08 08:44:02 AM [Insteon_PLM] Parsing serial data: 15
09/29/08 08:44:02 AM [Insteon_PLM] Interface extremely busy. Resending
command after delaying for 1 second
09/29/08 08:44:03 AM [Insteon_PLM] Parsing serial data: 15
09/29/08 08:44:03 AM [Insteon_PLM] Interface extremely busy. Resending
command after delaying for 1 second
09/29/08 08:44:04 AM [Insteon_PLM] Parsing serial data: 1515
09/29/08 08:44:04 AM [Insteon_PLM] Interface extremely busy. Resending
command after delaying for 1 second
09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data:
02500c6736000001cb1300
09/29/08 08:44:05 AM [Insteon_Device] command:13; type:alllink; group: 01
09/29/08 08:44:05 AM [Insteon_Device] found: off
09/29/08 08:44:05 AM [Insteon_PLM] Processing message for $Kitchen_Sink
09/29/08 08:44:05 AM [Insteon_Device] $Kitchen_Sink::set(off,
Insteon_Link=HASH(0xb2dc2ac))
09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006
09/29/08 08:44:05 AM [Insteon_PLM] Parsing serial data: 02620d66bb0f130006
09/29/08 08:44:06 AM [Insteon_PLM] Parsing serial data: 15
09/29/08 08:44:06 AM [Insteon_PLM] Interface extremely busy. Resending
command after delaying for 1 second

Hi Robin,
i am in need of the startup script.
I am currenty using SuSE 10.3 (does your scipt works on both versions?)
thanks in advance


Robin Edwards schrieb:
> Robin Edwards wrote:
>   
>> Hi, I've been away from list for while and from 'improving' my system due to
>> alot of other commitments.  However, just recently had some spare time and
>> decided to upgrade from Suse 10 to 11.  Needless to say I've now got couple of
>> problems.  I'm hoping someone can point out a way forward.  Currently running on
>> Misterhouse 2.103,  I tried 2.104 but backed it out, too many changes at once.
>>
>> So, good news is 2.103 works with Suse 11.  It autostarts as well (if anyone
>> wants startup script let me know).  CM11 and W800RF work just fine, but....
>> I get loads of the following error occurring in the mh.log:
>>
>> Bad time format:  02:23   caller=main /usr/local/mh/bin/mh 6232
>> db mday=24 mdayf=09 min=34 minf=23 secf=0 hour=21 hourf=02 ap= m=9 mf=23 y=2008
>> yf=108
>> Bad time_now format:  09/24 02:23  caller=main (eval 479) 5861
>> Bad time format:  20:09   caller=main /usr/local/mh/bin/mh 6232
>> db mday=24 mdayf=09 min=34 minf=09 secf=0 hour=21 hourf=20 ap= m=9 mf=22 y=2008
>> yf=108
>> Bad time_now format:  09/23 20:09  caller=main (eval 479) 5868
>> Bad time format:  00:10   caller=main /usr/local/mh/bin/mh 6232
>> db mday=24 mdayf=09 min=34 minf=10 secf=0 hour=21 hourf=00 ap= m=9 mf=23 y=2008
>> yf=108
>> Bad time_now format:  09/24 00:10  caller=main (eval 479) 5875
>> Bad time format:  17:02   caller=main /usr/local/mh/bin/mh 6232
>> db mday=24 mdayf=09 min=34 minf=02 secf=0 hour=21 hourf=17 ap= m=9 mf=23 y=2008
>> yf=108
>> Bad time_now format:  09/24 17:02  caller=main (eval 479) 5882
>>
>> Second and possibly unrelated my WMR968 produces no output.  I copied all the
>> directory structure for MH from my /usr/local/mh on Suse10 to Suse11 but nothing
>>  and reverting back to SUSE 10 (I have second partition) everything works fine.
>>  I wondered if the newer level of Perl on 11 might have impact?
>>
>> Any suggestions more than welcome. regards, robin
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
>> Build the coolest Linux based applications with Moblin SDK & win great prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> ________________________________________________________
>> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>>
>>
>>     
> I discovered in the process of moving I've managed to remove the following line
> from mh.ini "serial_wmr968_module=Weather_wmr968".  I put that back in and now
> MH won't run.  It terminates after a few seconds with "Undefined subroutine
> &Weather_wmr968::convert_local_barom_to_sea_mb called at
> ../lib/Weather_wmr968.pm line 423."  As far as I can see the Weather_wmr968 is
> in /lib and is dated 2006/10/07 14:49.  Is this the correct version?
>
> BTW, reading about 2.105, I can install it to replace my existing if someone
> wants me to, once ready, but my testing will be limited, although at least it
> will sit and run.  (on Suse 11.. all being well)
>
> robin
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
>   

Jack,
It may be easier, more practical, and certainly more "standard" to use 
ntp on your various machines.  I have a mixes bag network of PCs, Linux 
hosts, IP Phones and my wife's Mac all using one local server for time, 
and that one local server uses a pool of hosts at NIST to get its time 
from.  It's pretty easy to set up, and happens in the background on a 
regular basis (every 61 seconds I believe).  This is your truly best 
shot at achieving synchronicity aside from going to the record store ; )
If I remember correctly, you are a windows user.  There are some free 
NTP server software packages out there that will allow your windows PC 
to provide NTP services to devices on your network, so even if you lost 
your internet connection, all devices on your network would drift together.
-Dave
As another musical aside, am I the only one unable to discuss NTP/time 
services without humming a certain Chicago tune?

Jack Edin wrote:
> Gregg,
>
> You've fixed the error. *Thank you!*
>
> Sorry it took so long to inform you, but It wasn't until this morning 
> that I heard a report:
>
> /"System Clock adjusted: two second difference!"/
>
> Now...
>
> I am requesting 3 improvements - all as parameters for the .ini file(s)...
>
> 1) Time Server's URL
> 2) Time of day this operation is preformed.
> 3) The ability to silence the announcement(s).
>
> I'm trying to synchronize various devices daily. They all have clocks 
> that drift a bit... If I can make them all use the SAME server, and 
> set them all at the SAME time each day, I believe I have my best shot 
> at achieving sychronicity...
>
> As for the announcement - _I can do without it._ Especially when I 
> expect to do this at midnight...!!
>
> Yes I understand ALL atomic clocks (probably) return the same result. 
> I would still prefer to choose my own server!
>
> Thanks, in advance.
>
> Sincerely,
>
> Jack
> :)
>
>
>
> Gregg Liming wrote:
>> Jack Edin wrote:
>>   
>>> Before Matt spins a new release, I thought I would point out a flawed 
>>> module.
>>>
>>> My coder friend was asked to take a quick look, and he _complained_!
>>>
>>> He said something like "If somebody like ME can't figure something like 
>>> this out in 15 minutes, there is a problem!"
>>>     
>>
>> mmmmm...
>>
>>   
>>> I apologize for a lack of details. I just know the problem exists...
>>>
>>> It was fine until I updated from the SVN about a month ago... Now every 
>>> morning, at 100% volume, I get the warning: "System Time not set due to 
>>> Internet error."
>>>
>>> Evidently part of this is hard coded, but that alone isn't the problem.
>>>
>>> Also it doesn't seem to read the private.mh.ini for the URL of the time 
>>> server. I believe it also doesn't use mh.ini either.
>>>     
>>
>> it doesn't.  ... would be trivial to change if that is an issue for you ...
>>
>>   
>>> I don't know who wrote this module. The SVN log didn't indicate a recent 
>>> change either...
>>>     
>>
>> it didn't
>>
>>   
>>> Yet I had it working, and now it don't!
>>>     
>>
>> But, you now seem to have a good, morning alarm clock--albeit a message 
>> that isn't very tailorable ;)
>>
>>   
>>> If it IS a coding issue, should it be fixed prior to release of the next 
>>> version??
>>>     
>>
>> Apparently, the targeted server (time-a.timefreq.blrddoc.gov) decided to 
>> be fully compliant and stop answering to incorrect tcp ports.  I had a 
>> time askew adjustment while fixing; so, I can't tell you whether it took 
>> me 10 minutes or 20 minutes.  You decide.
>>
>> svn update and report if your morning-time announcements continue their 
>> monotony.
>
> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> ------------------------------------------------------------------------
>
> ________________________________________________________
> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365
>
>   

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Gregg,<br>
<br>
You've fixed the error. <b>Thank you!</b><br>
<br>
Sorry it took so long to inform you, but It wasn't until this morning
that I heard a report:<br>
<br>
<i>"System Clock adjusted: two second difference!"</i><br>
<br>
Now...<br>
<br>
I am requesting 3 improvements - all as parameters for the .ini
file(s)...<br>
<br>
1) Time Server's URL<br>
2) Time of day this operation is preformed.<br>
3) The ability to silence the announcement(s).<br>
<br>
I'm trying to synchronize various devices daily. They all have clocks
that drift a bit... If I can make them all use the SAME server, and set
them all at the SAME time each day, I believe I have my best shot at
achieving sychronicity...<br>
<br>
As for the announcement - <u>I can do without it.</u> Especially when
I expect to do this at midnight...!!<br>
<br>
Yes I understand ALL atomic clocks (probably) return the same result. I
would still prefer to choose my own server!<br>
<br>
Thanks, in advance.<br>
<br>
Sincerely,<br>
<br>
Jack<br>
:)<br>
<br>
<br>
<br>
Gregg Liming wrote:
<blockquote cite="mid:48D...@li..." type="cite">
  <pre wrap="">Jack Edin wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">Before Matt spins a new release, I thought I would point out a flawed 
module.

My coder friend was asked to take a quick look, and he _complained_!

He said something like "If somebody like ME can't figure something like 
this out in 15 minutes, there is a problem!"
    </pre>
  </blockquote>
  <pre wrap=""><!---->
mmmmm...

  </pre>
  <blockquote type="cite">
    <pre wrap="">I apologize for a lack of details. I just know the problem exists...

It was fine until I updated from the SVN about a month ago... Now every 
morning, at 100% volume, I get the warning: "System Time not set due to 
Internet error."

Evidently part of this is hard coded, but that alone isn't the problem.

Also it doesn't seem to read the private.mh.ini for the URL of the time 
server. I believe it also doesn't use mh.ini either.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
it doesn't.  ... would be trivial to change if that is an issue for you ...

  </pre>
  <blockquote type="cite">
    <pre wrap="">I don't know who wrote this module. The SVN log didn't indicate a recent 
change either...
    </pre>
  </blockquote>
  <pre wrap=""><!---->
it didn't

  </pre>
  <blockquote type="cite">
    <pre wrap="">Yet I had it working, and now it don't!
    </pre>
  </blockquote>
  <pre wrap=""><!---->
But, you now seem to have a good, morning alarm clock--albeit a message 
that isn't very tailorable ;)

  </pre>
  <blockquote type="cite">
    <pre wrap="">If it IS a coding issue, should it be fixed prior to release of the next 
version??
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Apparently, the targeted server (time-a.timefreq.blrddoc.gov) decided to 
be fully compliant and stop answering to incorrect tcp ports.  I had a 
time askew adjustment while fixing; so, I can't tell you whether it took 
me 10 minutes or 20 minutes.  You decide.

svn update and report if your morning-time announcements continue their 
monotony.</pre>
</blockquote>
<br>
</body>
</html>