Topic: FOSHKplugin - brief introduction

[olicat]

Hello Jim,

Updated from beta yesterday and it's been problem-free.

thank you very much for the confirmation.
So far I haven't received any other (error) message or request. So it seems to be working.
That gives me some time for my other projects ...


Regards, Oliver

[joem]

Hey olicat,

any chance to be able to connect it to InfluxDB 2?

Thanks

[olicat]

Hi!

Since InfluxDB2 should actually be backwards compatible with InfluxDB1, there are currently no concrete plans.
However, I always collect the wishes of the users and prioritise (also) according to them. In this respect, I can imagine that support may follow.

Oliver

[joem]

I'm on a fresh influxdb2 install, and since this works with tokens, organizations and buckets, instead of username/pass/database, I'm out of ideas how could I feed the data to the database.

[zinz]

Hi!

Since InfluxDB2 should actually be backwards compatible with InfluxDB1, there are currently no concrete plans.
However, I always collect the wishes of the users and prioritise (also) according to them. In this respect, I can imagine that support may follow.

Oliver

sadly influxdb is pretty incompatible between version one and 2.
I took a look at the code.
On the github page https://github.com/influxdata/influxdb-python it says that this library only supports Influxdb 1 and not 2.
It is suggested to use influxdb-client-python instead. For it to work The organization Token (password) and bucket would be needed. Maybe I will give it a try to implement it.

[zinz]

So I added another forward for influxdb2 and the needed dependencies.

 [ You are not allowed to view attachments ]

@Oliver
I hope the support for influxdb2 makes into the next release.
Is there a way that FoshkPlugin resents data when my influxdb is back online after backup or maintenance?

Code: [Select]

[Forward-26]
FWD_CMT = InfluxDB 2 metric forward Testing
FWD_TYPE = INFLUXMET2
FWD_URL = http://server:port@myBucket
FWD_SID = myOrganization
FWD_PWD = "Token"
FWD_INTERVAL = 60
FWD_ENABLE = False

[olicat]

Hi!

That's exactly how I wanted to implement it. Thank you very much.
But I'll call the new forward types INFLUX2MET and INFLUX2IMP instead of INFLUXMET2 and INFLUXIMP2.

At the moment, however, I don't have the possibility to test it - I only have an InfluxDB1 server here.
Maybe I can set up an additional InfluxDB2 server for testing here before the next release. Then InfluxDB2 should also be implemented in FOSHKplugin.
But from your point of view, can this be used productively?

Otherwise, the new libraries for Influx2DB now explicitly require a Python version > 3.6.
Until now, I could also install FOSHKplugin on systems with e.g. Python 3.5.3. With integrated Influx2DB support, this would no longer work and I would exclude quite a few users.
I still have to think about whether I really want that or generally how to deal with this.

Oliver

[zinz]

Hi!

That's exactly how I wanted to implement it. Thank you very much.
But I'll call the new forward types INFLUX2MET and INFLUX2IMP instead of INFLUXMET2 and INFLUXIMP2.

At the moment, however, I don't have the possibility to test it - I only have an InfluxDB1 server here.
Maybe I can set up an additional InfluxDB2 server for testing here before the next release. Then InfluxDB2 should also be implemented in FOSHKplugin.
But from your point of view, can this be used productively?

Otherwise, the new libraries for Influx2DB now explicitly require a Python version > 3.6.
Until now, I could also install FOSHKplugin on systems with e.g. Python 3.5.3. With integrated Influx2DB support, this would no longer work and I would exclude quite a few users.
I still have to think about whether I really want that or generally how to deal with this.

Oliver

Yes your naming scheme certainly makes more sense.
After some thought changing the location of the bucket and the orginization. As it is much more likely to have multiple buckets than organizations. So buckets would be more similar to the username (fwd_sid)

Code: [Select]

