Using the new PWS API v2 - but nothing shows up on Windy
-
@marekd The list of problems since I switched to API v2 is "endless".
Now I get another problem this morning. I am reporting as I have done for a week or more now. Suddenly your server rejecs my ts-timestamp as being in the future as seen here:
2026-01-26 09:31:08 : Windy URL: https://stations.windy.com/api/v2/observation/update?id=EWtLHK4&ts=1769416250&temp=15.7&dewpoint=13.3&humidity=86&wind=3.9&gust=8.9&winddir=138&pressure=101497&precip=0.0&uv=1.0&solarradiation=299&softwaretype=WLL2Windy_3.0.2.406
2026-01-26 09:31:08 : Windy Error: BadRequest - {"message":["ts must not be in the future"],"error":"Bad Request","statusCode":400}We can see that reporting time is 2026-01-26 09:31:08 and the ts-value is 1769416250. I have decoded this value and it is this timestamp: 2026-01-26 09:30:50. That is NOT in the future.
Where are we now? I see my 3 stations as offline, my reported data does not show up on windy.com and now I also get ts-errors. Finally a new station I created 2-3 days ago also shows offline. Should I stop reporting or switch back to API v1 until all problems have been fixed? I am ready to help you if you want.
-
@Rolandoz Thank you for the logs, they helped us a lot. The issue is fixed now. Thanks again. You have almost developed our new API thanks to your feedback and technical knowledge 🙂
It was confusing because we have 68 other stations reporting via the new API and they work without any problems. However, those stations do not report the
tsproperty. We expect this property to be in seconds, but our systems were treating it as milliseconds. In a previous deployment, this property was skipped. When we fixed the handling of this property, we accidentally broke it for you. Sorry about that.We hope no further development will be needed and that everything is stable now. Thank you again. Your feedback is very valuable to us and we are glad you tested this API with us. And of course, sorry for all the complications we caused.
Regarding the online or offline status on stations.windy.com, toggling it likely distracted you from the real issue. We recently changed the threshold for showing a station as online or offline from hours to two days. Sorry about that. We will probably switch it back to hours.
-
@marekd The only reason I am sending the ts value is that I read data from Davis WeatherLink cloud API and I dont know how old they are. My WeatherLink devices (I have one on each location) reports to WeatherLink cloud and from that I get "the current values". If they have some delay, these values could theorecially be very old. So I decided it is best I tell you the timestamp of the data and thereby "how old is the milk". ;-) If you want I can remove the ts-parameter. But my log shows that data is normally 45-60 seconds old when I report it to you and that is good, right? Yes, to ts - it is Unix seconds (not milliseconds) since 1970, so just one long integer value.
I see all my 3 stations (the new Hillerød Vejr and the two others) are online again. I agree with you that a 1-2-3 hours without data should say "offline", but several days is all too long.
I can also confirm that my station with the NEW ID is showing again since 9:55 this morning, so it is fine now.
If you dont want the ts parameter I will recommend you remove it from API documentation to avoid confusion about it. Until further I will let it stay in the URL. Let us see what happens.
-
@marekd I have a suggestion for the My Stations page. As shown here, there is free space right to the Status column. Maybe you could insert a "Last updated" column and show, for each station, the timestamp of the latest valid data you have received from the station, fx 26-01-2026 17:05:24.
In that way station owner can quickly see if data is very delayed etc.
-
@rolandoz Thank you for the confirmation. Do not remove the ts parameter, it makes your data more precise. That was our fault. It is impossible to test all possible cases during development, there are always production bugs. You were (un)lucky to be the first one who migrated to the new API. Luckily for us, you were extremely helpful. Thank you again.
Your idea regarding the last observation is great, we will add that feature.
-
@marekd Thanks for your nice comments and feedback.
Yesterday I decided to delete my old stations that reported under API v2 and create new stations. I was surprised that my old station ids were reused and now, because I created them in a new order, the ids were mixed so fx. Paradise Residence got the old Helligsø Drag id. That was not so good as I really wanted to get rid of them including their old data. Then I created a total of 6 ids - the 3 old + 3 new and that gave me complete new ids for my stations. Now there is only left to ask you to 100% remove my old ids and their data from your system. The ids we talk about are these:
It has been a pleasure to help improve Windy. :-)
Maybe you can write in the documentation not only about parameter names and what values you expect but also how they are used later on in app and website. Fx. I expected solar radiation to be shown on the website (and in the app) but as I understand you dont use it. So in my mind "why should I send it to you if you dont use it?".
-
@marekd I think I understand why my PWS station was not showing up anymore since yesterday morning. I switched to API V2 and my ts was in (ms) as it was working in v1 before.I just put it in seconds right now and it's working.
-
@Rolandoz Regarding reusing station IDs: we are aware of the issue, but there is nothing we can do about it right now. To be honest, there is a fix, but it is not worth the effort. This can be easily resolved once the old API v1 is fully terminated.
The root cause is a poor decision in the old implementation: the station ID contains the userId combined with the station index. We removed this in the new implementation, but it must be kept for backward compatibility. As a result, when you remove a station and create a new one, the ID is composed of your userId and the first available station index. After API v1 is dropped, this will be removed and the ID will be randomly generated.
Sorry about that, but we are not going to change it at the moment. It is quite an edge case, and hopefully you will not need to create stations anymore. And it will be fixed at the end of 2026.
-
@neronde Thanks for the feedback. Just to be sure, I have improved the error message to: "ts must not be in the future. Ensure the provided value is in seconds, not milliseconds."
-
@marekd Good answer. I saw it when I started on API v2 but did not give it much attention. :-)
