Like many others I am waiting for delivery of some T-Beams. Meanwhile, I am trying to get familar with the device code for future contributions. I have some ESP32 devices and tried to build and run the device code. Unsuprisingly it did not run, but I think there would be some value to get it running on a generic device (ESP32, NRF52, …) as a development and test tool when working on Bluetooth, Wifi, mobile apps, anything that doesn’t require GPS or LORA.
I noticed the flag USE_SIM_RADIO, and set that to get past some errors, and I may continue with that approach.
However maybe a broader approach to simulation would be useful to the project, with similar code stubs that simulate a Radio, a GPS, a screen, External i/o and other sensors. These could be passive stubs that simply return an acceptable value to avoid errors, or more dynamic that generate psuedo-data (e.g. radio messages from other mesh node, random sensor values for MQTT, GPS locations within a locality, ), or write data out to serial etc . These sims may be superior to actual devices for testing, by generating test cases/data that are hard to generate physically. Also would allow a developer to enable/disable components and isolate & troubleshoot issues. Porting to a new device, power management development may also benefit from being able to substitute a component with a known-good software simulator.
It looks like this could be achieved without major changes to the device application or too much bloat (changes to platform.ini envs, and the existing board selection logic in main.cpp, along with the stub functions).
What does the project think ?