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/9cab6980-bc65-4481-92b7-0482e199705ao%40googlegroups.com.

Reply via email to