Support replies and reactions

[zdenek-biberle]

All text message events now include two extra fields - reply_id and emoji.

These correspond to the same fields in the Data protobuf and can be used to determine whether the message is a reply or a reaction.

The three service actions that send messages (Send Text, Broadcast Channel Message and Send Direct Message) now accept an emoji parameter, which will be reflected in the transmitted packet. This can be used together with the existing reply_id parameter to send reactions.

I've decided to also simplify some of the existing reply_id code. We don't need an explicit None case, since zero already has exactly that meaning. This makes some of the code simpler and some of the events more predictable - reply_id now has exactly one value indicating that a message is not a reply (i.e. zero) and not two (i.e. both zero and None).

I've also altered the descriptions for the reply_id field. They're now more in-line with the Meshtastic protobufs.

Finally, I've changed the reply_id selectors to be templates, since you'll definitely be putting a template inside that field.

Please let me know if there's anything you'd like to see changed or improved. Thanks!

[CLAassistant]

All committers have signed the CLA.

[zdenek-biberle]

Hey there @broglep. Sorry to bother you, but could I perhaps have some feedback on this PR?

[broglep]

Would you mind rebasing it to dev branch? Your changes overlap with a previous contribution: f974152

Unfortunately didn't find time to yet to get dev really released, and the existence of that dev branch is not that apparent.

In case a rebase it too much work right now, I'll do it when preparing dev for a release

[zdenek-biberle]

Oh I see, that's actually a very relevant change. I'll get on the rebase right away.

[zdenek-biberle]

The rebase is finished.

I've decided to alter some of the existing reply_id functionality. I think that it's now a bit simpler. It should be backwards compatible. @ov1d1u please let me know if you are all right with those changes.

[zdenek-biberle]

I feel like we don't need to wait for ov1d1u's opinion on the reply_id changes any more.

I've been running the extension with my changes for the past three weeks and it's been working well.

[broglep]

Great that it work and you have tested it. Have you tried if the change is backwards compatible? I'm unsure if it will break existing automations that don't have reply_id and emoji field in the payload.

[zdenek-biberle]

Yes, I have tried that.

broadcast_channel_message, send_direct_message and send_text all work without the two parameters - it's the voluptuous validation that takes care of that and provides sensible defaults.

It is actually expected that reply_id will not be present, because the reply_id selector is marked as optional:

In addition, I've also tested the following:

• Sending messages via the notification platform - works fine.
• request_traceroute and request_telemetry - both work fine.
• The send_message device action - works fine.