Opentx: add copy/paste functions to telemetry page under companion

[strgaltdel]

Problem:
Due to hardware changes (new ESC, GPS of another manufacturer etc..) certain telemetry sensors are deleted and read in again via automatic recognition.
As a result, the sorting sequence has changed.
If logical switches have been created, they are now functionless or based on wrong telemetry sensors, since the assignment is made via the sorting number of the telemetry sensors.

current workaround

• if not known: read "new hardware sensors" in a dummy memory to recognize ID, instances etc.
• in the target memory, enter the ID's / instances manually to the adequate sensors so that the sorting sequence is not lost.

Desired solution (companion):
Similar to logical switches and special functions, copy & paste functionality on the telemetry page would also be an advantage within Companion.
You could create reference memories that contains hardware-specific telemetry sensors and easily migrate them by drag & drop to a desired memory in a certain order.
Side effect would be an easy way to resort the sensors and group them in a more logical way than they are automatically recognized

thanks & regards
Udo

[kilrah]

What about "move up/move down" buttons next to each sensor?

[strgaltdel]

Yep, a big step forward !
If i would be a SW-dev, and this solution could mean 50% less work, i would go this way.

[guycnicholas]

Let me walk through a scenario to make sure I understand this.
I am setting up my model, I scan for sensors and my battery sensor shows up as "LCel". I then go to my logical switches and set up a switch to do something on low voltage, and in that switch row I see something like, "L05 a Time passes and my sensors get re-read and the order of the items changes. I think you are saying that my logical switch 5 will now have some other item in place of "LCel" correct? First of all, that would be very problematic, and how would a user know that their switch just changed. Secondarily, if I did notice my logical switch was wrong, I think it would be completely unobvious that it is an ordering problem and that I need to go reorder my sensors. The sensor order value really never showed up to the user in the switch area and seeing it in the sensor area the number probably doesn't seem important.
Please forgive me and feel free to disregard my comment if my understanding of the problem is incorrect.

[kilrah]

Correct.

how would a user know that their switch just changed

This only happens if you delete and rescan sensors.

[guycnicholas]

This only happens if you delete and rescan sensors.

Right, but still, seems like a non-obvious side effect given the use of sensors in switches is via name not number. Further I don't think any user would be able to figure out that reordering the sensors would be the way to fix their switch. If I noticed my switch went bad, I think I would edit the switch and re-choose the sensor I originally had.
IMHO the only real solution is to save index/name pairs before the rescan and adjust values accordingly after the scan.

[kilrah]

Gone over this many times. Not straightforward. Names are user definable. You can have multiple sensors with the same name. Custom names are lost when you delete sensors. If you delete all sensors it's because of significant changes so reusing previous stuff usually makes little sense or would break things, it's all going to need rework anyway.

It can't be automated, so best is to give some tool to make it easier.

[strgaltdel]

@kilrah: Thanks for implementation in 2.3

@guycnicholas
like kilrah said, an "integrated solution" is not so simple as it appears on a first view.
I'm not a dev, but would suggest tracking of historical entrys costs memory/storage, maybe a redesign in LS parameter handling (plausibility checks .., in another words lot of work), and doesn't mean a bullet proof re-detection.
Example: by know i'm switching to new ESC's which gives you two "VFAS" and two "Curr" IDs, because the manufacturer defined the SBEC sensors in the same range like the Input Voltage&Current
So it's not exactly clear which new Sensor should "overwrite" the historical one

When the user is aware of the interrelationship he knows that he has to rearrange the sort order after telemetry rescan.
My intention was to simplify this process by using companion,
so the solution wouldn't "compromise" firmware coding

Greetings & thanks
Udo

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ParkerEde]

this would be a nice feature.
please "unstale"

[RipperDrone]

I second that! :-)

[elecpower]

Feature will be in 2.3.10