[Forward-26]
FWD_CMT = InfluxDB 2 metric forward Testing
FWD_TYPE = INFLUX2MET
FWD_URL = http://server:port@myOrganization
FWD_SID = myBucket
FWD_PWD = "Token"
FWD_INTERVAL = 60
FWD_ENABLE = False
For testing I would suggest to simply spin up one with docker Compose.
Here is the one I am using. change ports and volumes to the ones that fit your system. After you run the docker login in and under Data/ApiTokens generate a read write token for your bucket.
I am also not so sure why the weather community seems so averse to docker. Programs like CumulusMX, weewx etc. would be 100 times more user friendly for non programmers. No need to worry about dependencies, mono installs, data directories and so on. Everyone could be up and running in 5 minutes. Including secure public webpages. Well that is slightly off topic. For Foshkplugin this would also be helpful for updates and multiple instances.

Code: [Select]

version: "3.5"

services:
  influxdb2:
    image: influxdb:latest
    container_name: InfluxDBWeatherData
    ports:
      - "8086:8086"
    volumes:
      - "/mnt/user/appdata/InfluxDBWeatherData/data:/var/lib/influxdb2"
      - "/mnt/user/appdata/InfluxDBWeatherData/config:/etc/influxdb2"
    environment:
      - DOCKER_INFLUXDB_INIT_MODE=setup
      - DOCKER_INFLUXDB_INIT_USERNAME=YourAdmin
      - DOCKER_INFLUXDB_INIT_PASSWORD=superSecretPassword
      - DOCKER_INFLUXDB_INIT_ORG=myOrg
      - DOCKER_INFLUXDB_INIT_BUCKET=WeatherData
    restart: always

So far this is running fine for me. (besides the data loss due to my server with the influxdb running performing a backup)
 [ You are not allowed to view attachments ]

From my understanding it should be possible to only provide this functionality for people with the appropriate python version. https://www.pythonpool.com/python-conditional-import/ Sadly python is not my primary programming language. So I would need to do some testing concerning what would be the best approach.

Some other points I have noticed about the code:

• I am not a big fan of having only one file with 6k lines of code. This means that an import like influxdbclient has to be loaded in the main execution script. While it is only necessary for one specific function.
• Your functions are doing too much and should be separated into several smaller functions that can be reused. For example in the forwardDictToInfluxDB function:
  
  • The first 40 lines are just for preparing the data from generic data to the specific influxdb one.
  • A further 20 lines are just for evaluating the URL. Which should ideally be done only once when ingesting the configuration file.
  • The real sending method is then another 30 lines.
• Many variables are very short and therefore difficult to understand what they are supposed to do. In the function forwardDictToInfluxDB the variable d is not very clear what it should mean.
• I haven't found the code on github or another Version Control software yet. If you haven't played around with that yet i highly recommend to do that as the sheer amount of code and effort you have put into this makes it really a lot easier to work with.

[Daali]

I'd love to get FOSHKplugin in a docker to ride as an addon in HomeAssistant.  I could repurpose a couple pi's =).  I need to dig in and learn a bit.

[thunder.ky]

Hi @olicat,

Thanks for sharing your work on FOSHKplugin. I'm trying to solve a problem that I believe I can with the REMAP functionality. So I have an Ecowitt Wittboy/GW2001 & WS90. It's configured via the Custom Server to forward to an instance of FOSHKplugin. Since it has a piezo rain gauge, the rain data comes in the EW format as the following variables:

&rrain_piezo=0.000
&erain_piezo=0.256
&hrain_piezo=0.000
&drain_piezo=0.256
&wrain_piezo=1.437
&mrain_piezo=8.736
&yrain_piezo=9.083

If I understand correctly I should be able to remap these with FOSHKplugin to the standard EW rain variables so that I can forward to "Personal Weather Tablet". Is this correct? However I cannot find a list of the FOSHKplugin internal variable names to successfully remap it.

For example with:
FWD_REMAP = @rainrate=@rrain_piezo

I get the error:
Remap: problem while remapping @rainrate with @rrain_piezo
Appreciate any assistance you can offer.

EDIT:
Got it working with the following:

FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo

Another question is about the "WeatherStation" section in the config file. Does this make FOSHKplugin use the Ecowitt API on the station instead of having to use the "Custom Server"?

Thanks,
Arthur

[olicat]

Hi!

I'm trying to solve a problem that I believe I can with the REMAP functionality.

