Adding Location Support for Local Coordinate System inside Tasmota

[belveder79]

I'm a power-user of Tasmota for many years now and I'm always excited about the robustness and reliability of the framework - and the possibilities to use it for other stuff as well like this.

Let me share something with you which I recently built.

It's a full node-based 3D interface allowing for annotating devices registered in TasmoAdmin to a 3D model of a house. It also uses some OpenBeken switches and a Homee. The model is interactive, so you have a cyber-physical model (switching something physically changes the model, e.g. lights in the model go on, vice versa, you can switch physical assemblies in the browser to turn the lights on or off).

What I found is that while Tasmota has the full functionality in terms of electronics, it misses location support (afaik). We are talking about x/y/z in a local coordinate frame, probably also some alpha/beta/gamma as rotation parameters. Those parameters are owned by the device, not by any framework building upon it. @philfleck and me were discussing about implicit support for this as part of MQTT best practices, say /house/bathroom/lightswitch1, but that does not give enough information except a rough location - and only if you follow the practices, and I actually do not...

My thought is that with more and more 3D interaction also coming up through AI, this would at least enable linking the electronics components somewhat into the physical world and enable direct use in 3D interfaces - and it would just likely be a SetOption and a SetLocation call.

Any thoughts welcome...

[s-hadinger]

Hi, and thanks for your feedback.

Sure, this looks like a very valuable addition. Do you have any suggestions about the format of the location, i.e. what type of values we would need to store in Flash (3x 32 bits integers, or 6x if we want orientation)?

[s-hadinger]

Moving around Settings with #ifdefs is a big no-no. It break everything. More generally we favor run-time configuration rather than compile-time. Compile-time flags are mostly there to reduce the Flash size.

[s-hadinger]

Hmmm, I didn't think Settings was already so packed because of ESP32-S31 which leaves around 14 bytes free, on top of which we may add 6 bytes...

[s-hadinger]

@arendst we may need to reconsider the following:

uint8_t       rf_code[17][9];            // 5D4 - 153 bytes

And see if we can shrink it a little

[belveder79]

probably I'm the bad cop, but that is a hack, not a solution...

[arendst]

@s-hadinger consider use of union like i did at fbc for rf_code.