[weewx-user] Re: Using WeeWxMQTT - problems
Ralph, I have replied to you on the same question in weewx-development Not too hard...I've been running OWFS as a driver along with a "modified Bill wxMesh" MQTT service for 8 months Neil On Friday, 13 April 2018 05:45:09 UTC+12, Ralph Underwood wrote: > > What's involved in changing the driver to a service? My coding skills are > just above minimal, however I would be happy to be involved in testing. I > frequently fall asleep reading my 1,540 page "Learning Python" - using it > as a pillow has only raised by knowledge level slightly. > > I have one station in the wild that uses owfs and file parse. I would like > to add mqtt capability to that one. I was going to experiment with using > mqtt as driver and both fileparse and owfs as services. One option I have > been thinking about would be to convert the sensors I use file parse for to > mqtt - then only having one driver and one service for sensors. That option > would have two (or more) mqtt clients publishing and WxMesh magically > sorting it out. > > The station at my vacation home has a Ultimeter 2100 and to add mqtt based > sensors I think I would need to run wxMesh as a service. > > Again thanks so much for the help getting this working. > > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
What's involved in changing the driver to a service? My coding skills are just above minimal, however I would be happy to be involved in testing. I frequently fall asleep reading my 1,540 page "Learning Python" - using it as a pillow has only raised by knowledge level slightly. I have one station in the wild that uses owfs and file parse. I would like to add mqtt capability to that one. I was going to experiment with using mqtt as driver and both fileparse and owfs as services. One option I have been thinking about would be to convert the sensors I use file parse for to mqtt - then only having one driver and one service for sensors. That option would have two (or more) mqtt clients publishing and WxMesh magically sorting it out. The station at my vacation home has a Ultimeter 2100 and to add mqtt based sensors I think I would need to run wxMesh as a service. Again thanks so much for the help getting this working. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Thursday, 12 April 2018 08:13:51 UTC-3, gjr80 wrote: > > Just as an aside, as of weeWX 3.7.0 a couple of changes were made to the > included drivers that use a mapping to map a sensor (read output from some > external device/system) to a weeWX schema field (read a field in the loop > packet or archive record generated by the driver). In a nutshell, when > defined in a driver stanza in weewx.conf, the map is placed in a stanza > named [[sensor_map]]. The sensor mappings are then included using the > format schema_name = hardware_name (or you can think of it as weeWX > loop/archive field = sensor name). So a sensor map might look like > > ... > [ABC123] > # driver stanza for ABC123 weather station > [[sensor_map]] > outTemp = sensor25 > outHumidity = ABCDEFG.123456 > windSpeed = wind_speed > ... > > > Not a change that will cause any driver that uses a different construct to > fail, but it may be useful to adopt such a construct in a future release > (if nothing else helps us all speak the same language when talking > drivers). I expect in due course this will be included in the developer > notes somewhere. > > Gary > Good to know, Gary. Thanks. I'm looking at the effort to change the driver to be a service in my fork. So might tackle this construct after or during that. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Just as an aside, as of weeWX 3.7.0 a couple of changes were made to the
included drivers that use a mapping to map a sensor (read output from some
external device/system) to a weeWX schema field (read a field in the loop
packet or archive record generated by the driver). In a nutshell, when
defined in a driver stanza in weewx.conf, the map is placed in a stanza
named [[sensor_map]]. The sensor mappings are then included using the
format schema_name = hardware_name (or you can think of it as weeWX
loop/archive field = sensor name). So a sensor map might look like
...
[ABC123]
# driver stanza for ABC123 weather station
[[sensor_map]]
outTemp = sensor25
outHumidity = ABCDEFG.123456
windSpeed = wind_speed
...
Not a change that will cause any driver that uses a different construct to
fail, but it may be useful to adopt such a construct in a future release
(if nothing else helps us all speak the same language when talking
drivers). I expect in due course this will be included in the developer
notes somewhere.
Gary
On Thursday, 12 April 2018 20:51:18 UTC+10, Bill Morrow wrote:
>
> On Thursday, 12 April 2018 00:23:13 UTC-3, Ralph Underwood wrote:
>>
>> *IT WORKS!*
>>
>> I added: TIME = dateTime to wxMesh stanza of weewx.conf the stopped and
>> restarted WeeWx - waited a few minutes and I now have values showing up in
>> /var/www/html/weewx/index.html
>>
>>
> Hurray!
>
> This line in your earlier log file excerpt :
>
> Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: label map is {'INTE':
> 'inTemp', 'INHU': 'outHumidity'}
>
> was our clue that we had nothing mapped to dateTime.
>
> I put the blame on my genLoopPackets code. It always *replaces* an
> incoming dateTime/TIME value. It should just create it regardless of what
> is provided. In my defense, I have plans to add a real time clock in the
> field, and use an NTP derived time on the networked inside node.
>
> I've updated the wiki at github
> with this finding.
>
>
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Thursday, 12 April 2018 00:23:13 UTC-3, Ralph Underwood wrote:
>
> *IT WORKS!*
>
> I added: TIME = dateTime to wxMesh stanza of weewx.conf the stopped and
> restarted WeeWx - waited a few minutes and I now have values showing up in
> /var/www/html/weewx/index.html
>
>
Hurray!
This line in your earlier log file excerpt :
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: label map is {'INTE':
'inTemp', 'INHU': 'outHumidity'}
was our clue that we had nothing mapped to dateTime.
I put the blame on my genLoopPackets code. It always *replaces* an incoming
dateTime/TIME value. It should just create it regardless of what is
provided. In my defense, I have plans to add a real time clock in the
field, and use an NTP derived time on the networked inside node.
I've updated the wiki at github
with this finding.
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
*IT WORKS!* I added: TIME = dateTime to wxMesh stanza of weewx.conf the stopped and restarted WeeWx - waited a few minutes and I now have values showing up in /var/www/html/weewx/index.html Thanks a lot for all of the help! Now that I have something working I can start experimenting with other sensors. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Wednesday, 11 April 2018 20:56:39 UTC-3, vince wrote: > > On Wednesday, April 11, 2018 at 11:54:47 AM UTC-7, Ralph Underwood wrote: >> >> Do I need to have TIME = date-time in my weewx..conf wxMesh stanza? >> >> >> > Thinking not - I think you need: > >1. a "SOMETHING = dateTime" mapping in your weewx.conf file so the >driver knows what element is secs since the time epoch >2. a "SOMETHING: nnn" key/value pair in your MQTT payload, where nnn >= secs_since_the_epoch (or 0 if you want to use the weewx computer > dateTime) > > Maybe you're just missing the TIME mapping in your weewx.conf label map. > > Can you provide: > >- your [wxMesh] stanza from weewx.conf >- an example of the MQTT payload you're sending > > > Ah, Vince may be on to something. This is my weewx.comf, Ralph. Note the TIME = dateTime mapping [wxMesh] driver = user.wxMesh # MQTT specifics host = localhost # MQTT broker hostname client = *redacted* username = *redacted* password = *redacted* topic = weather # topic is all weather (indoor and outdoor, e.g.) poll_interval = 10 [[label_map]] TIME = dateTime HUMT = outTemp RHUM = outHumidity INTE = inTemp INHU = inHumidity BARP = barometer IRRA = radiation PHOV = supplyVoltage BATV = consBatteryVoltage AMBT = extraTemp1 SYST = extraTemp2 WDIR = windDir WIND = windSpeed > > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Wednesday, April 11, 2018 at 11:54:47 AM UTC-7, Ralph Underwood wrote: > > Do I need to have TIME = date-time in my weewx..conf wxMesh stanza? > > > Thinking not - I think you need: 1. a "SOMETHING = dateTime" mapping in your weewx.conf file so the driver knows what element is secs since the time epoch 2. a "SOMETHING: nnn" key/value pair in your MQTT payload, where nnn = secs_since_the_epoch (or 0 if you want to use the weewx computer dateTime) Maybe you're just missing the TIME mapping in your weewx.conf label map. Can you provide: - your [wxMesh] stanza from weewx.conf - an example of the MQTT payload you're sending -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Do I need to have TIME = date-time in my weewx..conf wxMesh stanza? I thought that the TIME sent from mosquitto would be ignored. I attempted Vince's suggestion and still same. I'll look it all over again later. Thanks On Wednesday, April 11, 2018 at 11:24:38 AM UTC-7, vince wrote: > > On Wednesday, April 11, 2018 at 10:06:22 AM UTC-7, Bill Morrow wrote: >> >> Line 308 in wxservices.py is failing: >> 306 data['maxSolarRad'] = weewx.wxformulas.solar_rad_RS( >> 307 self.latitude, self.longitude, self.altitude_m, >> 308 data['dateTime'], self.atc) >> >> >> > I'm wondering if perhaps you have no 'dateTime' in the data[] that you > are generating > > If you're ok with hacking+slashing in there with a test copy of that file, > I'd suggest trying to print 'data' out and see what's in there > > Something like (untested): > >else: >try: > # the existing stuff on lines 306-308 >except: > print data > > > > > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Wednesday, 11 April 2018 15:24:38 UTC-3, vince wrote:
>
> On Wednesday, April 11, 2018 at 10:06:22 AM UTC-7, Bill Morrow wrote:
>>
>> Line 308 in wxservices.py is failing:
>> 306 data['maxSolarRad'] = weewx.wxformulas.solar_rad_RS(
>> 307 self.latitude, self.longitude, self.altitude_m,
>> 308 data['dateTime'], self.atc)
>>
>>
>>
> I'm wondering if perhaps you have no 'dateTime' in the data[] that you
> are generating
>
> If you're ok with hacking+slashing in there with a test copy of that file,
> I'd suggest trying to print 'data' out and see what's in there
>
> Something like (untested):
>
>else:
>try:
> # the existing stuff on lines 306-308
>except:
> print data
>
>
>
>
That's right Vince, there is no dateTime in the incoming record. It
presumably gets created during processing of the packet, or not in Ralph's
case.
I don't have his problem. We are both subscribed to the same type of
incoming data from the MQTT broker.
I tried your suggestion. Added line 309 to wxservices.py,
299 def calc_maxSolarRad(self, data, data_type): # @UnusedVariable
300 algo = self.algorithms.get('maxSolarRad', 'RS')
301 if algo == 'Bras':
302 data['maxSolarRad'] = weewx.wxformulas.solar_rad_Bras(
303 self.latitude, self.longitude, self.altitude_m,
304 data['dateTime'], self.nfac)
305 else:
306 data['maxSolarRad'] = weewx.wxformulas.solar_rad_RS(
307 self.latitude, self.longitude, self.altitude_m,
308 data['dateTime'], self.atc)
309 syslog.syslog(syslog.LOG_INFO, "calc_maxSolarRad:
datetime error %s" % ' '.join(str(v)+':'+str(data[v]) for v in data))
changed debug to 1 in weewx.conf, stopped and restarted weewxd, and
datetime looks OK:
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: Queue of 2 entries
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: Working on queue entry 1 with
payload : TIME:0,INTE:21.79,INHU:31.38
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: TIME value: 1523472250
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None rainRate:0 heatindex:None
maxSolarRad:None dateTime:1523472250.0 windDir:None pressure:None inDewpoint
:None altimeter:None usUnits:1 windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: INTE value: 21.79
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None inDewpoint:None heatindex:None
rainRate:0 maxSolarRad:None dateTime:1523472250.0 windDir:None pressure:None
inTemp:71.222 altimeter:None usUnits:1 windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: INHU value: 31.38
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None inDewpoint:39.3382446966
heatindex:None rainRate:0 maxSolarRad:None dateTime:1523472250.0 windDir:
None pressure:None inHumidity:31.38 inTemp:71.222 altimeter:None usUnits:1
windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: Working on queue entry 0 with
payload : TIME:0,INTE:21.81,INHU:31.46
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: TIME value: 1523472250
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None rainRate:0 heatindex:None
maxSolarRad:None dateTime:1523472250.0 windDir:None pressure:None inDewpoint
:None altimeter:None usUnits:1 windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: INTE value: 21.81
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None inDewpoint:None heatindex:None
rainRate:0 maxSolarRad:None dateTime:1523472250.0 windDir:None pressure:None
inTemp:71.258 altimeter:None usUnits:1 windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: key: INHU value: 31.46
Apr 11 15:44:10 walrus weewx[10068]: calc_maxSolarRad: datetime error
barometer:None windchill:None dewpoint:None inDewpoint:39.4347791969
heatindex:None rainRate:0 maxSolarRad:None dateTime:1523472250.0 windDir:
None pressure:None inHumidity:31.46 inTemp:71.258 altimeter:None usUnits:1
windGustDir:None
Apr 11 15:44:10 walrus weewx[10068]: wxMesh: Sleeping for 20
Apr 11 15:44:14 walrus weewx[10068]: wxMesh: Added to queue of 1 message
TIME:0,INTE:21.80,INHU:31.46
>
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
On Wednesday, April 11, 2018 at 10:06:22 AM UTC-7, Bill Morrow wrote: > > Line 308 in wxservices.py is failing: > 306 data['maxSolarRad'] = weewx.wxformulas.solar_rad_RS( > 307 self.latitude, self.longitude, self.altitude_m, > 308 data['dateTime'], self.atc) > > > I'm wondering if perhaps you have no 'dateTime' in the data[] that you are generating If you're ok with hacking+slashing in there with a test copy of that file, I'd suggest trying to print 'data' out and see what's in there Something like (untested): else: try: # the existing stuff on lines 306-308 except: print data -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
I didn't start a discussion on that but I will look for it. I have been searching for a post where (I thought it was mwall) mentions setting the dateTime to something to force weewx to use the correct one. Or maybe it was a dream :) Thanks for your help. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Doh! Your system time is right there in front of me:
> Apr 11 08:03:22 mapleleaf weewx[4079]: wxMesh: key: TIME value:
> 1523459002
>
According to epochconverter:
Conversion results (1523459002)
1523459002 converts to Wednesday April 11, 2018 08:03:22 (am) in time zone
America/Vancouver
(PDT)
The offset (difference to Greenwich Time/GMT) is -07:00 or in seconds
-25200.
So there is no problem with time.
Line 308 in wxservices.py is failing:
299 def calc_maxSolarRad(self, data, data_type): # @UnusedVariable
300 algo = self.algorithms.get('maxSolarRad', 'RS')
301 if algo == 'Bras':
302 data['maxSolarRad'] = weewx.wxformulas.solar_rad_Bras(
303 self.latitude, self.longitude, self.altitude_m,
304 data['dateTime'], self.nfac)
305 else:
306 data['maxSolarRad'] = weewx.wxformulas.solar_rad_RS(
307 self.latitude, self.longitude, self.altitude_m,
308 data['dateTime'], self.atc)
presumably because dateTime is a bad value, or has not been set. I'm not
sure where dateTime is calculated. It most certainly is done after wxMesh
finishes with genLoopPackets. It looks like you have started a discussion
on that in the development group.
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
pi@mapleleaf:~ $ date +%s 1523465424 pi@mapleleaf:~ $ date Wed Apr 11 09:50:28 PDT 2018 appears to match my iMac time. The Rpi does not have a realtime clock; however I have a couple in my parts drawer. I will find a battery and try one of them. I programmed the Huzzah with another Rpi - when I do a date +%s on both of them as fast as I can click the results are 1523465622 and 1523465625 - I think that they are pretty close considering I have to change windows and click. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Comments imbedded On Wednesday, 11 April 2018 12:17:23 UTC-3, Ralph Underwood wrote: > > Hi Bill > > I rebuilt my development system, installed Jessie, configured rpi, > installed Mosquitto and weewx with the simulator. Attempted to do the > extension install of wxMesh, that failed so I manually installed the wxMesh > file in /usr/share/weewx/user. Changed the driver to wxMesh and made > changes to weewx.conf as described in wxMesh.py. > > Now I am getting this: (my comments are in* blue*) > ... > > Apr 11 08:03:18 mapleleaf weewx[4079]: wxMesh: Added to queue of 1 message > TIME:0,INTE:20.35,INHU:52.23* looks good to me* > *Yes, looks good* > Apr 11 08:03:22 mapleleaf weewx[4079]: wxMesh: Working on queue of 1 > Apr 11 08:03:22 mapleleaf weewx[4079]: wxMesh: Working on queue 0 payload > : TIME:0,INTE:20.35,INHU:52.23 > Apr 11 08:03:22 mapleleaf weewx[4079]: wxMesh: key: TIME value: 1523459002 >*what?? * > *I replace the time of 0 with the current epoch time within the driver. My outdoor hardware can't yet provide reliable time stamps. 1523459002 looks right, check at http://epochconverter.com* > Apr 11 08:03:22 mapleleaf weewx[4079]: engine: Main loop exiting. Shutting > engine down. > Apr 11 08:03:22 mapleleaf weewx[4079]: engine: Caught unrecoverable > exception in engine: > Apr 11 08:03:22 mapleleaf weewx[4079]: 'dateTime' > Apr 11 08:03:22 mapleleaf weewx[4079]: Traceback (most recent > call last): > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/engine.py", line 871, in main > Apr 11 08:03:22 mapleleaf weewx[4079]: engine.run() > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/engine.py", line 190, in run > Apr 11 08:03:22 mapleleaf weewx[4079]: > self.dispatchEvent(weewx.Event(weewx.NEW_LOOP_PACKET, packet=packet)) > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/engine.py", line 223, in dispatchEvent > Apr 11 08:03:22 mapleleaf weewx[4079]: callback(event) > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/wxservices.py", line 45, in new_loop_packet > Apr 11 08:03:22 mapleleaf weewx[4079]: > self.calc.do_calculations(event.packet, 'loop') > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/wxservices.py", line 191, in do_calculations > Apr 11 08:03:22 mapleleaf weewx[4079]: getattr(self, 'calc_' > + obs)(data_us, data_type) > Apr 11 08:03:22 mapleleaf weewx[4079]: File > "/usr/share/weewx/weewx/wxservices.py", line 308, in calc_maxSolarRad > Apr 11 08:03:22 mapleleaf weewx[4079]: data['dateTime'], > self.atc) > Apr 11 08:03:22 mapleleaf weewx[4079]: KeyError: 'dateTime' > Apr 11 08:03:22 mapleleaf weewx[4079]: Exiting. > > I seem to remember seeing a post about setting dateTime somewhere but > can't find that post. > Possibly your Pi's time is off, which is why the calculation in wxservices.py is failing. If you go to a shell prompt, and type these commands, what do you get? date +%s date The first command gives you the time in seconds since 1970-01-01 00:00 UTC, the "epoch time", the second command in something humanly readable. On my raspbian: > date +%s 1523463375 > date Wed 11 Apr 16:16:19 UTC 2018 There's some discussion on getting the time set at boot for raspbian here: https://raspberrypi.stackexchange.com/questions/8231/how-to-force-ntpd-to-update-date-time-after-boot -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Hi Bill
I rebuilt my development system, installed Jessie, configured rpi,
installed Mosquitto and weewx with the simulator. Attempted to do the
extension install of wxMesh, that failed so I manually installed the wxMesh
file in /usr/share/weewx/user. Changed the driver to wxMesh and made
changes to weewx.conf as described in wxMesh.py.
Now I am getting this: (my comments are in* blue*)
Apr 11 08:03:17 mapleleaf systemd[1]: Starting LSB: weewx weather system...
Apr 11 08:03:17 mapleleaf weewx[4075]: engine: Initializing weewx version
3.8.0
Apr 11 08:03:17 mapleleaf weewx[4075]: engine: Using Python 2.7.9 (default,
Sep 17 2016, 20:26:04) #012[GCC 4.9.2]
Apr 11 08:03:17 mapleleaf weewx[4075]: engine: Platform
Linux-4.9.35-v7+-armv7l-with-debian-8.0
Apr 11 08:03:17 mapleleaf weewx[4075]: engine: Locale is 'en_US.UTF-8'
Apr 11 08:03:17 mapleleaf weewx[4075]: engine: pid file is
/var/run/weewx.pid
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Using configuration file
/etc/weewx/weewx.conf
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: debug is 1
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Initializing engine
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading station type wxMesh
(user.wxMesh)
Apr 11 08:03:17 mapleleaf weewx[4065]: Starting weewx weather system: weewx.
Apr 11 08:03:17 mapleleaf systemd[1]: Started LSB: weewx weather system.
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: MQTT host is 10.0.0.161
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: MQTT topic is weather
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: MQTT client is wxclient
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: polling interval is 5.0
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: label map is {'INTE':
'inTemp', 'INHU': 'outHumidity'}
Apr 11 08:03:17 mapleleaf weewx[4079]: wxMesh: Connected to MQTT
*(I edited this message in wxMesh
while troubleshooting - used to say "Connected)*
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.engine.StdTimeSynch
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.engine.StdTimeSynch
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.engine.StdConvert
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: StdConvert target unit is 0x1
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.engine.StdConvert
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.engine.StdCalibrate
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.engine.StdCalibrate
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.engine.StdQC
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.engine.StdQC
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.wxservices.StdWXCalculate
Apr 11 08:03:17 mapleleaf weewx[4079]: wxcalculate: The following values
will be calculated: barometer=prefer_hardware, windchill=prefer_hardware,
dewpoint=prefer_hardware, appTemp=prefer_hardware,
rainRate=prefer_hardware, windrun=prefer_hardware,
heatindex=prefer_hardware, maxSolarRad=prefer_hardware,
humidex=prefer_hardware, pressure=prefer_hardware,
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
cloudbase=prefer_hardware
Apr 11 08:03:17 mapleleaf weewx[4079]: wxcalculate: The following
algorithms will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.wxservices.StdWXCalculate
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.engine.StdArchive
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Archive will use data
binding wx_binding
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Record generation will be
attempted in 'hardware'
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Using archive interval of
300 seconds (specified in weewx configuration)
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Use LOOP data in hi/low
calculations: 1
Apr 11 08:03:17 mapleleaf weewx[4079]: manager: Daily summary version is 2.0
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Using binding 'wx_binding'
to database 'weewx.sdb'
Apr 11 08:03:17 mapleleaf weewx[4079]: manager: Starting backfill of daily
summaries
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.engine.StdArchive
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.restx.StdStationRegistry
Apr 11 08:03:17 mapleleaf weewx[4079]: restx: StationRegistry: Registration
not requested.
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.restx.StdStationRegistry
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Loading service
weewx.restx.StdWunderground
Apr 11 08:03:17 mapleleaf weewx[4079]: restx: Wunderground: Posting not
enabled.
Apr 11 08:03:17 mapleleaf weewx[4079]: engine: Finished loading service
weewx.restx.StdWunderground
[weewx-user] Re: Using WeeWxMQTT - problems
That looks good. The debug messages from the sketch are showing the right message format. I don't think you need my sketch, yours is publishing OK now. Eventually (depending on your mosquitto persistence settings) the bad messages will disappear. Googling will reveal methods to clear them out faster. I'm fairly clueless in this area, but I think if you run mosquitto_sub as the same client as weewx/wxMesh, it will clear them out. It might already be cleared from what I see below. Make sure not to run mosquitto_sub as the same client as weewx when you want data to go to weewx. The other might pick up the subscription first. It looks like mosquitto_sub is picking a client name at random for you? On Tuesday, 10 April 2018 14:35:14 UTC-3, Ralph Underwood wrote: > > I restarted mosquitto and when I use mosquitto_sub -d -t weather I get: > > Client mosqsub|16684-ru-pi sending CONNECT > Client mosqsub|16684-ru-pi received CONNACK > Client mosqsub|16684-ru-pi sending SUBSCRIBE (Mid: 1, Topic: weather, QoS: > 0) > Client mosqsub|16684-ru-pi received SUBACK > Subscribed (mid: 1): 0 > Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r1, m0, 'weather', > ... (11 bytes)) > *temperature* > Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r0, m0, 'weather', > ... (10 bytes)) > INTE:72.50 > Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r0, m0, 'weather', > ... (10 bytes)) > INTE:72.39 > > So I need to figure out how to clear the buffer. > > Don't worry about insulting me. Many have said I know just enough to be > dangerous. I fairly sure that I made the sketch changes. Will verify that. > > With each run of the sketch loop I get something like: > 20.50 > 68.79 > Published: INTE:68.79 > > The first two lines are serial printing the temp in C and then my > converted to F value. > > > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Thanks Bill. I have to go to my tax guy. When I get back I will reconfigure my development set up with a clean install and use my Huzzah and HTU21 and your sketch. Thanks again! On Tuesday, April 10, 2018 at 10:14:40 AM UTC-7, Bill Morrow wrote: > > On Tuesday, 10 April 2018 12:44:32 UTC-3, Ralph Underwood wrote: >>> >>> I understand that you are using the HTU21 and think that it might be >>> best if I concentrate on that setup. Can you post the actual sketch you >>> are using? >>> >> > Attached. I use an Adafruit Feather Huzzah, > -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
I restarted mosquitto and when I use mosquitto_sub -d -t weather I get: Client mosqsub|16684-ru-pi sending CONNECT Client mosqsub|16684-ru-pi received CONNACK Client mosqsub|16684-ru-pi sending SUBSCRIBE (Mid: 1, Topic: weather, QoS: 0) Client mosqsub|16684-ru-pi received SUBACK Subscribed (mid: 1): 0 Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r1, m0, 'weather', ... (11 bytes)) *temperature* Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r0, m0, 'weather', ... (10 bytes)) INTE:72.50 Client mosqsub|16684-ru-pi received PUBLISH (d0, q0, r0, m0, 'weather', ... (10 bytes)) INTE:72.39 So I need to figure out how to clear the buffer. Don't worry about insulting me. Many have said I know just enough to be dangerous. I fairly sure that I made the sketch changes. Will verify that. With each run of the sketch loop I get something like: 20.50 68.79 Published: INTE:68.79 The first two lines are serial printing the temp in C and then my converted to F value. -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
> > On Tuesday, 10 April 2018 12:44:32 UTC-3, Ralph Underwood wrote: >> >> I understand that you are using the HTU21 and think that it might be best >> if I concentrate on that setup. Can you post the actual sketch you are >> using? >> > Attached. I use an Adafruit Feather Huzzah, -- 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 weewx-user+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. wxIndoorHuzzah.ino Description: Binary data
[weewx-user] Re: Using WeeWxMQTT - problems
Hmm, this debug in the log
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: Added to queue of 1 message
temperature
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: Working on queue 0 payload :
temperature
means that wxMesh is still getting the message "temperature" through its
subscription to:
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT host is 10.0.0.161
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT topic is weather
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT client is wxclient
It's possible that your MQTT broker has a number of those bad messages
buffered? Try restarting it?
Not to be insulting - are you sure your fixed sketch was uploaded? What
does the ESP8266 serial console output for these print statements:
Serial.print("Published: "); Serial.println(charBuf);
On Tuesday, 10 April 2018 12:44:32 UTC-3, Ralph Underwood wrote:
>
> Thanks Bill for the reply.
>
> I am now sending
>
> INTE:68.11
>
> via mqtt
>
> I do note that I do not have TIME in my mqtt message.
>
>
> WeeWx still not happy with this as the log after starting:
>
> Apr 10 08:24:14 ru-pi systemd[1]: Starting LSB: weewx weather system...
> Apr 10 08:24:14 ru-pi weewx[6379]: engine: Initializing weewx version 3.8.0
> Apr 10 08:24:14 ru-pi weewx[6379]: engine: Using Python 2.7.9 (default,
> Sep 17 2016, 20:26:04) #012[GCC 4.9.2]
> Apr 10 08:24:14 ru-pi weewx[6379]: engine: Platform
> Linux-4.9.35-v7+-armv7l-with-debian-8.0
> Apr 10 08:24:14 ru-pi weewx[6379]: engine: Locale is 'en_US.UTF-8'
> Apr 10 08:24:14 ru-pi weewx[6379]: engine: pid file is /var/run/weewx.pid
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Using configuration file
> /etc/weewx/weewx.conf
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: debug is 1
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Initializing engine
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading station type wxMesh
> (user.wxMesh)
> Apr 10 08:24:14 ru-pi weewx[6369]: Starting weewx weather system: weewx.
> Apr 10 08:24:14 ru-pi systemd[1]: Started LSB: weewx weather system.
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT host is 10.0.0.161
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT topic is weather
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT client is wxclient
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: polling interval is 5.0
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: label map is {'TIME':
> 'dateTime', 'INTE': 'outTemp', 'INHU': 'inHumidity'}
> Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: Connected
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.engine.StdTimeSynch
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> weewx.engine.StdTimeSynch
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> user.owfs.OWFSService
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: service version is 0.21
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: binding is archive
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: interface is u
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor map is {'extraTemp':
> '/uncached/28.7A06/temperature', 'inTemp':
> '/uncached/28.03CF0806/temperature'}
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor type map is {}
> Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor unit system is metric
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> user.owfs.OWFSService
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.engine.StdConvert
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: StdConvert target unit is 0x1
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> weewx.engine.StdConvert
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.engine.StdCalibrate
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> weewx.engine.StdCalibrate
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.engine.StdQC
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> weewx.engine.StdQC
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.wxservices.StdWXCalculate
> Apr 10 08:24:14 ru-pi weewx[6385]: wxcalculate: The following values will
> be calculated: barometer=prefer_hardware, windchill=prefer_hardware,
> dewpoint=prefer_hardware, appTemp=prefer_hardware,
> rainRate=prefer_hardware, windrun=prefer_hardware,
> heatindex=prefer_hardware, maxSolarRad=prefer_hardware,
> humidex=prefer_hardware, pressure=prefer_hardware,
> inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
> cloudbase=prefer_hardware
> Apr 10 08:24:14 ru-pi weewx[6385]: wxcalculate: The following algorithms
> will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
> weewx.wxservices.StdWXCalculate
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
> weewx.engine.StdArchive
> Apr 10 08:24:14 ru-pi weewx[6385]: engine: Archive will use data binding
> wx_binding
> Apr 10 08:24:14 ru-pi weewx[6385]:
[weewx-user] Re: Using WeeWxMQTT - problems
Thanks Bill for the reply.
I am now sending
INTE:68.11
via mqtt
I do note that I do not have TIME in my mqtt message.
WeeWx still not happy with this as the log after starting:
Apr 10 08:24:14 ru-pi systemd[1]: Starting LSB: weewx weather system...
Apr 10 08:24:14 ru-pi weewx[6379]: engine: Initializing weewx version 3.8.0
Apr 10 08:24:14 ru-pi weewx[6379]: engine: Using Python 2.7.9 (default, Sep
17 2016, 20:26:04) #012[GCC 4.9.2]
Apr 10 08:24:14 ru-pi weewx[6379]: engine: Platform
Linux-4.9.35-v7+-armv7l-with-debian-8.0
Apr 10 08:24:14 ru-pi weewx[6379]: engine: Locale is 'en_US.UTF-8'
Apr 10 08:24:14 ru-pi weewx[6379]: engine: pid file is /var/run/weewx.pid
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Using configuration file
/etc/weewx/weewx.conf
Apr 10 08:24:14 ru-pi weewx[6385]: engine: debug is 1
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Initializing engine
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading station type wxMesh
(user.wxMesh)
Apr 10 08:24:14 ru-pi weewx[6369]: Starting weewx weather system: weewx.
Apr 10 08:24:14 ru-pi systemd[1]: Started LSB: weewx weather system.
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT host is 10.0.0.161
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT topic is weather
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: MQTT client is wxclient
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: polling interval is 5.0
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: label map is {'TIME':
'dateTime', 'INTE': 'outTemp', 'INHU': 'inHumidity'}
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: Connected
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.engine.StdTimeSynch
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.engine.StdTimeSynch
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
user.owfs.OWFSService
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: service version is 0.21
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: binding is archive
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: interface is u
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor map is {'extraTemp':
'/uncached/28.7A06/temperature', 'inTemp':
'/uncached/28.03CF0806/temperature'}
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor type map is {}
Apr 10 08:24:14 ru-pi weewx[6385]: owfs: sensor unit system is metric
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
user.owfs.OWFSService
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.engine.StdConvert
Apr 10 08:24:14 ru-pi weewx[6385]: engine: StdConvert target unit is 0x1
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.engine.StdConvert
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.engine.StdCalibrate
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.engine.StdCalibrate
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.engine.StdQC
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.engine.StdQC
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.wxservices.StdWXCalculate
Apr 10 08:24:14 ru-pi weewx[6385]: wxcalculate: The following values will
be calculated: barometer=prefer_hardware, windchill=prefer_hardware,
dewpoint=prefer_hardware, appTemp=prefer_hardware,
rainRate=prefer_hardware, windrun=prefer_hardware,
heatindex=prefer_hardware, maxSolarRad=prefer_hardware,
humidex=prefer_hardware, pressure=prefer_hardware,
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
cloudbase=prefer_hardware
Apr 10 08:24:14 ru-pi weewx[6385]: wxcalculate: The following algorithms
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.wxservices.StdWXCalculate
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.engine.StdArchive
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Archive will use data binding
wx_binding
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Record generation will be
attempted in 'hardware'
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Using archive interval of 300
seconds (specified in weewx configuration)
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Use LOOP data in hi/low
calculations: 1
Apr 10 08:24:14 ru-pi weewx[6385]: wxMesh: Added to queue of 1 message
temperature
Apr 10 08:24:14 ru-pi weewx[6385]: manager: Daily summary version is 2.0
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Using binding 'wx_binding' to
database 'weewx.sdb'
Apr 10 08:24:14 ru-pi weewx[6385]: manager: Starting backfill of daily
summaries
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.engine.StdArchive
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading service
weewx.restx.StdStationRegistry
Apr 10 08:24:14 ru-pi weewx[6385]: restx: StationRegistry: Registration not
requested.
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Finished loading service
weewx.restx.StdStationRegistry
Apr 10 08:24:14 ru-pi weewx[6385]: engine: Loading
[weewx-user] Re: Using WeeWxMQTT - problems
Sigh, pushed Post too quickly. The correct suggested change to your
sketch...
There's also some problems with that if block. Try changing dataString to a
> message that wxMesh can parse, for example
>if((temp > -20) && (temp <110))
>{
> char temperatureStr[6];
> dtostrf(temp, 4, 2, temperatureStr); // ESP8266 does not convert
> doubles to Strings
> dataString = String("INTE:") + temperatureStr;
> dataString.toCharArray(charBuf, 150);
> client.publish(topic,charBuf );
> Serial.print("Published: "); Serial.println(charBuf);
>}
On Friday, 6 April 2018 13:27:31 UTC-3, Ralph Underwood wrote:
>
> One station uses a Ultimeter 2100 driver -* can I use WeeWxMQTT as a
> service*?
>
Not yet. There is a discussion about this in the development group.
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
Ralph, this line in the log file:
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: Working on queue 0 payload :
temperature
means that your sketch has published a message of the string "temperature".
Looking at your sketch, it looks like it might have
if((temp > -20) && (temp <110))
dataString = String("{\"temperature\":") + temp + String("}"); <--
not in a format which wxMesh can parse
dataString.toCharArray(charBuf, 150);
{
client.publish(topic,charBuf );
}
There's also some problems with that if block. Try changing dataString to a
message that wxMesh can parse, for example
if((temp > -20) && (temp <110))
{
dataString = String("{\"temperature\":") + temp + String("}");
dataString.toCharArray(charBuf, 150);
client.publish(topic,charBuf );
Serial.print("Published: "); Serial.println(charBuf);
}
Also weewx can do data quality
control: http://weewx.com/docs/usersguide.htm#StdQC. I would recommend
passing whatever you get from the sensor on to weewx, and set it up to
decide if the data are good.
wxMesh does not quite read JSON format, it reads key:value pairs separated
by commas, with the key and value separated by a colon.
Here are the last two publications to my mosquitto broker, which will be
consolidated into weewx by the wxMesh driver.
TIME:0,INTE:20.03,INHU:33.00
TIME:0,AMBT: 0.59,BARP:1022.26,RHUM:64.87,HUMT:
0.57,IRRA:16,BATV:1010,PHOV:383,SYST:32.20,WIND: 0.0,WDIR: 0.0
The first was published by an ESP8266 which is indoors, the second is from
my outside homebrew station, relayed by a 2.4GHz radio to ethernet broker.
I have indefinite plans to change the message format to JSON.
--
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 weewx-user+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Using WeeWxMQTT - problems
I found some goof info on the development group and got closer to a working
setup. I purchased an Adafruit HTU21 sensor board and using Bill Morrows
code example I now get MQTT output like this:
TIME:0,INTE:19.36,INHU:59.75
TIME:0,INTE:19.35,INHU:59.74
TIME:0,INTE:19.35,INHU:59.88
TIME:0,INTE:19.32,INHU:59.83
*WeeWx still is not happy as I get this after starting WeeWX:*
Apr 7 18:59:33 ru-pi systemd[1]: Starting LSB: weewx weather system...
Apr 7 18:59:33 ru-pi weewx[19707]: engine: Initializing weewx version 3.8.0
Apr 7 18:59:33 ru-pi weewx[19707]: engine: Using Python 2.7.9 (default,
Sep 17 2016, 20:26:04) #012[GCC 4.9.2]
Apr 7 18:59:33 ru-pi weewx[19707]: engine: Platform
Linux-4.9.35-v7+-armv7l-with-debian-8.0
Apr 7 18:59:33 ru-pi weewx[19707]: engine: Locale is 'en_US.UTF-8'
Apr 7 18:59:33 ru-pi weewx[19707]: engine: pid file is /var/run/weewx.pid
Apr 7 18:59:33 ru-pi weewx[19697]: Starting weewx weather system: weewx.
Apr 7 18:59:33 ru-pi systemd[1]: Started LSB: weewx weather system.
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Using configuration file
/etc/weewx/weewx.conf
Apr 7 18:59:33 ru-pi weewx[19737]: engine: debug is 1
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Initializing engine
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading station type wxMesh
(user.wxMesh)
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: MQTT host is localhost
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: MQTT topic is weather
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: MQTT client is wxclient
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: polling interval is 5.0
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: label map is {'INTE':
'outTemp', 'INHU': 'inHumidity'}
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: Connected
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.engine.StdTimeSynch
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.engine.StdTimeSynch
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
user.owfs.OWFSService
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: service version is 0.21
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: binding is archive
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: interface is u
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: sensor map is {'extraTemp':
'/uncached/28.7A06/temperature', 'inTemp':
'/uncached/28.03CF0806/temperature'}
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: sensor type map is {}
Apr 7 18:59:33 ru-pi weewx[19737]: owfs: sensor unit system is metric
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
user.owfs.OWFSService
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.engine.StdConvert
Apr 7 18:59:33 ru-pi weewx[19737]: engine: StdConvert target unit is 0x1
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.engine.StdConvert
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.engine.StdCalibrate
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.engine.StdCalibrate
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.engine.StdQC
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.engine.StdQC
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.wxservices.StdWXCalculate
Apr 7 18:59:33 ru-pi weewx[19737]: wxcalculate: The following values will
be calculated: barometer=prefer_hardware, windchill=prefer_hardware,
dewpoint=prefer_hardware, appTemp=prefer_hardware,
rainRate=prefer_hardware, windrun=prefer_hardware,
heatindex=prefer_hardware, maxSolarRad=prefer_hardware,
humidex=prefer_hardware, pressure=prefer_hardware,
inDewpoint=prefer_hardware, ET=prefer_hardware, altimeter=prefer_hardware,
cloudbase=prefer_hardware
Apr 7 18:59:33 ru-pi weewx[19737]: wxcalculate: The following algorithms
will be used for calculations: altimeter=aaNOAA, maxSolarRad=RS
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.wxservices.StdWXCalculate
Apr 7 18:59:33 ru-pi weewx[19737]: wxMesh: Added to queue of 1 message
temperature
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.engine.StdArchive
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Archive will use data binding
wx_binding
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Record generation will be
attempted in 'hardware'
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Using archive interval of 300
seconds (specified in weewx configuration)
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Use LOOP data in hi/low
calculations: 1
Apr 7 18:59:33 ru-pi weewx[19737]: manager: Daily summary version is 2.0
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Using binding 'wx_binding' to
database 'weewx.sdb'
Apr 7 18:59:33 ru-pi weewx[19737]: manager: Starting backfill of daily
summaries
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Finished loading service
weewx.engine.StdArchive
Apr 7 18:59:33 ru-pi weewx[19737]: engine: Loading service
weewx.restx.StdStationRegistry
Apr 7 18:59:33 ru-pi
