Sometime around 6:30 AM yesterday, my WD stopped pulling data from my Meteohub, which is on my local network. What is strange is that now, I see the cronmeteohub icon in the system tray, but that status window looks to me like it is trying to pull files that exist on Meteoplug, not Meteohub – the error shown is "
The requested URL ‘/cgi-bin/livedataxml.cgi’ was not found on this server."
I backup my data nightly from the Meteohub, and originally had this running on a Raspberry Pi – but just to rule out any problems with that, this afternoon with troubleshooting to rule out a bad RPI or card, I migrated my license and data from the RPI to a Vmware VM and a fresh install. There is no such livedataxml.cgi file on a fresh install either, so I’m not sure what WD is attempting to access.
In WD, I have the IP address of the Meteohub entered in “Com Port Setup”, “TCP/IP Connection to Davis/Meteohub/Meteobridge”, Port 80. I have the box checked for “Use with Meteohub”. The update rate is set to 10. The box for “Meteobridge in use” is UNCHECKED, as is the box for “Nano in use”. Station type is set to “Stationless”
If I start WD, it acts like it is receiving data. Data received is blinking green and the count increases. But the data itself has not changed since 6:22 yesterday morning or so.
I am running WD 10.37S140. I applied the latest .zip update this morning in an attempt to troubleshoot, but that didnt fix anything. For now, my website is down since WD is what uploads my data.
Just an update… If I do the steps for forcing the data to download missed data by using Control Panel, Data Logger and setting it ahead and then editing the 52022lg.txt file to delete after that point, WD upon restart will only download the first minute of data from Meteohub. Subsequent restarts of WD will continue to download that same one minute each time.
This is what the Meteohub HTTP server log shows… Notice it shows the initial one minute of data with the correct address for a Meteohub, but then it just continues sending requests as if it is a MeteoBRIDGE after that (I deleted the additional lines, but it just continues with that):
Yes, of course… That was one of the first things I did… As I mentioned in the initial post - to ensure it wasnt a hardware issue with the RPI, I migrated the entire platform and data over to a VM and took the RPI offline. The VM is now configured with the same IP that the RPI was using. All of the logger data is there – that is, I can use the Meteohub logging protocol to view the data in XML format – its all there, and it is responding to my HTTP requests properly… But as I said before – for whatever reason, Weather Display is only making the initial first minute download since the last shutdown using Meteohub HTTP data logging protocol – and then switches over to the protocol used on the Meteobridge – which of course does not work.
Do you know why WD would be using Meteobridge data protocol when “Use with Meteohub” is checked? Look at the attached log – those are all requests generated by Weather Display to the Meteohub – and livedataxml.cgi is what the MetoBRIDGE uses, not what MeteoHUB uses.
Just so you know – 10.68.1.3 is my PC with WD. These requests are every 10 seconds, which is what I have the data interval set in WD for the Meteohub. And the 404 error is returned because - that files doesnt exist on a Meteohub, so again - not sure why WD is looking for it.
So, after unzipping to the folder - on startup, it still only pulls one minute from the Meteohub from early morning 5/22 (the date I had set in the Data Logger screen to start retrieving data from) – and then stops. Now, the Cron Meteohub window shows errors every 10 seconds – and no requests are making it to the Meteohub from it. However, if I enter the URL it is complaining about in the browser, I get data.
In the Cron Meteohub window, it now repeatedly says Error Invalid URL: “10.68.1.15:80/meteolog.cgi?mode=data&type=xml”
In the browser, entering 10.68.1.15:80/meteolog.cgi?mode=data&type=xml pulls data:
Also I had been using a version from Jan 2020 for a very long time. Around 2 weeks ago, I updated to the latest version that was available then. And then this evening I downloaded the latest again.
No, thats not what is happening. With the original version, I see your requests in Wireshark coming from the PC to the Meteohub… They look like this with the bundled version:
GET /cgi-bin/livedataxml.cgi HTTP/1.1
Connection: Keep-Alive
User-Agent: Embarcadero URI Client/1.0
Host: 10.68.1.15
HTTP/1.1 404 Not Found
Server: thttpd/2.25b 29dec2003
Content-Type: text/html; charset=iso-8859-1
Date: Tue, 24 May 2022 10:52:39 GMT
Last-Modified: Tue, 24 May 2022 10:52:39 GMT
Accept-Ranges: bytes
Connection: close
Cache-Control: no-cache,no-store
But for the version you attached above – there is no traffic request for the Meteohub leaving the PC (and I also dont see any hint of the requests in the Meteohub’s HTTP request logs)
Those errors look like an error with the syntax of the requests.
Anyway – the main issue here is that in the WD startup routine, prior to the separate cronmeteohub.exe application, WD would loop through the queries to the Meteohub to catch missing data since the last time WD was shutdown – that is the part that is not happening at startup – instead, it is only pulling the first minute and not repeating until the current time. In Wireshark with the original version of cronmeteohub.exe, I do see the request properly as well as its response – but the data extraction window in WD closes after this first minute and then reverts to that other incorrect URL after the data extraction window closes
Im also guessing that these two processes are different based on the different User-Agent – IPWorks HTTP Component - www.nsoftware.com seems to be what was WD’s internal mechanism for querying the Meteohub, while Embarcadero URI Client/1.0 seems to be what is embedded in cronmeteohub.exe:
re cronmeteohub.exe
are you sure you have using the new update to correct the wrong format? (and so to get live data)
it should say vers 1.1 along the top
re the history data, I will investigate, its likely I broke some code there when working on meteobridge code
Yes, I’m sure… Look at my screenshot – you can see the 1.1.
The pasted text is from the older version – because thats the only one that is transmitting outside of the PC. The 1.1 version is creating an error and not creating any network traffic.
Not sure what to do at this point. My website has been down now since the 22nd… I may just have to bite the bullet and restore my backup from 3 weeks ago, but thats going to take forever to catch back up with the data.
That is what it is requesting – but thats the file for a Meteobridge, not a Meteohub – which is why it doesnt find it. I have a Meteohub (and the box is checked for a Meteohub)
I have no doubt that it gets data from a Meteobridge – but its a different device, and different protocol. But I’m confused why you call it cronmeteohub – if its for accessing a Meteobridge?
The version I upgraded from was from 1/4/2020 – and the version details of WeatherDisplay.exe show Version 1.40.0.0 – and meteohub support was working fine.
it works the same way, getting live data from meteohub or meteobridge, same protocol
what windows version are you using? -< this is important
that is a big upgrade from 2 years ago, it would have been prudent to have backed up the version you have now
the file version right click i dont update so just ignore that
there is also build 120 from dec 2020 on the WD download page
The version I upgraded from was from 1/4/2020
-< that was important info..originally WD would get the live data but then I split it out to a separate cron program
but that program uses a http protocol that is only compatible with more later windows versions
Alright, you’re mistaken – but that’s OK… Its not the same protocol. Only Meteobridge uses livedataxml.cgi (for XML format), and livedata.cgi (for plain text). The Meteohub uses their HTTP data logging protocol - which is detailed at https://www.meteohub.de/files/HTTP-Data-Logging-Protocol-v1.2.pdf
Meteobridge is going to use livedataxml.cgi, while Meteohub is going to be using meteolog.cgi
The Meteohub platform flat out does not have the file you are referencing
And as I mentioned – I DO have everything backed up – going back 6 weeks… I can restore back to that point in time – and at this point - thats clearly the best idea… What a mess.
