Extra sensor naming (samplestrings.ini)

[HansR]

In my samplestrings.ini I find the following strings for the extra sensors => see code below.

In the extra sensor page I expect to find those strings displayed however there is a discrepancy between the extra sensors displayed and the samplestrings.ini file. Notably (but not limited to):

• I miss the Solar entry in the extra sensor page (are these strings still required/is sensor still possible, which sensor?)
• Is the ExtraSensorCaptions section still required?
• The Leaf Temp/Wetness display is not consistent with the number of sensors possible according to the string-file
• The section AirQualityCaptions / CO2 sensor is not consistent with the naming of the extra sensors The CO2 could have been handled as an AirQuality sensor, now it is specifically the W45? Then it could be named as such.
• Lightning sensor is not in the strings. Why not and how to detect that sensor is present?
• What does the UserTempCaptions mean and which sensors are assigned to it? (there is already an Extra Temp possibility

Context: I am trying to find a unique way to determine which extra sensors are possible and which are present from the information present or from information I could (would?) oblige the user to enter.

Code: Select all

[ExtraSensorCaptions]
Solar=Solar
ExtraChannel2=Extra Channel 2
ExtraChannel3=Extra Channel 3
ExtraChannel4=Extra Channel 4
ExtraChannel5=Extra Channel 5
ExtraChannel6=Extra Channel 6
ExtraChannel7=Extra Channel 7
ExtraChannel8=Extra Channel 8
ExtraChannel9=Extra Channel 9
ExtraChannel10=Extra Channel 10

[ExtraTempCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10

[ExtraHumCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10

[ExtraDPCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10

[SoilTempCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10
Sensor11=Sensor 11
Sensor12=Sensor 12
Sensor13=Sensor 13
Sensor14=Sensor 14
Sensor15=Sensor 15
Sensor16=Sensor 16

[SoilMoistureCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8
Sensor9=Sensor 9
Sensor10=Sensor 10
Sensor11=Sensor 11
Sensor12=Sensor 12
Sensor13=Sensor 13
Sensor14=Sensor 14
Sensor15=Sensor 15
Sensor16=Sensor 16

[LeafTempCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4

[LeafWetnessCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8

[AirQualityCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
SensorAvg1=Sensor Avg 1
SensorAvg2=Sensor Avg 2
SensorAvg3=Sensor Avg 3
SensorAvg4=Sensor Avg 4

[UserTempCaptions]
Sensor1=Sensor 1
Sensor2=Sensor 2
Sensor3=Sensor 3
Sensor4=Sensor 4
Sensor5=Sensor 5
Sensor6=Sensor 6
Sensor7=Sensor 7
Sensor8=Sensor 8

[...]

[CO2Captions]
CO2-Current=CO&#8322 Current
CO2-24hr=CO&#8322 24h avg
CO2-Pm2p5=PM 2.5
CO2-Pm2p5-24hr=PM 2.5 24h avg
CO2-Pm10=PM 10
CO2-Pm10-24hr=PM 10 24h avg

[mcrossley]

* I miss the Solar entry in the extra sensor page (are these strings still required/is sensor still possible, which sensor?)

Solar isn't on the extra sensor page it's on the main pages?
The only solar settings available at the moment are the daylight strings. These are used on default web site.
Strings.ini isn't just about extra sensors, is also used to customise the default web site data - hence all the stuff about forecast strings etc. It was so Cumulus can provide customised/localised data to the web site.

* Is the ExtraSensorCaptions section still required?

They were used for the WMR200 extra sensors, but these are now mapped to the "normal" extra sensors, so are no longer used. Looks like legacy stuff that can be removed to me.

* The Leaf Temp/Wetness display is not consistent with the number of sensors possible according to the string-file

CMX supports up to 8 leaf wetness channels, Ecowitt also supports this number of sensors, but I never expanded the display page from the 4 supported by Davis - and nobody has shouted yet!

* The section AirQualityCaptions / CO2 sensor is not consistent with the naming of the extra sensors The CO2 could have been handled as an AirQuality sensor, now it is specifically the W45? Then it could be named as such.

It could, but AQ sensors are already complicated enough in regards mapping sensors to channels, and the CO2 has unique data.

* Lightning sensor is not in the strings. Why not and how to detect that sensor is present?

Would you want to call your lightning detector something else?
I'm not sure how strings.ini can be used to detect anything is present?

What does the UserTempCaptions mean and which sensors are assigned to it? (there is already an Extra Temp possibility

The Ecowitt sensor family has a set of sensors that operate under the same ids but can be either soil or water temperature sensors. These are classed as User defined temperatures.

[HansR]

Thanks for the reply

* I miss the Solar entry in the extra sensor page (are these strings still required/is sensor still possible, which sensor?)

Solar isn't on the extra sensor page it's on the main pages?
The only solar settings available at the moment are the daylight strings. These are used on default web site.
Strings.ini isn't just about extra sensors, is also used to customise the default web site data - hence all the stuff about forecast strings etc. It was so Cumulus can provide customised/localised data to the web site.

OK. I asked this because solar is in ExtraSensorCaptions block.
Or does this have to do with the Blake-Larsen?

* Is the ExtraSensorCaptions section still required?

They were used for the WMR200 extra sensors, but these are now mapped to the "normal" extra sensors, so are no longer used. Looks like legacy stuff that can be removed to me.

OK (but see above on solar).

* The Leaf Temp/Wetness display is not consistent with the number of sensors possible according to the string-file

CMX supports up to 8 leaf wetness channels, Ecowitt also supports this number of sensors, but I never expanded the display page from the 4 supported by Davis - and nobody has shouted yet!

I am shouting now
Not so much because I have 8 wetness sensors but because I am looking for a method which I can use to handle the extra sensors generic (I explain below) so I need to count to 8 for these as well.

* The section AirQualityCaptions / CO2 sensor is not consistent with the naming of the extra sensors The CO2 could have been handled as an AirQuality sensor, now it is specifically the W45? Then it could be named as such.

It could, but AQ sensors are already complicated enough in regards mapping sensors to channels, and the CO2 has unique data.

True. Is there going to be a unified field theory of AQ sensors some time or do they remain sensor by sensor with their own specific?
It should not all be too complicated: they measure PM2p5 and PM10 and the rest are calculable derivatives. But maybe I am a bit too optimistic now.

* Lightning sensor is not in the strings. Why not and how to detect that sensor is present?

Would you want to call your lightning detector something else?
I'm not sure how strings.ini can be used to detect anything is present?

stings.ini is also a translation thing isn't it? So I would call it something else. But apart from that see below how I am thinking about dealing with extra sensors. I am looking for a consistent way extra sensors are treated to be able to detect. When using the strings.ini (is what I am thinking about) it would not work for the lightning. How would I know the lightning is present?

What does the UserTempCaptions mean and which sensors are assigned to it? (there is already an Extra Temp possibility

The Ecowitt sensor family has a set of sensors that operate under the same ids but can be either soil or water temperature sensors. These are classed as User defined temperatures.

Hmm... OK. It's time I buy some of those. I might.

OK, so what do I want to do? I want to handle extra sensors in CUtils and I need some way to detect which sensors to display. As you say Cumulus does not care. This means it has to be the user who defines what he wants to see (in CUtils) and to prevent the user has to enter info twice, once for CMX (and the default website) and once for CUtils, I was thinking of using the strings.ini. If the user enters a string other than the default one, the sensor is assumed present (even if detached).

As apparently an extra sensor is displayed in the interface when connected without any notification anywhere, I have to come up with something the user can use. It could be just my own configuration file where the user says: ExtraTemp1=present which would trigger me to fetch the data.

But I need the strings.ini to translate the name to get the API call right so the strings.ini has a key role here.

This means, that I could oblige the user to change the name away from the default "sensor 1" and if he does, it would mean CUtils has to handle the extra sensor. So in a way, changed extra sensor names could be used as an indicator of a present sensor (detached or not detached).

I take station info from Cumulus.ini to prevent the user having to enter info that twice (e.g. like location), I want to use the same idea for the extra sensors if possible. So that leads me to the strings.ini. But I am not sure yet.

[mcrossley]

Regarding the solar in ExtraSensorCaptions - that is not used. The whole section is redundant, I'll remove from the next release.

Regarding translation - yes and no. The intent is that it will translate "data" provided by Cumulus. Most web tags etc are just numbers and/or units, but some like forecast, wind direction and daylight have "language" embedded in them so require translation in strings.ini.

Things like the name "lightning" are boiler plate and translated in whatever template you use. Strings.ini would have to grow massively if it allowed you to change every bit of text on the dashboard and default web site - and of course would be pretty useless if you have a custom web site.

The C1 version of strings.ini also contained settings for all the graph titles and data ranges - because C1 provided those graphs for the web site as images and so they could not be changed as boiler plate text.

The other purpose of strings.ini is to add the ability to assign meaningful names to the extra sensors.

[HansR]

Regarding the solar in ExtraSensorCaptions - that is not used. The whole section is redundant, I'll remove from the next release.

Regarding translation - yes and no. The intent is that it will translate "data" provided by Cumulus. Most web tags etc are just numbers and/or units, but some like forecast, wind direction and daylight have "language" embedded in them so require translation in strings.ini.

Things like the name "lightning" are boiler plate and translated in whatever template you use. Strings.ini would have to grow massively if it allowed you to change every bit of text on the dashboard and default web site - and of course would be pretty useless if you have a custom web site.

The C1 version of strings.ini also contained settings for all the graph titles and data ranges - because C1 provided those graphs for the web site as images and so they could not be changed as boiler plate text.

The other purpose of strings.ini is to add the ability to assign meaningful names to the extra sensors.

OK, thanks for the elaboration.
The idea on how to deal with this is stabilizing.