Author Topic: WiFiLogger - Connect your Davis console directly to the Internet via WiFi  (Read 109347 times)

0 Members and 1 Guest are viewing this topic.

Offline WheatonRon

  • Forecaster
  • *****
  • Posts: 1237
    • WUnderground
For what it is worth, I have two VP2 consoles side by side. Both are on AC power, one has the new WiFiLogger the other has a “green-dot” USB Davis logger. Both consoles report the same inside temperature, which is about 4 to 5 degrees warmer than reality. The console that has the WiFilogger has the SHT31 whereas the console that has the Davis logger is 10 years old and does not. Draw your own conclusions but since I don’t rely on the consoles to give me inside temperatures, I really don’t care. Others may have different thoughts.
« Last Edit: June 16, 2018, 04:19:44 PM by WheatonRon »
Davis VP2 with SHT31 (3 complete VP2 systems—2 with a daytime fan and 1 that has a 24 hour fan); CWOP--CW5020, FW3075 and FW4350; WU--KILWHEAT17, KILWHEAT36 and KILWHEAT39; WeatherCloud.net; CoCoRaHS--IL-DP-132; and Weatherlink 2.0

Offline dport

  • Senior Contributor
  • ****
  • Posts: 203
For what it is worth, I have two VP2 consoles side by side. Both are on AC power, one has the new WiFiLogger the other has the “green-dot” USB Davis logger. Both consoles report the same inside temperature, which is about 4 to 5 degrees warmer than reality. The console that has the WiFilogger has the SHT31 whereas the console that has the Davis logger is 10 years old and does not. Draw your own conclusions but since I don’t rely on the consoles to give me inside temperatures, I really don’t care. Others may have different thoughts.

^^This^^.  I would never rely on a console of any weather station to give me inside data.  I have two nest thermostats for that.  Each nest has 12 temp sensors in and around the unit to give the most accurate temp possible.

Note, totally respect if you expect the davis console to give more accurate indoor readings though.

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
@WiFiLogger: Isn't there a 3rd mode where the WFL automatically pauses eg. minutely to allow 3rd party software to access the console? This is actually the recommendation by Davis for 3rd party SW. In these pauses it becomes possible to read/catch up archive data.

Not yet, will be done, but I don believe that it will be work perfectly. With automatic pausing function new problems will occur.

On another note, I think it would be beneficial to everyone to make the FW update process completely seamless and automated. No phases, distinction is not necessary between static HTML data and FW blob, etc., from a user perspective. Leaving the possibility for uploading individual static files is a good idea as it's possible to customise the web layout, but I think it's better to hide these details from those who don't care. A smartphone app would be ideal, but obviously it's another development investment, both in time and money.

I have tried with two files update. That was disaster. One WiFiLogger stopped working. Now it's robust, but less convenient.
Web browser doesn't support such possibility to make those files upload automatically.
Yes smartphone app would help, but I am not familiar with this technology.
All I have done was to make this update easy. It is, but need some time and looks less professional than other system on market. I hope there will be a solution for that in the near future.

Offline medic29

  • Weather Watcher
  • Member
  • *
  • Posts: 10
This is a problem with all loggers except the original serial one. The subject has been beaten to death for the USB logger (for which it tends to cause the most trouble) in numerous other threads.

I apologize...I am new to this forum and didn't realize the subject had been beaten to death in other threads.  I had the "Belfry sp?" logger prior to this one and it didn't raise the temp any.

Since this apparently an expected issue, I'm not concerned.  Thanks for the information.
Rick

Offline Mattk

  • Forecaster
  • *****
  • Posts: 2135
I believe that I am correct in saying that the Envoy allows the plugging in only of an external temperature sensor. Measuring indoor humidity remains a problem. Your argument about the problems presented by the design of the VP2 console is a bit circular, since Davis were responsible for that design and could, presumably, have allowed for the possibility of an external sensor.

Just to clarify that, the so called "External temperature sensor" than can be plugged directly into the Envoy when plugged becomes a replacement for the Internal on board sensor and is reported as Internal temp so effectively even though one might call it an external sensor it is actually being reported as the Internal temperature. A Temp/Humidity sensor plugged directly to the Envoy simply does not work and blows the temp way out (on the temp side only but does not affect the internal humidity) but then there is no real issue with the Humidity anyway.       

Offline pfletch101

  • Forecaster
  • *****
  • Posts: 329
    • Personal Website
I believe that I am correct in saying that the Envoy allows the plugging in only of an external temperature sensor. Measuring indoor humidity remains a problem. Your argument about the problems presented by the design of the VP2 console is a bit circular, since Davis were responsible for that design and could, presumably, have allowed for the possibility of an external sensor.