In fact there is a problem with FOSHKplugin in v0.09, which will be fixed in the next version:

Changelog:
...
fixed: WS90 rain-handling - replacing the new names with the old ones now works correctly (e.g. "rrain_piezo" --> "rainratein")
...

Actually, it was intended that FOSHKplugin would automatically convert to the conventional names if only the new key names were available. Precisely to ensure compatibility with software that has not (yet) been adapted, such as PWT.

The default active option for this is

Code: [Select]

Weatherstation\WS90_CONVERT = True
If WS90_CONVERT is set, the conversion to the conventional names takes place:

rrain_piezo --> rainratein
erain_piezo --> eventrainin
hrain_piezo --> hourlyrainin
drain_piezo --> dailyrainin
wrain_piezo --> wekklyrainin
mrain_piezo --> monthlyrainin
yrain_piezo --> yearlyrainin

However, due to a silly bug in v0.09, this conversion does not happen. Sorry.
Fortunately, though, you can actually solve this with the FWD_REMAP function, as you've already done:

Code: [Select]

FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
However, with the upcoming v0.10 this remap will work automatically - as originally intended for v0.09.

However I cannot find a list of the FOSHKplugin internal variable names to successfully remap it.

The available variable names are - depending on the available sensors - user specific. Therefore I didn't want to generate a static list of all possible key names (very large and not very helpful) but a dynamic overview of what is possible for each user. You can reach this overview page with all variable names that can be reached by FOSHKplugin (for you) with http://ipaddress:port/FOSHKplugin/keyhelp. This page is very helpful, especially for individual queries (getvalue) or for the remap function.
I would also like to point out the help page of FOSHKplugin: http://ipaddress:port/FOSHKplugin/help - which documents all http control and query options.

Regards, Oliver

[thunder.ky]

Changelog:
...
fixed: WS90 rain-handling - replacing the new names with the old ones now works correctly (e.g. "rrain_piezo" --> "rainratein")
...

Actually, it was intended that FOSHKplugin would automatically convert to the conventional names if only the new key names were available. Precisely to ensure compatibility with software that has not (yet) been adapted, such as PWT.

The default active option for this is

Code: [Select]

Weatherstation\WS90_CONVERT = True
If WS90_CONVERT is set, the conversion to the conventional names takes place:

rrain_piezo --> rainratein
erain_piezo --> eventrainin
hrain_piezo --> hourlyrainin
drain_piezo --> dailyrainin
wrain_piezo --> wekklyrainin
mrain_piezo --> monthlyrainin
yrain_piezo --> yearlyrainin

However, due to a silly bug in v0.09, this conversion does not happen. Sorry.

Excellent, I look forward to the updated v0.10. Thanks for your work on such a useful tool! I'm about to make my install a bit more complicated  by installing another instance of FOSHKplugin to get around some firewalls.

Fortunately, though, you can actually solve this with the FWD_REMAP function, as you've already done:

Code: [Select]

FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
However, with the upcoming v0.10 this remap will work automatically - as originally intended for v0.09.

It took a bit of troubleshooting and testing, but was able to figure it out. The WS90_CONVERT will make it a lot easier on new users. I think the WS90 may create some new weather enthusiasts since it's so compact and easy to set up.

The available variable names are - depending on the available sensors - user specific. Therefore I didn't want to generate a static list of all possible key names (very large and not very helpful) but a dynamic overview of what is possible for each user. You can reach this overview page with all variable names that can be reached by FOSHKplugin (for you) with http://ipaddress:port/FOSHKplugin/keyhelp. This page is very helpful, especially for individual queries (getvalue) or for the remap function.

I would also like to point out the help page of FOSHKplugin: http://ipaddress:port/FOSHKplugin/help - which documents all http control and query options.

Perfect, I didn't realize how "self documenting" FOSHkplugin is. These URLs are tremendously helpful, and I've made note of them for future use. There's a lot of good information in there that I can use to extend my use case of it.

Another question is about the "WeatherStation" section in the config file. Does this make FOSHKplugin use the Ecowitt API on the station instead of having to use the "Custom Server"?

