UDP packet content in the absence of sensor data

[vinceskahan]

I’m working on a new app and had some ‘what UDP does WF emit’ questions…

Question: what UDP does WF emit for the various sensor values if that sensor is failed ?

Example - if the wind sensor fails, what values does WF emit for rapid_wind ?

It normally is:

{
	  "serial_number": "SK-00008453",
	  "type":"rapid_wind",
	  "hub_sn": "HB-00000001",
	  "ob":[1493322445,2.3,128]
	}

If the sensor fails, do you get:
"ob":[timestamp,null,null]

or:
"ob":[timestamp,,]

or
"ob":[timestamp,0,0]

or something even different ?

[sunny]

i don’t know at all but timestamp,0,0 seems unlikely as those could be valid values. I would just flag anything that is not [timestamp,float,float] as an error.

Would it even emit a value for rapid wind, if it fails??

[vinceskahan]

I am asking what the unit ‘does’ not whether it makes any sense or not.

The API specifies the happy path where all sensors report their data but not the exceptions.

I’m asking for what the Hub emits if sensors are failed or not reporting at all (example - in a battery degraded state where the unit starts shedding sensors).

[sunny]

I understand what you are asking, but I’m assuming you want to use it in some program. If the answer would be timestamp,null,null you would check for that and handle it. All I’m suggesting is to test for anything that isn’t timestamp,float,float and you’ll have the same result.

Unless of course it doesn’t report rapid wind at all in case of a failed sensor.

[vinceskahan]

sunny - you can stop responding. Your answer is “I do not know what it does”. Lets move on and hope somebody who ‘does’ know an authoritative answer responds.

[sunny]

[vreihen]

Unsupported fields are usually double commas in packets that I’ve seen, but I have no idea what broken sensors send.

Whatever programming language/library you are using to parse the obs packets may alter the output values, like Python converting double commas into nulls…

[vinceskahan]

yup - I’m just trying to understand the input so I can deal with it. Basically need to see the UDP from any station with any sensor that has failed or that is being skipped due to low battery levels.

For those weewx users out there, I’m writing an extension that will emit WF UDP API compliant UDP so that we can use @peter’s wfpiconsole to display info from a non-WF setup. Have the happy path reasonably usable. Now need to work the sensors missing part.

[btst.online]

I have a couple of Tempests with failed sensors… I’ll grab some Obs packets and send them your way.
–Sam

[btst.online]

Showing zeros for a wind sensor that reports failure:
‘raid_wind’
[1725972443,0.00,0]

But NULL in obs_st:
“obs”:[[1725972400,null,null,null,null,3,1014.53,23.57,92.89,21758,1.98,181,0.000000,0,0,0,2.613,1]]

[vinceskahan]

Much appreciated. The nulls are what I was hoping to see.

If anybody has data from a tempest with sensors were shed due to low battery state that would help too.

Making a lot of progress and have the console running stably vs. an Ecowitt station with my current draft weewx extension, so looking pretty good so far. This screenshot is with the rest interface enabled (for forecast) and UDP for the data.

Re: the display:

• Lack of solar/radiation is because my ecowitt doesn’t have those sensors
• No rain is because it hasn’t rained (might get some this week).
• Trends and hi/lo info is due to known limitations in how Peter gets a few values from websockets only. I might do a little fiddling to see if I can populate those fields since weewx has them natively.

But looking really promising so far. When it gets good enough to release I’ll probably mention it here with a pointer to a more detailed announcement on the weewx-user google group.

If any weewx users have interest in the interim, PM me please…