I am trying to wrap my head around all this newness. I see some examples like the airTemps example and I think my biggest confusion is on Tags. Are they required? For instance we have weather stations on site. They record:
humidtiy,
temperature
dewpoint
But then we have another sensor that records:
humidtiy,
temperature
dewpoint
pressure
Then yet another sensor that records:
a telescopes structure temp
a telescopes mirror temp
a telescopes air temp
etc.
So while they are all airTemp sensors, they all record differing data. So how does that look as a schema? Is that same measurements with lots of fields and different tags? or more measurements with no tags and less fields? I was never a grand sql database guru, and this is another layer of abstraction to wrap my head around.
I would love to have a tag with a sensor id
so we have a measurement:
airTemps
tag:
sensor id (outside_air, inside_air, telescope_air)
Where this breaks down and I guess the question is if I create that Data Point:
airTemps, sensorID, humidity, temperature, dewpoint …
how do i handle the sensors that record more or different information? does that mean its a different measurement?
like measurement:
telescopeTemps
having fields like, structure, primary , air temp etc.
airTemp having just humidity temp and dewpoint while another airTemp_inside sensor has pressure humidity temp dewpoint.
After writing this out it feels like I opt for no tags (then I dont see the point of tags) and just have more measurements with only the fields it measures?
Hello @codejoy,
If you use InfluxDB v3 you don’t have to worry about tags or fields they all become columns in a measurement or table.
If you don’t have a tag and you’re recording temp from two sensors and they happen to record a value at the same time then you’ll overwrite your data. Which is why you’ll want to use a tag for each sensor or make unique field names for your temp values like temp_sensor_1.
As a schema you’ll have the same number of measurements (unless you change that) just within your measuremetns you’ll have a different ratio of fields to tags.
I love
I would love to have a tag with a sensor id
so we have a measurement:
airTemps
tag:
sensor id (outside_air, inside_air, telescope_air)
Ty for this, I was curious if it matters then if each sensor has different fields to it. i.e. in the above case:
airTemps is the measurement
tag is sensor id (thusly one has outside_air)
that one has, humidity, temperature, dew point.
Then one is telescope_air that has:
humidity, temperature, dew point, primarymirrortemp, secondarymirrortemp, tmirrortemp.
So there are more fields for a particular sensor, is that okay? Or does say every sensor has to have the same number of fields?
Further to what @Anaisdg wrote, this is how I would do it (using v2 with Flux because I’m old school):
fields:
temperature
humidity
dewpoint
pressure
tags:
sensor_id
Possible tag values for sensor_id (you can of course add more). These may also apply to humidity or dewpoint or pressure or whatever other fields you have.
inside_air
outside_air
telescope_structure
telescope_mirror
telescope_air
primarymirror
secondarymirror
etc.
Sure!
In my real world scenario, I measure temperature from many places and always use the field temperature and describe it via multiple tags, e.g.
equip_type: (example tag value: “oven”)
equip_number: (example tag value: “82”)
etc.
Some pieces of equipment may have, for example, a pressure reading. So for those, I would use the field pressure and describe it in a similar fashion:
equip_type: (example tag value: “boiler”)
equip_number: (example tag value: “D19”)
fluid_location: (example tag value: “inlet_line_B”)
Ty so much for this response, it helps congeal in my head how all this would look. I see how the tags can be used and maybe I was overy thinking my schema a bit too
Hey @codejoy, I am happy to share what I have learned.
Here’s another nugget…
I have a tag called MeasType and the tag values are “setpoint” and “actual”. They get recorded into Influx at the same exact time, so it makes the comparison of actual vs setpoint very straightforward, such as:
|> map(fn: (r) => ({ r with _value: (r.setpoint - r.actual)}))
oh thank you for posting this. We will have those things as well or at the very least need to send alerts or change graphs to show values out of parameter. I am so new to all this but these little bits here are helping solidify some ways to move forward with my project. Ty!
