Ok, closing the loop here. It appears that when you use anonymous login to an MQTT broker, everything works fine and it will publish individual measurements properly. When you utilize a username/password, this is when things break, and individual measurements do not work.
For my purposes, it's all on the internal network and I can simply use anonymous publishing over 1883. If someone else can test individual records via a broker with username/pass authentication and it does work, I would be very interested to know what you did here. On Friday, March 8, 2019 at 9:30:25 PM UTC-5, bdf0506 wrote: > > Turns out, it's something with my mosquito config. I'm not sure what > exactly is wrong with the config, but I tried pushing the data to a public > broker, and when I push it to a public broker, the individual stats ARE in > fact coming through. I'll investigate there, but can safely say that it is > not a weewx issue. > > On Friday, March 8, 2019 at 9:00:04 PM UTC-5, bdf0506 wrote: >> >> I did a fresh install of WeeWX, then installed the MQTT extension. I >> observed the same behavior - individual measurements is really just taking >> the first measurement from a long json string, and ignoring the rest. >> >> I even installed a couple of older versions of the MQTT extension, that >> still didn't work. I wonder if this has ever worked. >> >> Or maybe it is dependent on an older version of restx.py that has been >> updated, really hard to say. Curious if anyone else has run into this >> issue, as I am beating my head against a wall trying to figure this out. >> >> On Friday, March 8, 2019 at 2:04:09 PM UTC-5, bdf0506 wrote: >>> >>> When aggregate = individual, I am expecting it to NOT send in JSON >>> format, and instead send it just the individual metric to the topic of >>> /weewx/<mesurement>. I believe that is how yours is working today. If we >>> want to test with your instance, you can add -v to your mosquitto_sub query >>> and that will then show us the individual topics that are underneath the >>> topic of "weather" and that likely each measurement is a different subtopic. >>> >>> When weewx sends the JSON string, I am utilizing the loop bindings. With >>> loop bindings, the JSON strings will differ with each transmission since it >>> doesn't get everything on every reading. As a result of this, it makes it >>> rather difficult for my other application to interpret these JSON strings >>> since each one is different and not consistent. >>> >>> Other options will include defaulting back to archive bindings, but they >>> aren't real time enough for my application. If I do that, the JSON string >>> should be mostly uniform each time the archive runs. But once again, if I >>> select "individual" measurements when doing archive, I have the same issue, >>> where it will only parse the first reading of the JSON string. So instead I >>> have to use "aggregate" and parse the JSON string again, back to square >>> one, but at least now the JSON string should be a little more uniform. >>> >>> Overall I am pushing these measurements into MQTT so that I can set them >>> up as sensors within my home automation platform. I can probably do some >>> hackery to make my home automation platform properly decipher the JSON if I >>> need to. But overall this smells like a bug or configuration issue within >>> the MQTT extension for WeeWX. >>> >>> On Friday, March 8, 2019 at 1:44:46 PM UTC-5, HoracioDos wrote: >>>> >>>> Hi. >>>> I think I didn't fully understand your problem. When aggregate = >>>> individual mqtt extension does not send data to the broker in json format. >>>> Is that correct? I think that's how it works. >>>> If you want to select a specific data you must to subscribe to the >>>> proper topic. Why do you need individual values? Perhaps we can help you >>>> better if we know your needs. I'm sorry if I missed that in a previous >>>> question. >>>> >>> -- 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.