Referring to the above question, can FOSHKplugin query the GW2000/WS90 API directly or does it just work with the "Custom Server"?

Thanks again,
Arthur

[olicat]

Hi!

I'm about to make my install a bit more complicated  by installing another instance of FOSHKplugin to get around some firewalls.

That should not be a problem.
I run about 8 or 9 instances in parallel on one host. As long as you don't get confused with the different directories, service names and ports, it works very well.

can FOSHKplugin query the GW2000/WS90 API directly or does it just work with the "Custom Server"?

FOSHKplugin only supports data reception via custom server.
The API functionality is not available for all devices and I wanted to have a solution that is as comprehensive as possible.

Oliver

[thunder.ky]

Hi @olicat,

Where is the best forum to discuss suggestions about FOSHKplugin? Unless I hear otherwise, I'll just post about a possible bug here.

I've just recently set up a forward to "WeatherCloud". On FOSHKplugin 0.09, it seems that the FWD_REMAP does not seem to be working for WC.

Code: [Select]

[Forward-4]
FWD_ENABLE = True
FWD_CMT = WeatherCloud
FWD_INTERVAL = 60
FWD_URL = http://api.weathercloud.net/v01/set?wid=XX&key=XX&
FWD_TYPE = WC
FWD_REMAP = rainrate=@rrain_piezomm,et=@erain_piezomm,rain=@drain_piezomm

Here's the snd-foshkplugin.log with no foshkplugin.py modification (no rain data)

Code: [Select]

http://api.weathercloud.net/v01/set?wid=XX&key=XX&date=20220707&time=2115&tempin=265&humin=46&bar=10130&temp=295&hum=76&wdir=115&wspd=34&solarrad=2151&uvi=10&battery=54&pwrsply=54&temp1=262&hum1=43&temp2=270&hum2=44&temp3=250&hum3=47&temp4=349&hum4=50&pm25=4.0&noise=40&leafwet=0.5&dew=248&chill=295&heat=352&aqi=17&wspdavg=34&wdiravg=115&wspdhi=61&dewin=139&heatin=264&type=FOSHKplugin&ver=v0.09
In the interim I've made some temporary modifications to foshkplugin.py to capture these keys.

Code: [Select]

def forwardDictToWC(url,d_in,fwd_sid,fwd_pwd,script,nr,ignoreKeys,remapKeys):
|
<snip>
|
    elif key == "drain_piezomm":
      outstr += "rain=" + str(round(float(value)*10)) + "&"
    elif key == "rrain_piezomm":
      outstr += "rainrate=" + str(round(float(value)*10)) + "&"
    elif key == "erain_piezomm":
      outstr += "et=" + str(round(float(value)*10)) + "&"
|
<snip>
|

Here's the snd-foshkplugin.log with the foshkplugin.py modification (has rain data)

Code: [Select]

http://api.weathercloud.net/v01/set?wid=XX&key=XX&date=20220707&time=2119&tempin=268&humin=46&bar=10129&temp=296&hum=76&wdir=163&wspd=19&solarrad=4204&uvi=30&rainrate=0&et=40&rain=40&battery=54&pwrsply=54&temp1=264&hum1=44&temp2=272&hum2=44&temp3=254&hum3=47&temp4=349&hum4=50&pm25=4.0&noise=40&leafwet=0.3&dew=249&chill=296&heat=354&aqi=17&wspdavg=21&wdiravg=143&wspdhi=60&dewin=142&heatin=270&type=FOSHKplugin&ver=v0.09
Thanks for your help,
Arthur

[olicat]

Hi Arthur!

Where is the best forum to discuss suggestions about FOSHKplugin? Unless I hear otherwise, I'll just post about a possible bug here.

No problem - this is the best place to discuss these things.

it seems that the FWD_REMAP does not seem to be working for WC.

No.
The FWD_REMAP is just working a bit different.
But you have found an interesting thing that I haven't come across yet. And actually you wouldn't have noticed it either if v0.09 behaved exactly as it was intended.
Because when only operating a WS90 (without an additional WH40), FOSHKplugin should already change the rain values to the traditional names when receiving the data from the console and BEFORE converting to the metric system. Then the "new" keys would not exist at all but only the traditional names.
Due to an error, however, exactly this does not happen - the error has already been fixed in my internal beta v0.10.

