Hi again,
Has nobody but me experienced this problem so far?
Is anybody currently using Jabber with mh and could tell me the versions of
the libraries that do work together correctly?
Cheers,
Kai
"Kai" wrote:
> Hi,
>
> I am having big problems getting net_im_send to work with Jabber on
> openSuSE 11.1.
>
> I have set all parameters in my mh.private.ini and have the following
> line in my code:
>
> net_im_send(pgm => 'jabber', text => "Hello World!") if $Startup;
>
> When starting up, I get the following in the log:
>
> Logging onto jabber.org 5222 with name=xxx resource=misterhouse
> - Sending username/resource xxx/misterhouse
> Error found in user code file: /opt/misterhouse/data/mh_temp.user_code
>
> 04/30/09 10:14:02 PM: Usage: Authen::SASL::Cyrus::client_new(pkg,
> parent, service, host,
> ...) at
> /opt/misterhouse/mh/bin/../lib/site/Authen/SASL.pm line 63.
>
> I couldn't figure out the problem myself, I can only guess that this is
> due to
> incompatible versions of perl-Net-Jabber (2.0-4.96) and
> perl-Authen-SASL-Cyrus
> (2.1.22-182.1) which come with openSuSE 11.1.
>
> Does anybody have this working or any hint how I can solve this?
>
> Thanks a million in advance!
> Kai
>
>
> ------------------------------------------------------------------------------
> Register Now & Save for Velocity, the Web Performance & Operations
> Conference from O'Reilly Media. Velocity features a full day of
> expert-led, hands-on workshops and two days of sessions from industry
> leaders in dedicated Performance & Operations tracks. Use code vel09scf
> and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf
> ________________________________________________________
> To unsubscribe from this list, go to:
> http://sourceforge.net/mail/?group_id=1365
>
>

Marc MERLIN wrote:
> On Thu, May 07, 2009 at 10:15:08PM -0500, w20090329.mh@... wrote:
>> Marc MERLIN wrote:
>>> I was looking at http://misterhouse.wikispaces.com/Insteon, and it says
>>> "automatic retries (in the event that the Insteon peer retry fails)"
>>>
>>> I don't think this means what I wrote in the subject line, but that made me
>>> think that it could mean that.
>>>
>>> If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh
>> My understanding is that the PLM will only report (via the serial
>> interface) either DIRECT messages to it, or other messages with from ids
>> that are in it's link table and for which it is marked a responder.
>
> Right, that's definitely what it does by default. I was hoping it might have
> some kind of promiscuous mode so that it could see other traffic.
>
> But eh, this might just be wishful thinking too :-/
It has that mode. Someone else would need to completely rewrite the
insteon libs to take advantage. I have no desire to walk down that trail.
Gregg

