High-level interface needed

[GoogleCodeExporter]

The classes available here are very low-level and require the user to have an 
AT command reference handy in order to make use of them.  A higher-level Python 
API is needed to expose these commands and arguments as native Python methods 
and data types.

For instance:

    # Set remote DIO pin 2 to low (mode 4)
    xbee.remote_at(
      dest_addr='\x56\x78',
      command='D2',
      parameter='\x04')

Could become:

    xbee.SetDigitalOutput(2, xbee.LOW, remote='5678')

I'm happy contributing such a thing, but it's not clear how/where such a layer 
would sit with the existing API.

Original issue reported on code.google.com by [email protected] on 12 May 2011 at 3:15

[GoogleCodeExporter]

Hi David,

Thanks for your feedback. The low-level nature that you're noticing was by 
design; the scope of the recent work was to make the library functional and 
useful, if not particularly simple.

With that said, we'd be happy to accept your contributions if you would like to 
make some improvements. Since this functionality works at a higher level, my 
first thought would be to create wrapper classes that contain an instance of 
the XBee and ZigBee classes respectively.

This wrapper class would then translate higher-level commands into one or more 
API commands that would be serviced by the existing code.

Does that sound reasonable?

~Paul Malmsten

Original comment by [email protected] on 13 May 2011 at 4:49

• Changed state: Accepted

[GoogleCodeExporter]

Original comment by [email protected] on 13 May 2011 at 5:15

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Curious if anything like this has been done...  Seems it would make xbee 
features/functions so much more accessible.  Numbers like \x56\x78, \x04 are 
incomprehensible and AT commands very abstract.

Original comment by [email protected] on 8 Apr 2012 at 4:42

[GoogleCodeExporter]

No, nothing has been done yet. Some of the nastiness is unavoidable, i.e. for 
addressing and raw data transmission. I agree though, it would be nice to have 
a higher level interface to complement the low level one.

It hasn't bothered me (or apparently anyone else) enough yet to write one, so 
it hasn't been done.

Original comment by [email protected] on 13 Apr 2012 at 9:29

[GoogleCodeExporter]

I hear you, Paul.  It's just that I've struggled to get 2 way communications 
working and I feel like there's too many moving parts for me to know what's 
wrong.  I've used the library with the 
xbee.remote_at(dest_addr='\x56\x78',command='D2',parameter='\x04') and for the 
life of me, I can't seem to make it work.

I can collect data from numerous xbees 24x7 and send it to web services like 
pachube, but I cannot reverse the process and turn on a silly LED.  I'm 
starting to think I need to look in more detail at the settings I need to 
change in X-CTU to allow the 2-way communication.  If you have any pointers, 
I'd appreciate it.

Thanks,
Chris.

Original comment by [email protected] on 13 Apr 2012 at 10:27

[GoogleCodeExporter]

I've been working on a high-level API (using python-xbee as its base 
communication layer). https://github.com/markfickett/xbee-homeautomation

Setting a pin value does actually look similar to the OP's imagined code:

cmd = ConfigureIoPin(dest=0x13a200abcd1234, pinName=PIN.DIO1, 
function=ConfigureIoPin.FUNCTION.DIGITAL_OUT_HIGH)
cmd.send()

(And by the way, I think Chris' issue was that dest_addr must be the 64-bit 
serial number, not the shorter network address.)

Original comment by [email protected] on 25 Sep 2012 at 1:04