Feedback Req'd: Getting %V Readings via Python Periodically


I’m trying to get readings of %V (Supply Voltage) of an xbee module router mode placed on a xbee dev. board (xbib) on a periodic basis via a .py device driver.

The Condition:
#1 Obtain %V value
#2 If %V value => 3000mV, return True
#3 If %V value < 3000mV, return False.

I’m trying to achieve knowing whether my xbib board is powered with Vin or not (in this case, an xbee module Router mode is attached to it). Hence the Boolean property

I’ve theorized into 2 ways of doing it:
#1. Create a XBeeDeviceManagerRunningEventSpec(). This will return the %V value when the device has transitioned to the running stage
#2. Create a XBeeDeviceManagerRxEventSpec(). This will return the %V value whenever the device manager “receives a parameter”
#3. Device Manager polls for xbib to return %V value every x period
#4. If value detected; return True to its respective channel property. If value not detected, and timeout occurs; return False

#1. Repeat steps [A]#1 - #2.
#2. Sample %V according to the period of XBee S2 Chip IR parameter.
#3. Channel Property shows True when %V value obtained.
#4. Channel Property shows False when %V value could not be obtained after a timeout occurs.

My limitations:
On method [A], I’m trying to achieve obtaining %V value at
i) t = 0: device cannot be discovered, hence returns False;
ii) t = 1: device is switch ON and discovered, hence returns True;
iii) t = 2: device is switch OFF, hence returns False

I’ve successfully implemented i) and ii). But struggling to achieve iii) because I’m not sure how I can run [A]#3 (Device Manager polls for xbib to return %V value every x period). A while loop don’t fix it because it will continuously run the loop and if exit, it won’t run the loop again. Feeling lost on how to proceed.

On method [B],
I’m not sure how I can run [B]#2. (Sample %V according to the period of XBee S2 Chip IR parameter.) To tie the IR value to a time function, is just as challenging as method [A].

I would appreciate feedback and opinions on how I should work on them and some directions on how to do them. Kinda stuck too long here.

I’m attaching the python code I’m working on
Disclaimer: Code adapted and modified from post:,999#3836; - A resourceful work from lynnl’s :wink:

I hope the Christmas and New Year mood is not affecting the rate of replies to the Digi Forum Community :frowning:

Well, your post is a bit complex :slight_smile:

You can also have the V% value returned once per minute - I think.

Set the V+ value to something unrealistically high - say 3600 mV. Given the XBIB is running on 3.3, this should always cause ‘an alarm’ of voltage too low.

Read up on the “periodic IO Sampling” in the XBee manual. Then setting IR to 60000 SHOULD (if my idea is correct) cause an I/O production once per minute. The V% is returned as part of the data, flagged with bit #7 (Supply Voltage) being returned.

The IO sample arriving will also call your driver periodically.

(Bahagia tahun baru! FYI - I lived in Singapore for 11 years and at one time spoke enough Melayu to drive around Malaysia and work at Petronas refineries)

hehe, I’m trying to be as detail as I can :slight_smile:

Yes I’ve read from a comment somewhere that you were driving up to Batu Pahat often for Durians? (You really liked them!!!??)
your Malay is pretty rusty now. I’m guessing you used google translator? haha! :P; hint: “Selamat

I was hoping that you would reply, since the code originated from your post actually (at Done some pretty neat mods.

Ah… right… why did I miss out “analog channel masking”? Darn. But anyway, my get_parameter work as you can see from my posted py code; I will tweak it tmr according to your suggestion.

But I’m thinking, even bit masking of supply voltage won’t tell the presentation manager that it’s a 0mV. Because the device is switched off, hence it won’t be able to detect the value.

How would you suggest to deal with it? My presentation property for this driver is just Boolean outputs. Hence if it’s a above 3000mV it’s ON else it’s OFF. (yet it won’t display OFF if XBee don’t return the sample value)

I’m thinking putting

io_sample = parse_is(buf)

in a try and except clause. But ain’t that sure what kind of exception it will raise (…at the moment, because I’m at home at 12 am and 8 hours more before I can test it.) :slight_smile:

I left Singapore in 1999, love durian & roti prata, and no doubt my tongue is rusty - plus virtually every engineer or technician I dealt with in Malaysia spoke excellent English. It was mainly the elderly Kopi-Ibu at job sites who got a big kick out of my limited Malay.

One problem with ‘polling’ for the DDO-level answer is that when it’s off-line, your gateway BLOCKS on the request for from 30 seconds to what seems like minutes. That is because the DDO commands are half-duplex in nature. If you have 20 other devices, during that block any messages they send may be queued & delayed, plus no new responses can be sent to the other 19 devices.

That is the beauty of using the periodic IO polling - you can know the device is dead because it STOPS sending in data. There is no blocking or delayed behavior.

In my own drivers, if I expect the device to send data every 10 minutes, then I set an event timer for say 3+ times that period (so 31 minutes). As soon as I receive data, I clear that event and set a new one.

As long as the device is online, it sends data, the ‘offline timer’ never triggers because it is reset every period.

If the device goes offline & misses 3 consecutive data periods, then the event timer triggers and you can set some internal bad/offline state. As soon as the device recovers, you’ll receive data again & clear out the bad/offline state info.

So you might not even need to bother with the voltage - just have the XBee send you the digital IO states even if you don’t care.

Well the urban myth that says “orang putih / guai lo” doesn’t like durian is not true…well…some of it.

Haha. It’s actually for a demo of a project I’m working on.
Trying to code it in such a way that it detects Supply On / Off; Live State Monitoring; and Last State Update (after it’s device has been switched off) of the XBee chipsets. (Do you’ve any code similar to share?)

I’ll work on that event timer tmr. Previously my event timer was clause with polling via DDO method. Perhaps it can work better with IO sampling method. hmm…

Off the record,
do you have a sample of a device driver code that you work on CPX using threading? I’m looking to exploring threading in the future. Figure using an example to start of :slight_smile:

Look at the file: src/devices/

There’s not much to it. Just base the device on threading, start the thread during start & have a run() which never exits UNLESS the stop() function is called. You’ll want your thread to exit gracefully as the Dia is inheritting methods to support deep-sleep (aka: power down between runs)

Just be aware that each thread can eat 30K or more of RAM, so use sparingly.