Influxdb support about ahoy

[stefan123t]

Hi Florian,
this sounds great. Lukas is currently updating the protocol parts of the HM communication. But after that it would be good to send it straight into InfluxDB. I believe someone asked about JSON output too.

We have found out more about the paket structure in the past few days/weeks and that needs to go into the ESP code first to make communication reliable and the results e.g. for the HM-600/700/800 series meaningful. Here some of the data is broken over the last / first bytes of two pakets. So we need to reconstruct the payload first, then verify it according to the CRC16/CRC_M and then fetch the data matching the three models HM-300/350/400/500, HM-600/700/800 and HM-1000/1200/1500 and their single, double or quad channel MPPT DC input channels.

[Sprinterfreak]

For some reason the idea didn't let me go...
My initial goal was not to provide live data directly into influxdb but re-parse old logfiles of raw data into influx, using the latest protocol implementation. This could eventually make it possible. I prefer to have live data on my broker, so I can subscribe things directly to specific topics they need.

[Sprinterfreak]

I don't like the idea of supporting a bunch of different output connectors.
Influx's data collector is telegraf. It can gather data from mqtt just fine. (like I do)

For the python part of this project, I had allready in mind to transform the module in a way that anybody could wrap its output handler around by himself. Currently not on the list because we still discover fundamental basics in the protocol which we also don't know how to process in the future.

Influx line protocol is fairly easy. So for the python part would not be very difficult to implement.
Just another branch in poll_inverter() if influx is configured. But do we really need this twice if we already have it?

[stefan123t]

@DerRiFlo bitte mit der v.0.5.9 überprüfen bzw. spezifizieren was Du für einen API Endpoint brauchst um die Daten in InfluxDB zu bekommen. Danke
Wir können das Issue eventuell mit #142 angehen und den entsprechenden API Endpoint anpassen, falls die bestehende Funktion nicht ausreicht.