Weather34 TEMPLATE

[weatherist34]

..I cannot do much with this new mapping feature of MeteoBridge, probably I am too old to understand how it works, maybe there will be a more detailed description in the future WIKI of MeteoBridge.
It would be a pity if the development of this very nice template would be stopped by you, Brian, because of these new incalculable scenarios. But I can understand the frustration about it and I hope that this template will be around for a long time and that you can continue to develop it, although it works pretty perfect as it is...
Best regards and many, many thanks for your work!
Mike

template will always work as it is there is nothing in the template itself to prevent it from correctly working as designed,developed but what can happen is the use of mapping will or could basically break things unexpectedly .as above needs a fresh approach and new designer/developer hard to find both normally one or the other , i.e my nephew phenomenal coder but awful designer simply has no concept of color matching then i have my wife superb designer but zero interest in code ..

as above the newer features are beneficial for those needing it just not beneficial to this template ..

[prestwickwx]

Brian,

I don't fully understand the mapping function, but I think that the logical sensors are supposed to be mapped to the corresponding sensors of station #0 by default. So, th0temp should be the default mapping, unless a user changes it.

So, my guess is there are some bugs in the latest firmware causing some of the mappings to not use the default. Or, users are changing the mappings.

Just a guess.

Chuck

[weatherist34]

Brian,

I don't fully understand the mapping function, but I think that the logical sensors are supposed to be mapped to the corresponding sensors of station #0 by default. So, th0temp should be the default mapping, unless a user changes it.

So, my guess is there are some bugs in the latest firmware causing some of the mappings to not use the default. Or, users are changing the mappings.

Just a guess.

Chuck

thats the unknown i cant cater for .. as before 196 strings in the api already ive mentioned before its not possible to extend it beyond that . that said i see the other side of the coin where setups are purposely put together for a reason , one may have two temperature sensors one external which perhaps is more reliable than the default ISS for numerous reasons i.e sighting,age of sensor etc .. for instance you could quite easily run your weatherflow lightning sensor via the nanosd its an example of it would make sense todo I toyed with the idea until i realized it could screw up the api output if incorrectly mapped.. anyway as the template stands it will work just cant cater for mapped sensors ..

[jasonmfarrow]

TL;DR It's not the w34 template it's likely a bug with a particular HW/SW combination

My understanding of the mapping is that there can be many physical sensors (the input data) collected from multiple HW sources.
There are also a number of standard logical sensors (the output) that are then used to export data to the various weather services.

Screenshot 2020-10-03 at 3 October 2020 20.12.38 pm.png (215.89 KiB) Viewed 3735 times

The "Primary Sensor" (the 0th, zero-th) will be the default sensor hardware to map inputs to outputs as above. So in the API you should still see values for th0temp, th0dew etc. as normal.

If someone wanted to use the temperature or humidity reading from the one of the other HW sensorts instead of sensor 0 values for thb0temp or thb0hum then they could do that mapping and thb0temp would output the secondary HW sensor data to your API sensor value. E.g. th2!0temp mapped to thb0temp.

I have two AQI sensors: my own Nova SDS011 aka - sensor #1, and the Davis Airlink aka sensor #2). I have mapped the Airlink input sensors to the new air0pm/air1pm/air2pm which are not defaulted (afaics). These are then outputted as items 180/181/182 in the w34 template API.

As Chuck said, if something else is ending up in the w34 template API, not sensor data but a physical sensor name, then I believe this is a bug of some sort for Boris to work on as I believe it's not expected behaviour. What particular combination of HW/Sensor/SW causes this would be the first problem determination step.

Deliberately changing the output sensor names would clearly break the API templates in the meteobridge config file and I cannot think that would have been done intentionally by Boris without further documentation and a heads up.

[admin]

