please explain more —
There is a new version of WD from about 6 hours ago that says it has Tempest improvements.
I just installed this new version with cronweatherflow 8.7. I am set to use exclusive (no web socket) and it appears to update once a minute. Hope this fixes problems some have been having with Tempest data.
Add: Here’s a screen cap of my current setup:
Well - I had to go an f*** with things…and I screwed it up. I installed the newest version over my old one, and now cron doesn’t retrieve data again. Back to ground zero. But - at least I know that the data is retrievable, since the web-update-thing you showed above (and which I thought might have been the catalyst to solving my problems) still gets data. However, Cron 8.7 does not. Oh well, at least I have been mostly disappointed, with a small bit of elation yesterday, so being back to disappointed is normal for this software, for me.
And to add, I’ve also re-tried Cron 8.5 and 8.6. Nothing there. The web-site data is still pulling from my station happily, but cronweatherflow refuses to. Bummer.
Also - if anyone knows Brian, I’d be happy to work with him on this issue, but he doesn’t answer my email.
A note to me from Brian:
re rain.,.,.it now uses the web socket data (cloud rain)
so dont have ticked to use udp only
8.7 is working perfectly here as far as I can tell. Still waiting to get some rain this evening…
That’s awesome that it’s working…I’m betting it’s working for a LOT of folks (otherwise they’d be here like me 
Still not working for me. Here’s the URL of the swd.weatherflow website that is pulling the correct data from my station…as recently as just now. But CRON can’t seem to get this data into itself. And since I have no idea how all that works…I just have to be disappointed.
swd.weatherflow.com/swd/rest/observations/station/107169?token=aa57a411-de93-4f79-9f21-83da8628b794
Sorry to hear you’re still having issues. Only suggestion I have is try re-installing the full exe of the latest build of WD. Shutdown WD, reboot your computer before doing the install. It’s possible something was not completely halted before the install started.
Thanks. Tried that, still same situation. I emailed Brian with a detailed request for help. I’ll see if he responds.
Ok. If you get a chance can you upload a current screen grab of your cronweatherflow screen?
Here it is. I highlighted the two check boxes because I’ve tried all thee combinations of these checkboxes without any difference:
From Brian:
re rain.,.,.it now uses the web socket data (cloud rain)
so dont have ticked to use udp only
Suggest you untick the “Use Exclusively (no web Socket)”, then shutdown WD completely and restart.
What happens if you untick both boxes then hit the “Reset UDP” button? Note that updates are slow, maybe 1 per minute, so be sure to give it some time to collect your data.
Is your station marked “Share Publicly” in the Tempest app?
Another WD update in the last hour or so. Talks about further mods to cronweatherflow which allows rain data to be obtained correctly.
Thanks Dan. I have tried all 4 ways (none checked, one checked, the other checked, all checked) without any difference. When I hit the “Reset UDP” option, usually nothing happens. Sometimes, it re-checks the Network Authorization Firewall access (the Microsoft warning thing) but usually it doesn’t.
My station is definitely marked as “Share Publicly”…remember, it all used to work for about 6 straight days until it no longer did…with nothing changing on my part.
I’ve let the Cron sit for minutes at a time with each check-box iteration multiple times. Nothing changes.
And thanks for the WD update alert, Chris. Seems that the actual Cronweatherflow.exe didn’t change…it’s still dated June 28th, and the version is still 8.7. Didn’t fix anything for me, fwiw.
That sounds odd. Usually once you tell the firewall that your computer and another device are allowed to talk then you don’t need to do it again. Are you sure the firewall settings are correct?
Meh - I wouldn’t focus on that. I think one time the Windows Security window popped up. Most times hitting the “Reset UDP” does nothing. Here’s the Firewall setting for all the Crons that have been loaded over the past 3 weeks:
And another point (reiterating an earlier point, but it’s lost in the noise):
I can put in ANY other Tempest WX Station ID, and Cron pulls the data perfectly…almost immediately when I change it. So far, it’s just my Station ID.
Okay - once again I’m preplexed, confused, frustrated. Just now, in replying to Chris, I put in another Station ID just to “prove” to myself before I posted the above message that it would work with any other Station ID. Of course, it did. Then I put mine back in - and (once again, though it’s far from consistent), the Cronweatherflow started pulling my data in. ??? I just don’t get the inconsistencies. Now I don’t want to touch my computer for fear it’ll stop.
I’m not a Tempest user and have never used Weatherflow so I’m not an expert. I just see stuff on the forum and interpret it (and possibly misinterpret it sometimes) based on my knowledge of other stations (and systems in my long lifetime of working in IT and IT Security).
Based on what I think I’ve read over the years I think Weatherflow has two ways to get data…
- From the cloud. I would assume this is probably http/tcp access across your LAN and then the Internet to a location on the Weatherflow cloud service.
- Directly from your station. I think this uses a UDP connection of some sort across you LAN with no Internet connection used/needed.
If I’m right then the two methods are very different.
In the first case, your computer is essentially accessing a web site. LANs, routers and internet connections are usually automatically configured to pretty much allow any internal device that wants external http access to get to the outside world and get data back. So WD (actually cronweatherflow) is pretty much guaranteed access to the cloud data - after you’ve told the Windows security system that cronweatherflow is a friendly app. Note the traffic flow is internal device → router → internet and back again.
In the second case the system uses UDP which is a ‘no guaranteed delivery protocol’. Fire and forget is another way to look at it…if the data gets through that’s great but it’s not used where it’s essential and provable that data gets to the destination. There’s also another difference with the second case, the traffic routing. It’s internal device 1 → router → internal device 2 and back again. This kind of connection isn’t always automatic. Depending on your router it may be blocked, e.g. WiFi isolation may be turned on to deliberately isolate devices on your network because in many cases internal devices don’t need to talk to other internal devices. Indeed, WiFi Isolation exists to try to prevent LAN devices on your network from spreading viruses between themselves, or prevent alien devices or alien software on one device from hacking into other LAN devices to steal data.
So whereas (1) is pretty much a guaranteed connection (2) is less so, and being UDP no software can complain about missing packets of data because that’s how UDP works.
It may be that your router firewall (as opposed to you PC firewall) is blocking all UDP traffic or perhaps just internal to internal UDP traffic. I seem to recall hearing of someone using a particular ISP WAN connection that didn’t allow certain types of traffic to run over it (not 100% sure if it was UDP but I think it was) so blocking UDP isn’t unknown.
I also suspect that your Tempest device might transmit data to the cloud using UDP so if you have something blocking UDP then your data might not be getting into the cloud which is perhaps why you can’t download it using the cloud data connection option (1).
I may be way off mark here and if I am then I’ll shut up after this because I won’t be able to add anything further to the discussion.