Topic: Reading data locally from WLL

[kobuki]

but its not known what triggers that UDP data to start up sending

At the expense of embarrassment repeating myself, did someone try the following with an ISS connected to the WLL? So far we only see an attempt without. The wording of the error message in the first post would imply that with at least an ISS connected, it would start the UDP stream.

Try pulling the URL: http://ip-of-wll/v1/real_time via browser or any other tool, with app not running but transmitters (ISS, ATK, etc) running.

[johnd]

Mine's in the office - won't be back there until Tuesday now. Mayday holiday on Monday

[miraculon]

@miraculon: Looks like you have
on TX #2 a wind plus solar station
on TX #3 a temp/hum plus rain station
on TX #4 a wind plus UV and solar station
on TX #5 a ISS with UV and solar
on TX #6 a temp/hum plus rain station
on TX #7 a temp station

Is that right? Existing data does not seem to match available Davis stations types perfectly.
Station identifier (telling what kind of station it is) seems not to be in the data. May be the user has to define that within the SW and SW just grabs the data pieces from JSON that make sense to the selected sensor type... still guessing

on TX #2 a wind plus solar station ACTUAL: wind station only
on TX #3 a temp/hum plus rain station CORRECT
on TX #4 a wind plus UV and solar station ACTUAL: wind w/ temp
on TX #5 a ISS with UV and solar CORRECT
on TX #6 a temp/hum plus rain station ACTUAL: temp and rain (no hum) (this is primarily a rain station with a buried temp probe for soil temp)
on TX #7 a temp station CORRECT

Greg H.

[johnd]

Almost certainly an obvious point, but there wouldn't necessarily be a reading for every sensor connected to a transmitter in every message (at least not unless Davis have changed their general approach). The update rate from transmitters can't have changed, so eg a new solar/UV reading might be expected only every 50-60 seconds.

[docbee]

I think the WLL logs the data from sensors coming in an internal generic structure that is the same for all sensors, but just some of the fields are filled/relevant depending on the data the sensor provides. Request for current conditions just returns these internal structures for all transmitters in JSON format. Therefore, when you know it is a UV sensor just updating every 50 seconds, then asking for the record every 10 seconds is not wrong, but you simply should expect to get unchanged data reported a lot. When looking for wind speed, things are different. But we still have to prove, if this assumption of mine is right. 

I also think that the records for itself do not tell which type of sensor it is. Some evidence can be taken from which sensor data is returned as "null", but as Greg replied my guesses are not completely right and I doubt there is a perfect guessing schema. Therefore, I will implement a feature in Meteobridge, where the user has to define per transmitter, which kind of sensor is connected. I think it is a severe design flaw with Davis sensors from the beginning, that those don't identify which kind they are. May be it makes life more easy for production (can use the ISS modules with all the other sensor types) but it adds a lot of confusion and manual hassle to get things sorted out. In general it is simply stupid to let the user tell the system that this is a pure wind sensor instead of the wind sensor telling this within its payload data. But I stop here listing what Davis engineers are not doing right on a conceptual level... would be a rather long list

[johnd]

I think the WLL logs the data from sensors coming in an internal generic structure that is the same for all sensors, but just some of the fields are filled/relevant depending on the data the sensor provides. Request for current conditions just returns these internal structures for all transmitters in JSON format.

Agreed that would be logical (Captain!) but it's not what seems to be happening, at least as I read Greg's post.

So his Tx #2 message did not contain solar data apparently. So either solar is not included in every #2 message or maybe it is only included if there is a different value from the previous reading? But maybe I've misunderstood Greg's post.

[kobuki]

The inconsistency can be a bug in the current JSON API. This might be a reason the docs aren't published yet. I think it's worth waiting for the yet undocumented API to stabilize before jumping to conclusions, though knowing it to an extent can help developing support for beta drivers where only these issues need to  be addressed later.

[johnd]

This might be a reason the docs aren't published yet.

That's my reading of the situation too FWIW.

If I had to guess, I suspect that Davis is no different to any other company with a new product about to launch, ie there's a little tension between the commercial side of the business who want it launched just as soon as it's a stable, credible product (and initial signs are that WLL is behaving at wl.com fully as designed) and the development team who'd prefer to see all the i's dotted and t's crossed before launch.

