Hi @edmundo096 - since writing that post, I switched from ZHA → Zigbee2MQTT and learned a lot about HA. Zigbee2MQTT sensor aren’t in an area - so I think the request doesn’t really make sense anymore.
If I still cared about it, I’d probably bypass HA and figure out how to add an area tag myself. Or else pick a different data model?
Hey, thank you.
After some fiddling with InfluxDB, the HA integration config, and some headaches, I end up thinking in a better and more extensible approach, which boils down to something similar, if not the same principle, of what you end up with.
Using HA with the InfluxDB integration works ok for something quick or humble, but it’s not flexible or extensible at all (e.g. _measurements defaults logs units, which may become hard to digest after having multiple units for the same measurement, such as sizes and time units).
Altough having the Area as a Tag is something that should be baked it on the InfluxDB integration (as it’s an attribute/property/value set within HA), I believe a much better approach to get data is doing it by yourself on a separate hub/proxy/middle man/broker/gateway point were your custom configured/modeled sensor data passes through it first, then relayed to InfluxDB and/or HA, which I believe what MQTT ends up doing/can do, with all the flexibility needed.
HA would act mostly as a read-only consumer of sensor data, as well as control interface panel, instead of a forced relay of data to InfluxDB or any other DB or logger.
At the end, I could learn and get some results.
Sharing for whomever reaches here later in the future.
OK, so any new interesting results and thoughts?
I’m just preparing my data model for InfluxDB implementation. At that moment I added area by custom attribute in customize.yaml and then passing it thru tags_attributes.