-
Notifications
You must be signed in to change notification settings - Fork 117
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,153 @@ | ||
/* | ||
* Copyright (c) 2019-2020 Alexander von Gluck IV for OpenEVSE | ||
* | ||
* ------------------------------------------------------------------- | ||
* | ||
* Additional Adaptation of OpenEVSE ESP Wifi | ||
* by Trystan Lea, Glyn Hudson, OpenEnergyMonitor | ||
* All adaptation GNU General Public License as below. | ||
* | ||
* ------------------------------------------------------------------- | ||
* | ||
* This file is part of Open EVSE. | ||
* Open EVSE is free software; you can redistribute it and/or modify | ||
* it under the terms of the GNU General Public License as published by | ||
* the Free Software Foundation; either version 3, or (at your option) | ||
* any later version. | ||
* Open EVSE is distributed in the hope that it will be useful, | ||
* but WITHOUT ANY WARRANTY; without even the implied warranty of | ||
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the | ||
* GNU General Public License for more details. | ||
* You should have received a copy of the GNU General Public License | ||
* along with Open EVSE; see the file COPYING. If not, write to the | ||
* Free Software Foundation, Inc., 59 Temple Place - Suite 330, | ||
* Boston, MA 02111-1307, USA. | ||
*/ | ||
#ifdef ENABLE_LORA | ||
|
||
#include <lmic.h> | ||
#include <hal/hal.h> | ||
#include <SPI.h> | ||
|
||
#include "emonesp.h" | ||
#include "lora.h" | ||
|
||
#include "app_config.h" | ||
|
||
|
||
#define LORA_HTOI(c) ((c<='9')?(c-'0'):((c<='F')?(c-'A'+10):((c<='f')?(c-'a'+10):(0)))) | ||
#define LORA_TWO_HTOI(h, l) ((LORA_HTOI(h) << 4) + LORA_HTOI(l)) | ||
#define LORA_HEX_TO_BYTE(a, h, n) { for (int i = 0; i < n; i++) (a)[i] = LORA_TWO_HTOI(h[2*i], h[2*i + 1]); } | ||
#define LORA_DEVADDR(a) (uint32_t) ((uint32_t) (a)[3] | (uint32_t) (a)[2] << 8 | (uint32_t) (a)[1] << 16 | (uint32_t) (a)[0] << 24) | ||
|
||
#define ANNOUNCE_INTERVAL 30 * 1000 // (In Milliseconds) | ||
|
||
|
||
// TODO: Store these via WebUI? We're doing (simple) ABP activation for now | ||
const char *devAddr = "00000000"; | ||
const char *nwkSKey = "00000000000000000000000000000000"; | ||
const char *appSKey = "00000000000000000000000000000000"; | ||
|
||
|
||
// LoRaWAN credentials to use | ||
static uint8_t DEVADDR[4]; | ||
static uint8_t NWKSKEY[16]; | ||
static uint8_t APPSKEY[16]; | ||
|
||
// Next LoRaWAN announcement | ||
unsigned long nextAnnounce; | ||
|
||
// LoRa module pin mapping | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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) There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
const lmic_pinmap lmic_pins = { | ||
.nss = LORA_NSS, | ||
.rxtx = LMIC_UNUSED_PIN, | ||
.rst = LORA_RST, | ||
.dio = {LORA_DIO0, LORA_DIO1, LORA_DIO2}, | ||
}; | ||
|
||
// Used for OTAA, not used (yet) | ||
void os_getArtEui (u1_t* buf) { } | ||
void os_getDevEui (u1_t* buf) { } | ||
void os_getDevKey (u1_t* buf) { } | ||
|
||
|
||
void onEvent(ev_t ev) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. |
||
switch (ev) { | ||
case EV_TXCOMPLETE: | ||
DBUGF("LoRa: TX Complete."); | ||
// LoRaWAN transmission complete | ||
if (LMIC.txrxFlags & TXRX_ACK) { | ||
// Received ack | ||
DBUGF("LoRa: TX ack."); | ||
} | ||
break; | ||
case EV_TXSTART: | ||
DBUGF("LoRa: TX Begin."); | ||
break; | ||
default: | ||
// Ignore anything else for now | ||
break; | ||
} | ||
} | ||
|
||
/// Reset LoRa modem. Reload LoRaWAN keys | ||
void lora_reset() | ||
{ | ||
LORA_HEX_TO_BYTE(DEVADDR, devAddr, 4); | ||
LORA_HEX_TO_BYTE(NWKSKEY, nwkSKey, 16); | ||
LORA_HEX_TO_BYTE(APPSKEY, appSKey, 16); | ||
|
||
LMIC_reset(); | ||
LMIC_setSession (0x13, LORA_DEVADDR(DEVADDR), NWKSKEY, APPSKEY); | ||
LMIC_setAdrMode(0); | ||
LMIC_setClockError(MAX_CLOCK_ERROR * 10 / 100); | ||
LMIC_selectSubBand(1); | ||
LMIC_setLinkCheckMode(0); | ||
LMIC.dn2Dr = DR_SF7; | ||
} | ||
|
||
|
||
/// Initial setup of LoRa modem. | ||
void lora_setup() | ||
{ | ||
Profile_Start(lora_setup); | ||
|
||
os_init(); | ||
lora_reset(); | ||
|
||
// Set us up for an immeadiate announcement | ||
nextAnnounce = millis(); | ||
|
||
Profile_End(lora_setup, 1); | ||
} | ||
|
||
|
||
void lora_publish(uint8_t *dataPacket) | ||
{ | ||
if (millis() < nextAnnounce) | ||
return; | ||
|
||
Profile_Start(lora_loop); | ||
DBUGF("LoRa: Starting LoRaWAN broadcast..."); | ||
// Check if there is not a current TX/RX job running | ||
if (LMIC.opmode & OP_TXRXPEND) { | ||
DBUGF("LoRa: Modem busy. Retry later"); | ||
return; | ||
} | ||
|
||
LMIC_setTxData2(1, dataPacket, sizeof(dataPacket), true); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. When is the dataPacket filled in with the state? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
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.
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: 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:
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) |
||
nextAnnounce = millis() + ANNOUNCE_INTERVAL; | ||
|
||
Profile_End(lora_loop, 1); | ||
} | ||
|
||
#else /* !ENABLE_LORA */ | ||
|
||
#include "emonesp.h" | ||
#include "app_config.h" | ||
|
||
void lora_setup() { /*NOP*/ } | ||
void lora_reset() { /*NOP*/ } | ||
void lora_publish(uint8_t *dataPacket) { /*NOP*/ } | ||
|
||
#endif |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
#ifndef _LORA_H | ||
#define _LORA_H | ||
|
||
|
||
void lora_setup(); | ||
void lora_reset(); | ||
void lora_publish(uint8_t *dataPacket); | ||
|
||
|
||
#endif // _LORA_H |
There was a problem hiding this comment.
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)