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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/31940e33-fe29-491d-9734-6db92a0ca349n%40googlegroups.com.

Reply via email to