Ah, crap.  This has to do with an attempt to quality control data by time. 
Next major release, I really need to rework it...
Since you have individual payloads (no timestamp from the origin) add the 
following under [[topics]]
ignore_start_time = true
Ignore_end_time = true

We are getting close.  Sorry for the pain.
rich


On Friday, 9 October 2020 at 18:36:27 UTC-4 [email protected] wrote:

> syslog extract posted. weewx is loading the service, though it also seems 
> to subscribe to the data which MQTT is publishing from weewx. the second 
> section shows that subscribe receives the data I published from the 
> terminal (6 inches of snow), but rejects it as outside of interval. Is 
> there an entry to be made somewhere to sync incoming data? I note that 
> another extension I use (GW1000) needed dateTime = datetime in a field map 
> to work properly.
>
> On Friday, October 9, 2020 at 2:54:56 PM UTC-6 [email protected] wrote:
>
>>
>> That could be simplified, but looks like it should work. The quickest and 
>> easiest way to proceed is to set debug to 1, restart WeeWX, let it run 
>> through an archive cycle during which you published to that topic and then 
>> post the log.
>>
>> Re: snowBatteryStatus - The units config option is only needed if the 
>> field units do not match the units expected by the unit_system. So 
>> eliminating will at least get the data in the DB. 
>> Note, units is not needed for snowDepth because inches is the Units for 
>> that field in the US unit_system.
>> rich
>> On Friday, 9 October 2020 at 14:23:01 UTC-4 [email protected] wrote:
>>
>>> I've attached a syslog extract showing where weewx crashed. it seems 
>>> that "volt" is an invalid unit for my topic. i don't know why but for now I 
>>> commented out that topic and its parameters. Now, weewx will continue 
>>> running when subscribe is enabled, but subscribed topics are not being 
>>> posted to the database. Here is the first topic in weewx.conf:
>>>
>>>         # The first topic
>>> # MQTT Topic
>>> [[[snow/snowDepth]]]
>>> # MQTT name
>>> [[[[snowDepth]]]]
>>> # weewx name
>>> name = snowDepth
>>> ignore = false
>>> contains_total = false
>>> conversion_type = float
>>> units = inch
>>>
>>> I used a terminal to publish "6" to snow/snowDepth on Mosquitto. Another 
>>> terminal window command to subscribe to snow/snowDepth received the "6" but 
>>> the database entries for snowDepth are null. Is this configuration of 
>>> topics still not correct. Thanks.
>>> On Tuesday, October 6, 2020 at 1:43:31 PM UTC-6 Timothy Buchanan wrote:
>>>
>>>> Thanks, Rich. I'll try it when I get back. I'll be in our second home 
>>>> for a few days: going to the gun range and the clothing-optional resort 
>>>> (not at the same time!).
>>>>
>>>> On Tuesday, October 6, 2020 at 1:19:26 PM UTC-6 [email protected] 
>>>> wrote:
>>>>
>>>>> So, the [[[first/topic]]] are meant to be replaced with the actual 
>>>>> topic. So it would be something like this
>>>>> ```
>>>>> [[Topics]]
>>>>>   [[[topic name that snowDepth is published on]]]
>>>>>     [[[[topic name that snowDepth is published on]]]]
>>>>>       name = snowDepth
>>>>>   [[[topic name that snowRate is published on]]]
>>>>>     [[[[topic name that snowRate is published on]]]]
>>>>>       name = snowRate
>>>>> ```
>>>>> The duplication is an artifact of dealing with json and keyword 
>>>>> payloads. The ```use_topic_as_fieldname``` option can be used to make 
>>>>> the config a bit prettier.
>>>>> ```
>>>>> [[Topics]]
>>>>>   use_topic_as_fieldname = true
>>>>>   [[[topic name that snowDepth is published on]]]
>>>>>     name = snowDepth
>>>>>   [[[topic name that snowRate is published on]]]
>>>>>     name = snowRate
>>>>> ```
>>>>> Note, if snowDepth is actually published on the topic snowDepth, the 
>>>>> ```name``` option can be left off.
>>>>> I don’t think that you want to set contains_total=true for snowDepth. 
>>>>> This is used when the field contains a total and it needs to be converted 
>>>>> into an increment for WeeWX.
>>>>>
>>>>> I’ll work on clarifying the wiki.
>>>>>
>>>>> With that said, it shouldn’t have broken WeeWX. If you are up for it, 
>>>>> before changing the config, setting debug=1, restarting WeeWX for a 
>>>>> couple 
>>>>> of archive intervals and attaching the log would be appreciated .
>>>>>
>>>>> rich
>>>>>
>>>>>
>>>>>
>>>>> On Tuesday, 6 October 2020 at 13:28:34 UTC-4 [email protected] 
>>>>> wrote:
>>>>>
>>>>>> Attached is the extension material that I put into weewx.conf. But 
>>>>>> when I set enable = true, weewx stops archiving data. Is there an error 
>>>>>> in 
>>>>>> this configuration, or could subscribe be incompatible with another 
>>>>>> service? I'm using the Weatherflowudp driver with mqtt and GW1000 
>>>>>> extensions.
>>>>>>
>>>>>> On Tuesday, October 6, 2020 at 9:17:07 AM UTC-6 Timothy Buchanan 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks, Rich, I should be able to edit weewx.conf based on the 
>>>>>>> example at the bottom of that page.
>>>>>>>
>>>>>>> I am using an ESP8266 board with an ultrasonic sensor and a 
>>>>>>> temperature sensor (to calibrate the speed of sound), and programming 
>>>>>>> in 
>>>>>>> the Arduino IDE. I'll 3D print a case and mount it above my deck. The 
>>>>>>> materials cost about $15.
>>>>>>>
>>>>>>> I'd be happy to post the code here, under a new topic, once I get it 
>>>>>>> working.
>>>>>>>
>>>>>>> Timothy
>>>>>>>
>>>>>>> On Tuesday, October 6, 2020 at 8:53:45 AM UTC-6 [email protected] 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> What type of sensor are you using for measuring snow depth?
>>>>>>>>
>>>>>>>>
>>>>>>>>

-- 
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/42d83b59-9ac8-4ff3-90ec-1bbcacc74960n%40googlegroups.com.

Reply via email to