However, when operating both the WS90 and a conventional rain sensor - i.e. when both forms of the keys are sent - your question also arises - at least with Weathercloud (and all other services that require metric values).
Because there you have to tell FOSHKplugin via FWD_REMAP which keys it should use to pass on to the respective service.
In this respect, here is a good opportunity to explain this better.

You can only exchange Ecowitt fields or (within limits) add new fields. The output format (as it is sent to the destination - here WC) is not decisive, but the input format (as it comes from the weather station).
A complicating factor in the case of WC is that not the original Ecowitt keys are used, but the metric ones. And these metric keys have a slightly different name than the imperial variables.

With your FWD_REMAP:

FWD_REMAP = rainrate=@rrain_piezomm,et=@erain_piezomm,rain=@drain_piezomm

you set the key rainrate to the value of rrain_piezomm. The conversion routine to WC, however, does not check for the key rainrate but searches for the key rainratemm in order to pass its value on to WC as rainrate.
FOSHKplugin also searches for the key dailyrainmm for the daily amount of rain and passes its value to WC as rain. Your rain in FWD_REMAP is therefore simply ignored.

A correct FWD_REMAP for Weathercloud if you want to use the data of the WS90 would therefore be:

Code: [Select]

FWD_REMAP = rainratemm=@rrain_piezomm,dailyrainmm=@drain_piezomm
What you mean by et=@erain_piezomm is not quite clear to me. In Weathercloud, et stands for evapotranspiration, which is neither sent by the console nor calculated (yet) by FOSHKplugin.
At least et says something completely different than the amount of rain of the current rain event. Therefore, it is not advisable to report the event rainfall amount as et to WeatherCloud.
But the fundamental problem is, that I have deactivated the forwarding of unknown keys in WeatherCloud due to a lack of experience. I don't know how WC reacts to unknown keys. Therefore, your et=@erain_piezomm is ignored and not transmitted.

But I've been planning to take a closer look at WC for a while and to use the 30-day trial period for the extended Plus service.
At least I could then finally test to what extent the sensor values for temp2, hum2, soiltemperature, soilmoisture, leafwetness and air quality, which are not included in the free Basic Plan, are correctly transmitted by FOSHKplugin.
Because that should actually work - only I have never tested it (of course I send this data - only I cannot see them on the WC page).
So far I have hoped in vain that these values will also be available in the free Basic Plan at some point.

At the moment, however, I want to finish the new version v0.10. I will probably not be able to take care of WC until the end of the year at the earliest. Sending data to WeatherCloud is not such a high priority for me because the Ecowitt consoles can do this by default (even if not as well as FOSHKplugin). In any case, I have not yet had any enquiries regarding FOSHKplugin and WeatherCloud. You're the first one - thanks!
Most people probably use the built-in data transfer to WC and don't realise that there is a better way.

Regards, Oliver

[thunder.ky]

Hi Oliver,

Thanks for responding.

No.
The FWD_REMAP is just working a bit different.
But you have found an interesting thing that I haven't come across yet. And actually you wouldn't have noticed it either if v0.09 behaved exactly as it was intended.
Because when only operating a WS90 (without an additional WH40), FOSHKplugin should already change the rain values to the traditional names when receiving the data from the console and BEFORE converting to the metric system. Then the "new" keys would not exist at all but only the traditional names.
Due to an error, however, exactly this does not happen - the error has already been fixed in my internal beta v0.10.

Ah understood, I'm running into the same error that we discussed in my earlier post with

Code: [Select]

Weatherstation\WS90_CONVERT = True

You can only exchange Ecowitt fields or (within limits) add new fields. The output format (as it is sent to the destination - here WC) is not decisive, but the input format (as it comes from the weather station).
A complicating factor in the case of WC is that not the original Ecowitt keys are used, but the metric ones. And these metric keys have a slightly different name than the imperial variables.

That's what I've run into, wanting to be able to arbitrarily assign fields. For fun I have mapped lightning strikes to the unused WC field "noise" so that it can be visualized. .

