I created a pre-release with the fix. It is here, https://github.com/bellrichm/WeeWX-MQTTSubscribe/releases/tag/v1.6.2-rc03 Hopefully this is it. rich On Saturday, 10 October 2020 at 10:15:29 UTC-4 [email protected] wrote:
> OK, thanks for your help. > > On Saturday, October 10, 2020 at 7:22:18 AM UTC-6 [email protected] wrote: > >> Thanks for the log. Looks like there is a bug with the ignore_start_time >> option. Fix looks easy, I just need to make sure there are no side effects. >> I’ll let you know when the fix is available. >> - rich >> >> On Friday, 9 October 2020 at 22:55:11 UTC-4 [email protected] wrote: >> >>> 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/57bf0dea-bf97-4c5f-92f5-64ee987e42e2n%40googlegroups.com.