Marc MERLIN wrote:
> I was looking at http://misterhouse.wikispaces.com/Insteon, and it says
> "automatic retries (in the event that the Insteon peer retry fails)"
>
> I don't think this means what I wrote in the subject line, but that made me
> think that it could mean that.
>
> If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh
> should see switch1 tell lamp1 to turn on (it already sees that and logs it),
> and then it could see if lamp1 acks switch1.
> If that ack is not received, it could then poll lamp1 for its status and
> resend it the message it was supposed to get, possibly with a higher retry
> count and/or more interval between the retries.
>
> The reason I'm thinking about this is that despite having tried to make my
> home network as clean as possible, I still have occasional messages that get
> dropped.
> When they come from the PLM, that's fine since the PLM will retry enough (in
> number of times and clock time) that the message will get there, but from
> KPL to KPL, it sometimes looks like they maybe retry once and give up, or at
> least their retries are not as reliable as the ones coming from the PLM.
> If the PLM could log those KPL to KPL acks, it could then resend the
> commands that didn't get acked.
>
>
Well, I'm not sure I've seen this behavior in practice, but the dev
guide says transmitters will first transmit with max hops set to 1 (or
was it zero) and then increase and re-transmit if they don't see an
ACK. If the devices do manage to communicate with a low max hops count,
the PLM might never see the traffic at all if the two devices are "far
enough away". (It seems to me from what I've seen that the all-link
message is always sent with max hops of 3, then the individual device
cleanups use the increasing max hops formula.)
Of course, with the PLM in the "scene", it should get the group and
cleanup messages, so it could go after and check up on the devices,
since MH knows the link tables anyway.
I have no idea if it already does or not, mind you.
>> My understanding is that the PLM will only report (via the serial
>> interface) either DIRECT messages to it, or other messages with from ids
>> that are in it's link table and for which it is marked a responder.
>>
> Right, that's definitely what it does by default. I was hoping it might have
> some kind of promiscuous mode so that it could see other traffic.
>
> But eh, this might just be wishful thinking too :-/
>
Even if the PLM has a device address in it's link table and is set as a
responder, it doesn't seem to send the ACK/cleanup messages thru the PLM
to MH because the TO address does not match, /and the security feature
of the PLM says it should therefore never allow that/. Yup, that's a
feature. And although I've seen some tricks for "figuring out"
information about other devices on the network without knowing their
address, I don't believe there is /any/ sort of promiscuous mode
possible without re-writing the internal software -- and maybe not even
with that depending on the hardware setup (I may be thinking of the PLC
when thinking there was a possibility of re-written software allowing it).

On Thu, May 07, 2009 at 10:15:08PM -0500, w20090329.mh@... wrote:
> Marc MERLIN wrote:
> > I was looking at http://misterhouse.wikispaces.com/Insteon, and it says
> > "automatic retries (in the event that the Insteon peer retry fails)"
> >
> > I don't think this means what I wrote in the subject line, but that made me
> > think that it could mean that.
> >
> > If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh
>
> My understanding is that the PLM will only report (via the serial
> interface) either DIRECT messages to it, or other messages with from ids
> that are in it's link table and for which it is marked a responder.
Right, that's definitely what it does by default. I was hoping it might have
some kind of promiscuous mode so that it could see other traffic.
But eh, this might just be wishful thinking 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 & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/

Marc MERLIN wrote:
> I was looking at http://misterhouse.wikispaces.com/Insteon, and it says
> "automatic retries (in the event that the Insteon peer retry fails)"
>
> I don't think this means what I wrote in the subject line, but that made me
> think that it could mean that.
>
> If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh
>
My understanding is that the PLM will only report (via the serial
interface) either DIRECT messages to it, or other messages with from ids
that are in it's link table and for which it is marked a responder.

I was looking at http://misterhouse.wikispaces.com/Insteon, and it says
"automatic retries (in the event that the Insteon peer retry fails)"
I don't think this means what I wrote in the subject line, but that made me
think that it could mean that.
If the PLM can be configured to pass ACKs that aren't for it, up to mh, mh
should see switch1 tell lamp1 to turn on (it already sees that and logs it),
and then it could see if lamp1 acks switch1.
If that ack is not received, it could then poll lamp1 for its status and
resend it the message it was supposed to get, possibly with a higher retry
count and/or more interval between the retries.
The reason I'm thinking about this is that despite having tried to make my
home network as clean as possible, I still have occasional messages that get
dropped.
When they come from the PLM, that's fine since the PLM will retry enough (in
number of times and clock time) that the message will get there, but from
KPL to KPL, it sometimes looks like they maybe retry once and give up, or at
least their retries are not as reliable as the ones coming from the PLM.
If the PLM could log those KPL to KPL acks, it could then resend the
commands that didn't get acked.
For now, I have code that listens to state toggles and have the PLM resend
them 1 second later, no matter what, but this scheme has flaws:
- not happy with quick device on/off toggles
- creates additional traffic that usually wasn't necessary
- I can't request_status before sending the maybe lost command, because that
would generate traffic too.
What do you think?
Doable? Crackpot idea? other?
Thanks,
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 & security ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/