What you mean by et=@erain_piezomm is not quite clear to me. In Weathercloud, et stands for evapotranspiration, which is neither sent by the console nor calculated (yet) by FOSHKplugin.
At least et says something completely different than the amount of rain of the current rain event. Therefore, it is not advisable to report the event rainfall amount as et to WeatherCloud.

I misinterpreted "et" as the current rain event instead of evapotranspiration. So i got rid of it. Oops!

But the fundamental problem is, that I have deactivated the forwarding of unknown keys in WeatherCloud due to a lack of experience. I don't know how WC reacts to unknown keys. Therefore, your et=@erain_piezomm is ignored and not transmitted.

Is there any way that I can easily enable the forwarding of unknown keys? I've had a scan through the Python code to understand better how it works. Perhaps I can help shine some light on how WC works. More than happy to share anything I learn.

At least I could then finally test to what extent the sensor values for temp2, hum2, soiltemperature, soilmoisture, leafwetness and air quality, which are not included in the free Basic Plan, are correctly transmitted by FOSHKplugin.
Because that should actually work - only I have never tested it (of course I send this data - only I cannot see them on the WC page).

I managed to get Leafwetness displayed, but not air quality or the temp2, hum2 etc. I have a paid account with WC and have reached to to their support.

I also have the latest v1.0 API documentation that WC Support sent me, if you don't have it and would find it useful.

At the moment, however, I want to finish the new version v0.10.
:
I have not yet had any enquiries regarding FOSHKplugin and WeatherCloud. You're the first one - thanks!

Indeed keep on track with v0.10 and don't let me distract you. I like WCs interface and they seem to be actively developing and more willing to listen to users compared to some of the other services.

Thanks,
Arthur

[olicat]

Hi!

I have taken your request as an opportunity to raise various points again with WeatherCloud.
As soon as I have more information, I will get back to you.

Is there any way that I can easily enable the forwarding of unknown keys? I've had a scan through the Python code to understand better how it works.

In FOSHKplugin v0.9 you only may remap the known keys because I restrict the sending to keys available on WeatherCloud. So this is not easily changeable.
But of course you could make some modifications in your local code:

Code: [Select]

    else:
      if myDebug: logPrint("<DEBUG> forwardDictToWC: unknown field: " + str(key) + " with value: " + str(value))
      outstr += str(key) + "=" + str(value) + "&"
With the line after else and logPrint all (!) incoming keys will be transferred to WeatherCloud.

I managed to get Leafwetness displayed, but not air quality or the temp2, hum2 etc.

Do you use a WH45? The data should - if possible - be sent to WeatherCloud.
Unfortunately, according to the available API documentation, there is still no field for the CO2 value, which is of course a shame for a CO2 sensor like the WH45.
temp2 and hum2 are currently not transmitted due to a misinterpretation of the API on my part. WeatherCloud expects the keys temp02 and hum02 (instead of temp2 and hum2).
This will be corrected in the next FOSHKplugin version.
In the meantime you could adapt the temp block in the forwardDictToWC function and insert the missing "0":

Code: [Select]

    elif "temp" in key and len(key) == 6 and key[-1] == "c":                 
      val = round(float(value)*10)
      outstr += "temp" + "0" + str(int(key[4])+1) + "=" + str(val) + "&"


I like WCs interface and they seem to be actively developing and more willing to listen to users compared to some of the other services.

I am torn on this.
I like the graphic visualisation and especially the diverse language support.
On the other hand, contact and further development is rather slow. According to the blog, the last update (v10.1) was more than a year ago! The API documentation v1.0 that I have is also at least 15 months old.
In addition, unfortunately only very few sensors from the Ecowitt world are supported.
And even with the small selection of additional sensors supported (only one other T/H sensor, one soil moisture sensor, one leaf moisture sensor, one air quality sensor), a paid tariff is required to view them.
I was promised more fields a long time ago. But - see above - further development is not really rapid.

And basically, the free Ecowitt service offers much more than the rather expensive Pro tariff of 10 EUR/month at WeatherCloud.
But if you don't like the design, that won't help you, of course.
BTW: Do you already know my Comparison PDF for the different weather services and programmes with Ecowitt support?
Maybe Ambient Weather would be something for you? Or Awekas?

