My offer to debug why the cache is not working for you still stands.
rich

On Monday, 6 December 2021 at 10:38:47 UTC-5 [email protected] wrote:

> Ok, I seem to have jumped the gun :(   
>
> Things are much better but I'm still getting the N/A in place of data 
> every few archive records (current data). My suspicion here is that the 
> sensor is not sending on exactly 60 minute intervals. Looking at the actual 
> times in the LoRa server, it's 60, 61 or 62 minute intervals--not always 
> the same. Is it possible, using the basic  " $hour.co2.last" syntax, to 
> change the "hour" to say 65 minutes? This would probably catch the changes 
> from one hour. I have attached a file of what is in the weewx.sdb showing 
> the missing data in certain instances. If the sensor has updated just after 
> the archive time (15 minutes) then it misses recording new data.
> I'm just guessing here at what might be going on. The graph seems to be 
> picking up the data with no problem.
> Thanks.
> Bob[image: zbsng7lr.bmp]
>
> On Sunday, December 5, 2021 at 12:41:03 PM UTC-5 [email protected] wrote:
>
>> It looks like " $hour.co2.last" did it, at least the last four hours are 
>> updating correctly with no N/As mixed in.
>>
>> Many thanks to all who contributed help on this, and much appreciated is 
>> all the hard work that goes into weewx maintenance and updates by many!
>> Bob
>> http://grattans.org/wx
>>
>> On Sunday, December 5, 2021 at 8:10:12 AM UTC-5 [email protected] wrote:
>>
>>> I'd go with Tom's advice, but if you want to get the cache working I'd 
>>> need a log file with debug set to 2. It needs to have a few archive records 
>>> before the first CO2 reading arrives via MQTT and a few records after. 
>>> Warning, the file is going to large, very large.
>>> rich
>>>
>>> On Saturday, 4 December 2021 at 20:08:19 UTC-5 [email protected] wrote:
>>>
>>>> Take the accumulator stuff out.
>>>>
>>>> Why not just use $hour.co2.last?
>>>>
>>>>
>>>>
>>>> On Sat, Dec 4, 2021 at 4:17 PM gjr80 <[email protected]> wrote:
>>>>
>>>>> Suggesting use of $hour_delta=1 wasn’t wise on my part as data 
>>>>> arriving once per 60 minutes will likely lead to some occasions where no 
>>>>> data is displayed depending on exactly when the data arrives. Conceivably 
>>>>> data arriving or being processed a few seconds late could fall outside of 
>>>>> $hour_delta=1. 
>>>>>
>>>>> Actually, thinking some more, you my be able to use the aggregate 
>>>>> ‘last’ to get the last value in the aggregation period, so try 
>>>>> $span($hour_delta=2).co2.last. I may be mistaken but I think the 
>>>>> aggregates 
>>>>> exclude the None values so this tag may give you the most recent non-None 
>>>>> value in the last two hours. Refer to 
>>>>> http://weewx.com/docs/customizing.htm#Tag_$span and 
>>>>> http://weewx.com/docs/customizing.htm#aggregation_types.
>>>>>
>>>>> Failing that you may like to try $span($time_delta=3900).co2.avg or 
>>>>> 4200 to display the average over the last 70 or 80 minutes. Be aware 
>>>>> though that just as $hour_delta=1 missed some records going the other way 
>>>>> to > 1 hour will likely see more than one record be included in some 
>>>>> aggregates, probably not an issue but something to be aware of.
>>>>>
>>>>> Gary
>>>>> On Sunday, 5 December 2021 at 08:35:01 UTC+10 [email protected] wrote:
>>>>>
>>>>>> I've tried a few suggestions. The sensor output time can be changed 
>>>>>> to a shorter period but, at this point, I prefer to keep it at 60 
>>>>>> minutes 
>>>>>> since the internal battery looks impossible to change easily. At 60 
>>>>>> minutes 
>>>>>> it is supposed to last a little over 3 years.
>>>>>>
>>>>>> I added the suggestion " $span($hour_delta=1).co2.avg" which seems to 
>>>>>> bring in data more often but there are still some periods of "N/A."
>>>>>>
>>>>>> I added " expires_after = none" but for now that doesn't seem to do 
>>>>>> anything.
>>>>>>
>>>>>> The suggestion of writing data to a scratch file may be the only way 
>>>>>> to go if I can't configure it another way.
>>>>>>
>>>>>> I have produced a daily graph on the main page
>>>>>>
>>>>>> [image: yafe6kzk.bmp]
>>>>>>
>>>>>> The sensor is in the house for now and the peaks seem to come from 
>>>>>> using the oven and burners on the gas stove.
>>>>>>
>>>>>> Thanks for all the help. I'll give this a day or so to accumulate 
>>>>>> some data.
>>>>>> On Saturday, December 4, 2021 at 4:46:26 PM UTC-5 [email protected] 
>>>>>> wrote:
>>>>>>
>>>>>>> Bob,
>>>>>>> As noted earlier, now that you have a base MQTTSubscribe 
>>>>>>> configuration up and running, you probably want to look at its 'archive 
>>>>>>> record cache capability'. Details are here,
>>>>>>>
>>>>>>> https://github.com/bellrichm/WeeWX-MQTTSubscribe/wiki/Configuring-additional-options#expires_after
>>>>>>>
>>>>>>> I think that setting expires_after to none would be the simplest. So 
>>>>>>> you would end up with something like this.
>>>>>>> [MQTTSubscribeService]
>>>>>>> [[topics]]
>>>>>>> [[[mytopic]]]
>>>>>>> ignore = true
>>>>>>> [[[[CO2_Value_PPM]]]]
>>>>>>> name = co2
>>>>>>> ignore = false
>>>>>>> expires_after = none
>>>>>>>
>>>>>>> rich
>>>>>>>
>>>>>>> On Saturday, 4 December 2021 at 15:09:39 UTC-5 gjr80 wrote:
>>>>>>>
>>>>>>>> The other approach is to give WeeWX at least one co2 value per 
>>>>>>>> archive period (it can be the same value) but that is a function of 
>>>>>>>> your 
>>>>>>>> data source and the driver being used and I don’t know the 
>>>>>>>> limitations/capabilities of each.
>>>>>>>>
>>>>>>>> Gary
>>>>>>>>
>>>>>>>> On Sunday, 5 December 2021 at 05:56:10 UTC+10 gjr80 wrote:
>>>>>>>>
>>>>>>>>> The issue here is that the ‘co2 field’ receives data only once per 
>>>>>>>>> hour, so based on a 15 minute archive period only one in four archive 
>>>>>>>>> records will have co2 data. Changing the accumulator type and 
>>>>>>>>> extraction 
>>>>>>>>> policy will not change this. I would leave the co2 accumulator 
>>>>>>>>> settings out 
>>>>>>>>> of weewx.conf. I doubt whether $last will be much help either; $last 
>>>>>>>>> displays data from the last known good record in the database as 
>>>>>>>>> opposed to 
>>>>>>>>> the current record used by $current. If there is no co2 data  in most 
>>>>>>>>> records then $last will provide a similar result.
>>>>>>>>>
>>>>>>>>> You may have better luck with some sort of aggregate over the past 
>>>>>>>>> hour, say something like (untested) $span($hour_delta=1).co2.avg. 
>>>>>>>>> The actual aggregate is probably meaningless since you only have one 
>>>>>>>>> value 
>>>>>>>>> per hour so min be mx will work just as well.
>>>>>>>>>
>>>>>>>>> Gary
>>>>>>>>> On Sunday, 5 December 2021 at 03:59:46 UTC+10 [email protected] 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Sorry, here is some info. This time, I re-inserted the 
>>>>>>>>>> [Accumulator] paragraph at a different place in weewx.conf and it 
>>>>>>>>>> restarted 
>>>>>>>>>> without an exit. The web data is still showing "$last.co2"
>>>>>>>>>> It ran for a while and then stopped. Debug file attached. Thanks
>>>>>>>>>> weewx.conf
>>>>>>>>>>
>>>>>>>>>> # Options for 'MQTTSubscribeService'
>>>>>>>>>> [Accumulator]
>>>>>>>>>>     [[co2]]
>>>>>>>>>>         accumulator = firstlast
>>>>>>>>>>         extractor = last
>>>>>>>>>>
>>>>>>>>>> [MQTTSubscribeService]
>>>>>>>>>>     # This section is for the MQTTSubscribe service.
>>>>>>>>>>
>>>>>>>>>>     # Turn the service on and off.
>>>>>>>>>>     # Default is: true
>>>>>>>>>>     # Only used by the service.
>>>>>>>>>>     enable = true    # false
>>>>>>>>>> ==================================================
>>>>>>>>>> index.html.tmpl
>>>>>>>>>> <tr class = "even">
>>>>>>>>>>                 <td class="stats_label">105 Crawl Temperature</td>
>>>>>>>>>>                 <td class="stats_data">$current.extraTemp1 / 
>>>>>>>>>> $current.extraTemp1.degree_C</td>
>>>>>>>>>>               </tr>
>>>>>>>>>>                 <tr class = "even">
>>>>>>>>>>                 <td class="stats_label">CO2 level</td>
>>>>>>>>>>                 <td class="stats_data">$last.co2</td>
>>>>>>>>>>               </tr>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ==================================================
>>>>>>>>>>
>>>>>>>>>> Standard web page reads: (http://grattans.org/wx)
>>>>>>>>>>
>>>>>>>>>> 105 Crawl Temperature 72.0°F / 22.2°C
>>>>>>>>>> CO2 level $last.co2
>>>>>>>>>>
>>>>>>>>>> On Saturday, December 4, 2021 at 12:07:09 PM UTC-5 vince wrote:
>>>>>>>>>>
>>>>>>>>>>> On Saturday, December 4, 2021 at 7:16:00 AM UTC-8 
>>>>>>>>>>> [email protected] wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I tried changing $current.co2 to $last.co2 but it only printed 
>>>>>>>>>>>> "$last.co2" on the web page.
>>>>>>>>>>>>
>>>>>>>>>>>> Adding the  [Accumulator] section to weewx.conf only caused an 
>>>>>>>>>>>> error and exit when I restarted weewx. I tried adding this in 
>>>>>>>>>>>> several 
>>>>>>>>>>>> places but none seems to let weewx restart without an exit error.  
>>>>>>>>>>>> Is there 
>>>>>>>>>>>> a special place to add this? Couldn't find anything in the doc 
>>>>>>>>>>>> about 
>>>>>>>>>>>> placement.  Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> Usual answers apply.
>>>>>>>>>>>
>>>>>>>>>>> Unless you post the error messages verbatim and/or the changes 
>>>>>>>>>>> you made to the skin, we are not going to be able to help you.
>>>>>>>>>>>  
>>>>>>>>>>>
>>>>>>>>>> -- 
>>>>> 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/60583ac3-73f3-479c-91d0-34fcdf1c0865n%40googlegroups.com
>>>>>  
>>>>> <https://groups.google.com/d/msgid/weewx-user/60583ac3-73f3-479c-91d0-34fcdf1c0865n%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/66646871-4505-4d55-aaf7-c1c5645d717an%40googlegroups.com.

Reply via email to