So the ESP32 doesn’t talk bluetooth and wifi at the sametime well (it causes dropped packets). So I’m thinking of making a new rule: If you have wifi configured (either as an access point or as a station) it would leave bluetooth disabled. Does anyone have a problem with this?
I can’t think of anything but wanted to check before I removed a ‘feature’.
Personally, I think this is completely reasonable given the use case difference between the two options.
There could be a few gaps that would be nice to bridge for the android app in my opinion, if this decision is made:
For messaging and channel settings, could the android app could be made to support TCP connection to the device either over soft ap or as client on a traditional wireless network?
And I think the same question applies to firmware updates. I’ll give an example. I have a wifi connected device inside of an enclosure way up on my children’s playset. Bluetooth updating that device’s firmware was a huge convenience. It would be swell to have that ability over tcp. I’m probably not the only one with a device on wifi in a very inconvenient place to access.
Seconding thebentern on this. I’m one of those weird users who use both Bluetooth and WiFi at the same time because the phone app only supports Bluetooth and I don’t want to take the device down from my window to plug it into my PC to access it via the serial port.
If the phone app could support everything over TCP/IP, I think I wouldn’t mind so much.
What if WiFi and Bluetooth were gated behind preference settings? The Wi-Fi STA and AP settings are already hidden away in the Python API/CLI.
That’s also actually a pretty good stop-gap solution for the bluetooth firmware flashing, disabling the bluetooth radio by default but adding a preference for enabling bluetooth radio.
In my use case for instance, I could easily run something like meshtastic --host 192.168.2.6 --set bluetooth_enable true to turn on bluetooth temporarily for flashing new firmware and then turn it back off when everything is complete.