Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

lora: Initial work at LoRaWAN support. Empty announcements. #70

Closed
wants to merge 1 commit into from

Conversation

kallisti5
Copy link
Contributor

@kallisti5 kallisti5 commented Apr 21, 2020

This has been greatly simplified using a common LoRa library, and removing the Heltec code.

  1. If enabled for the board, LoRa is setup using the network credentials hard coded within the code
    (these can be pulled via the OpenEVSE storage, but just not there yet)
  2. If a LoRaWAN gateway is in range (a few miles), the device will begin to announce the OpenEVSE status.
    (the status is empty at the moment, need to pull from OpenEVSE still. The status information needs packed into as small a datastructure as possible)
  3. The LoRaWAN network (in my case The Things Network) will receive the data, translate it, and pass it onto any configured integrations the user specifies. (aka, Plugshare??? :-) )

unsigned long lastAnnounce;
uint8_t dataPacket[9];

// LoRa module pin mapping
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might be able to get these from HAL.. but not sure HAL is aware of them if we don't pull in the Heltec libraries. Needs more investigation. For now we can just define these per board.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this have to be anything specific? There is a hardware ID that can be obtained from the (ESP) HAL (the WiFi MAC)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry, that comment was aimed at the LoRa module pin mapping. The Heltec ESP32 V1 vs V2 has different pin mappings per device. I've seen some references to the pin mappings being available from HAL, but there are no docs around using them.

https://github.com/mcci-catena/arduino-lmic/blob/master/src/hal/getpinmap_heltec_lora32.cpp

void os_getDevKey (u1_t* buf) { }


void onEvent(ev_t ev) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For now we just blast our status to the network every 30 seconds. We could add some confirmation code to "ensure the network accepted the update", but for now i'm keeping it simple.

#define ANNOUNCE_INTERVAL 30 * 1000 // (In Milliseconds)


// TODO: Store these via WebUI? We're doing (simple) ABP activation for now
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ABP activation is where "every device is configured" OpenEVSE could move to a "OTAA" activation where devices "automatically register and activate themselves under an application" but this is overkill unless OpenEVSE wants to become a 'managed' product (plug it in, and it works under the OpenEVSE account)

@kallisti5
Copy link
Contributor Author

kallisti5 commented Apr 21, 2020

Testing has been limited thus far, without a spare OpenEVSE module testing is tough since the ESP32 enters a "Unable to communicate to OpenEVSE" loop. The code was taken from another (working) project I have.

All code remains inactive however unless you build for the heltec LoRa board.

@kallisti5
Copy link
Contributor Author

Oh.. beyond The Things Network, this code could be used to connect to any other LoRaWAN network (915 Mhz in the US). one option is Helium. https://developer.helium.com/console/cli

Not sure of the options there, however there are a ton of Helium devices out there today. https://network.helium.com/coverage

Copy link
Collaborator

@jeremypoulter jeremypoulter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work on this, looks like an interesting project

unsigned long lastAnnounce;
uint8_t dataPacket[9];

// LoRa module pin mapping
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this have to be anything specific? There is a hardware ID that can be obtained from the (ESP) HAL (the WiFi MAC)


// TODO: Pack important OpenEVSE stats into dataPacket.

LMIC_setTxData2(1, dataPacket, sizeof(dataPacket), true);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When is the dataPacket filled in with the state?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this have to be anything specific? There is a hardware ID that can be obtained from the (ESP) HAL (the WiFi MAC)

The three values identify + authenticate the OpenEVSE unit on the LoRaWAN network. Pretty much the three values are generated at your LoRaWAN gateway provider and filled in. The values will be unique per OpenEVSE unit. (prime candidates for a webui setting)

Other things to adjust in the web ui in the future are the LoRa Spread factor. (7 = narrow bandwidth, but less prone to interference. 12 = wide bandwidth, but more prone to interference)

https://www.thethingsnetwork.org/article/how-spreading-factor-affects-lorawan-device-battery-life explains SF a bit.

When is the dataPacket filled in with the state?

That's what the todo is for :-) We need to decide what's "important enough" to broadcast over LoRaWAN to a gateway potentially a few miles away. Charger state, vehicle state of charge, etc. Likely some subset of what you can send to MQTT today. we should pack these as small as possible to improve reliability. (two bits for charger state, etc)

Pretty much, data payloads that are sent over LoRa need to be as small as possible. But essentially we're free to pack whatever OpenEVSE stats we want to.

Then, you add some "decoding logic" at the destination to unpack the lora data into whatever structure you want before passing it onto other integrations.

There is a review of the process here:
https://hackmd.io/@pmanzoni/Hy6qUmbA4

I'm using The Things Network here since it's free and has a low bar to entry. There are several however. Essentially a LoRaWAN gateway such as The Things Network is an online API to:

  1. Receive data from physical LoRaWAN gateway devices attached to the internet.
  2. Translate the data from LoRaWAN, and send to configured integrations.

Think of LoRaWAN gateways as "cell phone towers". Anyone can use the LoRaWAN gateway you provide, but each LoRaWAN gateway is configured for "a single gateway service" like The Things Network (free), helium.com (cryptocurrency based cost to use LoRaWAN), loriot.io (haven't looked at them yet)

src/lora.cpp Outdated

LMIC_setTxData2(1, dataPacket, sizeof(dataPacket), true);

lastAnnounce = millis();
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IHMO it is better to work out what time the next packet should be, ie:

Suggested change
lastAnnounce = millis();
nextAnnounce = millis() + ANNOUNCE_INTERVAL;

You only need to do the addition once rather than every check, but a minor point

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. Good point :-)

@kallisti5 kallisti5 force-pushed the lora-support branch 3 times, most recently from 7b1e0c7 to 1ea51f7 Compare April 25, 2020 13:23
@kallisti5
Copy link
Contributor Author

Ok. The latest patch has a bunch of fixes and actually pushes useful data over LoRaWAN :-)

The only change which is active when building non-lora enabled firmware is the addition of the "create_rapi_packed" function to input.cpp. This takes important values and packs them into a bunch of uint8's to be broadcast over LoRa. If a value could be reasonably > 255, I added a conversion factor (voltage, elapsed, temp)

Keep in mind this is all still untested. I need to short circut the OpenEVSE communication tests to try and fake the ESP32 to send some data over LoRaWAN.

@jeremypoulter jeremypoulter marked this pull request as draft February 28, 2021 19:16
@jeremypoulter jeremypoulter marked this pull request as draft February 28, 2021 19:16
@jeremypoulter
Copy link
Collaborator

Replaced by #537

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants