WS-1001 data direct to WD?

I see whats wrong
there must have been a slight change to the json format
an extra space
I have accounted for that now
use a new .zip update of WD, ready now

Now is working!

I am not sure I have to put the file location on “URL” TextBox, or on “Select raw script data file”, but in any case I have put the same on both and it works. I try to improve a little my program to allow change update time, because now I change program to receive each 15 seconds. The IP Observer sends me another packet when I close the socket, so it receive more than 1 message per second if I don’t limit it!. I will let user to choose this maximun receiving rate.

I also add some parameters that PHP program calculate (but I don’t know if WD needs it!).

If you add this direct receiving Support to the WD, let me and then this program won’t need anymore.

Thanks in advance.

Ruben
PD: I have realized that on “WD title” appear: “Stationless, VWS data.csv”… is this ok? It is taking csv file or json file? (my program is actually generating both)


re the station type across the top of WD
try this:
exit WD
then in the wdisplay.ini settings file
find
[Weather Station Type]

and delete that whole section

then run WD
then select the Wifi pro station
and then select the raw json file your program updates (and make sure its ticked to use the wunderground json format)

WD does have an option to listen on port 80
that is the setting to use direct usb connection
(believe it or not)
you could try ticking that setting in WD and see if that works (and not having to run your program (do the wdisplay.ini reset of the station type settings as above…as a test)

Thanks Brian, I will test all of this, this afternoon.

Meanwhile, a somewhat more refined version of the listening program with some visualization: http://kona2.alc.upv.es/IPObserverRecMFC.zip

Need Visual Studio 2015 redistributables on some machines and works also with XP
Redistributables are here: https://www.microsoft.com/en-US/download/details.aspx?id=53587

Ruben
PD: Maybe the format data that your program is waiting when listen to a port (80 or other) aren’t the same that IP Observer send…

the raw data that arrrives via the simple server listening function I already have in use on port 80 should show under view, debug info

Well, I have made the test…

  • First erase full section [Weather Station Type]
  • Next test on Wifi pro station tab, selecting on WiFi IP server → client,
  • Set “enabled” checkbox, change port to 85 (I have this port on my station)
  • Put local IP (192.168.1.2)
  • View debug info… Nothing, nobody is connecting to this… tell TCP Conection to 192.168.1.2 (but this is not a server… client?)
  • Change IP to 192.168.1.6 (IP of Observer box).
  • View debug info… Same as before, nothing but tell Conection to 192.168.1.6.

Begin again:

  • Erase full [Weather Station Type] section again
  • Tab “WiFi Pro station”
  • Check “Stationless”
  • Check on “WiFi Station” the checkbox “Ambient/Digitech/Aercus…”
  • Leave checked the “Wunderground format” checkbox that is already checked.
  • Click button “Select raw script data file” and select the file that my application IP Observer Receiver is creating.
  • Save - Close All.
  • Run my app.
  • And now is all correctly working (same as before, using my application is all working).
    The side effect is that after erasing the [Weather Station Type], the background of the WD is now black! instead of blue.

Ruben
PD1: You can add the IP Observer Receiver program to WD if you want for other people with this kind of stations.
PD2: I stay tunned if you include this functionality of receiving data directly from IP Observer.

I tested your program on a remote pc I have access to that has one of these stations, but the console version of the station
I had to install the run time libraries
it did not get any data
if I tried changing the port to 80 instead of 85 and clicked on the button next to that, the program closed

Oh!, the button is “Salir”, exit or close program. If you change port, have to restart the program to take effect.

In any case, have the console version also the possibility to change destination IP and port number? (I think that yes modifying the .ini of the console, isn’t it?)

Changing the port is desired, because port 80 maybe occupied by other programs like web server, Skype, etc.

Enviado desde mi Nexus 7 mediante Tapatalk

how do you exit the program to save the port to 80?
there is no windows close button
if i change it to port 80 and then use the exit button , which I thought was a set button, then it starts up with port 85 still

So is this a bug, the port number must be saved with the close button press. I will revise it tomorrow.

Can you change the destination port on server.ini of the console?

not currently as the usb to the console is not currently connected

Updated: Now I have test that closing program save port numbrer. Also translated “Salir” to “Close”.
http://kona2.alc.upv.es/IPObserverRecMFC.zip

You can test the program with any internet navigator. Simply past on URL the same petition that the Weather Station send to WUnderground:

http://computerIPwhereprogramruns:port(or nothing if is 80)/[i]dontcarethis?ID=IPOBSERVERREC&PASSWORD=IPOBSERVERREC&tempf=58.5&humidity=55&dewptf=42.4&windchillf=58.5&winddir=322&windspeedmph=1.12&windgustmph=2.46&rainin=0.00&dailyrainin=0.00&weeklyrainin=0.00&monthlyrainin=0.00&yearlyrainin=0.00&solarradiation=14.70&UV=0&indoortempf=70.7&indoorhumidity=46&baromin=27.48&lowbatt=0&dateutc=2017-3-21%2018:5:26&softwaretype=Weather%20logger%20V2.2.0&action=updateraw&realtime=1&rtfreq=5 HTTP/1.0

There are several things that could do that the above message doesn’t arrive to the program. I write it in the next post, I need some time to explain (local restrictions, firewall, port binded to other program…).

Ruben

There are several things that could do that the above message doesn’t arrive to the program:

  • Local restrictions: Comunicating two aplications on same computer on Windows 10 by network loopack interface are normally restricted by security reasons. Unblocking the apps to allow comunication is not trivial. So if this happens (simply open web browser and put http://127.0.0.1:port/hello), is better to test from other computer on local network (or some mobile connected to same network through WiFi).

  • Firewall. First time execute the program, normally Windows Firewall ask you to block or unblock the program. If you allow, it must be able to receive the packets. But if use other Firewall or block the communications, you have to go to the Firewall settings to allow the program.

  • Port used by other application. Everey port only could be used by one app. When any server application “listen” to a port, no other program could listen too. I recomend to change the port 80 of the HTTP web connections, because this port is commonly used. It can be checked executing on a command prompt this: netstat -a -o. On second column (local address) appear a list of IP:PORT, and normally a “LISTEN” in the state column. If the port is here, it means that is used by the appliction whos PID is shown in last column. So you can check on Task Manager the application, and close it (I attach and image where can see that Skype is listening port 80). Web server is always listening this port.

I will wait for feedback!
I am sure that this method implementing a “simple web server” is useful to capture packets from any Weather Station that sends data directly to WU because it uses always the same protocol. The only restriction is that the Weather Station must allow to change the IP address where it sends the information that would be by default to rtupdate.weatherundergound… (or something like this).

Ruben


I got an error when trying to unzip (mismatch on central size or something)
can you re zip and re upload?

Try it again.
http://kona2.alc.upv.es/IPObserverRecMFC.zip

I have rezip and copied again, but I have tested before and it for me…

Ruben

that one unzipped OK
it does not receive anything on the system I have access to
but I am not surprised, as I could not get any of the methods that WD supports to work with that station anyway(except via access to wunderground data (using own api key)
this station that I have access to has the original firmware that the station comes with…i.e it has not been updated

Maybe the server.ini on station is pointing to rupdate.wunderground.com and not to you WD computer IP. In this case, no packet is sent to your WD computer.

You can test the methods on your WD simulating the packets that the station would send using a internet browser, same as you can test with my program.

Ruben

Enviado desde mi Nexus 7 mediante Tapatalk

ah, yes, I had missed that I needed to update that ini file to point to the pc ip
(I had tried initially having set to point to a web server IP to update the php script file their to create the json file…)
I will need to get the usb connected again…will need to ask

Working without problem from almost one month. I will setup a page with the program and a tutorial to configure WD to work with it. I only need some spare time!

I have also to switch between the production “weather station” yet with 1-wire hardware to the “Aercus” one. Could I copy the entire “Weather Station” section in ini file from one computer to the other leaving the rest ini file untouched?

Ruben

Enviado desde mi Nexus 7 mediante Tapatalk

Hi
good that this solution is working
I have not had the usb re connected on the remote system I did have access too yet