Alternate Weather Source - Your Own Weather Station

[BJReplay]

I have a Pantech branded Home Weather Station (of course I do - I'm a gadget geek) - Ecowitt (aka Fine Offset) are the OEM for a bunch of home weather stations, including Pantech, and probably most commonly known in the US is Ambient Weather.

I've just discovered (since my internal display died last night) that they have an API: https://doc.ecowitt.net/web/#/apiv3en?page_id=19

I knew that it was possible to intercept the output having read up on weewx interceptors, but now that they have an API, it seems feasible to provide an alternative weather input to Weather411 for the dashboard.

Here's a list of weatherstations from another site that talks about accessing their data utilising the wire protocol - but I suspect this is now superseded given there is an API: https://www.openhab.org/addons/bindings/fineoffsetweatherstation/

First steps will be to get the API working in Postman, and then to figure out how to get it up and running so that it can be included into grafana - I would welcome any suggestions!

[jasonacox]

Hi @BJReplay, you could definitely modify the weather411 code (here) to poll for this API data and store it in InfluxDB. But even if you didn't create a service for this, polling and putting this into InfluxDB isn't too difficult. Some options:

1. Use the python library for influxDB with something like this (untested):

from influxdb import InfluxDBClient
# grab weather data from api and store in dict
# ...
# store data in InfluxDB
client = InfluxDBClient(host="localhost", port=8086, database="powerwall")
output = [{}]
output[0]["measurement"] = "pantech"
output[0]["time"] = weather["dt"]
output[0]["fields"] = {}
for i in weather:
    output[0]["fields"][i] = weather[i]
print(output)
if client.write_points(output, time_precision='s'):
    print("Succes")
else:
    print("Error"
client.close()

2. Push the data directly with a simple bash script (example of temp only):

# Pull TEMP value from API
TEMP=`curl ...` # whatever is used to pull temp from pantech API

# Save to InfluxDB
curl -XPOST 'http://localhost:8086/write?db=powerwall' --data-binary "pantech temp=${TEMP}"

3. This dashboard project already uses telegraf which is designed for polling and storing API data of any kind into InfluxDB. I did a quick search and found this: https://gist.github.com/dhowland/158c01b0cfb65e6dc09c316402930c67 - Modification to the telegraf.conf file could accomodate some of what you are wanting.

Let us know what you discover or what you end up doing. I'm also open to hearing any better / generic ways for users to add their own weather data to the project.

[mcbirse]

@BJReplay and @jasonacox - Coincidently, I have been working on a Weather History Import Tool (similar to my Tesla History Import Tool) that will import historical weather data from OpenWeatherMap directly into InfluxDB.

I notice the API for the Pantech supports historical data, as such the tool I am developing may be very well suited to be adapted/modified to this (at least to pull in historical data... modifying weather411 for real-time data logging may be more appropriate).

Similar to Jason's first example it uses the python InfluxDBClient module to write to the database, however this in done in Line Protocol format (faster for importing large amounts of data), so the creation of the fields will look a bit different in my code to his example.

I have just about finished this due to finally having some free time (thanks Christmas holidays! 🎄 ).

I am guessing there will be interest in this tool, so I can submit a PR as before to add it to the tools list.

Obviously the intention was to be able to import historical data from OpenWeatherMap replicating the Weather411 functionality to fill missing data in our Powerwall Dashboard graphs, but it could be useful as a base to adapt for use with other API's or data sources too!

[BJReplay]

Thanks @jasonacox and @mcbirse - those two hints are enough to get me going.

The advantage that OpenWeatherMap has is cloud cover information (even though it is not necessarily correct - at times it says 100% when it is clear:) - it is nice to have), but the detail I've been able to get out of the local API is nice as it includes UVI and insolation data as W/m2 (note the example below is manually indented for readability, so the closing braces are not indented). For example, this is a recent call to real_time.

It also has history data, and if I call it for a 24 hour period, I can get it at 5 minute resolution.

"code": 0,
"msg": "success",
"time": "1672195188",
"data": {
  "outdoor": {
    "temperature": {
      "time": "1672195104",
      "unit": "℃",
      "value": "20.5"
},
    "feels_like": {
      "time": "1672195104",
      "unit": "℃",
      "value": "20.5"
},
    "app_temp": {
      "time": "1672195104",
      "unit": "℃",
      "value": "21.6"
},
    "dew_point": {
      "time": "1672195104",
      "unit": "℃",
      "value": "15.5"
},
    "humidity": {
      "time": "1672195104",
      "unit": "%",
      "value": "73"
}
},
  "solar_and_uvi": {
    "solar": {
      "time": "1672195104",
      "unit": "W/m²",
      "value": "151.0"
},
    "uvi": {
      "time": "1672195104",
      "unit": "",
      "value": "1"
}
},
  "rainfall": {
    "rain_rate": {
      "time": "1672195104",
      "unit": "mm/hr",
      "value": "0.0"
},
    "daily": {
      "time": "1672195104",
      "unit": "mm",
      "value": "0.0"
},
    "event": {
      "time": "1672195104",
      "unit": "mm",
      "value": "0.0"
},
    "hourly": {
      "time": "1672195104",
      "unit": "mm",
      "value": "0.0"
},
    "weekly": {
      "time": "1672195104",
      "unit": "mm",
      "value": "0.0"
},
    "monthly": {
      "time": "1672195104",
      "unit": "mm",
      "value": "58.4"
},
    "yearly": {
      "time": "1672195104",
      "unit": "mm",
      "value": "2743.0"
}
},
  "wind": {
    "wind_speed": {
      "time": "1672195104",
      "unit": "km/h",
      "value": "3.5"
},
    "wind_gust": {
      "time": "1672195104",
      "unit": "km/h",
      "value": "5.5"
},
    "wind_direction": {
      "time": "1672195104",
      "unit": "º",
      "value": "322"
}
},
  "pressure": {
    "relative": {
      "time": "1672195104",
      "unit": "hPa",
      "value": "1001.3"
},
    "absolute": {
      "time": "1672195104",
      "unit": "hPa",
      "value": "1012.7"
}
}
}
}

