LoRaWAN Extension for Hardware

[aErbi]

Hello,
I would like to start a discussion, about a possible LoRaWAN extension for the AMS Reader hardware.

Why?

• Some smart meters (here I can only speak for the rural area in Austria) are mounted close or directly at the property border, where Wifi signal is very weak or non-existing. Further the problem could appear as well in apartments (Smart meter in the basement and apartments on the 3rd floor). In my limited view LoRaWAN could bring a solution to those problems.
• Renewable energy communities are on the rise across Europe – Austria was one of the first movers in this field. Realtime smart meter data could enable there a more proactive self-consumption optimisation (e.g. with a central storage system) or provide services for grid stability. Furthermore, using the Customer Information Interface(s) (CII) of the smart meter would be financially and operationally easier than using separate meters (Fronius, Carlo Gavazzi, Chint, etc.).

My Questions?

• Would such a LoRaWAN extension be possible? Maybe directly in the slot for the FTDI-Module.
• Could the AMS Reader (POW-U, POW-P1) still be powered by the smart meter (e.g. M-Bus CII form Kaifa) without an external power supply?
• What priority would the community give such an extension?
• The gateway to the home network could be realised in the first step via a ESP controller, if possible (pleas correct me, if am wrong there).

I found some companies that already have such smart meter plugs with LoRaWAN capability in Austria(e.g. Smartmeterwatch (SET) or Smart Energy), although one is a start-up focussing on Renewable Energy Communities (with a price of around 200€ - quiete high in my view) and the other plug is, to my information, a closed system with no interfaces (MQTT, …).

Best regards,
Erbi

[ArnieO]

Hi @aErbi - thank you for your input and ideas, and for taking the initiative to such a discussion.

I am responsible for the hardware designs on our products: Pow-U, Pow-K and Pow-P1, that are built around Espressif micro controllers. We started with ESP8266, and have moved on to ESP32-S2.

I also have some experience with developing hardware for LoraWAN, primarily the Seeed Studio Wio-E5 module controlled via UART from an ATTiny micro controller.

Side note:
If you study the Wio-E5 you will see that it is in principle possible to directly program its built-in micro controller in stead of adding an external one. However, when I looked into that I realized it was a massive task to sort out how to do that, while preserving its pre-programmed content. So I got convinced that the easiest route was to add a (small and cheap) ATtiny; one of the new ones programmed over UPDI.

Back to the issue:
The functionality you want to obtain means the WiFi capability of the ESP micro controller module would be switched off during normal operations. Instead of sending data over WiFi, the ESP micro controller would control an external LoRa extension (for instance the Wio-E5) via UART. WiFi would only be used when the unit needs firmware update: Move it to a position with Wi-Fi coverage, do the update, then place it back in the meter using Lo-Ra.

This is technically feasible, and I am quite sure such a unit would be able to run from the power available from the power meter, as LoRa transmission are (per design) low energy transmissions with low overhead (while Wi-Fi per design is quite the opposite).

So I see no major technical obstacle.

The real obstacle is commercial, as I am not convinced the market is sufficiently large to cover the cost to (and the list is probably not exhaustive):

• Adapt the current hardware (3 designs!) to expose an ESP32 micro controller UART to a suitable connector where a LoRa extension board can be connected.
• Design the LoRa extension board
• EMC-testing of the LoRa extension board - which is necessary to legally be able to issue an EU Declaration of conformity (you find it here for our current products).
• Develop the firmware to control the LoRa extension board from the ESP micro controller.
• Decide on and implement the right strategy vs the LoRa "acceptable use" ratio. Some power meters do a measurement every second; you cannot push all that data over LoRa.
• Test the implementation
• Write documentation

Even if LoRa is a fantastic technology, LoRa is still a "niche" transmission system that is not widely used by end users (compared to our current cutomer base). So I have great difficulties seeing how such a development could be financed by selling LoRa extension boards.

Taking all this into account, I do not find 200 EUR for a LoRa based power meter reader to be high.
An you in a way "prove my point" by saying that such a price point is unacceptable for a consumer end user.

My current conclusion is therefore:

