[LORA] Improvements

[1technophile]

Description:

• Added capability to change LORA receiving frequency, merged environments that were previously per frequency
• Added WebUI
• Added TTGO v1 display support
• Added TTGO V21 support
• Added a LORA node example leveraging the ESP32 internal temperature sensor and the MAC id as the node ID
• Lora node ID as a subtopic per default (per device MQTT topic)
• Configuration through the WebUI
• Auto-discovery, when the node sends an id and one of the following keys tempc, hum, or moi, it will be auto-discovered into Home Assistant as a device. Note that a model can also be sent optionally.

Checklist:

• The pull request is done against the latest development branch
• Only one feature/fix was added per PR and the code change compiles without warnings
• I accept the DCO.

[tommyjlong]

I just sorta of glanced through the changes, and have a couple of questions:

• Looks like support for the Lily TTGO LORA32 v1's display was added. From what I can tell it displays only packets sent over LoRA. Is their a display of LoRa packets received?
• WebUI: Sync Word.... Can a hex value be input? i.e. x12 instead of 18?

[1technophile]

Looks like support for the Lily TTGO LORA32 v1's display was added. From what I can tell it displays only packets sent over LoRA. Is their a display of LoRa packets received?

It should display packet received, I have tested it with the reception of packets until now, LORAtoMQTT

WebUI: Sync Word.... Can a hex value be input? i.e. x12 instead of 18?

Yes I could do that, I'm curious about the use cases around changing the sync word ?

[tommyjlong]

I'm curious about the use cases around changing the sync word ?

Here is a copy of a write-up I did on the Sync word:
A LoRa packet starts with a preamble and the preamble ends with this "Sync" word. If a LoRa receiver doesn't find this Sync word, then it is suppose to ignore the rest of the packet. The Sync word is also to be used to distinguish between public and private LoRa networks, namely the value of 0x34 (for SX127x devices) is recommended for public LoRa networks and 0x12 for private. Other values can be used, but there appear to be rules that limit how many other values are available. In my experimentation, it didn't seem to matter what the Sync word was set to as the Gateway always accepted it. Nevertheless, I used the 0x12 value.

I think in general it should only be x12, but I have seen others change it (example, "Priceless Toolkit" changed it for his LoRa mail-box sensor).

[PricelessToolkit]

Wow, thank you very much!! I will test it this week. What structure should the sent data "LoRa" have, Json?

[1technophile]

Here is an example of json that should be sent by the node:

{
  "model": "ESP32TEMP",
  "id": "ESP32_MAC_ADDRESS",
  "tempc": "TEMPERATURE_IN_CELSIUS"
}

You can also refer to the example with this PR

I added hum and moi also.
Other keys can be used from here:

OpenMQTTGateway/main/config_mqttDiscovery.h

Line 139 in bfca747

#define jsonBatt "{{ value_json.batt | is_defined }}"

but I will need to add them.

[1technophile]

@PricelessToolkit @tommyjlong any feedback before I merge this ?

[PricelessToolkit]

Hi, unfortunately, I have not tested it yet, I don't have time "disaster in my lab" I'll do a test as soon as I have time.

[nikito7]

I will test it later 👍

[nikito7]

Yes I could do that, I'm curious about the use cases around changing the sync word ?

Last time I tried sync word is ignored.

Maybe we can use it in future for detect encryption.

[tommyjlong]

Hi, unfortunately, no time to test this out either (and so no further comments).

[1technophile]

@nikito7 I introduced the support as a byte September 15th, not sure if you did your test before or after

[nikito7]

@nikito7 I introduced the support as a byte September 15th, not sure if you did your test before or after

Before.

Can we ignore this?

N: Send on /LORAtoMQTT msg {"hex":"34D1456F629BF06F6380B405DF3248075DD58D259D8478FEAB14E20D09A26913C5A59FBCCEE56A43DF70C1F355AD74169008E6D8593DBDC76218E0434596119B84E01CA8C12E2E01DC6BC5E93F622078","rssi":-114,"snr":-10.25,"pferror":5947,"packetSize":80}

[1technophile]

Can we ignore this?

Yes I can add a boolean to do so

[nikito7]

It work.

Sender code is mine.

Send on /LORAtoMQTT/Node7 msg {"id":"Node7","tempc":99,"hum":50,"pres":999,"up":60,"rssi":-47,"snr":9.75,"pferror":612,"packetSize":53,"model":"LORA_NODE"}
N: Send on /LORAtoMQTT/Node7 msg {"id":"Node7","tempc":99,"hum":50,"pres":999,"up":70,"rssi":-53,"snr":9.25,"pferror":612,"packetSize":53,"model":"LORA_NODE"}
N: Send on /LORAtoMQTT/Node7 msg {"id":"Node7","tempc":99,"hum":50,"pres":999,"up":80,"rssi":-47,"snr":10,"pferror":629,"packetSize":53,"model":"LORA_NODE"}
N: Send on /CLIMAtoMQTT/bme msg {"tempc":25.18,"tempf":77.324,"hum":0,"pa":101321.3,"altim":0.306171,"altift":1.004496}
N: Send on /LORAtoMQTT/Node7 msg {"id":"Node7","tempc":99,"hum":50,"pres":999,"up":91,"rssi":-47,"snr":10.25,"pferror":612,"packetSize":53,"model":"LORA_NODE"}
N: Send on /LORAtoMQTT/Node7 msg {"id":"Node7","tempc":99,"hum":50,"pres":999,"up":101,"rssi":-47,"snr":10,"pferror":612,"packetSize":54,"model":"LORA_NODE"}
N: 

[1technophile]

Thanks, I will add the capability to ignore raw message and merge it

[1technophile]

New screenshots and photos: