Make sure you subscribe to the correct topic on your MQTT system. You should see the topic it publishes in the output. Also make sure that you have the db you specify defined in influxdb as well.
LOL - of course! It’s now working for me as well (actually it never was NOT working). The culprit in my case was the “-M” option that I was using along with the combined mqtt and influx arguments. That changed the mqtt topic, so I was not seeing the mqtt messages. Removed the “-M” and all is good now.
impossible to know for certain but possibilities include:
your db name is wrong in the command you mentioned
the ip is wrong or the port is wrong (less likey)
perhaps you need to also specify the influxdb username+password
at a minimum I’d suggest you try just the vanilla listener to make sure it hears something, before trying to have it publish to influxdb (as a second step)
listen.py --raw
# hit ^C a couple times to stop the process
raw is outputting data and I have tried a couple different databases with and without username password. Is there a way of debuging the stream going to influx?
You’d need to run a sniffer such as ethereal/wireshark, or do something with iptables to count packets coming into the database port on the db system or out of the nic on the listener system, or possibly run your influxdb process in a high debug level (no, I don’t know how to do that). Definitely make sure the database you’re trying to exists already and that the username/password are correct. Check that you have the case matching (I don’t know if influxdb is case-sensitive when you specify a db). Normal stuff.
Would be really nice if the listener could run properly as a service. I’ve tried doing so with the exact same parameters as the CLI, but it doesn’t actually collect any data when running as a service. For now I have it running in a screen session.
Other than “Would be really nice nice if…” you have provided really nothing I can use as info to even try to help you.
there is a systemd example in the github repo if you wanted to use that.
You could also old-school it via putting something like “nohup listener.py arg1 arg2 arg3 >/dev/null 2>&1” into your rc.local file.
You could also do something via @boot in your crontab.
Likely there are a dozen other ways to do it.
Unfortunately I no longer have any WF gear, so I can’t do too much to help edge cases like this one especially with such a skeletal problem description.
The systemd example is what I tried. It gives no indication that it is working, nor does it put anything into the database, using the same CLI parameters as manually running it.
I really can’t spare any time to work this one, given there are so many viable easy alternatives.
If you eventually get it working and find errors in my code or documentation, please submit a pull request on my github site and I’ll consider merging your changes. Thanks.
Hello! Loving my Weatherflow that I just installed. Was looking to grab some direct UDP metrics and dump them into a logging framework because I couldn’t get this script to work at first runaround. Came back around and tried again and for some reason, now working great! Going to polish up some Grafana dashboards once I get a few more created but just wanted to say an early thanks to @vinceskahan and the community for the efforts!
Adding a quick update that uses this WeatherFlow UDP collector as part of an All In One stack.
Would love any feedback on the dashboards based on other data/queries. Right now I just have one WeatherFlow Tempest - so the dashboards are geared towards a single device. But happy to make some other extensions to the dashboards as needed.