• A LoRa solution based on our current hardware and firmware is technically feasible.
• However, we will not self finance the development of such a development, as we consider the market to be too small.
• The only viable way for us would be if a commercial actor willing to finance such a development, for instance for a whitelabel product. But if that happened, nobody should expect that to result in a solution that is significantly lower cost than your indicated 200 EUR.

[aErbi]

Hi @ArnieO,
Thank you for the fast and detailed reply.

Unfortunately, my knowledge of hardware design and communication technologies is limited to the basics, but as I understood it:

• The three hardware designs would need to be adapted, but could still be sold independently from the extension (for a bit higher price, or the adaption would need to be covered entirely by the extension)
• The extension, if realised, could be bought afterward or with the product and then plugged into the existing Hardware (with or without a new chasing).

Please correct me if I mentioned/understood something wrong.

The hurdle of the economic implementation of the LoRaWAN extension could also be overcome by a research project, in my view. Or at least the costs for the first steps could be covered:

1. You get the financial resources for a prototype through research project (as project member or third-party provider). There, in my understanding, EMC-test are not needed, as it would be in the proof-of-concept phase.
2. Then the hardware with the plug would be tested and validated in the field by the project team and validated for different Use-Cases.
3. After those steps the whole concept of the extension and the market situation could be reevaluated. With the benefit for you that the first steps would be co-financed or completely financed.
   a. If negatively evaluated the concept would be shelved.
   b. If positively evaluated the extension could be brought to the market for the right price.
   Side note: I know from a study colleague, who works for a bigger electricity supplier, that they are looking for real-time solutions (10-second or minute interval) for smart meter data (especially the power value) to optimize their balancing energy cost risks.

Maybe the next steps could be, that you (roughly) estimate the necessary financing budget for the proof-of-concept phase and communicate it, via this discussion or on personal request. Then the community (or the part of it that is interested in such an extension) could look for possible projects or project participations.

Would the mentioned cost range of around 200 Euro include the Pow-hardware? So e.g.: Pow-Hardware: ~70-80 Euro; LoRaWAN extension: 120-130 Euro

[GEAG]

There are already other products available on the European market that read the SM data and forward it over LoRaWan. But you have to consider the European restriction in this frequency band used by LoRa and LoRawan: Max. Duty-cycle 1%. I believe that this means that you are not allowed to send data from the IoT device over LoRa for longer than 36 seconds per hour, if you don't want to risk that your IoT device is being collected by the state authorities and you receive a fine for not having respected the regulation. Given that a single SF12 LoRaWan packet takes more than 1 second airtime (SF12 for longest reach ), your best bet would probably be 1 message every 5 minutes, if you run your own LoRaWan network or just use LoRa. Most LoRaWan networks operated by others (like TTN or telecom operators) will let you use even less airtime. Some policies only let you use a single message per day. LoRa just isn't appropriate for real-time data in the seconds range. LoRa is a great tech to read sensor values in the hours or days range.

A much more appropriate wireless tech would be Wifi HaLow (IEEE 802.11ah) which is just about to arrive on the horizon. Tests have confirmed, that HaLow may achieve data throughput of > 5 Mbps (1 kB in < 2ms) while respecting European regulations (OFDM with up to 256 QAM modulation is in the IEEE standard since 2017). It achieves a range of up to 1 km in free space LoS and about 40 m within concrete building through multiple walls and floors. And because of this advanced technology, the duty-cycle restriction is relaxed to 2.8% (100 seconds/hour) for devices and 10% for AP airtime. If you want to know more about this technology, you may consider watching the youtube video by Andreas Spiess on Wifi HaLow. A somehow clumsy, experimental HW based on an ESP32 an a CN SOC from taixin-semi is available from Lilygo since July 2024.

[ArnieO]

Thank you for your thoughts on the subject.

I mentioned LoRa "acceptable use ratio" in my previous post, and fully agree. Updates will need to be reduced significantly.

New Wi-Fi technologies with increased reach is certainly something we will monitor, and WiFi HaLow could potentially become interesting.

[Noschvie]

@aErbi maybe you can add a device supported by Tasmota: LoRa-and-LoRaWan-Bridge