jbouwh / omnikdatalogger

Datalogger for Omnik solar power inverters with DSMR integration and output to Home Assistant, PVOUTPUT, InfluxDB and MQTT
https://jbsoft.nl/site/omnik-datalogger/
GNU General Public License v3.0
10 stars 3 forks source link

DSMR via 3rd party device #62

Closed ihulsbus closed 2 years ago

ihulsbus commented 2 years ago

Hi Jan,

I currently have a HomeWizard Wi-Fi P1 meter connected to the central meter to export some power data. Now, this device sends it both to an remote system and exposes the data via a local, unprotected endpoint. I would like to see if it would be possible to integrate this data with the data from our solar panel inverters. Would it be possible to support such endpoints?

I realize of course that it is impossible to support such devices all from the datalogger but maybe if users supply their own field mapping for the endpoint, assuming the data is exposed in JSON, it could work?

I'm currently looking at the following exported data:

{
    "smr_version": 42,
    "meter_model": "Kaifa KAIFA-METER",
    "wifi_ssid": "<REDACTED>",
    "wifi_strength": 54,
    "total_power_import_t1_kwh": 19076.256,
    "total_power_import_t2_kwh": 16463.774,
    "total_power_export_t1_kwh": 3110.004,
    "total_power_export_t2_kwh": 7837.318,
    "active_power_w": 826,
    "active_power_l1_w": 219,
    "active_power_l2_w": 4,
    "active_power_l3_w": 603,
    "total_gas_m3": null,
    "gas_timestamp": null
}

Unfortunately I do not have this information for the gas part as it's not a "smart" gasmeter.

If this cannot be supported, could I do the same data combining afterwards via my InfluxDB collections? Or does the logger do some magic internally to match the two sources together?

Thanks, Ian

jbouwh commented 2 years ago

The logger combines DSMR data with the closets timestamp to the solar data. But if the solar data is polled directly from the inverter, this is not an issue. The current datalogger reads the P1 port. My meter pushes data every second, and updates occur every 10s. It should be possible though to poll a JSON based API instead. Perhaps some data speciation exists that could be used.

ihulsbus commented 2 years ago

Thanks. Looking at the output of the device, it seems to be a proprietary format, and not something publicly available, making integration difficult.

I think I'll try to do the math in InfluxDB afterwards.

I got two additional problems I'm running into, one is the logger not able to authorize against influxDB with a token or basicAuth. The second one has to do with the scraping of an inverter. one can be scraped over 8899 (Inverter connected over WiFi) the other not (connected over Ethernet). Both are the same age inverter with a serial number that should be high enough (16XXXXXXXX and 19XXXXXXXX)

I'll create a separate issue for the first one, but I'm not sure about the inverter issue?

jbouwh commented 2 years ago

If connecting over 8899 is possible for all inverters than that is ok. for Influx you need to enable v1 auth if you are using Influx v2

ihulsbus commented 2 years ago

It is for one, but strangely enough not for the other. The main difference is connection medium and the serial number is of a higher number. Firmware on both is exactly the same. I'm still not sure what's going on there.

Saw the Influx v2 PR. I'll try it as soon as I have the chance. Thanks!

jbouwh commented 2 years ago

It is for one, but strangely enough not for the other. The main difference is connection medium and the serial number is of a higher number. Firmware on both is exactly the same. I'm still not sure what's going on there.

Saw the Influx v2 PR. I'll try it as soon as I have the chance. Thanks!

To reverse engineer the data it is, to begin with a good thing to have data samples. If you set the loglevel to debugging tcpclient will also log a base64 datadump if the data block is >= 99 bytes.