What this probably comes down to in practice is that stable performance of the product in its primary role is given maximum development priority while add-on features like a solid and properly documented API suitable for use by 3rd parties, repeater compatibility etc need to wait a few months before development is signed off and a firmware update is released. (Incidentally, one WLL feature I've not been able to spot so far anywhere is an indication of what the current firmware revision might be. Maybe there is an as yet hidden web interface that reveals such details?)

[miraculon]

I thought that some screenshots might help. The sensor configuration "Edit" screens have checkboxes for each type of sensor.

I am attaching the main config and the 3 individual edit screens for #2, #4 and #6.

EDIT: I have a temp sensor attached to #4, but didn't select it for WLL. (I use it for meteohub)

Greg H.

[johnd]

I thought that some screenshots might help.

Ah, OK, sorry that's probably my fault for confusing things. I was interpreting your 'ACTUAL' as the data content in the message, whereas you were referring to actual sensor configuration. That makes more sense. So the #5 message might be of more interest.

[docbee]

I couldn't resist to make a first experimental port to Meteobridge. So Meteobridge users can give it a try and report bugs back to me. As I only have an early US WLL to test with and no sensors sending on US frequencies here in Germany, I need support from the Meteobridge user base.

I tested with Gregs data.

This is how I did setup the transmitters in Meteobridge:

 [ You are not allowed to view attachments ]

And this is the reported data:

 [ You are not allowed to view attachments ]

Test version is released, so any Meteobridge user with a WLL can give it a test drive.
 

[kobuki]

The WLL allows arbitrary (almost) conbimations of sensors, will you implement that later?

[docbee]

currently it is restricted to these combinations:

 [ You are not allowed to view attachments ]

[kobuki]

currently it is restricted to these combinations:

 [ You are not allowed to view attachments ]

I'm aware, that's why I asked "later"...

[docbee]

yes, if a real need occurs. I try to keep it simple to address 95% of the situations first. Does Davis allow to configure the transmitters apart from their standard setups and do they make use of that in weather link? Anyway, I am happy that we got that far over a single weekend.   

BTW: Leaf/Soil stuff is not supported yet. I will need a user to send me example data how this looks like in the JSON. I guess that will be in the so far not spotted "data_structure_type" #2. Anybody out there using this with an WLL? If so, could you please sniff some data for us?

[miraculon]

docbee,

I decided to give it a try. The indoor temperature is too low. (is it using the offset for the internal PRO sensors?)

Indoor   29 sec   -4.1°C 46% 1011.2hPa (989.3hPa)   24.6°F 46% 29.86inHg (29.21inHg)

Baro and Outdoor sensors look OK. I am not sure which wind set is in use, but for a brief test it will be OK.

I'll run it as a test for a couple of hours, but then I am going to switch back to the normal configuration with the internal RED receiver.

Greg H.

[johnd]

Does Davis allow to configure the transmitters apart from their standard setups and do they make use of that in weather link?

Not 100% sure what the question is, but if you mean: Can WLL receive the same fully arbitrary mix of transmitters as an Envoy8X then there's every indication that the answer is yes. Until someone sets up 8 separate ISS units simultaneously then I guess we can't be absolutely sure  that the maximum can be reached but it can certainly receive all data from two separate ISS units, which a standard VP2 obviously cannot do.

And weatherlink.com can show all of that data. This isn't surprising since it's effectively what an EM station does routinely at wl.com.

[docbee]

Indoor   29 sec   -4.1°C 46% 1011.2hPa (989.3hPa)   24.6°F 46% 29.86inHg (29.21inHg)
Baro and Outdoor sensors look OK. I am not sure which wind set is in use, but for a brief test it will be OK.

Yes, indoor temp correction gets applied, so you will need to remove that if using the WLL.

[waiukuweather]

just to say great work docbee and thanks for sharing

[johnd]

Try pulling the URL: http://ip-of-wll/v1/real_time via browser or any other tool, with app not running but transmitters (ISS, ATK, etc) running.

Just seems to return the default JSON error string and nothing more I'm afraid.

[waiukuweather]

calling the real_time
does return info about the broadcast port

but has anyone then got an UDP data captured on that port?

[kobuki]

calling the real_time
does return info about the broadcast port

Could you please paste the full output? (Please use the # icon to use code tags.)

[waiukuweather]

{"data":{"broadcast_port":22222,"duration":1200},"error":null}

is what I got with the help from a tester
which has already been reported earlier in this thread
that is the same port that the IP data logger normally uses
listening in for UDP packets on that port..nothing

[kobuki]

{"data":{"broadcast_port":22222,"duration":1200},"error":null}

listening in for UDP packets on that port..nothing

Hmm, it's actually quite promising. This is not an error message (see "error":null), but looks like a confirmation message about enabling the broadcast message stream for 1200 seconds (I assume seconds). You need to listen to broadcast messages, not messages directed to your IP. Usually you listen on the wildcard address (0.0.0.0) and a specific port (in this case port 22222) to receive UDP broadcasts. When you receive one you can check the source IP address to see if the packet is one you're interested in.

[waiukuweather]

oh, I just realised have done my code wrong...will try again