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

On Monday, May 16, 2022 at 9:59:43 AM UTC-7 Ryan Stasel wrote:

> 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. 
>
>  
>
> *From:* weewx...@googlegroups.com <weewx...@googlegroups.com> *On Behalf 
> Of *Tom Keffer
> *Sent:* Monday, May 16, 2022 9:41 AM
> *To:* weewx-user <weewx...@googlegroups.com>
> *Subject:* Re: [weewx-user] Just flipped drivers to Vantage, two questions
>
>  
>
> 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.
>
>  
>
>  
>
> On Mon, May 16, 2022 at 9:29 AM Ryan Stasel <rcst...@gmail.com> wrote:
>
> 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? 
>
> On Monday, May 16, 2022 at 9:09:53 AM UTC-7 tke...@gmail.com wrote:
>
> 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?
>
>  
>
> On Mon, May 16, 2022 at 8:16 AM Ryan Stasel <rcst...@gmail.com> wrote:
>
> 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)?
>
> On Saturday, May 14, 2022 at 8:52:51 PM UTC-7 Ryan Stasel wrote:
>
> 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. 
>
> On Saturday, May 14, 2022 at 4:59:54 AM UTC-7 Ryan Stasel wrote:
>
> 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! 
>
> On Friday, May 13, 2022 at 3:04:28 PM UTC-7 Ryan Stasel wrote:
>
> 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. 
>
> On Friday, May 13, 2022 at 2:14:06 PM UTC-7 tke...@gmail.com wrote:
>
> 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 <rcst...@gmail.com> 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 tke...@gmail.com 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 <rcst...@gmail.com> 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 tke...@gmail.com 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 <rcst...@gmail.com> 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 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
>  
> <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 weewx-user+...@googlegroups.com.
>
> 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 weewx-user+...@googlegroups.com.
>
> 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 weewx-user+...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/7771d657-6913-458b-b199-d716c56396e6n%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/7771d657-6913-458b-b199-d716c56396e6n%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 weewx-user+...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/weewx-user/25192f49-af25-4d96-8942-c5a659e37c9bn%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/weewx-user/25192f49-af25-4d96-8942-c5a659e37c9bn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> -- 
> 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
>  
> <https://groups.google.com/d/msgid/weewx-user/CAPq0zEA3P7cPhhij77tJyM7g3032yaxdWxxRFWKLDjsi0EoVsA%40mail.gmail.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 weewx-user+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/20b097cb-788d-4492-a48f-6dbe11ea171cn%40googlegroups.com.

Reply via email to