Re: [mh] Problem connecting to xPL

[Gregg L. <gr...@li...>]

Neil Wrightson wrote:

> Hi Greg,
>
> Thanks for your help. The only xPL device I have is a OSD/Terminal 
> micro with a 16*2 LCD and 5 push buttons, see 
> http://www.olimex.com/dev/index.html AVR-MT-128. I have written the 
> firmware to suit xPL and it appears to be working correctly within 
> xPL. I now have MH sending the date and time out to it every 5 
> seconds. Fancy clock :).
>
with 16 cols and 2 lines, surely you could write out "mh rox" every 5 
secs ;)

> -------------------------------------------------------------
>
> The heart beat messages that were in the TK interface and recorded in 
> the Print.log are
> 07/07/05 21:34:04  xpl data: hbeat.basic : interval = 2 |
> 07/07/05 21:34:27  xpl data: hbeat.basic : interval = 2 |
> 07/07/05 21:34:27  xpl data: hbeat.basic : interval = 2 |
> 07/07/05 21:34:27  xpl data: hbeat.basic : interval = 2 |
> 07/07/05 21:34:28  xpl data: hbeat.basic : interval = 2 |
> etc etc
>
So, these must be your device?  You must be getting this info by 
enabling test_xap.pl.

> The MH heart beat messages are now coming into xPLHAL every minute.
> Refer to below captured data from the xPL Manager Monitor
> STAT    mhouse-mh.misterhouse   *       HBEAT.APP       5/07/2009 
> 11:27 1       interval=1, port=3866, remote-ip=10.0.0.54, pid=3188
>
So far--so good...

> -------------------------------------------------------------
>
> With regard to MH not receiving xPL messages. It is to some degree, 
> refer to below captured from the MH TK Interface
> This is from a push button trigger on my display. Strangley, it does 
> not show the address of the sending device?
>
Not strangely... the output from text_xap.pl (which is serving as a 
"dumb" repeater) is displaying only the content portion of the message.  
By address, do you mean the xPL "remote-ip" address that is sent in the 
header?  If so, that is still accessible programatically.  If you mean 
"source" header, then likewise that is also accessible programatically.  
Again, think of the test_xap.pl as being a simple way of observing some 
aspect of the data.  If you want more info, please set your debug to 
"xap".  Alternatively, I can help you with code to access specific 
header vars.

> 09/07/05 10:41:20  xpl data: sensor.basic : current = pulse | 
> sensor.basic : type = input | sensor.basic : device = pb_up |
>
> 09/07/05 10:41:20  xpl data: sensor.basic : current = pulse | 
> sensor.basic : type = input | sensor.basic : device = pb_up |
>
> 09/07/05 10:41:20  xpl data: sensor.basic : current = pulse | 
> sensor.basic : type = input | sensor.basic : device = pb_up |
>
> I have to write some code in MH yet and try to process the above. 
> (Perl is not one of my programming strengths)
>
Feel free to post some pseudo code here or to me directly if you desire 
some help here.

> -------------------------------------------------------------
> I have now disabled my xAP, thanks.
>
Cool--although it has an arguably equally rich set of applications to 
leverage.

> -------------------------------------------------------------
>
> > Can you elaborate about "MH interface"? In general, if mh is
> > no longer
> > implementing a hub (as you've indicated above), then it doesn't "see"
> > messages that are intended for anything but itself (technically, it
> > does, but it quickly quits processing) .
>
> Does this mean that it will not interpret my triggers from my OSD 
> terminal?
>
No--that was a bad explanation.  It will see and process the messages 
assuming that your non-mh hub passes them on.

>
> Does this mean I need a MH Hub for my OSD device messages to be decoded?
>
No.  But, you will need to write code to do something with it.  Again, I 
will be happy to try to help.

> -------------------------------------------------------------
>
> >This last group is *only* used to transmit and receive a mh-specific 
> schema
> >(dialect) that is--thus far--only used to "synch" different mh
> >instances.  The keyword here in the mh parm variable is "item"--which is
> >intended to suggest that mh is communicating information about mh
> >"items" (e.g., x10 items, RF items, etc.).
>
> Need another cup of coffee. I don't understand what you are saying here.
>
Ok--some time ago, someone (who's name escapes me) asked about an 
ability to "sync" the state of multiple mh instances. Historically, the 
mh "proxy" protocol is used to permit multiple mh instances of 
intercommunicating (and possibly other protocols).  Bruce decided to use 
xAP (and xPL?) to support the ability to sync state.  The message schema 
to support this message syncing is specific to mh.  As it turns out, the 
schema is somewhat abstract and does allow non-mh transmitters or 
receivers to communicate with it. However, unless you (or someone else) 
has written application to do so (and you'd have to do so 
deliberately--so, it's rather unlikely), then it doesn't apply.  My 
reference to "item" was referring to the ability to transmit and receive 
state via xAP and xPL about an mh item's state (e.g., an x10 item might 
be ON or OFF).  If you were an xAP user, the mh schema for this specific 
usage is very similar to BSC.