The mapping tab shown in the posting above is the way to control which of the physical sensors (the ones with the exclamation mark syntax) are meant when the logical sensor mentioned in the upload template is evaluated by Meteobridge. physical sensors should never show up in any upload API as when doing so you get a complete mess on the template side.

The weather34 upload string just makes use of logical sensors, so I can't see any problem here. When data is missing, please check on the Meteobridge mapping tab to have your physical sensors mapped correctly. A bunch of this mapping is done automatically as a default. But when you have multiple stations, you will most probably do some manual mapping.

I have not found time to update the wiki, but in the release notes you find most of the needed details.
https://www.meteobridge.com/wiki/index.php/Forum

Sorry, that this might be confusing on the first look, but I think it is rather simple... once I have all the bugs resolved

@Brian: one thing I might have done wrong with the defaults is the mapping of the three airXpm sensors. air0pm is now 10 micron, air1pm is 2.5, air2pm is 1 micron. I fear I have told you the opposite order. did I? If so I would like to adapt the upload string to weather34 by swapping air0pm and air2pm to avoid that users need to twist it. I don't see any need to change anything else in the API.

[weatherist34]

good morning Boris

there is a lot of confusion going on particularly Airlink . it not clear cut and seems all users Im aware off are seeing different or using a different config seems its not a plug and detect approach requires input ..

so lets take a look at this Davis Airlink and I have no idea how the user has implemented it or setup in Meteobridge

[-act:--] 9.1 985.3 0.0 1.4 [-act:--] 2.0 [-act:--]

