I added those this way:
# The topics to subscribe to.
[[topics]]
# Units for MQTT payloads without unit value.
# Valid values: US, METRIC, METRICWX
# Default is: US
unit_system = US
ignore_start_time = true
Ignore_end_time = true
but I still get this:
Oct 9 20:38:29 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published
record 2020-10-09 20:38:47 MDT (1602297527)
Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) MessageCallbackProvider data-> incoming topic: snow/snowDepth,
QOS: 0, retain: 0, payload: b'7'
Oct 9 20:38:30 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) TopicManager data-> incoming snow/snowDepth: snow/snowDepth: 7.0
Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) TopicManager data-> outgoing snow/snowDepth: dateTime:
1602297510.2596123, snow/snowDepth: 7.0, usUnits: 1
Oct 9 20:38:31 raspberrypi weewx[30461] INFO user.MQTTSubscribe: (Service)
TopicManager ignoring record outside of interval 1602297510.259612
1602297529.000000 1602297510.259612 dateTime: 1602297510.2596123,
snow/snowDepth: 7.0, usUnits: 1
Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) TopicManager data-> outgoing accumulated snow/snowDepth:
Oct 9 20:38:31 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) data-> final packet is 2020-10-09 20:38:49 MDT (1602297529):
avg_distance: 0, dateTime: 1602297529, lightning_strikes: 0, outHumidity:
23, outTemp: 13.34, outTempBatteryStatus: 2.919, pressure: 744.7, usUnits:
17
Oct 9 20:38:31 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published
record 2020-10-09 20:38:49 MDT (1602297529)
Oct 9 20:38:32 raspberrypi weewx[30461] DEBUG user.MQTTSubscribe:
(Service) data-> final packet is 2020-10-09 20:38:50 MDT (1602297530):
dateTime: 1602297530, usUnits: 17, windDir: 336, windSpeed: 0.72
Oct 9 20:38:32 raspberrypi weewx[30461] INFO weewx.restx: MQTT: Published
record 2020-10-09 20:38:50 MDT (1602297530)
On Friday, October 9, 2020 at 5:13:41 PM UTC-6 [email protected] wrote:
>
> 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/9baa8ed4-10ea-4722-a550-a4299dceb817n%40googlegroups.com.
