What is the use case of `dataType` of the class `LabelDef`?

[abutscher]

Hi,

What is the actual meaning and use case of the dataType member in the class LabelDef (https://github.com/raomin/ESPAltherma/blob/ebc7757dab8fa4b319b8bda0fd45d13b39724c3e/include/labeldef.h#L13)? I can only see it used in the constructor to initialize its pointer counterpart. But then, it looks as if it's not actually used in the application source code. In the defining header files (the model specific ones), it seems to adopt either 1 or -1 as value. So, is dataType really used in the source code or am I just overlooking something? The reason why I am asking is following. I want to write an application (in Python) that listens to the MQTT messages and forwards them to a InfluxDB (which is eventually visualized by Grafana). For that, I need a simple typing mechanism for the LabelDefs of the registry. In fact, for a first draft, it's enough to know for each registry entry if it's a string or a float. As I am anyway parsing the model specific header file, I was hoping to find that information there... Or is the type information even encoded in the conversion ID?

BR

[Tardymo]

Yes, it looks like dataType is unused. And regarding InfluxDB, there is no need to write an application as Telegraf can parse JSON and write it to InfluxDB. That is exactly what I am doing right now. Just add this to telegraf.conf in INPUT PLUGINS section:

[[inputs.mqtt_consumer]]
  servers = ["tcp://mosquitto:1883"]
  topics = [
    "espaltherma/ATTR",
  ]
  data_format = "json"

My mqtt broker is running in a container next to telegraf, hence I can specify container name instead of IP address of the broker. Additional things like username/password, certificates e.t.c. can also be specified. By default string fields are filtered out by mqtt_consumer, and if you want some of them stored in InfluxDB, add them to configuration like this:

  json_string_fields = [
    "Thermostat ON/OFF",
  ]

You can further customize the consumer to for example filter out some of the JSON fields, rename them e.t.c. There is also json_v2 consumer which is even more powerful, but I don't have a configuration for it.

Oh, and in OUTPUT PLUGINS you have to configure connection to InfluxDB. I have this:

[[outputs.influxdb_v2]]
  urls = ["http://influxdb2:8086"]
  token = "your token"
  organization = "your org"
  bucket = "your bucket"

There are many more options for input and output plugins and for agent itself, but this should be enough to get you started. You will probably want to change flush interval to match sampling rate of ESPAltherma. I have it at 10s like this: flush_interval = "10s"

[raomin]

Yes you're right. This parameter is not used. I'll remove it in a next commit.

[abutscher]

Thanks for your answers. Really appreciate it. @Tardymo even better if there is already an existing solution :+1: . Wasn't aware of that. @raomin Just for my understanding of the source code. Is it then true to say that the actual type of each registry entry is then "encoded" in its converted ID?

[raomin]

Each value is encoded somewhere in the registry bytes. See it has a packed struct in C. The converter identified by the convID, is then taking the bytes and extract it to the right value. This can be a boolean, temperature, pressure etc... So yes you can have a look at the different converter to know if the value is string of int or float. But that's easier to do it by hand for the exact values you want

[Tardymo]

@raomin All header files will have to be re-generated, since Daikin has released new version of Dhecker, which finally solves the problem of choosing the right file, since file names list compatible heat pump models. I can try to do this since I successfully generated one for my Altherma model. Can I also remove unused dataType field from the structure and maybe even PROGMEM, which conflicts with ESP8266? I can create a pull request then. By the way, there is one small pull request from me which you have not yet merged.

[Tardymo]

Just checked and here is what dataType actually means:

1 - temperature value 2 - pressure value 3 - temperature difference value -1 - all other values

So probably dataType should remain in header files, as this value could allow to configure units for temperature and pressure in some future ESPAltherma update.

[raomin]

Hi @Tardymo. Sorry for the late reply. I've been busy with other projects recently... and I didn't even have time to have a look at the new definition files, but I love what you're saying! This sounds great. If you can make a PR with this, that would be fantastic.

I've merged your PR on negative values, sorry again for being late...