Only one connection to the device via PhoneAPI is allowed at any time.

[mc-hamster]

Old title: ""most recently read messageNum" is kept in MeshService"

From Kevin:

There is an ugly hack in there to shutdown the BLE API whenever someone connects through another instance of PhoneAPI.

This was a mistake I made originally - the notion of "most recently read messageNum" is kept in MeshService (which is a singleton used by everyone). It really should be in PhoneAPI instead.

From Jm:

When this is rewritten, also include information so we can track which client connected to the device sent the message.

• Did it come from BLE? Which connected device?
• Did it come from wifi?
• Did it come from a plugin on the device?
• Somewhere else?

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/webui-doesnt-show-devices-when-a-python-script-is-running/2186/2

[garthvh]

Getting this bug fixed is a prerequisite to having multiple users with concurrent connections to a single device.

[garthvh]

Based on some crash feedback from the iOS app it appears that some crashes that seem to be caused by doing a BLE PIN connection via the app may be caused by users trying to connect via serial and BLE being simultaneously.

[ventz]

@garthvh Thanks for posting.

@geeksville I was that user :) -- I had a serial console opened on a T-Beam and was connecting via @garthvh's iOS app.

If it will be helpful to test anything specific, or provide any info/debug/etc, let me know.

[geeksville]

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/multiple-phones-connected-to-1-t-beam/4586/6

[joshpirihi]

Does the device really need to keep a track of each client individually? it'd make it really easy if every client got every FromRadio packet, whether they asked for it or not. What issues might that cause?

[mc-hamster]

Otherwise the client would get packets it has already seen and would need to manage state it wouldn't otherwise have to.

[joshpirihi]

I missed the discussion on the call this morning -- I'll stay out of it until I know more about how hard this is

[mc-hamster]

I missed the discussion on the call this morning -- I'll stay out of it until I know more about how hard this is

Don't hold back and please keep questions coming. It's better that we learn more.

[thebentern]

@garthvh do we know if this has been resolved with the transition to the new bluetooth stack?

[garthvh]

This is not resolved, to be honest I think this in an enhancement not a bug really. This is enabling multi user on a single device, which I think we kind of kicked way off down the road by increasing the node count. @mc-hamster is probably more authoritative on this but I suspect multi user with 80 node limit is a hard problem for the nodedb as configured to solve.

[garthvh]

Closed as not practical anymore based on changes for 2.0.

[k1n6b0b]

There's a lot of discussion around use cases for multi connections

Could this be reevaluated or is it never possible?

My post from another thread---

We would use this if it became available. We fit into the multiple groups / one device per group when doing remote activities like hiking, camping, especially remote music festivals. Right now we designate one person to be the conduit and they have to proxy all coordinations. This group is price sensitive, not kidding, we’d prefer not to have to spend 20-80/pp to add this connectivity.

Any increase in # concurrent connections via wifi or Bluetooth from the mobile app to the LoRa communicator would be huge for us. We primarily use the T-Echos but have one T-Beam as a basestation at camp

Communicating as the same named user is fine. Multiple users would be ideal. But multi simultaneous connections in any fashion is the request!

Wish I could contribute in some way to this ask 🙏

Thanks!