Just flipped drivers to Vantage, two questions

[Ryan Stasel]

Hi All,

I just flipped drivers to the Vantage driver (having previously used the ambientweatherapi driver). I have two questions.

1. My page now thinks I have a Vantage Pro 2 rather than a Vue. I'm interfacing over "ethernet" to a Meteobridge Nano SD in an Envoy. Is there a different value I should put in for "model_type" to reflect Vantage Vue?

2. The ambientweatherapi driver reported battery level, and the Vantage one does not. But now I just have two "Unknown" values where those go. I assume just clear out those DB entires so the template doesn't render them? Will have to figure out what field it used for this so I can null it out... 

Thanks! 

[Tom Keffer]

1. I'm afraid I can't offer an opinion on this, because your arrangement is so non-standard. Normally, the station type is read out of EEPROM.

2. After 30 days, the logic in the skin gives up and figures the sensors are gone. So, you can either wait that long, or pare down the list of sensors in skin.conf. Look under stanza [DisplayOptions].

--
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 weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/cb9428de-0583-4b64-bc94-a86a65702922n%40googlegroups.com.

[Ryan Stasel]

Thanks Thomas. I was looking through the Vantage driver, and was curious if there was a way to just "force" Vue. Saw something about setting the value to 17, but not sure that is accurate. Does it read that value out of the Envoy EEPROM? I can inquire with the MB developer and see if they have any thoughts. Since you tell the MB what station you have, seems like it should be able to report that back to Weewx. 

One thing I do notice is there's a significant amount of "noise" in the graphs since switching over. If you take a look here: https://www.staze.org/weewx/ before about 2pm PDT when it'll roll off the graphs... maybe that's just the expected behavior with the LOOP data. 

Also, random, I set it to use both LOOP and LOOP2, and there's a note about setting to hardware for the values weewx would otherwise calculate. Those are currently set to "prefer_hardware". I assume that means it's still going to calculate on every packet that doesn't contain that data, so I should hard set to "hardware"? Maybe that'll remove the noise? Or is this also an MB side effect?

[Ryan Stasel]

To be clear, I have "model_type" set to 2 rather than 1. But neither are the Vue, so I'm not sure if that matters or not. If I just comment that line out, will it try to figure it out on it's own? There's no documentation on that parameter in the docs that I can find. 

[Ryan Stasel]

Ah, I see why the noise is there...

May 11 12:48:27 raspi-server-misc weewx[13000] ERROR weewx.engine: The archive interval in the configuration file (300) does not match the station hardware interval (60).

May 11 12:48:27 raspi-server-misc weewx[13000] INFO weewx.engine: Using archive interval of 60 seconds (specified by hardware)

This is something the MB can set on the console (Envoy) so I've changed this to 5 mins. 

The output from wee_device --info looks correct to me (now)... other than the station type reporting as Vantage Pro 2.... 

[Tom Keffer]

1. The hardware type is determined by the WRD command. You can check what it's returning by setting debug=1, then restarting. Look at the log. The hardware type will be listed and look something like:

May 12 15:22:59 nuc weewx[91691] DEBUG weewx.drivers.vantage: Hardware type is 16

 For whatever reason, yours must be returning 16, the code for the VantagePro series.

The option "model_type" is used only to differentiate between the original VantagePro, and the current VantagePro2. It is always set to 2 for a Vue.

2. Not sure what you mean by 'noise'. Your plots look pretty normal to me. Perhaps your Vue has better resolution than your old station?

3. WeeWX will calculate various derived variables if they are not supplied by your hardware. LOOP and LOOP2 include different types in their packets, most notably 'pressure' and 'altimeter', so it is possible you would be switching between hardware and software origins. Personally, I would pick one or the other. 

-tk

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/8339cdba-6cf5-4e46-98cf-7cdfcfe773f3n%40googlegroups.com.

[Ryan Stasel]

Thanks Thomas. debug shows:

May 13 10:21:22 raspi-server-misc weewx[6626] DEBUG weewx.drivers.vantage: Opened up ethernet host 10.0.6.22 on port 22222. timeout=4.0, tcp_send_delay=0.5
May 13 10:21:22 raspi-server-misc weewx[6626] DEBUG weewx.drivers.vantage: Gentle wake up of console successful
May 13 10:21:23 raspi-server-misc weewx[6626] DEBUG weewx.drivers.vantage: Hardware type is 16
May 13 10:21:25 raspi-server-misc weewx[6626] DEBUG weewx.drivers.vantage: ISS ID is 1
May 13 10:21:25 raspi-server-misc weewx[6626] DEBUG weewx.drivers.vantage: Hardware name: Vantage Pro2

So confirmed there. =/ I've inquired with the MB dev to see if we can be more specific. I think the MB emulates the LOOP protocol. Any chance we could get some (possibly hidden) option to force the station type in the Vantage driver? the biggest issue right now is weewx is expecting ET data since it's a Vantage Pro2, but not getting it. 

