jaustin
commented
3 years ago Hello @rapport this is an intersting writeup and useful!
I think the location here on codal-microbit-v2 isn't really the right place for it to get thought through in the way it needs to be for an implementation to emerge.
Lancaster have done a range of interesting pieces of research around IoT and the micro:bit including using Radio bridges to the internet, and there are also some opportunities to extend micro:bit Classroom to support IoT usage scenarios, while ensuring a teacher still has control over the sort of requests the devices are making. There is also a very well-defined micro:bit BLE profile that can help the device be accessible over BLE https://lancaster-university.github.io/microbit-docs/ble/profile/
Another really interesting area that this has been developed is in the Espruino ecosystem -see for example https://github.com/espruino/EspruinoHub and https://www.espruino.com/BLE+HTTP+Proxy
In fact, Espruino provides a lot of the things you describe already. Have you looked at that?
rapport
Currently this library is performing great for when you want a closed program running from a device created in Makecode but it is not working well at all for IoT applications! The difficulty is of course that BLE needs to bridge across to the internet and this communications is not well supported at the moment. There are various hardware attempts to add IoT support (proving need!) but they appear to be overcomplicating and overwhelming users with attaching various bits of hardware (WiFi,LoRa,Cellular etc.) and with mixing MQTT blocks and various things in makecode which is probably also an abstraction too far again!
I propose that we instead solve this problem with variations to the firmware (in codal) and software (adding a new 'makeapp' flashing environment). So how about we make a completely separate additional makecode type environment called 'makeapp'? There could be a https://makeapp.microbit.org/ store on the internet and also private makeapp stores running anywhere users want them ( e.g. https://makeapp.atmyschool.edu ) and can run a BLE bridge! The makeapp environment would save the current makecode users from being overwhelmed with options that are only required in client/server applications and this separation of concerns in dedicated environments would make it all so much easier to understand for users and massively extend the features and improve the usefulness of the project!
Also, if 'makeapp' existed and you wanted your Micro:bit to talk to IoT you don't need to attach anything to your device like now and it can just come fresh out the box and get attached by software! The difference would be that you flash it with the 'makeapp' flasher software rather than the 'makecode' flasher and that would open the BLE connection on the device specifically to speak with that IoT app. The IoT makecode apps would be things like 'vote on important world issues', 'vote on important things at school', 'get fit measure how I am doing and compete with friends', 'star wars co-op game with friends' etc.
The 'makeapp' environment could also be simple. You would only need to be able to subscribe to an app and establish a way with sharing the BLE, bind key, ids, tokens etc. to communicate over BLE with server. Then also just like with your phone APP you would need to choose and approve which sensors, actuators, gpio etc. you share with the it and how. There is also a huge area here for creativity here too and lets not forget that either... Even if your makeapp.microbit.org was just taking a 'yes' or 'no' vote from users they choose how to map it, whether to the buttons on the device, or some could attach foot switches to reduce COVID risks, or some could have shake or blow for yes or no or clap or anything they could imagine and build! This could also help improving accessibility in schools too as users could adapt micro:bits more widely to support user specific needs such as a physical or mental disability!
With this Micro:bits could be flashed by a new type of 'makeapp' HEX that exposes their BLE information and helps them communicate to IoT makeapp's in a standardized way. Then on the server side it would be much more straightforward to add the keys, tokens and IDs to read from the devices and what has been shared. This could easily be done server side in something like ESPhome BLE tracker (https://esphome.io/components/esp32_ble_tracker.html) for a couple of Micro:bits, or with bluez on Raspberry Pi for a class on in bluez in OpenWrt to service a whole school!