[mcbirse]

@BJReplay - That's really cool... and the amount of detail you get is pretty awesome. I may have to invest in my own weather station like this myself I think. 😊

[BJReplay]

@mcbirse Yeah, they are pretty good, and you can go crazy and add on all sorts of other sensors like soil moisture, lightning, multiple temperature, and so on. I've got a CO2, PM2.5 and PM10 sensor https://shop.ecowitt.com/products/wh45 that should arrive in the next couple of days as well as a replacement gateway https://shop.ecowitt.com/products/gw1100 because the internal display / console / display is on the way out - my current unit is a combo of the earlier model of this LCD display https://shop.ecowitt.com/products/ws2910_c and the earlier model of this external sensor array https://shop.ecowitt.com/products/ws69. I suspect that the main quartz crystal oscillator or driver circuitry is on the way out, as the display periodically freezes, and when it comes back to life, the time has also frozen. Given that the display is handy, but I monitor the temperature from an app, anyway, I've gone for the cheaper gateway replacement rather than a fancier display, but then splashed out on an air quality sensor.

Gadgets!!!

[BJReplay]

OK, I've made pretty good progress: I've got the a modified version of weather411 server.py now working with the Ecowitt API, serving data on port 8686, and I've managed to include it in the powerwall.yml and get it to build into the docker compose, but I can't get it talking to InfluxDB.

Parsing the Ecowitt API JSON is working (needed some re-work for different names, as well as structural differences), it is returning the weather data.

