Support for HMS-800W-2T

[henkwiedig]

I own a HMS-800W-2T which lacks a NRF or CMT support. Instead it does come with integrated WLAN.
If i'm not mistaken OpenDTU lacks the support for this, please correct me if i'm wrong.
From my point of view the DTU is directly integrated in the device.

So i dug deeper:
I used the "S-Miles Installer" App and reversed engineered parts of the protocol.
Basically this is a simple chat protocol useing "protobuf" for data transport.
I can access the inverter via the network directly and read and write to it.
The interface can be accessed via the inverter wlan or via the configured home wlan.
I'm unsure but this should work for all Hoymiles Factory DTUs as this uses the "S-Miles Installer" App interface. Input neeed here !
I have some POCs ready here: https://github.com/henkwiedig/Hoymiles-DTU-Proto

My Question is: Is that something worth to work on to integrate into OpenDTU ?
With that OpenDTU would benefit on the following ways:

• Support for Hoymiles WLAN only inverters
• Support for Factory Hoymiles DTUs as inverter sources, e.g. use the FactoryDTU as intended and add an OpenDTU for enhanced features. This would reduce the need for NRF or CMT modules if one has a FactoryDTU. This would basically mean OpenDTU supports 3 types of communication protocols NRF, CMT, WLAN (DTU)

[stefan123t]

HMS-WiFi Models use the S-Miles Cloud protocol to communicate over the built-in DTUBI WiFi interface. The commands are so called NetworkCommands wrapping NRF/CMT like Gen2/Gen3 codes which we already support. Support for NetworkCommands and DTU-BI will be analyzed as part of lumapu/ahoy#1189

[stefan123t]

Thanks for mentioning protobuf as we have already seen these files with usart_nrf[3].c/h code of the Gen2/Gen3 NRF protocol it is also available for the NetworkCommands.
Maybe we can reuse the *.protobuf files to generate C++ code for OpenDTU/AhoyDTU too ?
https://protobuf.dev/

[stefan123t]

@device111 did just that and forked @henkwiedig's https://github.com/device111/Hoymiles-DTU-Proto/tree/main/ESP32

I just read a rather in-depth discussion homieiot/convention#228 (comment) about the efficiency and pros/cons of JSON vs. protobuf over an MQTT Bus by the Homie convention team.
In the end they opted for JSON/MQTT instead of protobuf/MQTT for human readability purposes in their upcoming Homie 5 convention: https://github.com/homieiot/convention/blob/homie5/convention.md

I especially liked the idea to transparently support both JSON and protobuf over the same MQTT Bus topics: homieiot/convention#228 (comment) which allows resource constrained systems like ESPs to perform better using the efficient protobuf.

@tbnobody still no interest to support protobuf Network Commands for either S-Miles Cloud integration or additional HMS-xxxW models ?

[gitisgreat2023]

Just a reference for everybody looking for another (temporary) solution, apart from the already mentioned ESP32 solution: here is a rust based solution. It's currently still only reading out, power limiting setting doesn't working yet. I run it on my iobroker server without an issue.