Regards, Oliver

[thunder.ky]

Hi,

I have taken your request as an opportunity to raise various points again with WeatherCloud.
As soon as I have more information, I will get back to you.

OK, that's cool. I got a response from them to some of my questions.

• No lighting data in the short or medium term
• Here are the additional Sensors that they support. Displayed automatically from the moment you upgrade your plan on a new Extra tab on your device page.
• 1 x Additional ambient temperature
• 1 x Additional ambient humidity
• 1 x Soil temperature
• 1 x Soil moisture
• 1 x Leaf wetness
• 1 x Air quality (PM2.5, PM10, CO, NO, NO2, SO2 and O3)
• 1 x Noise

So overall not very many at all.

In FOSHKplugin v0.9 you only may remap the known keys because I restrict the sending to keys available on WeatherCloud. So this is not easily changeable.
But of course you could make some modifications in your local code:

Code: [Select]

    else:
      if myDebug: logPrint("<DEBUG> forwardDictToWC: unknown field: " + str(key) + " with value: " + str(value))
      outstr += str(key) + "=" + str(value) + "&"
With the line after else and logPrint all (!) incoming keys will be transferred to WeatherCloud.

Excellent, thanks for this direction. In the mean time I've modified my local code to do things like map my lighting strikes to the WC "noise" variable. Not perfect, but it's fun to do.

Do you use a WH45? The data should - if possible - be sent to WeatherCloud.
Unfortunately, according to the available API documentation, there is still no field for the CO2 value, which is of course a shame for a CO2 sensor like the WH45.

No I don't have the WH45, but I do have the WH41. I modified my local code to send the PM2.5 data from it to WC.

temp2 and hum2 are currently not transmitted due to a misinterpretation of the API on my part. WeatherCloud expects the keys temp02 and hum02 (instead of temp2 and hum2).

This will be corrected in the next FOSHKplugin version.

In the meantime you could adapt the temp block in the forwardDictToWC function and insert the missing "0":

That's exactly what I've done after reading the API now I have one of my WH31 T&H sensors data is now showing up. Also sending another WH31 T&H sensor to the "Temperature agro" field.

Likely not have too many modifications when you release v0.10 of FOSHKplugin.

I am torn on this.
I like the graphic visualisation and especially the diverse language support.
On the other hand, contact and further development is rather slow. According to the blog, the last update (v10.1) was more than a year ago! The API documentation v1.0 that I have is also at least 15 months old.
In addition, unfortunately only very few sensors from the Ecowitt world are supported.
And even with the small selection of additional sensors supported (only one other T/H sensor, one soil moisture sensor, one leaf moisture sensor, one air quality sensor), a paid tariff is required to view them.
I was promised more fields a long time ago. But - see above - further development is not really rapid.

BTW: Do you already know my Comparison PDF for the different weather services and programmes with Ecowitt support?
Maybe Ambient Weather would be something for you? Or Awekas?

I hear you. I'm hoping WC will do some new development in the near future. If they don't then I'll abandon it when I am bored of it.

Indeed, I read the Comparison PDF last night and it really does give an excellent breakdown of the various services. I may look into Ambient Weather and see how much effort it takes to get the license and then integrated it.

I may just continue expanding my own WeeWX site and maybe implement CumulusMX.

Thanks,
Arthur

[davidefa]

You can also take a look at meteotemplate ( see an example in my signature ), it now support all ecowitt sensors.

[thunder.ky]

You can also take a look at meteotemplate ( see an example in my signature ), it now support all ecowitt sensors.

I've seen mention of Meteotemplate. Thanks for your suggestion. I'll have a look!

[falkunmalti]

I am intrigued by this because I also would like to feed several devices from my HP2553.  I downloaded the software but is there a fairly succinct summary of how to set it up etc.  What does it run on, a raspberry pi maybe?

Right now, I feed my CumulusMX from my custom server but there is only one custom server.  I would also like to feed PWT and maybe others.

I am totally new to this so would appreciate help.  Thanks in advance.

