Moustachauve
Feedback request
I'm adding BLE (Bluetooth Low Energy) functionality to WLED and WLED-Native-Android.
I'm trying to follow best-practices with separation of control, etc.... I would be most grateful if you could take a look at my progress (ble branch on my fork) and let me know your thoughts and/or preferences as I move forward.
thanks rob
Can you explain in more details the advantages of Bluetooth over Wifi? battery efficiency? I like the Usermod approach, but I've been told by other WLED dev's that Bluetooth would not be implemented. Nice if you do it and it works! Also, I wonder how you overcome a problem : the control interface is actually hosted on the WLED device and transmitted through HTTP to WLED-Native (which basically act as a webbrowser). Do you plan on hosting the interface file on the smartphone? provide another/different interface? I will check the pull requests. Best, Arthur
Can you explain in more details the advantages of Bluetooth over Wifi? battery efficiency? I like the Usermod approach, but I've been told by other WLED dev's that Bluetooth would not be implemented. Nice if you do it and it works!
that's correct, the WLED project team have opted to not add BLE as an official feature, which is why I've done the usermod. I think this is partly due to the added size, but I'm not 100% certain. When adding the original Bluetooth stack to WLED, the bin file would not fit in the default partition schema of a 4MB ESP32 implementation. More recently, with the transition to IDF_V4 platform, I have been able to use the much smaller NimBLE stack and can fit BLE and several other mods into the default partition. (see this discussion for more details: WLED BLE JSON discussion )
Can you explain in more details the advantages of Bluetooth over Wifi? battery efficiency? ... Also, I wonder how you overcome a problem : the control interface is actually hosted on the WLED device and transmitted through HTTP to WLED-Native (which basically act as a webbrowser). Do you plan on hosting the interface file on the smartphone? provide another/different interface?
it's a progressive development project (AGILE, you might say)... The implementation is designed to control the underglow and other custom LEDs that I'm installing on my car. I've actually designed and built WLED compatible DRL (daytime running light) boards to replace the DRLs in my headlights and added ambient lighting as well.
the end-goal is to eventually add Android Auto functionality to the WLED-Native app. I use wireless AA in my car, which uses WiFi for the high-speed connection to the infotainment head unit, so Bluetooth makes the most sense to me for being able to control WLED and continue to maintain a proper WiFi connection to the car. (Plus, it's an practical use-case for learning BLE at the uController and Android levels)
regarding battery efficiency, to be honest, I haven't been concerned about it, since the controller will be powered by the car's 12V system. I've also designed a daughter board (esp32-hat) that senses when the ignition is on for controlling the power relays (so the LEDs don't drain the battery when the car is off)
regarding the HTTP question: As mentioned earlier, I'm targeting the Android side, so I get to cheat... :-) Since WLED-Native-Android uses a WebView, I can intercept the DeviceWebView's test for POST actions and redirect them to a BLE handler that will send the Json from the POST request over BLE. The BLE usermod implements a Nordic-compatible UART service that functions almost identically to the WLED_serial module. I'm thinking that I will have to intercept the GET requests,also, to facilitate loading the html pages into the WebView, and I know that I have to modify the html pages to generate Json POSTs rather than form posts. (I may end up implementing GET and POST services now that I think about it)
I have no idea how to implement any of that on the iPhone, though, since it looks like the iPhone app uses a different way of processing the web pages :-( (I'm not a iPhone guy LOL )
my design goals so far:
- add new property to the Device class:
isBle - derive BleDevice and WiFiDevice classes from the base Device class
- this should allow me to have each Device object manage its own network communications (IP or BLE) while leaving most, if not all, of the ViewModel code untouched
- serialize both to the Room database as Device objects
- deserialize the objects from the Room database to the derived classes