--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/ad3fe2f1-b6a6-4fc3-a2ce-23389815d8a0n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/0c40c0f0-9894-4794-a4b4-8e2e0e3d9fban%40googlegroups.com.
Makes sense that the lack of a clock would imply something else. But, what is it? Take a measured amount of water and pour it into the rain bucket. What do you see in the captured data?
Perhaps you have a unit conversion problem? The packet can use US, METRIC, or METRICWX unit systems (see the Appendix Units in the Customizing Guide for definitions), but whichever one you choose, all the data in the packet must conform to the chosen system.
You definitely do not want to set rainRate. It is typically a derived value, calculated by weewx from the stream of loop data. A few weather stations can calculate it themselves, but I'd be surprised if yours is one of them.
true if the incoming data is cumulative value (for example, rain total) and the WeeWX field expects an increment value.. The default is falseFinally, unless you have other reasons for wanting to use MQTT as an intermediary, there is a rtl-433 driver available for WeeWX. You could simplify your system by going directly from sensor to database by using it.
You received this message because you are subscribed to a topic in the Google Groups "weewx-user" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/weewx-user/ZMR4MWVakJk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to weewx-user+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEB%3D0a4LUzY9c%2Boav9mVcXLCN_L9kr2GzpWntBY6MsziSg%40mail.gmail.com.
wind_avg_km_h => There is no field for averages. It's calculated by WeeWX when needed.
wind_max_km_h => Field windGust
wind_dir_deg => Field windDir
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/87c74ce7-6991-46da-bdca-ef6eab5451acn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CACK8wijoHPpRQLMoQkODBCkDzWa1LhP%3DebSapX1AdhUqfqMpYQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/CAPq0zEAPAap-9zsRevPSOg60%3DrBwXoabSwFkG9is%3D9Jd0TSkoA%40mail.gmail.com.
[[topics]]unit_system = METRICuse_topic_as_fieldname = trueuse_server_datetime = True
[[[rtl_433/devices/Fineoffset-WHx080/temperature_C]]]name = outTemp[[[rtl_433/devices/Fineoffset-WHx080/humidity]]]name = outHumidity[[[rtl_433/devices/Fineoffset-WHx080/rain_mm]]]name = raincontains_total = Trueunits = mm
To view this discussion on the web visit https://groups.google.com/d/msgid/weewx-user/2c64067a-6ae0-4d5f-b457-85b0dd2711d4n%40googlegroups.com.
Let me try to give a better explanation. As Tom noted earlier, it doesn’t matter what the units of the data in the packet is. But, for a given packet all of the data ha to belong to one of the WeeWX unit_system, US, METRIC, or METRICWX.
Setting the unit_system under MQTTSubscribe controls what unit_system is in the packet that MQTTSubscribe creates. Normally (hopefully?) this the units of the data coming across MQTT. But, if any data coming over does not match the units expected by the unit_system value, it can be overridden by the unit value.
Or in other words, the unit_system and units value tell MQTTSubscribe the units of the incoming data. MQTTSubscribe will do any necessary conversion so that all the data in the packet belongs to the unit_system value.
And I’m sure that is now clear as mud...
rich