I'm making a thing! OpenEVSE LoRa support

End Devices (Nodes) Hardware
1

I’m getting an OpenEVSE (open-source electric vehicle charger, new ones are based on an ESP32)

I have one of the Heltec ESP32’s with the built-in LoRa modem, and was able to get OpenEVSE running on it.

As an initial feature, it would be neat to “announce” the status of the charger, and other information over LoRa. Are there any standards I should follow for these devices to be polite?

For the moment i’m just spamming LoRa with a Hello world from the hostname of the device :slight_smile:

Work so far here: https://github.com/OpenEVSE/ESP32_WiFi_V3.x/pull/47

2

Note that the plain LoRa you’ve added so far is not LoRaWAN (and hence is not related to The Things Network, nor to this forum).

I guess you’ll need some security, which LoRaWAN could add out of the box.

But LoRa(WAN) devices cannot transmit a lot of data (“uplinks” are very limited in both size and frequency/quantity), and sending data to the device (“downlink”) is even more limited. So there’s no way LoRa or LoRaWAN can replace the WiFi to support the built-in web server like the image below that I grabbed from their GitHub repo, if that’s what you’re expecting:

OpenEVSE app
OpenEVSE app1008×696 162 KB

But of course, one could host such web application on another server, and only transfer the data between the device and that server. That GitHub repo says:

OpenEVSE can post its status values (e.g. amp, wh, temp1, temp2, temp3, pilot, status) to an MQTT server. Data will be published as a sub-topic of base topic. E.g <base-topic>/amp. Data is published to MQTT every 30s.

You won’t be able to transmit the same data every 30 seconds with LoRaWAN. Even if the data is only 10 bytes, then in best conditions such would take 62 milliseconds per message, so on the TTN public network, in best conditions and if you need data 24/7, you can only send one 10-byte message every 3 minutes. So, assuming you won’t always have best conditions or you need more than 10 bytes, you can probably only transmit every 15 minutes or less. With no guarantee that the data will be received.

The GitHub repo also says:

RAPI commands can be used to control and check the status of all OpenEVSE functions. RAPI commands can be issued via the direct serial, web-interface, HTTP and MQTT. We recommend using RAPI over MQTT.

If controlling the device (which would use LoRaWAN downlinks) is very important, then note that such downlinks might simply not be received by the device. Also, the TTN public network currently only supports Class A devices, which means that downlinks can only be transmitted right after receiving an uplink. So, the latency for LoRaWAN is much, much higher than that of an MQTT connection. Also, downlinks are limited to 10 per day on the TTN public network.

You’ll need to define what you need and only then choose a technology that can support that.

2 Likes
3

Already understand this :slight_smile: My goal is mostly to accomplish some of the following tasks:

  • Report individual unit charge rates at a given time (40A, 7kw, etc)
  • Report individual unit statuses (Ready, charging, error, etc)
  • Report report any other low-bandwidth stats

I feel like these could be great metrics to send over LoraWAN since in a lot of cases, power can be available for these vehicle chargers, but wifi is unavailable. a 15,30,60 second announcement interval would be more than enough.

Another factor idea is to have the units “communicate with each other”, an example here is having units coordinate and decide on power delivery to each vehicle. As an example, someone may have a 60A circuit available, the charger units could “split” the 60A evenly between all vehicles. (3 cars, 30A each, etc)

I think the latter case is something more inline with LoRa without the LoRaWAN.

One stumbling block I keep having is actually finding a LoRaWAN gateway which I know will be compatible with The Things Network (or other networks). I know there is a requirement for “more than one LoRa radio” in a device, but the documentation and examples around this seem to be a bit of a mystery that isn’t well documented. I see a lot of reasonably cheap advertised LoRaWAN gateway devices which have “one radio” and no details on what networks are supported.

I also think running 2 or more LoRA radios over SPI attached to a Raspberry Pi is an option? The lora gateway software seems complex and underdocumented however.

4

Try here;

https://www.thethingsnetwork.org/docs/gateways/

5

That article mentions one for DIY which is the wrong frequency for the US.

Then I see this:
https://www.thethingsnetwork.org/docs/gateways/start/list.html

However:

So, my options:

Not trying to be a bummer, but the options available in the us kind of suck at the moment. Am I missing something?

6

Might be a good idea, but that sort of packet interval could easily exceed the fair access limit for free access to TTN.

You really need to plan for worst case, when the nodes might not have good (as in close ) connections to a gateway. Assuming this is the case and a very small 16byte packet then at the various intervals you would exceed the fair access limit in approximately;

15 second interval - 8 minutes.
30 second interval - 16 minutes
60 second interval - 32 minutes.

1 Like
7

That sounds like it would need strict orchestration, implying that one might need guarantees of message delivery? If so, then even with confirmed LoRaWAN downlinks, I wonder if LoRa(WAN) should be the technology of choice.

Indeed. Also, I feel that this limit is quite a sane limit, that should also apply to private installations, unless one is willing to deploy a lot of gateways, each covering a small area.

8

A lot of gateways only help if the transmit power is minimized, otherwise the use of the frequency would still block other nodes and other LoRaWAN users.

9

It being called a LoRa gateway should make you cautious. It is not LoRaWAN compatible and as such should not be used on TTN.

There are plenty of options for use in USA as well, search for RAK and Dragino LG308. You might need to fit the gateway in outdoor housing yourself for some to keep cost down. Outdoor gateways are a couple of hundred dollars more expensive, doing some work means an indoor gateway can be used outdoor for < $100 on top of the gateway hardware.