I just need to figure out if I set up an InfluxDB username and password (though I don't think I did), or try to work out what the problem is writing to InfluxDB.

Once I've sussed it out, I'll can either put together a pull request, or attach files to this discussion - @jasonacox let me know what is easiest for you to consider.

There is a New (slightly modified from the weather411) Dockerfile, localweather.conf (again, based on the weather411.conf file), server.py, etc. Basically a whole new subdirectory that sits under Powerwall-Dashboard.

It is focused on Ecowitt (and that whole OEM ecosystem) at the moment.

I haven't modified the setup script, but by modifying the powerwall.yml, integrated it by doing a compose-dash.sh stop, followed by a compose-dash.sh up -d. It should be simple enough to clone the Q&A in the setup.sh section to also ask about do you have a local weather station using the Ecowitt API, I guess.

[jasonacox]

That's great news @BJReplay - Great job! A few thoughts:

• Since you are pulling in the same data points, you should be able to re-use the same InfluxDB code to save the data to Influx: See https://github.com/jasonacox/Powerwall-Dashboard/blob/main/weather/server.py#L252
• Unless you modified it, there should not be a user or password set for InfluxDB.
• Would you want BOTH OpenWeather data and Ecowitt data? If not, that makes this substantially cleaner. I'll put my proposal out there:

User Contributed Weather Data Options (Exclusive)

1. We could leave everything as-is (fresh install) and the user can elect to NOT use weather411.
2. We could create a directory /weather/contrib (see similar approach for one of my other projects here) that contains a README and folders for different options (e.g. Ecowitt) which would contain a stand-alone service (server.py and configs) that will gather the data and stuff it into InfluxDB using the same measurement field names as weather411 (e.g. https://github.com/jasonacox/Powerwall-Dashboard/blob/main/weather/server.py#L149) - this allows the same dashboards to interoperate. Naturally, we could also add additional data points and dashboards for the different weather stations.
3. The /weather/contrib options could all contain a setup.sh that spins up a docker version. It would not be controlled by the primary compose-dash.sh but it really doesn't need to be. Alternatively, the contributor for that weather station support could also upload it to docker hub to make it easier to pull down. The name should represent the weather source (e.g. weather411-ecowitt).

User Contributed Weather Data Options (Inclusive)

1. At fresh install user selects to use weather411 but also wants additional weather data...
2. Is still suggest the /weather/contrib approach as above. The only difference is that the service would need to use a unique measurement field name to distinguish it from weather411.
3. A similar setup.sh would work as above.
4. The /weather/contrib would need to contain a separate dashboard.json that includes the separate weather station data.

Thoughts?

[BJReplay]

Ooof, I dunno, let me think on it.

Only just got it going - found it incredibly hard to debug, and I have a lot of work to do, to get it back as close as possible to the original code - not helped by the fact that I don't know python, influxdb, or linux.

• I changed some field names to more closely match the measurement names that I'm more used to seeing, but that might have made things harder, or not made any difference. Who knows?
• I struggled getting it into InfluxDB, and I suspect in the end it might have had to do with the way the Ecowitt API returned the timestamp as a string in JSON result, but it took me a long time trying to get it to work;
• First error I got visible was a tz error, so I added a tz tag manually (which I've added as a config item) - not knowing anything about grafana or InfluxDB I guessed it might be needed for time localisation
• I ended up fiddling around on the command line at a python prompt trying to get to get a meaningful error message out, because I couldn't successfully add meaningful error stack track logging into the docker stack (due to my python noob status), and (at least at first) couldn't work out to connect to the docker instance of influxdb while not running under docker
• I ended up adding in a tag section in the dictionary being written to InfluxDB because it was throwing an error (str not element in get or similar - I had the error message in a clipboard buffer somewhere, but have now lost it) in the write_points InfluxDB python library parser at the point that it was trying to parse the (non-existent) tags section of the dictionary, and adding in a tag got past that point, and that allowed me to get to the next error which was an error parsing the timestamp. That might have been the original error - I don't know, but it's been a long day.
• Some of the data points that are being parsed (e.g. wind_gust and wind_speed) are not showing up in grafana yet others are, so there is still work to do.

Gut feel is that aside from solar and UVI, and me deciding to rename fields, sticking with the same measurement field names thereby allowing the same dashboards is possibly the best option. Might need a mapping section in the config to achieve this, but that's doable.

Anyway, I'm going to leave this for a little while, allow some data to start populating, and see what it looks like. For the moment, I've duplicated one of the panels in a dashboard, added most of the new fields in the new measurement set (called localweather) and I'll see what it looks like.

[BJReplay]

HI @jasonacox, I've had a few clear days away from this, a chance to think about it, and a chance to do some debugging, and these are my thoughts:

• Whilst it would be great if you were to chase the holy grail of code reuse, I don't think it is worth it in this case to try to create a single server.py that can consume more than one weather API. The current two versions are pretty similar, and the differences are around differences in the source weather JSON. The JSON parsing could be made more complex but able to consume both - for the moment - but as soon as you introduce a third API source, you'll spend more time trying to make a generic API consumer than you will cloning and modifying. I don't think there's a big maintenance burden with two versions, either; the code that writes to influxDB is now back to identical (or will be once I've double checked), and that's where the maintenance burden lies, anyway.
• The ability to choose where to write the data - to the weather measurement, or to another one - I'm using localweather - could be made into a configuration option; that would allow users to use Weather411 and a local weather service or just a local weather service. Weather411 has Snow data - personal weather stations don't, and also has cloud and visibility data that personal weather stations don't, so there is some data that doesn't overlap, which means there is a reason why people may want both.
• That might mean that we could suggest that local weather data should always use the localweather measurement, and then dashboards could show that data (which will typically include solar and UVI, and potentially indoor measurements as well).
• All that said, keeping the field names identical makes a lot of sense, and that's my task for tomorrow (reverting the changes I made there, and working out if I can rename previously imported data) as it's black 9% IPA o'clock now, so if you choose weather as the measurement and don't install Weather411, then the default dashboard should "just work™"

[jasonacox]

Sold! Very thoughtful... some thoughts:

Local and Optional Weather Data Feeds

• Weather411 will exclusively use "weather" as the measurement label.
• Local weather station data (or alternative weather sources) will use "localweather" as the measurement label (can be included in our dashboards in addition to "weather")
• The "localweather" measurements will use the same data field names to allow consistency for dashboards (see below)
• These optional local (or other) weather services scripts will be available in their own folder in /weather/contrib (README in contrib directory will describe each and how to use them)

Weather Data Fields

data point	description	example
dt	sample timestamp in UTC (s)	1673111000
name	city/location	Los Angeles
country	country	US
id	city/station identifier	5393049
temperature	current temp C, K or F	12.09
humidity	relative humidity in percent (%)	58
pressure	pressure in hPa	1022
temp_min	regional min temp	9.25
temp_max	regional max temp	14.9
feels_like	heat index / wind chill temp	10.87
clouds	cloudiness in percent (%)	0
visibility	max visibility in meters (max 10km)	10000
wind_speed	wind speed in m/s or mph	2.57
wind_deg	wind direction, degrees	320
wind_gust	wind speed gusts in m/s or mph	None
weather_id	openweathermap weather condition id	800
weather_main	short description of weather condition	Clear, Rain, Snow, Extreme
weather_description	long description of weather condition	clear sky
weather_icon	openweathermap icon for current conditions	01d
rain_1h	rainfall in last 1 hour in mm	0.0
rain_3h	rainfall in last 3 hour in mm	0.0
snow_1h	snow in lsat 1 hour in mm	0.0
snow_3h	snow in lsat 3 hour in mm	0.0
sunrise	sunrise timestamp in UTC (s)	1673103669
sunset	sunset timestamp in UTC (s)	1673139561
tz	timezone offset for current location (s)	-28800
uvi *	UV index	1.4
dew_point *	DEW Point	277.08
solar *	Solar measurement	?
inside_temp *	inside temperature	18.0
inside_humidity *	inside humidity in percent (%)	60
others? *	---	---

* = Not in weather411

[BJReplay]

See updated table below with a couple of changes.

I've added in the notional data type - however it should be noted that the Ecowitt API all data as text fields (as a side note - this was the problem that sent me down my debugging rabbit hole - passing that time field as a timestamp in the write_points was failing, but the error wasn't obvious that it was the timestamp).

"code": 0,
"msg": "success",
"time": "1673132247",
"data": {
  "outdoor": {
    "temperature": {
      "time": "1673132202",
      "unit": "℃",
      "value": "22.2"
    },

One other thought on measurement set name: an option (driven by the .conf) to allow the local weather to use the weather measurement - so that users can use the default dashboards with minimal modification by editing the config file.

Weather Data Fields

data point	description	example	unit
dt	sample timestamp in UTC (s)	1673111000	int
name ~	city/location	Los Angeles	text
country ~	country	US	text
id ~	city/station identifier	5393049	int
temperature	current temp C, K or F	12.09	float
humidity	relative humidity in percent (%)	58	int
pressure	pressure in hPa	1022	float
temp_min ~	regional min temp	9.25	float
temp_max ~	regional max temp	14.9	float
feels_like	heat index / wind chill temp	10.87	float
app_temp *	(Steadman) apparent temperature	10.87	float
clouds ~	cloudiness in percent (%)	0	int
visibility ~	max visibility in meters (max 10km)	10000	int
wind_speed	wind speed in m/s or mph	2.57	float
wind_deg	wind direction, degrees	320	int
wind_gust	wind speed gusts in m/s or mph	None	float
weather_id ~	openweathermap weather condition id	800	int
weather_main ~	short description of weather condition	Clear, Rain, Snow, Extreme	text
weather_description ~	long description of weather condition	clear sky	text
weather_icon ~	openweathermap icon for current conditions	01d	?
rain_1h	rainfall in last 1 hour in mm	0.0	float
rain_3h ~	rainfall in last 3 hour in mm	0.0	float
rain_24h *	cumulative rainfall in last 24 hours in mm	0.0	float
snow_1h ~	snow in last 1 hour in mm	0.0	float
snow_3h ~	snow in last 3 hour in mm	0.0	float
sunrise ~	sunrise timestamp in UTC (s)	1673103669	int
sunset ~	sunset timestamp in UTC (s)	1673139561	int
tz ~	timezone offset for current location (s)	-28800	int
uvi *	UV index	1	int
dew_point *	DEW Point	277.08	float
solar *	Solar measurement in W/m²	552.2	float
inside_temp *	inside temperature	18.0	float
inside_humidity *	inside humidity in percent (%)	60	int
CO2 *	Carbon Dioxide ppm	450	int
PM25 *	PM2.5 micron concentration in µg/m³	10	int
PM25AQI *	PM2.5 micron Air Quality Index	15	int
PM10 *	PM10 micron concentration in µg/m³	2	int
PM10AQI *	PM10 micron Air Quality Index	2	int
others? *
* = Not in weather411
~ = Not in localweather

• See https://en.wikipedia.org/wiki/Heat_index for a discussion of Heat Index / Wind Chill - the "Feels Like" temperature
• See https://en.wikipedia.org/wiki/Apparent_temperature for a discussion of Apparent Temperature
• They are similar, however Heat Index often known as Feels Like is a calculation of air temperature and relative humidity whereas Apparent Temperature should combine air temperature, relative humidity and wind speed. The Ecowitt API returns both a Feels Like and Apparent Temperature reading, which is why I've included both in the table above.
• PM2.5, PM10 and C02 are air quality metrics - and give you a good idea of pollution, air quality, etc.
• There are heaps of other measurements that could be added, but I think this is a pretty good starting list :)

[mcbirse]

When adding data to an existing measurement in InfluxDB, you need to be careful to ensure the field data types are the same.

If you are trying to add a data point within the same shard, but you use a different field type, you will get an error.

If the data point falls within a new shard, using a different type would be allowed - but you will end up with different data types for the same field within the database. That could create problems when performing select queries.

There is more info about this here: https://docs.influxdata.com/influxdb/v1.8/troubleshooting/frequently-asked-questions/#how-does-influxdb-handle-field-type-discrepancies-across-shards

So, I would highly recommend when adding data to the 'weather' measurement used by Weather411, to force the field data types to be the same as previously used.

When I was writing the Weather History Import Tool, I struck this issue as I found one of the data types being returned from the OpenWeatherMap API was actually not the same as the data type Jason used in the weather411 program (as Jason is mapping the returned value to a specific data type) so had to replicate that (i.e. change the type of the value). I can't remember which field it was... one of the 'wind' one's I think.

Anyway, @BJReplay I have listed below the field data types used by the 'weather' measurement in InfluxDB. I think there is one discrepancy compared with your list, which is 'pressure' - this needs to be an int. Please check I haven't missed any others....

name: weather
fieldKey            fieldType
--------            ---------
clouds              integer
country             string
dt                  integer
feels_like          float
humidity            integer
id                  integer
name                string
pressure            integer   - NOTE: data type mismatch to above list
rain_1h             float
rain_3h             float
snow_1h             float
snow_3h             float
sunrise             integer
sunset              integer
temp_max            float
temp_min            float
temperature         float
tz                  integer
visibility          integer
weather_description string
weather_icon        string    - it's a string, specific to OpenWeatherMap, see: https://openweathermap.org/weather-conditions#How-to-get-icon-URL
weather_id          integer
weather_main        string
wind_deg            integer
wind_gust           float
wind_speed          float

[mcbirse]

I can't remember which field it was... one of the 'wind' one's I think.

It was 'wind_gust' in the history API call... for old historical data (<1-2yr ago) it is returned as an 'int' as below, instead of the 'float' value returned for live data and recent history.

{
  "data": [
    {
      "dt": 1610062293,
      "sunrise": 1610045659,
      "sunset": 1610097168,
      "temp": 18.79,
      "feels_like": 18.5,
      "pressure": 1024,
      "humidity": 68,
      "dew_point": 12.77,
      "clouds": 89,
      "wind_speed": 5.1,
      "wind_deg": 160,
      "wind_gust": 0,
      "weather": [
        {
          "id": 500,
          "main": "Rain",
          "description": "light rain",
          "icon": "10d"
        }
      ],
      "rain": {
        "1h": 0.22
      }
    }
  ]
}

Regardless, the moral being we need to ensure the same field data types are used when writing to InfluxDB.

[BJReplay]

Thanks @mcbirse that's really helpful; as I mentioned above, I'm a complete noob for python, influx and linux, so I'm really feeling my way around here; but I can confirm that the Ecowitt API returns pressure and wind as decimal numbers (so float in server.py in the Weather411 codebase).

As a side note, I've noticed other weather services - possibly Weather Underground - treat numbers as integers where the "native" weather unit is imperial like °F for temperature, and when they convert to °C, they convert to integer - but that simply isn't precise enough - and even for something where imperial / standard units are typically expressed in fractions (¼" rain), they convert to integer and lose precision; that's one of the reasons I'm using the Ecowitt service; there was a period of time when WU only returned temperature in integer Celsius which made it pretty much useless.

I think that seals it for the discussion on whether or not to use the same measurement in influxdb; because they use different measurements, we're probably better off using weather and localweather.

[BJReplay]

I'll pull together a pull request for a /weather/contrib/ecowitt version in the next few days.

[BJReplay]

The final piece in this puzzle is ready for testing - I've written a history tool that is ready for a brave tester to test. I'll submit a pull request shortly. It seems to work and I've pulled in history data for my local weather station back to 1 January 2019.

[jasonacox]

Nice work, @BJReplay ! Thanks for sharing this solution with the community. You and @mcbirse are setting the standard for anyone else wanting to extend the project for additional weather or other data feeds! 😁

Thanks! 🙇

[virusuf86]

I am trying to get my Ecowitt data to display.

I initially got data to show up on LocalWeather Server v0.2.2, but it was metric. I updated the ecowitt.conf file to imperial, rebooted, but values were null. I switched it back to metric to keep it consistent with the Powerwall temp reports. The values were still null until I made new Ecowitt API and APP codes. Now, Im back to data showing up in the LocalWeather Server.

I created the powerwall.extend.yml file with the code on the page, but running compose-dash.sh yielded an error since the container Ecowitt already existed when running Step #2 in the quick start instructions. So I deleted it, reran compose-dash.sh, and it worked.

There is still no data showing up on dashboard.json or dashboard-localweather.json. Do I need to edit the Dashboard code or run a setup file?

I tried the Ecowitt Weather History Import Tool, but Im getting this error:

"ERROR: Failed to write to InfluxDB: 400: {"error":"partial write: field type conflict: input field "humidity" on measurement "localweather" is type integer, already exists as type float dropped=5"}"

[jasonacox]

I initially got data to show up on LocalWeather Server v0.2.2, but it was metric.

Did you see any data in the dashboard-localweather.json dashboard before converting to imperial?

[virusuf86]

I did not check. I tried importing it now, but I get these errors:

"Internal Server Error - Check the Grafana server logs for the detailed error message."
"A dashboard or a folder with the same name already exists"
"Dashboard named 'Local Weather' in folder 'General' has the same UID"

The only dashboard I have under General is "Powerwall - Power Flow" (dashboard.json). I even tried renaming, change the UID, and click Import (Overwrite), but it wont save.

Its also weird that even with the errors, Local Weather shows up under General. This dashboard is blank.

[virusuf86]

I think I fixed both issues!!!
Ecowitt writes to field "localweather" into DB, but the Dashboard is looking for "weather". I changed them by going into edit:
Live Monitoring > Energy Usage > items G, H, I
Weather > Temperature, Humidity, and Clouds > all items
Weather > Wind, Pressure, and Precipitation > all items
Hopefully thats all of them.

I also fixed the errors Im getting from ecowitt-weather-history.py:
Lines 530 and 534: Changed "int" to "float" (humidity error)
Lines 553 and 556: Changed "float" to "int" (co2 and pm25 errors)
EDIT: With the changes I made, the errors go back and forth between float and int. I just ended commenting out humidity, co2, and pm25.

[BJReplay]

Lines 530 and 534: Changed "int" to "float" (humidity error)
Lines 553 and 556: Changed "float" to "int" (co2 and pm25 errors)

I ran into some problems with this as well - I'm in a region (Australia) that uses the metric system, but I think there are a couple of issues at play here:

• If you are in a region that uses Fahrenheit, temperature is typically recorded in whole numbers which, if you're loading into existing fields in the DB that started off with Fahrenheit, it may have either been defined as integer, or auto-typed as integer.
• I thought about blowing away history to try to fix these errors, but basically was trying to compromise between using the same fields as the weather411 service so the dashboards didn't need any changes and using an entirely new set of fields.
• I loaded history from the Ecowitt API, but the resolution drops away dramatically as you go back in time, so is less useful if you want to scroll back and look at a particular day - solar information is at reasonable resolution, but historical weather is not.
  In the end, new data was loading, and I wasn't expecting anyone setting this up from scratch to run into issues like I had, because I had been developing and changing the code multiple times trying to get this working.

It looks like you did, however.

I think I can see the logic for the changes for Lines 530 and 534 - I'm guessing that if you measure pressure in inches of mercury, you need float (I'm using hPA, so it is a whole number).

However, I'm less sure about the change on 553 and 556 - can you provide more information on the errors you were getting on CO2 and PM2.5 that were fixed by changing to int? My units are integers - e.g., 460 ppm and 1 μg/m³, but I'm surprised that you're getting an error.

[virusuf86]

CO2 and PM2.5 appear to be whole numbers with units of ppm and µg/m³, respectively.

[virusuf86]

I tried going back to imperial, but again the data returned NONE. It probably doesnt like going between int and float values. I also tried looking for a way to drop/delete localweather from InfluxDB to start from scratch, but failed. Illl just stick to metric and do the conversion on the dashboard with math().

[jasonacox]

I looked at the server.py source and it seems like it is casting float() for temp, which should apply to metric or imperial. I don't have an Ecowitt so I can't test or validate. The import tool will likely need to do the same to get it to work (casting imperial values to floats).

Powerwall-Dashboard/weather/contrib/ecowitt/server.py

Lines 244 to 250 in feadd11

	if "outdoor" in datapayload:
	data = datapayload["outdoor"]
	weather["temperature"] = getvalue(data, 'temperature', 'float')
	weather["feels_like"] = getvalue(data, 'feels_like', 'float')
	weather["app_temp"] = getvalue(data, 'app_temp', 'float')
	weather["dew_point"] = getvalue(data, 'dew_point', 'float')
	weather["humidity"] = getvalue(data, 'humidity', 'float')

[dJOS1475]

Chaps, is there an idiots guide to replacing Weather411 with Ecowitt? I have the ecowitt integration working:

I can happily upload historical data:

But Im missing the final piece of the puzzle - replacing Weather411. I've tried importing the Ecowitt dashboard just to see the data and that throws errors, despite not having this dashboard imported prior, creates a dashboard with no data:

What am I missing?

[dJOS1475]

Hilariously, I rebooted and everything is broken. 🤣 Im downloading 22.04.6 LTS now. 👍

[dJOS1475]

So I just rebuilt my server from scratch on US LTS 22.04 - and I run into the same problem with exactly the same symptoms as before.

One of the things I've noticed with the ecowitt integration, is that there is no mention of configuring a grafana data source like is needed for say pwdusage. Is that an oversight? If I even try to modify and save the refresh settings, it shows a "missing library panels" error, and also shows "Panel plugin not found: undefined".

[dJOS1475]

Btw, another item that isnt mentioned in the doco is if Weather411 should be removed (or not installed to start with) and if ecowitt is a direct substitute for it?

[dJOS1475]

I was able to view today's data from the point I enabled the ecowitt integration by modding the dashboard json in grafana to look at localweather instead of weather as the source. Strangely tho, I could not see any of the historical data I have imported. TBH, I think Im just going to call the ecowitt integration a bust and stick with the Weather411 - it's not super critical that I can see the last 2 years of weather data, but it would have been nice.

Thanks for putting up with my questions. 👍

[BJReplay]

I was able to view today's data from the point I enabled the ecowitt integration by modding the dashboard json in grafana to look at localweather instead of weather as the source.

That makes sense - the localweather integration attemps to use the same measures as the Weather411 integration so they're comparable but wasn't designed as a replacement - it was designed to run alongside - that's why it was designed as a different source.

It's really unclear why you couldn't load the sample dashboard.

I just deleted my dashboard, and then reloaded it from source, and it loaded fine (and displayed data); it seems like there's something funky with your grafana setup for some reason, but anyway, you're up and running and that's the main thing.

[BJReplay]

As the author for ecowitt, I'll have a look and see if I can work it out; that said, it's been a while since I set it up.

The sample dashboard was just that. If you have trouble importing, you can change the Name and the UID as you import.

I don't use the sample or the default; I use a heavily customised dashboard, but I'll have a look at the base dashboard and the sample, and see if I can work out what is missing from the instructions.

Something has probably changed since I wrote the instructions, but the idea was that the replacement would be reasonably straight forward.

[dJOS1475]

@BJReplay thankyou - my dev skills are near zero and I havent been in a technical IT ops role for a long time, so much of this is greek to me.

Btw, the thing with the sample dashboard is weird, it does what the screen-cap shows, even if I delete the "local weather" dashboard and start from zero again.

[BJReplay]

Btw, the thing with the sample dashboard is weird, it does what the screen-cap shows, even if I delete the "local weather" dashboard and start from zero again.

Check all your folders - maybe you're looking in one folder, but it's in another.

[dJOS1475]

I downloaded this file locally, then imported it from my local machine.

[BJReplay]

I downloaded this file locally, then imported it from my local machine.

No, I meant Grafana folders; the Grafana error dialog shows you importing it into the General folder. If the dashboard exists in another folder, you can't import it into a different Grafana folder.

For example, in my case, I have it in the Library folder:

[dJOS1475]

I see what you are saying, but if I delete it:

try again:

I still get this:

and hitting cancel shows a dashboard installed - but it doesnt work:

I even tried creating a new folder and got the same result:

When I installed the other 2 dashboards I have, they didn't throw any errors and worked OOTB.

[BJReplay]

OK, that seems to be more of an issue with Grafana and its handling of the dashboard, than anything else.

Find the json file, edit it, look for the Unique Identifier (it's very close to the bottom), change it to some other value - just change a few letters), save it, and try again.

[BJReplay]

P.S. signing off for tonight, so no more replies until tomorrow, sorry.

[dJOS1475]

No dramas, thanks for helping out. 👍