> > > You already lost that argument. > > Don Quijote is my hero since I was a little kid. I'm used to it. :)
> WF is moving in the opposite direction of what you want, toward > 'increasing' need for continuous internet connectivity to the WF servers, > and toward making the UDP messages notionally useless. There have been > many complaints from the original testers in the forums (including me). > Some have voted with their feet and gotten rid of all their WF gear > (including me). My opinion is you can't fix bad hardware with software. > > My guess - WF is very much in the weather forecasting business, and is > focussing their efforts there, more so than somebody like Davis who is in > the 'instrumentation' business. > It makes sense from a certain point of view, but the two things are not in contrast: you can gather all data you want, but users want to receive the raw data from the sensors, knowing it is not "enriched" (and that's a plus for some). > > Re: sensors and UDP.... > > The rain data is 'fixed up' via RainCheck before noon the next day local > time, available only on their servers via the ReST interface. How they > determine how to (badly, for me) 'fix' your rain data is not released to > the consumer. A lot of people just disable RainCheck for their stations to > avoid confusion. My opinion is the haptic sensor is fatally flawed and > they'll come out with a cheap tipping bucket eventually, if EcoWitt doesn't > undercut their price to the point where it's not a good idea to even > compete there. > > In the thread I replied to on their forum, DSJ explicitly said that he was finally convinced of having the same Raincheck enable/disable feature also for Lightning: https://community.weatherflow.com/t/lightning-reports-tempest/6262/133 We'll se if they keep the promise. I replied at the end of that thread. The lightning data is now totally synthetic and crowd-sourced, presented on > their app only via an algorithm that is not released. Your sensed > lightning readings make up 'part' of what they report as lightning for your > station, but the UDP info says only what your sensor saw, which frequently > is nothing even though you're ducking for cover due to lightning nearby. > The lightning sensor is the weakest part of the system, it's very shaky. > Vince, I NEVER received a single evt_strike through UDP, not even during a big storm that lasted for hours during the night, I was monitoring debug log to finally wait for at least 1 event but nothing. Meanwhile I was receiving a lot of lightning notifications on the android app. They say I should see raw data of the sensors through UDP, but that was not the case, I guess I have a faulty station/sensor. > > What they include from where in 'fixing' up your sensor readings is not > released by WF. There is no way to opt out of your data being altered > short of blocking your Hub from connecting to Internet, but at that point > (a) you can't get continuous learning tuning adjustments, (b) you can't get > firmware updates, and (c) it is unclear if a previously-tuned WF station > would even work without connectivity to the WF servers. > > Well, if all raw data of the sensors is sent via UDP, you don't have altered data, but the one coming from the sensors. And that's what I want. To compare it with my other stations (ecowitt and davis). > I don't believe it resets the clock on reboot, mine rebooted all the time > and I never saw odd data in weewx or in the UDP. > > I've always wondered what the Hub does on boot up, other than establishing > essentially a MQTT session to the WF servers. There has to be something > related to setting a system clock in there somewhere under the hood, but > it's never been documented that I recall. > > Definitely worth a test. Block your hub from all Internet access. Power > it down. Power it back up. What does it do ? Does it block startup if it > can't phone home for network time ? What are the timestamps in the UDP > broadcasts ? > > You can also tell if your system has rebooted by looking at uptime in the > UDP broadcasts. See the API docs for where. > Thanks for the suggestions, if it happens again I'll dig into it. > > Re: the UDP monitor program, if you run my UDP listener with the --raw > --decoded options you will see a reasonably nicely formatted output of what > the Hub is emitting. You 'can' run this on the same box as weewx and the > weatherflow UDP driver, but be sure to set 'shared_socket = true' in > weewx.conf so that the driver coexists with other things also listening for > udp/50222 on the same box. > > My listener is at https://github.com/vinceskahan/weatherflow-udp-listener > > Feel free to email offline if you need help with my listener... > I had already bookmarked your listener, in case I needed to debug things. Thank you very much for the support, I'll contact you if needed. :) Alessandro > > On Thursday, October 29, 2020 at 2:17:16 AM UTC+1, vince wrote: > > On Wednesday, October 28, 2020 at 4:11:45 PM UTC-7, Alessandro Del Prete > wrote: >> >> I'll read the exchange, thanks. I'm very interested in this problem, I >> have an ongoing conversation with support because the lightning sensor is >> not sending data via UDP, I just receive events on the app, but via UDP I >> received no evt_strike events. I know there's a specific discussion about >> this lightining issue and the UDP raw data vs enriched API data, and I hope >> they understand that locally, via UDP, we want to see ALL sensors' data, >> it's not acceptable that they decide what I can read from the system and >> what not. >> >> > You already lost that argument. > > [...disclaimer - past WF user for 24 months including being a field tester > of Sky, Solar panel, and Tempest...] > > > WF is moving in the opposite direction of what you want, toward > 'increasing' need for continuous internet connectivity to the WF servers, > and toward making the UDP messages notionally useless. There have been > many complaints from the original testers in the forums (including me). > Some have voted with their feet and gotten rid of all their WF gear > (including me). My opinion is you can't fix bad hardware with software. > > My guess - WF is very much in the weather forecasting business, and is > focussing their efforts there, more so than somebody like Davis who is in > the 'instrumentation' business. > > Re: sensors and UDP.... > > The rain data is 'fixed up' via RainCheck before noon the next day local > time, available only on their servers via the ReST interface. How they > determine how to (badly, for me) 'fix' your rain data is not released to > the consumer. A lot of people just disable RainCheck for their stations to > avoid confusion. My opinion is the haptic sensor is fatally flawed and > they'll come out with a cheap tipping bucket eventually, if EcoWitt doesn't > undercut their price to the point where it's not a good idea to even > compete there. > > The lightning data is now totally synthetic and crowd-sourced, presented > on their app only via an algorithm that is not released. Your sensed > lightning readings make up 'part' of what they report as lightning for your > station, but the UDP info says only what your sensor saw, which frequently > is nothing even though you're ducking for cover due to lightning nearby. > The lightning sensor is the weakest part of the system, it's very shaky. > > What they include from where in 'fixing' up your sensor readings is not > released by WF. There is no way to opt out of your data being altered > short of blocking your Hub from connecting to Internet, but at that point > (a) you can't get continuous learning tuning adjustments, (b) you can't get > firmware updates, and (c) it is unclear if a previously-tuned WF station > would even work without connectivity to the WF servers. > > > >> PS: I asked WF support also about the timestamp issue, if there's a >> possibility that the Tempest sends epoch time zero on reboot or in any >> other case. >> >> > I don't believe it resets the clock on reboot, mine rebooted all the time > and I never saw odd data in weewx or in the UDP. > > I've always wondered what the Hub does on boot up, other than establishing > essentially a MQTT session to the WF servers. There has to be something > related to setting a system clock in there somewhere under the hood, but > it's never been documented that I recall. > > Definitely worth a test. Block your hub from all Internet access. Power > it down. Power it back up. What does it do ? Does it block startup if it > can't phone home for network time ? What are the timestamps in the UDP > broadcasts ? > > You can also tell if your system has rebooted by looking at uptime in the > UDP broadcasts. See the API docs for where. > > Re: the UDP monitor program, if you run my UDP listener with the --raw > --decoded options you will see a reasonably nicely formatted output of what > the Hub is emitting. You 'can' run this on the same box as weewx and the > weatherflow UDP driver, but be sure to set 'shared_socket = true' in > weewx.conf so that the driver coexists with other things also listening for > udp/50222 on the same box. > > My listener is at https://github.com/vinceskahan/weatherflow-udp-listener > > Feel free to email offline if you need help with my listener... > -- You received this message because you are subscribed to the Google Groups "weewx-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8b0733cc-59bc-46db-a5af-fd47e8f99d1do%40googlegroups.com.