Just to clarify that, the so called "External temperature sensor" than can be plugged directly into the Envoy when plugged becomes a replacement for the Internal on board sensor and is reported as Internal temp so effectively even though one might call it an external sensor it is actually being reported as the Internal temperature. A Temp/Humidity sensor plugged directly to the Envoy simply does not work and blows the temp way out (on the temp side only but does not affect the internal humidity) but then there is no real issue with the Humidity anyway.     

Because of the way Temperature/Humidity sensors work, a temperature error (due to the sensor being 'heated') leads to a humidity reading error as well, even if the sensor is otherwise working perfectly. I assume that even if an external temp sensor is plugged in, the Envoy's humidity reading is influenced by the temperature that the internal sensor is seeing (and would be reporting if the external sensor were not plugged in). I therefore don't see a way, even with the Envoy, of getting accurate internal humidity readings.
Vantage Pro 2+ connected to Raspberry Pi running weewx by means of Meteo-Pi - data incorporated in domestic energy production (PV) and use monitoring system.

Offline Mattk

  • Forecaster
  • *****
  • Posts: 2135
I believe that I am correct in saying that the Envoy allows the plugging in only of an external temperature sensor. Measuring indoor humidity remains a problem. Your argument about the problems presented by the design of the VP2 console is a bit circular, since Davis were responsible for that design and could, presumably, have allowed for the possibility of an external sensor.

Just to clarify that, the so called "External temperature sensor" than can be plugged directly into the Envoy when plugged becomes a replacement for the Internal on board sensor and is reported as Internal temp so effectively even though one might call it an external sensor it is actually being reported as the Internal temperature. A Temp/Humidity sensor plugged directly to the Envoy simply does not work and blows the temp way out (on the temp side only but does not affect the internal humidity) but then there is no real issue with the Humidity anyway.     

Because of the way Temperature/Humidity sensors work, a temperature error (due to the sensor being 'heated') leads to a humidity reading error as well, even if the sensor is otherwise working perfectly. I assume that even if an external temp sensor is plugged in, the Envoy's humidity reading is influenced by the temperature that the internal sensor is seeing (and would be reporting if the external sensor were not plugged in). I therefore don't see a way, even with the Envoy, of getting accurate internal humidity readings.

No the external connection switches the internal temp sensor off and uses the so called external temp which is essentially the internal temp relative to the humidity sensor which is not affected by internal heating

Offline pfletch101

  • Forecaster
  • *****
  • Posts: 329
    • Personal Website
No the external connection switches the internal temp sensor off and uses the so called external temp which is essentially the internal temp relative to the humidity sensor which is not affected by internal heating

You may be right, but I would be rather surprised if you are. My understanding is that the 'link' between temperature and humidity is within the sensor. I believe that it reports the two actual 'final' readings separately - not that it reports a humidity value which is then corrected by the console on the basis of the temperature reading to give the 'real' relative humidity. Are you absolutely sure that it works as you say?
Vantage Pro 2+ connected to Raspberry Pi running weewx by means of Meteo-Pi - data incorporated in domestic energy production (PV) and use monitoring system.

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
It's possible to mathematically compensate the RH reading using the second thermometer. See here. I wonder if a similar technique is employed in the Envoy.

Offline Mattk

  • Forecaster
  • *****
  • Posts: 2135
The Envoy handles the "external temp sensor" data in some different ways especially related to the internal values associated with Temp, RH, Dewpoint, Heat, EMC and Air density and with some only fixated on specific values it does become a bit of a hole to get into without actually looking at the entire group of record values associated with the so called "internal temp value" be it the internal internal one or the external internal one.       

Offline optical_man

  • Member
  • *
  • Posts: 28
    • WeatherUnderground
Geetings Wojciech,

I’m so glad that you decided to release the WiFiLogger product. :grin:  It is just what I was looking for.  I received it today from Scaled Instruments and upgraded the firmware to .13.  Everything is working great so far.  I just wanted to shout out my gratitude for all your effort in making it work amazingly when considering the design limitations of the Davis hardware. =D> =D> =D>

Regards,
 Joe

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
Thank you Joe.  :grin:

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
I am testing now auto pause for Cumulus/WeatherLink connection.
It works perfectly. I don't know why I didn't make it in a first step.

I have a question to the WiFiLogger users. Should I leave manual trigger for pause with manual duration setup? Or should I make only auto pause enable option, or auto pause should works always?

 [ You are not allowed to view attachments ]

Offline kobuki

  • Forecaster
  • *****
  • Posts: 838
I have a question to the WiFiLogger users. Should I leave manual trigger for pause with manual duration setup? Or should I make only auto pause enable option, or auto pause should works always?

