One device manager with multiple devices?

[grimmwerks]

This might seem a little more abstract as I'm using your lib as a cocoa pod with Rubymotion, so posting code might be a little odd...

But I've basically two classes - a BLE_Mgr -- a singleton which sniffs for appropriate devices (from the company) and then a SensorMgr class -- which is birthed by the singleton and there are multiple instances of this script, one for each sensor found.

The BLE_Mgr finds the sensors, creates the SensorMgr instance with a pointer to the DeviceManager that the BLE_Mgr created to sniff for devices...

So in other words, multiple devices are using the same WLXBluetoothDeviceManager.deviceManager and set up their connections and call backs -- believe it or not it's working quite well when there's not a lot of data.

When we have a big data dump of sensor events however, right now it seems that only one instance continues the connection and sends data up while the other sensors are seen to disconnect.

My original thought was that if there was a problem with connecting multiple devices to the same shared DeviceManager I'd see it at birth of the instance, but that it disconnects on large data dumps tells me that perhaps it auto-oscillates between the instances and at that point just can't keep up.

Can you shed some light to this, and perhaps whether or not it's a completely stupid idea to have this shared DeviceManager across devices? Would/should I just birth multiple instances of the WLXBluetoothDeviceManager.deviceManager, or rethink in it's entirety?

[grimmwerks]

Actually - it seems to be the connection timeout -- if I open it up to say 200 seconds then both sensors respond just find on the same shared deviceManager.

[guidomb]

Sorry for the lat response. Is this a still an issue? Although I have never use this library to connect to more than one device at the time, multiple connections should be possible AFAIK. What could be happening is that you are overloading the bluetooth stack by sending too much data from different devices and the OS missing packaged thus dropping connections. But this is just a theory.

[grimmwerks]

No - the multiple connections, everything is working great. I'm having something else I tweeted you - it's tough to get into the depth of it but I've got a manager that queues up messages to send, waits for a response from the device and then goes on to the next message. In most cases all this works great.

But in one scenario, I've got to connect and set up the connection, the serviceManager call back and once I'm connected and the callback is listening, I send the first message. But for some reason (and I'm slowly troubleshooting today) it seems before the addObserverForCharacteristic is set for a callback to a selector, it dies for some reason.

I understand I should be totally able to send messages when connected (and read a characteristic, because I'm getting battery levels successfully even when the callback to a selector isn't set yet).

It's hard to show code as well, because I'm using Rubymotion and everything is written in Ruby and translated to obj-c.

I'm very slowly going through testing right now to see where this is throwing an error, so hopefully I'll have something very specific to ask. Mostly I was hoping that there might be a callback to know when the serviceManager notification has changed - which I think you do actually; just not being able to get a response on it yet.

[guidomb]

I am not sure I follow your problem, sorry. Again not sure if this is what you are talking about but keep in mind that when both explicit reads and characteristic notifications get notified through the same delegate. This is how CoreBluetooth works. What I do to try to differentiate explicit reads from notifications is to check if there is an active read callback block. This read callback block is stored every time you want to read a characteristic. If the callback block is available we invoke if not then we tell all observers that a value has been updated for a characteristic. Observers are added to this list of observers when you want to observe characteristic notifications even if you haven't enabled notifications for that characteristic.

In retrospective this design decision wasn't a very good one. Because depending on timing and threading updates could be lost or sent to the wrong observers. You can check the code here

I am going to close this issue. If you find any other problem feel free to submit another issue.