[Feature Request]: Add channel selector to serial module TEXTMSG mode

[linker3000]

Platform

Cross-Platform

Description

At the moment, the serial module's TEXTMSG mode sends messages over the default channel.

It would be very useful to have an optional channel selector message prefix to be able to select the channel over which the message should be sent,

Example, to send on channel 1: "/1Hello World"

[garthvh]

You want to use the protobuf mode for this.

[linker3000]

This is a very disappointing reply because it dismisses the suggestion straight away without further chance for discussion by proposing an extremely complex to implement solution for simple sensors that can be set to output just a serial string value, and would require an intermediate device to handle the complexity of protobufs adding to the cost of implementing a simple remote sensor or info reporting device.

[GUVWAF]

The request is a duplicate of #3713. The TXTMSG mode is supposed to be a very simple mode. Next to a specific channel, messages to a node are also often needed. If someone can come up with a simple scheme that supports both, it may be worth the breaking change and hassle of a more powerful MCU to run the protobuf mode.

That said, there is a simple example in the Arduino Client library that should be plug-and-play: https://github.com/meshtastic/Meshtastic-arduino/blob/master/examples/SendReceiveClient/SendReceiveClient.ino
Otherwise, you could consider changing the order of your channels on this device such that your desired channel is on channel 0.

And lastly, if this is a simple sensor, would it not make more sense to look into getting it supported in the main firmware? Text messages for sensor values are not really ideal.

[linker3000]

I have swapped channels for testing, but that doesn't help if you want to pick a specific one from many to direct the message.

Implementing this suggestion would support ANY current and new sensor that has an async output, or simple messaging scripts without the need for an intermediate, power using processor or microcontroller or core Meshtastic code change, and avoids the need to handle protobufs - it would 'just work'. Plus it would enable simple, scripted apps to be written...even in bash if so wanted.

Adding more and more sensor-specific code to the core app will bloat the code, take time, every time, to make it into a released version and adds more points of potential breakage, adds to testing for every build/release and then requiring ongoing maintenance.

I know this will sound snarky - that's not my intention, it's meant as an observation from someone who started coding in 6502, Z80 and 8086 assembler, PL/M 86 and pascal, and has a strong background in algorithmic coding and program structure - but really doesn't do much coding now so I'd be totally rubbish at working on this code myself these days, but...if adding a front-end parser to the TEXTMSG code is tricky then it would seem the code in that area is not structured to allow such a new procedure/function/method to be slotted easily in to the code flow. If that is the case and changes would have to be made in many areas I can see how implementing this suggestion could take a lot of testing and refactoring of structure, in which case I understand the push back, but it would be a shame if that were the case. In any event, kudos to the coders who've produced a really great app overall.

[linker3000]

Well that told me.

[garthvh]

This is intentionally a very simple mode without any options, there is a protobuf mode where you can do anything you want. Adding complexity to the simple mode is not on the roadmap, it is going to remain simple.