For 2. I had the MB set, and therefore the console, set to 60 second record time. Which was overriding the 300 sec in weewx, so the "noise" was just 60 second record times vs the standard 300. Got that fixed by setting MB to set the console to 5 mins. 

For 3. That makes sense. I set those to hardware rather than prefer. It is still set to use both, I guess I'm curious one over the other. Should I just use 2? 2 doesn't seem to include battery info. I do notice that with it set to "3" (both) sometimes when weewx does it's web render it doesn't have battery data (just Unknown) until the next time around when it apparently gets that info and fills it in. What's best practice here? Just use 2 and change the settings back to prefer_hardware and let weewx fill in the blanks?

Thanks! 

[Tom Keffer]

1. Yours is a non-standard setup. I'd rather that the MB dev fixed his implementation.

2. That makes sense.

3. With a 60 second archive interval, it's possible that the console will occasionally not have seen the battery info, so it shows as N/A. With a 5 minute interval, it should consistently show a value.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/9e85c652-9cb0-4203-9cfd-5a852be38872n%40googlegroups.com.

[Ryan Stasel]

1. totally fair. guessing he's not going to agree. lol. On MB you just say "Vantage" and that covers Pro, Pro2, Vue, and Envoy. 

3. I'm still seeing in weewx generated HTML on occasion an "Unknown" for batt info (after changing archive interval to 5mins). It seemed like those were in LOOP packets rather than LOOP2 (or possibly other way around), which is why I set to 3 (both). I figured it was the HTML was being generated after a LOOP packet that didn't include that info, so it was just outputting unknown. 

[Ryan Stasel]

hmm. weewx (possibly) has no lead to the MB crashing twice. so going to flip back to ambientweatherapi extension for a bit until I can figure out... 

Thank you sir! 

[Ryan Stasel]

so I have another Envoy, and a Weatherlink IP... and I'm trying to get it configured, but for some reason, the Envoy (and Weatherlink) are convinced I have a Vantage Pro2... setting it to a Vue it complains that it found a Pro... =/ 

Ticket in with Davis support, but would be curious if anyone else has seen this. 

[Ryan Stasel]

Howdy Tom,

So after asking on the wxforum, it sounds like for an Envoy, the station SHOULD be set to Vantage Pro, even if it's talking to a Vue: https://www.wxforum.net/index.php?topic=43911.new;topicseen#new

So, seems like there might be something we need to do for the Envoy console with a Vue ISS? I have confirmed using wee_device that it does report a Vantage Pro2 rather than a Vue. So the Vue info may only report as expected using a Vue console (since I think the Envoy is basically the PCB of the Vantage Pro console, sans screen, shoved in a different enclosure)?

[Tom Keffer]

I'm not sure why this matters. The identification is only for the tag $station.hardware. Otherwise, it is ignored.

If you want your skin to say "VantageVue" (or, for that matter, anything else), just replace "$station.hardware" with your preference.

Or, am I missing something?

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/7771d657-6913-458b-b199-d716c56396e6n%40googlegroups.com.

[Ryan Stasel]

Hi Tom,

Sorry, I thought the mis-identification was why ET was showing in WeeWX (though the Vue doesn't provide that information), so it's just stuck at 0.0. 

I can certainly modify the skin, but will that not revert on update? 

[Tom Keffer]

Skins are left untouched by upgrades.

The ET is probably being calculated in software. Try setting to hardware:

[StdWXCalculate]

  [[Calculations]]

    ...

    ET = hardware

I am reluctant to allow users to set hardware types to arbitrary values through weewx.conf because 1) it second guesses Davis's choices; and 2) it will lead to more support issues when people upgrade their systems. Your case is pretty unusual.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/25192f49-af25-4d96-8942-c5a659e37c9bn%40googlegroups.com.

[rcst...@gmail.com]

Totally understood about not allowing forcing that value.

 

Would it be possible to allow setting $station.hardware to a manual value in weewx.conf (or a separate skins.conf or something)? Specifically allow setting and “override” value that’s just a string. So maybe not $station.hardware but $station.text and say “if defined, set that in skin, otherwise use $station.hardware”? Would give one less thing to keep track of when doing updates (even though, as you say, skins are not touched during upgrades).

 

Thanks very much for your time! Will give ET setting option a go.

--
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/3exN5P1US0Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEA3P7cPhhij77tJyM7g3032yaxdWxxRFWKLDjsi0EoVsA%40mail.gmail.com.

[Ryan Stasel]

That change does seem to have fixed the ET issue, thanks! 

[Tom Keffer]

The Envoy is functionally identical to the VP2, which is why it reports itself as a VP2. I'm not as confident about the WLIP, but I think it's the same way.

To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/31940e33-fe29-491d-9734-6db92a0ca349n%40googlegroups.com.