[Request] Support LORA to overcome WIFI range issues

[fakegit997]

Is your feature request related to a problem? Please describe.

My inverter is quite far away so I am not able to bridge the distance to my router with WIFI and NRF24L01+.

Describe the solution you'd like

If opendtu would support LORA, range issues could be easily resolved. LORA MCUs are cheap and powerful with integrated wifi. So all features of opendtu could be supported + upload to lorawan.

Describe alternatives you've considered

Expanding my Wifi to the roof is overkill to me.

Additional context

No response

[Kampfschildkroete]

I know that isn't an answer to your request but do you have an ethernet connection available in the roof? If yes you could use an ESP32 that supports an ethernet connection.

[tbnobody]

Lora requires an additional RF hardware, different protocol implementation, and a lot of data to be transfered (not sure how this copes with the duty cycle)

[fakegit997]

@Kampfschildkroete : I Agree and it would be an option in my case. Still, I think the request is valid @tbnobody :

Lora requires an additional RF hardware

On the DTU side it doesn't if you use boards with Lora already soldered on. I've just tested a TTGO ESP32 with OpenDTU and it works just fine. Of course there must be a Lora gateway somewhere around, but I think a lot of the users live in a covered area and could easily use TTN to get their data.

and a lot of data to be transfered

I agree partially. It heavily depends on the use case. Lora wouldn't be suitable for polling rates of e.g. 5s. But for hourly data transfer it shouldn't be an issue. Side effect: openDTU users are generally techies so they may boost Lora coverage by running their own gateways on TTN

[stefan123t]

I love LoRaWAN too, but would prefer a openDTU Relay mode more to be honest.

Also Hoymiles offers DTU repeaters and in order to implement support for the newer HMS-WiFi series we will need to implement the so called NetworkCommand set from the DTU Pro, S-Miles Installer App and the S-Miles Cloud API anyway. Here a repeater mode of the DTU can act as multiple things:

• DTU repeater simply forwarding commands from the main OpenDTU to the inverter and back again (Hoymiles Gen2/Gen3 protocol)
• DTU which can be discovered in S-Miles cloud and which can be used to trace additional features, eg Grid Profile or Firmware Download / Install (Hoymiles NetworkCommand)
• mock Inverter which we can use to test new protocol command implementations against (Hoymiles Gen2/Gen3 protocol)
• mock DTU which we can use to test the not yet implemented S-Miles Cloud API against (Hoymiles NetworkCommand)
• mock DTU-BI (built in) which is integrated into the new Hoymiles HMS-WiFi models (Hoymiles NetworkCommand)

Some of these could be tested with the S-Miles Installer app or the S-Miles Cloud.

[stefan123t]

@tbnobody maybe we should start to implement a serial protocol, which we can use both via UART/USB and / or via the Info > Console in order to send dedicated commands to the DTU and the inverter and that returns the HEX or parsed data from the inverter in verbatim ?

This could then be extended to provide a core for OpenDTU which can be called via REST API, MQTT, UART/USB Console as well as unattended as before by consecutively querying all the inverters as setup via the UI and queried by the livedata page.