Joe

[Gyvate]

yes, you can run it on a RapberryPi (with any Linux type operation system which has the systemd service implemented) or on a NAS, natively or in a Virtual Machine (e.g. Docker) etc.- it has to run 24/7.

The installation instructions should be clear.
https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version

With CumulusMX you can have max three http posts/forwards - with FOSHKplugin up to 50, meanwhile even 100 as far as I know.
Beyond forwards you can convert formats, add information and do some console configuration.

FOSHKplugin is an information broker - for the principle see https://www.wxforum.net/index.php?topic=40730.0
section 7. data flow between sensors, consoles, application software and internet weather services
(the whole thread is a collection of background information regarding Ecowitt (clone) consoles and sensors)

[falkunmalti]

Thanks Gyvate

There is quite a bit there but i will check it out and try installing on my rpi3.  My ultimate goal at this point is to provide feeds from my HP2553 custom server to my CumulusMX and PWT.  And then I'll go from there.

[Gyvate]

that would also work without FOSHKplugin (even though FOSHKplugin is a nice tool and your scenario would be much easier to implement)
HP2551 --> CMX, CMX --> PWT
However the translation from CMX to PWT will need some work - you have to figure out the content of the custom server string (use @olicats ear service).
Then create the http post string for CMX to forward to PWT: the skelton comes from ear - for the values you need to find the CMX webtags (see CMX Wiki - it's a bit hidden)
then you would have a string like

http://your-PWT-IP:8072/data/reportPASSKEY=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx&stationtype=HP2551_V1.8.1&runtime=526615&dateutc=<CMX-webtag for date-time format:2022-07-18+10:38:25>&tempinf=<CMX-webtag for inside temp in F>&humidityin=<CMX-webtag for inside humidity>36&baromrelin=<CMX-webtag for rel air pressure in inches>&baromabsin=<>& ....&

by the way: "runtime" is not an important variable for PWT and can be left out

[thunder.ky]

There is quite a bit there but i will check it out and try installing on my rpi3.  My ultimate goal at this point is to provide feeds from my HP2553 custom server to my CumulusMX and PWT.  And then I'll go from there.

Personally I use my GW2000 Custom Server to feed FOSHKplugin which then feeds PWT and a number of other services. I did go a bit crazy by forwarding to quite a few Weather Services. FOSHKplugin is a brilliant piece of software.

Here's a snippet of my foshkplugin.conf for my PWT Tablets that may help you get started. I have to remap the rain fields since I have a WS90 with the piezo rain gauge.

Code: [Select]

[Forward-1]
FWD_ENABLE = True
FWD_CMT = Amazon Fire 8 PWT
FWD_URL = http://X.X.X.X:8572/
FWD_INTERVAL = 16
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =

[Forward-2]
FWD_ENABLE = True
FWD_CMT = Amazon Fire 10 PWT
FWD_URL = http://X.X.X.X:8572/
FWD_INTERVAL = 16
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =

[Forward-3]
FWD_ENABLE = False
FWD_CMT = Phantasoft Ecowitt AutoResponder
FWD_URL = http://ear.phantasoft.de/data/report/
FWD_INTERVAL = 30
FWD_IGNORE =
FWD_TYPE = EW
FWD_SID =
FWD_PWD =
FWD_REMAP = rainratein=@rrain_piezo,eventrainin=@erain_piezo,hourlyrainin=@hrain_piezo,dailyrainin=@drain_piezo,weeklyrainin=@wrain_piezo,monthlyrainin=@mrain_piezo,yearlyrainin=@yrain_piezo
FWD_STATUS = False
FWD_MQTTCYCLE = 0
FWD_EXEC =

I don't use Cumulus, but came across the below in the FOSHKplugin documentation which should help you get it set for CumulusMX.

Code: [Select]

[Forward-77]
FWD_TYPE = EW
FWD_CMT = CMX
FWD_URL = http://192.168.15.252:8998/station/ecowitt

It's all so flexible and @Gyvate has a great suggestion too.

Using FOSHKplugin gives you another option such as:

Code: [Select]

HP2551 -> FOSHKplugin -> PWT & CMX