meteohub.de

Good day to you,

I am trying to export Evapotransparation data to Meteotemplate, this is not being sent along and is also not visible in the apilog.

Am I doing something wrong or is it just not sent?

Gerrit

EP is only supported with some stations, when I remember correctly. Which station are you using?

Good day to you,

I use the vantagepro plus
I can see day, month and year data from EP but it is not sent to meteotemplate.

Gerrit.

When I look into the upload API definition for meteotemplate I can't find a parameter for evapotranspiration.
Link: http://www.meteotemplate.com/web/wiki/wikiAPI.php

Good day,

The parameter for the evaporation ET is not included by default, this is a custom file, which can display additional sensors.
If the ET data were sent along, it would be included in the data base and could be read out.

Gerrit

An option which will surely work is that you create your own, custom http post to your Meteotemplate site API, including &ET=[sensor-selector] where sensor-selector=converter.decimals:replacement (see https://www.meteobridge.com/wiki/index.php/Templates).

of course your API string will need to contain also all other parameters for the MT API and the standard posting at the weather network page has to be switched off for MT.
That's how I am doing it for several parameters that are not part of the Meteotemplate standard database schema.

Also, in Meteotemplate, one can display values sent to the API which are not saved in the database. You need a proper program (php) to pick the value up and process it.

I fear, as long as Jachym (owner of Meteotemplate) doesn't change his standard API description and database schema, the Meteobridge API string won't be changed.

If interested, I can provide you with the API string I am posting. You could use it to create your own one by removing what you don't need and adding what you need. If interested, send me a PM (personal message).

Good day Gyvate,

I would certainly like to use the api, if I can install it, but that seems easier than creating one.

I would like to see your PM.

Gerrit

Private Message sent.

I am fine to add something to the upload stream as long as it does not break the existing Installations. You just have to tell me what to add.

Good day to you,

as far as I know it is the ET which is under sol0evo
I hope I am saying it right.

Gerrit

the trouble is that "ET" is not part of the default MT database schema. Therefore @Gerrit better uses his own http string and repurposes an existing database field which is not used by him , e.g. "NL" for noise level (or his home country ).
e.g. &NL=[sol0evo-daysum.2:--]&...
Or he manages to extend the extra table of his MT database by the column "ET".
Then he can use "ET" in his private http post.

@Boris
For the MT API a wrong=not existing letter (combination) doesn't matter - it will simply be discarded as the php scripts do not process an unrecognized letter combination, i.e. a letter combination which doesn't represent an existing column in one of the database tables.
Even entries for existing columns in the default extra table won't be created until the column is initialized by the user.

However best imo would be to wait until @Jachym gets (hopefuly rather soon) some free time from his late engagements and creates a new default database schema for Meteotemplate which satisfies both the Davis and Ecowitt ecosystem of sensors and observations.

Thanks to Gyvate, it has been solved and the data is sent via an api file, so that expansion will be possible in the future.

As far as I am concerned, it has been solved.

Gerrit

I had a conversation with Jachym on the evopatranspiration topic. Jachym confirms that adding a new name-value pair to the upload string will not break anything.

His preferred method to work with evapotranspiration is to have Meteotemple to compute this. This is considered a more consistent approach not depending on the station you are using, as long as the needed base values are provided (temperature, humidity, wind speed, pressure, station elevation, latitude, solar radiation and wind speed measurement height).

Good day,

So is it added from meteobridge now?
In addition, I want to add lightning sensors from ecowitt soon, maybe it will be possible to have them included with meteobridge.
At the moment it is also possible to show the ecowitt wh57 in meteotemplate, but then using different plugins.

Gerrit

Gerrit wrote: ↑Sat Apr 09, 2022 12:18 pm Good day,

So is it added from meteobridge now?
In addition, I want to add lightning sensors from ecowitt soon, maybe it will be possible to have them included with meteobridge.
At the moment it is also possible to show the ecowitt wh57 in meteotemplate, but then using different plugins.

Gerrit

@Gerrit:
I think you need to be more specific with your requests
Also, "hijacking" a thread with a different topic (and ET and lightning of a WH57 are pretty much different), is not very helpful for other users -
who would expect a WH57 related post buried in a ET related post.
Imho it would have been better to open a separate thread for this topic - or use another existing but related one.
I say that because I know from reading the forum posts that there are a few people who are also waiting for the WH57 readings to be available in the Meteotemplate string. And there are existing threads even.
Never mind - next time we do better ...

@Gerrit, @Boris
In the standard/default version of Meteotemplate only the L sensor (=lightning total) is contained (but not in the default MB posting string).
To have all the information from a WH57, the database needs to be extended by the LD (lightning distance of last recorded lightning) and LT (timestamp of last occurrence) columns - and the full MB http string would be:

&L=[lgt0total-dmax.0:--]&LD=[lgt0dist-lastval.0:--]&LT=[lgt0total-nonzerotime=epoch:--]

This would provide the total number of lightning strikes per day (it would just add up like rainfall), the distance of the last strike occurrence and the time stamp in EPOCH notation of the last strike.

Having the string extended like before wouldn't interfere with the API, even if the LT and LD column were not available in the database.
Still the data could be used for current readings. In order to have them archived too, the database schema needs to be extended (not a MB issue).

LT and LD are already used by certain user defined plugins in Meteotemplate (e.g. ecowitt plugin based on custom server data provision). Therefore using LT and LD would be consistent with existing usage. From the default MT end there is no definition yet, but @Jachym would do well also adopting these database column names.