I'm not (yet) an user, but I think it's nice to leave the choice to the users. Possibly the best is to set 'Auto pause' as the default as it's supposed to work for everyone. But ones interested in LOOP packets must use the 'Enable' option, for instance.

Offline optical_man

  • Member
  • *
  • Posts: 28
    • WeatherUnderground
The auto pause feature sounds like a great idea.

I have an unrelated suggestion which concerns RapidFire.  It seems the current WiFiLogger implementation is defaulting to the fastest possible upload frequency which is great for those who desire that.  However, would it be difficult to add a frequency field that allows acceptable values from maybe every 2.5 seconds up to 30 seconds?

Quote
RapidFire Updates http://wiki.wunderground.com/index.php/PWS_-_Upload_Protocol

RapidFire Updates allow you to update weather station conditions at a frequency up to once observation every 2.5 seconds. Web site visitors will see these observations change in real-time on the wunderground.com site.
-A real-time update should look almost like the standard update.
-However, the server to request is:   rtupdate.wunderground.com, not weatherstation.wunderground.com
-And, please add to the query string:     &realtime=1&rtfreq=2.5
-where rtrfreq is the frequency of updates in seconds.

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
I am using seconds trigger so, it is not 2.5s, but 3.0s.
Yes I can make additional field in form to change that parameter. It will be 3-30 with step 1s.

Offline optical_man

  • Member
  • *
  • Posts: 28
    • WeatherUnderground
Understood, integer seconds is simpler to manage and it is sufficient.

Offline PaulMy

  • Forecaster
  • *****
  • Posts: 5509
    • KomokaWeather
Quote
I am testing now auto pause for Cumulus/WeatherLink connection.
It works perfectly. I don't know why I didn't make it in a first step.

I have a question to the WiFiLogger users. Should I leave manual trigger for pause with manual duration setup? Or should I make only auto pause enable option, or auto pause should works always?
Hi Wojtek, great but still not 100% understanding, and having the manual option seems like the most appropriate to suit different software possibilities.

Enjoy,
Paul
« Last Edit: June 20, 2018, 10:24:41 AM by PaulMy »

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
timer is always integer. It's milliseconds count.
I am using two timers. 1s and 1min. I have just used this 1s for RapidFire.
Please not that 0.5s it does not matter much. After sending WiFiLogger waits for response up to 7s.
It's working fine and keep uploading every 3s, but it's an Internet, it has limited latency.
I don't think that 0.5s makes any difference.

If you like I can start next timer 0.1 special for RapidFire. Then math will be ok, but reality will be the same.

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
Hi Wojtek, great but still not 100% understanding, and having the manual option seems like the most appropriate to suit different software possibilities.
Enjoy,Paul

Yes manual pause it's a good tool, but auto pause always on will avoid collisions with WiFiLogger internal functions. It will be more proof for user mistakes.

I will make two options: manual, auto,
but in future I would like to leave only auto when it proves its value. It will much more easy to operate for new users.
WiFiLogger needs to be natural to operate.

First we will check if somebody will need manual pause.

Offline optical_man

  • Member
  • *
  • Posts: 28
    • WeatherUnderground
Hi Wojciech,

Sorry for any confusion I may have caused.  My previous post was agreeing with you to maintain the 1000ms resolution timer for rapid fire.  There is no need to clutter up the code to allow higher a resolution.  Like you've already mentioned, the difference is not noticeable.

Joe
« Last Edit: June 20, 2018, 10:40:08 AM by optical_man »

Offline ihadablackdog

  • Member
  • *
  • Posts: 32
Hi,  Just reporting that I got my wifilogger from John @ Prodata (UK) and it was delivered as stated....dispatched on 18th and arrived on 19th! John even emailed me with firmware update details. Excellent service.

Got mine uploading to weatherlink.com and wunderground.com, both at 1 minute intervals.  Do I need to worry about the auto pause function people are talking about (can't even find it in the menu).

Offline WiFiLogger

  • Forecaster
  • *****
  • Posts: 733
Thank you for choosing my product.

Auto pause will be available in firmware 1.14. It allows to coexist connection with Cumulus. I am still testing, but works perfectly good.

Offline ihadablackdog

  • Member
  • *
  • Posts: 32
Its a neat little unit and was quite easy to set up and configure, and the firmware update was easy as well, no need for anyone to be worried about that (assuming they have a little IT knowledge).

So if I don't use Cumulus I don't need to use the auto-pause feature when 1.14 is released?

Offline optical_man

  • Member
  • *
  • Posts: 28
    • WeatherUnderground
Wojciech, I'm experiencing what seems to be a bug in v1.13 where it is sending the wrong temperature to Weather Underground.  The temperature field is reading the same as the high temperature within each cycle period.  Can you please check to see if that is the case?  I want the normal temperature which is the average temperature the way I set it up.  Thanks.