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/15fdcb6d-e649-4c20-9149-e7a78964b160n%40googlegroups.com.
