feature/lora: Enable LoraWAN supported hardware

[kallisti5]

• Allows OpenEVSE units (with a LoraWAN compatible modem) to announce their status up to several miles to TheThingsNetwork or Helium IoT gateways.
• Must be using a ESP32 with a built-in LoRA modem, or by manually attaching a LoRA modem to a stock ESP32

[kallisti5]

This is a rebase + redo of the original Lora PR i worked back in 2020 on. I need to do a lot of testing.

Interestingly enough, the LoRa gateway count has gone up exponentially due to people "mining" radiospace for Helium.

Network map: https://explorer.helium.com

Essentially, with Lora + LoraWAN, an OpenEVSE could announce its status via public LoraWAN networks to gateways "several miles away" without any wifi / network connectivity. The LoraWAN network would then broadcast those status updates to an MQTT server specified by the user in the network provider.

Should work with follow public Lora networks:

• TheThingsNetwork
• Helium

[jeremypoulter]

Great to see this revived, I will review and see if I can get the required hardware to test.

[kallisti5]

https://www.amazon.com/MakerFocus-Development-Bluetooth-0-96inch-Display/dp/B076MSLFC9 is the board targeted by openevse_esp32-heltec-wifi-lora-v2

I have this firmware running on it now. In theory any radio compatible with the MCCI Lora library attached to an ESP32 should work (meaning it could be an "add-on" option to the stock OpenEVSE ESP32 when wifi is unavailable)

The oled screen is nice, but not sure it's worth supporting that unless OpenEVSE wants to sell heltec ESP32 board with kits (i'm not sure of supply chain reliability either of these)

[jeremypoulter]

Do these apply to all builds? May be better to put them in the LORA specific env, or group all the LORA build env in to a new var that can be included in the envs:

build_flags_lora =
  -D ARDUINO_LMIC_PROJECT_CONFIG_H_SUPPRESS
  -D hal_init=LMICHAL_init ; Workaround mcci arduino-lmic bug 714 on esp32

then in the env:

build_flags =
  ${common.build_flags}
  ${common.src_build_flags}
  ${common.version}.dev
  ${common.build_flags_lora}
  -D DEBUG_PORT=Serial
  -D WIFI_LED=25

[kallisti5]

They're generic fixes for the LMIC code, but good point on moving them to lora specific builds. I can do the same for the other things like the country stuff too

[jeremypoulter]

The Heltec boards look to be out of stock, would something like this work: http://www.lilygo.cn/prod_view.aspx?TypeId=50060&Id=1270&FId=t3:50060:3

[kallisti5]

@jeremypoulter

I think that board will work. What's really key is using the sx1272 or sx1276 chipset (the sx1276 is the "gold standard" from what i've seen)

Looking at that board's repo, it uses an arduino-LoRa library which supports these... so I think it should work too.

[kallisti5]

I reworked it using the MicroTask thing. Hopefully I did it correctly 😆

[kallisti5]

For a little clarification on how this stuff works, here's generating a deveui/appeui/appkey fpr the Helium network:

And here's an existing (unrelated) LoraWAN device reporting data packets (which are going to an MQTT server.

Essentially:

Device (packs data small) -> LoraWAN -> LoraWAN Gateway -> LoraWAN service (helium in this example) -> Decoder function in LoraWAN service to "unpack" the data -> Whatever integration you want (MQTT, etc)

Also, before really finalizing this one, I may want to convert the "packing" of the OpenEVSE status. Cayenne LPP is a common encoding format Lora devices use:
https://developers.mydevices.com/cayenne/docs/lora/#lora-cayenne-low-power-payload

The packing I chose today is pretty simplistic mostly for testing and early development

[kallisti5]

Latest commit changes from the custom packed data to CayenneLPP packed data (which is more standard for LoRaWAN devices)

Only remaining thing to test is I need to manually inject the keys into the config store and test connectivity to the network.