With the Wi9P starter kit I have gotten the demo programs working and a few other pieces of code. I have the XBIB-U and XBIB-R dev boards but the XBIB device driver (xbee_xbib.py) does not have any code to support the serial (USB or RS232) that the dev boards are intended for. I also could not find a device driver from either of the RS232 or USB Digi Adapters to be used under iDigi Dia.
Where will I find the device drives that support all the features on the XBIB dev boards and/or the serial adapters?
I have seen and gotten to work fragments of code that work for serial (but not in Dia) or the analog/digital IO (stand alone or in Dia) but not both.
This may seem a strange question, but how would you expect those pipes to be used? I am assuming you hope to connect to the serial endpoint in the devices and pass serial data between the PC and the Wi9P. The Dia, however, is not really geared for providing a raw data pipe through a channel, to the best of my knowledge.
So you want a Dia driver that can read and write data to the XBee device (regardless of whether it’s connected to an XBIB or not) and have it come out the UART? I’ve done the reading bit; I’ve got a couple of sensors in my house that send data to the Dia gateway using the transparent config (data sent in the UART on one XBee comes out the UART on another XBee). I haven’t had to write data out, yet.
I’m attaching the driver; the yaml config looks like this:
The driver is kind of complicated; my data stream is line-oriented, but I’m not guaranteed to get complete lines when the data packet is sent, so I have to buffer the data in the driver and split out the lines after each packet is received. Thought the more complex example might be helpful…
Here is the simple Dia serial driver I use for an XBee RS-232 module attached to my RFID readre. The RFID sends data when it wishes, so I’m not polling. I also use the RS-232 status pings as a “clock-source” for another Dia block. I need aux-power enabled since the RFID reader tries to draw power from the RS-232 peer - so I run aux power (~12vdc) to the DSR-input of the reader.
I include my RFID code, but don’t promise it’s useful for anyone else
This is a good example of overlap between serial endpoints and the iDigi framework. A device driver can interpret serial data locally and compose discrete units (samples) that could be used to fill channels.
Thank you blalor, that is what I was looking for.
From the code experiments I have done I was guessing that the code to handle serial data from the XBee modules would need to do some parsing.
I do also wish to get the ‘pin data’ from the same XBee module as that will transfer serial data. From the code I’ve played with I will need to change the EndPoint values for serial data on each XBee module since two ‘tasks’ can not share the same EndPoint. I changed the serial EndPoint with X-CTU on a USB XBIB dev board the 0xc8 and the standard XBIB Device Drive worked under iDigiDia and I was able to send/recieve serial under a separate python program.
Is this how it should be set up?
Is EndPoint 0xc8 good to use? Or is there a better one?
I also got the idea that all of the XBee modules serial would be recieved within the same routine (same EndPoine, Profile ID & Cluster ID). The Source address would need to be examined to determine which module sent the data and have some way to pass the data on (maybe with a subscribe like in the WattHour Wiki example).
Am I on the right track?
Thanks. The code’s a little heaver than I’d like, but it does the job. Using transparent mode, I’m not guaranteed that my serial data won’t extend beyond packet, so I have to take that into account. My other sensor uses a format like “#12345:12345#” which is a little easier to parse.
I’m about to re-do both sensors and I’m thinking I might try using the xbee-api library for the Arduino and use different endpoints for each data type.
You can use the same endpoint address on multiple devices, to the best of my knowledge. As you later note, the hardware address is used in conjunction with the endpoint in both the outbound cases and the inbound cases (where, as you note, the source address is consulted).
Also, my code makes use of the publish-subscribe mechanism in Dia. So the “serial” device publishes (pushes) every string it receives into the RFID device.
So the RFID device is passive with NO thread. It is pushed to action by 2 things:
tag_source: rfid_reader.serial_receive pushes a new string into it
or time_source: rfid_reader.serial_status pushes anything into to it - in my case I cheat and have the RS-232 drive push the DTR/DSR status in. I could also link it to my alarm_clock to push in minutes ticks. It just needs something to enable it to “age” the RFID tags in the list.
Thanks for the link, Lynn. I think I have a use for pub/sub.
Quick question on the code I see throughout Dia. Most classes (well, devices, at least) inherit from SettingsBase, yet I see almost exclusive usage of the pattern “SettingsBase.get_setting(self, ‘foo’)”. Why aren’t you using “self.get_setting(‘foo’)”? Not to put to fine of a point on it, but it reads like someone who’s either not very familiar with object-oriented programming or has very little familiarity with Python.
Hi lynn,
The simple_serial driver worked out of the box. I could send a string into the USB dev bd from X-CTU and read it with a Dia CLI channel_dump. Also could send a string with Dia CLI channel_set and it shows up in X-CTU. Next is looking into the RFID code and the subscribe methods.
Side note: X-CTU is a handy utility for testing. All the functionality I’ve needed is there.
wr
In your simple_serial.zip file in this thread topic, I’ve mod the source code of xbee_serial.py to fit my required objective
One of the problems I’m facing now is that I would like to parse the received buffer of a XBee DIN pin to toggle off the boolean property in iDigi DIA. (Look at xbee_plug_lynn.serial_receive) I’m not really clear how to do so
I’ve inserted comments in the .py file for your reference
I’d appreciate all your troubleshooting done for me
