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. On Fri, May 13, 2022 at 10:27 AM Ryan Stasel <[email protected]> wrote: > 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! > On Thursday, May 12, 2022 at 9:09:17 PM UTC-7 [email protected] wrote: > >> 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 >> >> >> On Wed, May 11, 2022 at 9:33 AM Ryan Stasel <[email protected]> wrote: >> >>> 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? >>> >>> On Tuesday, May 10, 2022 at 6:18:38 PM UTC-7 [email protected] wrote: >>> >>>> 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]. >>>> >>>> On Tue, May 10, 2022 at 12:52 PM Ryan Stasel <[email protected]> wrote: >>>> >>>>> 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! >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/weewx-user/cb9428de-0583-4b64-bc94-a86a65702922n%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/weewx-user/cb9428de-0583-4b64-bc94-a86a65702922n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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 [email protected]. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/weewx-user/8339cdba-6cf5-4e46-98cf-7cdfcfe773f3n%40googlegroups.com >>> <https://groups.google.com/d/msgid/weewx-user/8339cdba-6cf5-4e46-98cf-7cdfcfe773f3n%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/weewx-user/9e85c652-9cb0-4203-9cfd-5a852be38872n%40googlegroups.com > <https://groups.google.com/d/msgid/weewx-user/9e85c652-9cb0-4203-9cfd-5a852be38872n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEB1OzCV3%3DcamYTyqqF_AZWZFwpRwjk%3DKniGoW6%2BaQhZrg%40mail.gmail.com.