[-act:--](this should be air0pm) 9.1 985.3 0.0 1.4 [-act:--]this should be air0pm 2.0(this correct air1pm) [-act:--](this should be air2pm

the three blank [-act:--] are in the API

air0pm air2pm the air1pm is correct showing a value of 2.0 in above

here is the full API output taken a few minutes later we can see the air1pm changed to 1.6 but all other airlink strings/values still show only [-act:--]

04/10/2020 06:49:59 9.0 89.0 7.3 2.1 0.4 263.0 0.0 2.2 985.3 248.0 1 m/s C hPa mm 1.7 985.0 110.4 743.4 68.5 23.1 43.0 -- 9.3 9.7 20201004025501 9.0 20201004063142 2.5 20201004040310 6.7 20201004040240 986.3 20201004000048 984.8 20201004043924 4.4 13905 3.6 CARAMBOLA2 -- 0.0 47.1 0.0 243.0 0.0 12.5 20201003090139 6.1 20201001141429 12.5 20201003090139 19.7 20200908142653 -9.2 20200325145343 0.0 95.0 20201004000711 89.0 20201004053559 8.9 20201004025501 7.3 20201004062559 9.0 89.0 7.3 23.1 44 1.5 1.3 -- -- -- -- -- -- 0.0 137869 13.2 20201003083507 9.6 20201003232952 17.2 20201002155147 9.0 20201004063142 32.4 20200625153035 -3.3 20200121074757 4.5 20201003203426 6.7 20201004040240 17.1 20200210124612 68.5 110.4 20201001000017 743.4 20200201012535 0.0 20201004000044 130.0 20201003135825 791.0 20201002133701 1423.0 20200710122458 20201004000017 0.9 20201003135424 3.8 20201002133711 9.7 20200701132252 8.7 20201003233905 1 9.2 20201004035034 33.2 20180708164500 -6.1 20180228013000 23.0 20190725155914 -12.0 20180228173000 21.6 20171230223000 990.2 20201003000150 986.0 20201003204309 1002.3 20201001000054 980.5 20201002070411 1049.6 20200119190137 964.5 20200227064546 1049.6 20200119190137 963.3 20191221204331 2492.2 9.5 5 95.2 11:25 19:55 09:37 1.3 96.0 20201001011505 53.0 20201001141308 100.0 20200101200726 19.0 20200325145343 96.0 20201003013910 94.0 20201003135945 0.0 0.0 34.0 860.0 [-act:--] 9.0 985.3 0.0 1.5 [-act:--] 1.6 [-act:--] 89.0 13.1 0.7 20100403205000 20100403205000 255.0 4 1 270.0 32.4 20200625153035 -- -- _


its confusing as the template does not know how to deal these new outputs or simply has no idea what the user configuration is or how any additional sensor has been mapped this is where it is difficult to develop for as there is a lot of unknown . it was easy or manageable to develop for the standard familiar strings and sensor process prior to these new ways.That said as above I see the your side and others benefits Im just not seeing a smooth process to work with at present so perhaps in a month or so all will be stable and it would be a better time to look implementation of template when things are stable..

worth noting that the use !0 appears at times even if no mapping sensor as been applied by end user as we saw yesterday from Richard he had appear in his API output [rain0!0total-max@Y1] [rain0!0total-max@M1] but all other rain related values used the familiar [rain0total-xxxx] as expected .

[weatherist34]

update Sunday removes Davis Air Quality module (large) due to unable to establish a standard format string from 4 different users at present is it basically user controlled and until an established correct way on how to use I have removed that option(with a message) and will return turn it at a later date..rain rate got its gradient back ..+40mm per hour or inch equivalent the gradient kicks in.

(*2nd Update for 4th October 13:12)
* Removes Davis Air Quality large module option too much uncertaintity on how it works with in meteobridge
* Adds gradient to rain rate indicator blue to red pending on rain rate intensity
* Cleans up new modules and removes unused code
* Adds translations to reworked sun related modules
* Attempts to fix unknown strings appearing in API after firmware updates

rr.png (17.42 KiB) Viewed 3686 times

dv.png (11.78 KiB) Viewed 3684 times

[admin]

here is the full API output taken a few minutes later we can see the air1pm changed to 1.6 but all other airlink strings/values still show only [-act:--]

04/10/2020 06:49:59 9.0 89.0 7.3 2.1 0.4 263.0 0.0 2.2 985.3 248.0 1 m/s C hPa mm 1.7 985.0 110.4 743.4 68.5 23.1 43.0 -- 9.3 9.7 20201004025501 9.0 20201004063142 2.5 20201004040310 6.7 20201004040240 986.3 20201004000048 984.8 20201004043924 4.4 13905 3.6 CARAMBOLA2 -- 0.0 47.1 0.0 243.0 0.0 12.5 20201003090139 6.1 20201001141429 12.5 20201003090139 19.7 20200908142653 -9.2 20200325145343 0.0 95.0 20201004000711 89.0 20201004053559 8.9 20201004025501 7.3 20201004062559 9.0 89.0 7.3 23.1 44 1.5 1.3 -- -- -- -- -- -- 0.0 137869 13.2 20201003083507 9.6 20201003232952 17.2 20201002155147 9.0 20201004063142 32.4 20200625153035 -3.3 20200121074757 4.5 20201003203426 6.7 20201004040240 17.1 20200210124612 68.5 110.4 20201001000017 743.4 20200201012535 0.0 20201004000044 130.0 20201003135825 791.0 20201002133701 1423.0 20200710122458 20201004000017 0.9 20201003135424 3.8 20201002133711 9.7 20200701132252 8.7 20201003233905 1 9.2 20201004035034 33.2 20180708164500 -6.1 20180228013000 23.0 20190725155914 -12.0 20180228173000 21.6 20171230223000 990.2 20201003000150 986.0 20201003204309 1002.3 20201001000054 980.5 20201002070411 1049.6 20200119190137 964.5 20200227064546 1049.6 20200119190137 963.3 20191221204331 2492.2 9.5 5 95.2 11:25 19:55 09:37 1.3 96.0 20201001011505 53.0 20201001141308 100.0 20200101200726 19.0 20200325145343 96.0 20201003013910 94.0 20201003135945 0.0 0.0 34.0 860.0 [-act:--] 9.0 985.3 0.0 1.5 [-act:--] 1.6 [-act:--] 89.0 13.1 0.7 20100403205000 20100403205000 255.0 4 1 270.0 32.4 20200625153035 -- -- _

The "[.act:--]" should never be the result of a template evaluation. This is a bug in Meteobridge, I have to resolve. Just looking how to reproduce it...

worth noting that the use !0 appears at times even if no mapping sensor as been applied by end user as we saw yesterday from Richard he had appear in his API output [rain0!0total-max@Y1] [rain0!0total-max@M1] but all other rain related values used the familiar [rain0total-xxxx] as expected .

When a user is defining its own upload string and makes use of physical sensors, then this is not our problem. The definition is not correct as it has been overlooked what to report when "rain0!0total-max" is not existing, the default ":--" is missing. So I regard this an improper template definition. As said, neither your nor my business.

[weatherist34]

Boris study this API I just grabbed it may throw some light on what is beginning to appear in the API . as before the template has never had to deal with !0 in the strings until recently so the template has no idea what those strings mean . as above Ill wait until some normalization appears before I approach anything else .



04/10/2020 13:13:18 9.6 98.0 9.3 9.4 12.1 291.0 4.2 25.2 983.8 293.0 6 m/s C hPa mm 9.2 984.1 65.2 1141.4 3.2 18.6 66.0 5.3 9.4 11.4 20201004000134 9.3 20201004083526 14.3 20201004121100 22.4 20201004120756 987.4 20201004000356 983.7 20201004112058 4.4 13813 19.7 TL-MR3020 -- -- 25.8 -- 292.0 5.8 11.3 20201003080506 5.5 20201001225634 11.3 20201003080506 21.7 20200812193157 -4.1 20200321201319 -- 98.0 20201004114726 75.0 20201004020447 9.5 20201004124116 6.4 20201004020505 9.6 98.0 9.3 18.4 66 8.8 9.0 -- -- -- -- -- -- -- 494052 12.7 20201003074342 10.8 20201003210526 14.8 20201001134235 6.1 20201001231553 28.4 20200624145252 -0.3 20200326055726 14.3 20201003082756 22.4 20201004120756 30.0 20200209081904 3.2 65.2 20200129071315 1141.4 20200129071315 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 8.0 20201003230109 0 9.6 20201004131226 28.4 20200624145252 -1.5 20200129071249 21.7 20200812193157 -4.1 20200321201319 30.0 20200209081904 993.8 20201003004257 986.9 20201003234700 1001.2 20201001000557 983.4 20201002054258 1041.0 20200329213408 982.3 20200229050705 1049.3 20200329213408 982.3 20200229050705 1141.4 10.2 5 94.0 11:25 20:04 09:48 9.4 100.0 20201002035716 67.0 20201001135506 100.0 20200302054801 30.0 20200529165801 94.0 20201003000002 81.0 20201003230109 0.0 0.0 [rain0!0total-max@M1] [rain0!0total-max@Y1] -- 9.6 983.9 -- 9.1 -- -- -- 98.0 12.4 3.7 20200129071249 20200129071233 281.5 9 5 176.2 29.8 20200625145130 -5.1 20200226001741 _Mostly cloudy and cooler. Precipitation possible within 12 hours, possibly heavy at times. Windy.

nothing has been mapped but the last month rain total and last year rain total produce a string with !0 in it ..note its a TL-MR3020 which has no capability of sending the last month or last year total. it just produces [rain0!0total-max@M1] [rain0!0total-max@Y1]

variations of Air Quality I have seen this morning for Air0pm

Air0pm
Air0!0pm
--act

im sure in time all will come good just all a bit confusing at present on what todo and how to approach..

[admin]

I tested to reproduce the "-act:--" artifact, without success. I guess newest code I am working with and that was just released has this resolved.

@Brian: should I swap positions of air0pm and air2pm in the upload string to weather34? air0pm does now represent 10 microns.
Or did you already adapt that on the template side?

[admin]

Regarding the " [rain0total-max@M1] [rain0total-max@Y1] " issue I inspected the upload template and I see that a default ":--" is missing there. I should have seen this before, sorry. I update the template (also the "rain0total-sum24h") to have these defaulted as well.

Now you shouldn't see any physical sensor names with exclamation marks in it again

Template is now as follows:

[DD]/[MM]/[YYYY] [hh]:[mm]:[ss] [th0temp-act:--] [th0hum-act:--] [th0dew-act:--] [wind0avgwind-act:--] [wind0wind-act:--] [wind0dir-act:--] [rain0rate-act:--] [rain0total-daysum:--] [thb0seapress-act:--] [wind0dir-avg5:--] [wind0wind-act=bft.0:--] m/s C hPa mm [wind0wind-avg5:--] [thb0seapress-val60:--] [rain0total-monthsum:--] [rain0total-yearsum:--] [rain0total-ydaysum:--] [thb0temp-act:--] [thb0hum-act:--] [wind0chill-act:--] [th0temp-val60:--] [th0temp-dmax:--] [th0temp-dmaxtime:--] [th0temp-dmin:--] [th0temp-dmintime:--] [wind0avgwind-dmax:--] [wind0avgwind-dmaxtime:--] [wind0wind-dmax:--] [wind0wind-dmaxtime:--] [thb0seapress-dmax:--] [thb0seapress-dmaxtime:--] [thb0seapress-dmin:--] [thb0seapress-dmintime:--] [mbsystem-swversion:--] [mbsystem-buildnum:--] [wind0wind-max10:--] [mbsystem-platform:--] -- [uv0index-act:--] [rain0total-sum24h:--] [sol0rad-act:--] [wind0dir-avg10:--] [rain0total-sum60:--] [th0dew-mmax:--] [th0dew-mmaxtime:--] [th0dew-mmin:--] [th0dew-mmintime:--] [th0dew-ydmax:--] [th0dew-ydmaxtime:--] [th0dew-ymax:--] [th0dew-ymaxtime:--] [th0dew-ymin:--] [th0dew-ymintime:--] [uv0index-dmax:--] [th0hum-dmax:--] [th0hum-dmaxtime:--] [th0hum-dmin:--] [th0hum-dmintime:--] [th0dew-dmax:--] [th0dew-dmaxtime:--] [th0dew-dmin:--] [th0dew-dmintime:--] [th0temp-val15:--] [th0hum-val15:--] [th0dew-val15:--] [thb0temp-val15:--] [thb0hum-val15.0:--] [wind0wind-avg15:--] [wind0wind-avg30:--] [lgt0energy-act:--] [lgt0dist-act:--] [lgt0dist-age:--] [lgt0total-daysum.0:--] [lgt0total-monthsum.0:--] [lgt0total-yearsum.0:--] [sol0rad-dmax:--] [mbsystem-uptime:---] [th0temp-ydmax:--] [th0temp-ydmaxtime:--] [th0temp-ydmin:--] [th0temp-ydmintime:--] [th0temp-mmax:--] [th0temp-mmaxtime:--] [th0temp-mmin:--] [th0temp-mmintime:--] [th0temp-ymax:--] [th0temp-ymaxtime:--] [th0temp-ymin:--] [th0temp-ymintime:--] [wind0wind-ydmax:--] [wind0wind-ydmaxtime:--] [wind0wind-mmax:--] [wind0wind-mmaxtime:--] [wind0wind-ymax:--] [wind0wind-ymaxtime:--] [rain0total-ydmax:--] [rain0total-mmax:--] [rain0total-mmintime:--] [rain0total-ymax:--] [rain0total-ymaxtime:--] [sol0rad-dmax:--] [sol0rad-dmaxtime:--] [sol0rad-ydmax:--] [sol0rad-ydmaxtime:--] [sol0rad-mmax:--] [sol0rad-mmaxtime:--] [sol0rad-ymax:--] [sol0rad-ymaxtime:--] [uv0index-dmaxtime:--] [uv0index-ydmax:--] [uv0index-ydmaxtime:--] [uv0index-mmax:--] [uv0index-mmaxtime:--] [uv0index-ymax:--] [uv0index-ymaxtime:--] [th0dew-ydmin:--] [th0dew-ydmintime:--] [mbsystem-lastgooddata:--] [th0temp-avg60:--] [rain0total-nonzerotime:--] [th0temp-amax:--] [th0temp-amaxtime:--] [th0temp-amin:--] [th0temp-amintime:--] [th0dew-amax:--] [th0dew-amaxtime:--] [th0dew-amin:--] [th0dew-amintime:--] [wind0wind-amax:--] [wind0wind-amaxtime:--] [thb0seapress-ydmax:--] [thb0seapress-ydmaxtime:--] [thb0seapress-ydmin:--] [thb0seapress-ydmintime:--] [thb0seapress-mmax:--] [thb0seapress-mmaxtime:--] [thb0seapress-mmin:--] [thb0seapress-mmintime:--] [thb0seapress-ymax:--] [thb0seapress-ymaxtime:--] [thb0seapress-ymin:--] [thb0seapress-ymintime:--] [thb0seapress-amax:--] [thb0seapress-amaxtime:--] [thb0seapress-amin:--] [thb0seapress-amintime:--] [rain0total-allsum:--] [th0temp-davg:--] [mbsystem-lunarsegment:--] [mbsystem-lunarpercent:--] [mbsystem-daylength:--] [mbsystem-moonrise:--] [mbsystem-moonset:--] [wind0wind-davg:--] [th0hum-mmax:--] [th0hum-mmaxtime:--] [th0hum-mmin:--] [th0hum-mmintime:--] [th0hum-ymax:--] [th0hum-ymaxtime:--] [th0hum-ymin:--] [th0hum-ymintime:--] [th0hum-ydmax:--] [th0hum-ydmaxtime:--] [th0hum-ydmin:--] [th0hum-ydmintime:--] [thb0lowbat-act:--] [th0lowbat-act:--] [rain0total-max@M1:--] [rain0total-max@Y1:--] [air0pm-act:--] [th0temp-avg5:--] [thb0seapress-avg5:--] [uv0index-avg5:--] [wind0avgwind-avg5:--] [air0pm-act:--] [air1pm-act:--] [air2pm-act:--] [th0hum-avg5:--] [th0temp-yavg:--] [wind0wind-yavg:--] [th0temp-starttime:--] [wind0wind-starttime:--] [wind0dir-davg:--] [wind0wind-dmax=bft.0:--] [wind0wind-davg=bft.0:--] [wind0dir-mavg:--] [th0heatindex-ymax:--] [th0heatindex-ymaxtime:--] [wind0chill-ymin:--] [wind0chill-ymintime:--] _[forecast-text:]

[weatherist34]

i can adapt the template accordingly however until my unit arrives im not going to do anything until then so i can actually determine what is correct. as it is now

180 [air0pm-act:--] * Davis Air Quality PM1 New september 2020
181 [air1pm-act:--] * Davis Air Quality PM 2.5 New september 2020
182 [air2pm-act:--] * Davis Air Quality PM 10 New september 2020

i can simply adjust the position to

180 [air0pm-act:--] * Davis Air Quality PM2.5
181 [air1pm-act:--] * Davis Air Quality PM 10
182 [air2pm-act:--] * Davis Air Quality PM 1

i think thats how your doing it now ?

also im seeing the act— sometimes returns zero so hence i need to closely look at what is best once i have it front of me perhaps use avg10 or max10 as opposed to act— . no need to change API this can be done in template livedata file.. just be nice if all air quality uses this type of string output as opposed to !0

[admin]

i can adapt the template accordingly however until my unit arrives im not going to do anything until then so i can actually determine what is correct. as it is now

180 [air0pm-act:--] * Davis Air Quality PM1 New september 2020
181 [air1pm-act:--] * Davis Air Quality PM 2.5 New september 2020
182 [air2pm-act:--] * Davis Air Quality PM 10 New september 2020

Thanks for the confirmation. I will change on the upload template by swapping air0pm and air2pm. No need to touch the code on your side for that.

Upload template is now:

[DD]/[MM]/[YYYY] [hh]:[mm]:[ss] [th0temp-act:--] [th0hum-act:--] [th0dew-act:--] [wind0avgwind-act:--] [wind0wind-act:--] [wind0dir-act:--] [rain0rate-act:--] [rain0total-daysum:--] [thb0seapress-act:--] [wind0dir-avg5:--] [wind0wind-act=bft.0:--] m/s C hPa mm [wind0wind-avg5:--] [thb0seapress-val60:--] [rain0total-monthsum:--] [rain0total-yearsum:--] [rain0total-ydaysum:--] [thb0temp-act:--] [thb0hum-act:--] [wind0chill-act:--] [th0temp-val60:--] [th0temp-dmax:--] [th0temp-dmaxtime:--] [th0temp-dmin:--] [th0temp-dmintime:--] [wind0avgwind-dmax:--] [wind0avgwind-dmaxtime:--] [wind0wind-dmax:--] [wind0wind-dmaxtime:--] [thb0seapress-dmax:--] [thb0seapress-dmaxtime:--] [thb0seapress-dmin:--] [thb0seapress-dmintime:--] [mbsystem-swversion:--] [mbsystem-buildnum:--] [wind0wind-max10:--] [mbsystem-platform:--] -- [uv0index-act:--] [rain0total-sum24h:--] [sol0rad-act:--] [wind0dir-avg10:--] [rain0total-sum60:--] [th0dew-mmax:--] [th0dew-mmaxtime:--] [th0dew-mmin:--] [th0dew-mmintime:--] [th0dew-ydmax:--] [th0dew-ydmaxtime:--] [th0dew-ymax:--] [th0dew-ymaxtime:--] [th0dew-ymin:--] [th0dew-ymintime:--] [uv0index-dmax:--] [th0hum-dmax:--] [th0hum-dmaxtime:--] [th0hum-dmin:--] [th0hum-dmintime:--] [th0dew-dmax:--] [th0dew-dmaxtime:--] [th0dew-dmin:--] [th0dew-dmintime:--] [th0temp-val15:--] [th0hum-val15:--] [th0dew-val15:--] [thb0temp-val15:--] [thb0hum-val15.0:--] [wind0wind-avg15:--] [wind0wind-avg30:--] [lgt0energy-act:--] [lgt0dist-act:--] [lgt0dist-age:--] [lgt0total-daysum.0:--] [lgt0total-monthsum.0:--] [lgt0total-yearsum.0:--] [sol0rad-dmax:--] [mbsystem-uptime:---] [th0temp-ydmax:--] [th0temp-ydmaxtime:--] [th0temp-ydmin:--] [th0temp-ydmintime:--] [th0temp-mmax:--] [th0temp-mmaxtime:--] [th0temp-mmin:--] [th0temp-mmintime:--] [th0temp-ymax:--] [th0temp-ymaxtime:--] [th0temp-ymin:--] [th0temp-ymintime:--] [wind0wind-ydmax:--] [wind0wind-ydmaxtime:--] [wind0wind-mmax:--] [wind0wind-mmaxtime:--] [wind0wind-ymax:--] [wind0wind-ymaxtime:--] [rain0total-ydmax:--] [rain0total-mmax:--] [rain0total-mmintime:--] [rain0total-ymax:--] [rain0total-ymaxtime:--] [sol0rad-dmax:--] [sol0rad-dmaxtime:--] [sol0rad-ydmax:--] [sol0rad-ydmaxtime:--] [sol0rad-mmax:--] [sol0rad-mmaxtime:--] [sol0rad-ymax:--] [sol0rad-ymaxtime:--] [uv0index-dmaxtime:--] [uv0index-ydmax:--] [uv0index-ydmaxtime:--] [uv0index-mmax:--] [uv0index-mmaxtime:--] [uv0index-ymax:--] [uv0index-ymaxtime:--] [th0dew-ydmin:--] [th0dew-ydmintime:--] [mbsystem-lastgooddata:--] [th0temp-avg60:--] [rain0total-nonzerotime:--] [th0temp-amax:--] [th0temp-amaxtime:--] [th0temp-amin:--] [th0temp-amintime:--] [th0dew-amax:--] [th0dew-amaxtime:--] [th0dew-amin:--] [th0dew-amintime:--] [wind0wind-amax:--] [wind0wind-amaxtime:--] [thb0seapress-ydmax:--] [thb0seapress-ydmaxtime:--] [thb0seapress-ydmin:--] [thb0seapress-ydmintime:--] [thb0seapress-mmax:--] [thb0seapress-mmaxtime:--] [thb0seapress-mmin:--] [thb0seapress-mmintime:--] [thb0seapress-ymax:--] [thb0seapress-ymaxtime:--] [thb0seapress-ymin:--] [thb0seapress-ymintime:--] [thb0seapress-amax:--] [thb0seapress-amaxtime:--] [thb0seapress-amin:--] [thb0seapress-amintime:--] [rain0total-allsum:--] [th0temp-davg:--] [mbsystem-lunarsegment:--] [mbsystem-lunarpercent:--] [mbsystem-daylength:--] [mbsystem-moonrise:--] [mbsystem-moonset:--] [wind0wind-davg:--] [th0hum-mmax:--] [th0hum-mmaxtime:--] [th0hum-mmin:--] [th0hum-mmintime:--] [th0hum-ymax:--] [th0hum-ymaxtime:--] [th0hum-ymin:--] [th0hum-ymintime:--] [th0hum-ydmax:--] [th0hum-ydmaxtime:--] [th0hum-ydmin:--] [th0hum-ydmintime:--] [thb0lowbat-act:--] [th0lowbat-act:--] [rain0total-max@M1:--] [rain0total-max@Y1:--] [air0pm-act:--] [th0temp-avg5:--] [thb0seapress-avg5:--] [uv0index-avg5:--] [wind0avgwind-avg5:--] [air2pm-act:--] [air1pm-act:--] [air0pm-act:--] [th0hum-avg5:--] [th0temp-yavg:--] [wind0wind-yavg:--] [th0temp-starttime:--] [wind0wind-starttime:--] [wind0dir-davg:--] [wind0wind-dmax=bft.0:--] [wind0wind-davg=bft.0:--] [wind0dir-mavg:--] [th0heatindex-ymax:--] [th0heatindex-ymaxtime:--] [wind0chill-ymin:--] [wind0chill-ymintime:--] _[forecast-text:]

[weatherist34]

ok now break it down into simple explanation for everyone ????? because I cant my head around it hence I have no unit so im not going to do anything..


[air2pm-act:--] = PM1

[air1pm-act:--] = PM10

[air0pm-act:--] = PM2.5

[admin]

ok now break it down into simple explanation for everyone


[air2pm-act:--] = PM2.5

[air1pm-act:--] = PM10

[air0pm-act:--] = PM1

nope, it is
[air2pm-act:--] = PM1
[air1pm-act:--] = PM2.5
[air0pm-act:--] = PM10

I hope the template upload string of my previous post does have the variables positioned correctly. If not, I can easily change again. I think we are close to have this sorted out (on top of the confusion I inducted).