It sounds like your field "wind_avg_km_h" is actually current wind speed. Hopefully, by "average" they mean over the last few seconds, not minutes.
On Wed, Jan 13, 2021 at 7:13 AM Jonis Maurin Ceará <[email protected]> wrote: > Tks Rich, I'll do these changes right now and test. > > Tom, you've said: > >> 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 > > > I commented th 'wind_avg_km_h' and left only "wind_max_km_h" to > windGust.....but with this configuration, I got nothing on wind speed or > gust, just direction. > Both fields has values in MQTT......but if I don't map wind_avg_km_h to > windSpeed, I got nothing in reports. I'm not sure if I should map or not > this avg field to windSpeed. > > > > > Em qua., 13 de jan. de 2021 às 10:48, [email protected] < > [email protected]> escreveu: > >> Hi, >> If the incoming data, rain_mm, is cumulative then you want the WeeWX >> field rain and the option contains_total = true. This will convert the >> cumulative value into an increment value that WeeWX expects. >> rich >> >> On Wednesday, 13 January 2021 at 06:53:11 UTC-5 [email protected] wrote: >> >>> Hi Tom! >>> >>> Tks for your answer. >>> >>> 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? >>> >>> Well, I think the value is cummulative, but not for the last 24h, it's >>> forever (until reboots). At least it's what I'm seeing now. I'm monitoring >>> my MQTT and about 23h the sensor was reporting 2.1. Rain stopped (until >>> now, 08h35) and the sensor is still reporting 2.1 . I'll wait until 23h to >>> see if it will 'zero' the value after 24h. The station doesn't have a >>> clock, but it can 'count'....so reset after X hours is possible even >>> without a clock. >>> >>> 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. >>> >>> My sensor reports in mm, and I think it's correct.....the sensor name >>> irself is called 'rain_mm'. Since I'm using MQTTSubscribeDriver driver, I >>> have this set in driver section: >>> [[topics]] >>> unit_system = METRIC >>> use_topic_as_fieldname = true >>> use_server_datetime = True >>> >>> Them, my StdReports are set for METRIC too: >>> [[Defaults]] >>> [[[Units]]] >>> # The following section sets what unit to use for each unit >>> group. >>> # NB: The unit is always in the singular. I.e., >>> 'mile_per_hour', >>> # NOT 'miles_per_hour' >>> [[[[Groups]]]] >>> group_altitude = meter # Options are 'foot' or 'meter' >>> group_degree_day = degree_C_day # Options are >>> 'degree_F_day' or 'degree_C_day' >>> group_distance = km # Options are 'mile' or 'km' >>> group_pressure = mbar # Options are 'inHg', 'mmHg', >>> 'mbar', 'hPa', or 'kPa' >>> group_rain = mm # Options are 'inch', 'cm', or 'mm' >>> group_rainrate = mm_per_hour # Options are >>> 'inch_per_hour', 'cm_per_hour', or 'mm_per_hour' >>> group_speed = km_per_hour # Options are >>> 'mile_per_hour', 'km_per_hour', 'knot', or 'meter_per_second' >>> group_speed2 = km_per_hour2 # Options are >>> 'mile_per_hour2', 'km_per_hour2', 'knot2', or 'meter_per_second2' >>> group_temperature = degree_C # O >>> >>> >>> And in the StdConvert section, I left as 'US'. Should I change it to >>> METRIC too?? It's a brand new database, not merging new/old data. >>> >>> >>> 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. >>> >>> Maybe this is my mistake. I'm using rainRate for my rain_mm value. But >>> when I tried just 'rain', the values went totally crazy. I mean, 0.6 in >>> sensor was displaying about 88mm rainRate and 36mm total rain. There is an >>> option in the driver called 'contains_total'. I'm almost sure that my >>> sensor reports only totals (see my last answer in this e-mail), but I'll >>> make sure after 23h today. If this is the case, in which field should I use >>> this driver option, 'rain' or 'rainRate'? >>> This is the description of this option: >>> contains_total: >>> Set to *true* if the incoming data is cumulative value (for example, >>> rain total) and the WeeWX field expects an increment value.. The default is >>> false >>> >>> >>> >>> Finally, unless you have other reasons for wanting to use MQTT as an >>>> intermediary, there is a rtl-433 driver >>>> <https://github.com/matthewwall/weewx-sdr> available for WeeWX. You >>>> could simplify your system by going directly from sensor to database by >>>> using it. >>> >>> Well, here is why I'm not using rtl-433 driver directly: >>> 1) I'm running Weewx on my server (inside my house) >>> 2) Signal from the station could not get into my server if my dongle was >>> plugged there. >>> 3) I already have some raspberry pi's outside for other functions. I >>> just added a dongle to one rpi and started sending data to my MQTT server. >>> 4) I plan to include more sensor data from other sensors in the same >>> MQTT broker. Using this driver it's easier to merge all these sensors. >>> 4) I use all these MQTT data for my Home Assistant application too. >>> >>> >>> >>> Em ter., 12 de jan. de 2021 às 21:48, Tom Keffer <[email protected]> >>> escreveu: >>> >>>> Things to think about: >>>> >>>> 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. >>>> >>>> Finally, unless you have other reasons for wanting to use MQTT as an >>>> intermediary, there is a rtl-433 driver >>>> <https://github.com/matthewwall/weewx-sdr> available for WeeWX. You >>>> could simplify your system by going directly from sensor to database by >>>> using it. >>>> >>>> >>>> On Tue, Jan 12, 2021 at 3:03 PM [email protected] <[email protected]> >>>> wrote: >>>> >>>>> I don't think its based on daily rain. Why? Because it's a very simple >>>>> station and i'm pretty sure it doesn't have internal clock. I don't have >>>>> any way to set the clock in station....so how would it calculate >>>>> midnight?! >>>>> >>>>> This is my 'station': Spare part for weather station (Transmitter / >>>>> thermo hygro sensor) 433Mhz, with solar panel|Temperature Instruments| - >>>>> AliExpress >>>>> <https://www.aliexpress.com/item/32872784585.html?spm=a2g0s.9042311.0.0.27424c4dhJeTs7> >>>>> >>>>> I have a rain bucket attached to it. >>>>> To get data, I'm using rtl_433 to 'capture' the wireless data, >>>>> generate a JSON and send to my MQTT server. In Weewx, i'm >>>>> using WeeWX-MQTTSubscribe to get the data from MQTT server. >>>>> Everything is working fine now, except for the rain, which still twice >>>>> the reported value. >>>>> >>>>> >>>>> Em terça-feira, 12 de janeiro de 2021 às 19:41:32 UTC-3, >>>>> [email protected] escreveu: >>>>> >>>>>> There is no master list of all the database variables. >>>>>> >>>>>> However, there are some comments about rain in the section *Porting >>>>>> to new hardware* <http://www.weewx.com/docs/customizing.htm#porting> of >>>>>> the Customizing Guide. In particular, the field 'rain' should be the >>>>>> amount >>>>>> of rain that fell *during the period*. That is, if it's LOOP >>>>>> packets, it's the amount of rain that fell since the last LOOP packet, >>>>>> *not*, for example, the amount of rain for the day. >>>>>> >>>>>> I suspect your field rain_mm is the amount of rain that has fallen >>>>>> since midnight. As explained in the porting guide, you'll have to take >>>>>> deltas of that field to get the field rain. >>>>>> >>>>>> So, to answer your questions: >>>>>> >>>>>> rain_mm => If this is rain since midnight, it should be mapped to >>>>>> dayRain, which is not in the standard database schema, but is used by >>>>>> some >>>>>> uploaders. >>>>>> temperature_C => outTemp. Correct. >>>>>> humidity => outHumidity. Correct. >>>>>> >>>>>> 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 >>>>>> >>>>>> Please read the porting guide. Make sure your driver emits packets >>>>>> using a consistent unit system. The unit system used by the database >>>>>> doesn't matter. Incoming data will be converted automatically. >>>>>> >>>>>> -tk >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 12, 2021 at 2:11 PM [email protected] <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> Also, a second question: >>>>>>> >>>>>>> My station is reporting "0.6" in "rain_mm" field. It's a very light >>>>>>> rain now. I'm not sure if this is for the last hour or last 15 minutes. >>>>>>> The thing is that database is clean and in report generate, this is >>>>>>> what i'm getting for rain: >>>>>>> >>>>>>> Rain Rate 88.8 mm/h >>>>>>> Rain Today 36.0 mm >>>>>>> >>>>>>> >>>>>>> What am I missing? >>>>>>> >>>>>>> My units are set (globally in weewx.config) to METRIC. >>>>>>> >>>>>>> Em terça-feira, 12 de janeiro de 2021 às 18:50:23 UTC-3, >>>>>>> [email protected] escreveu: >>>>>>> >>>>>>>> Is there any list of fields and what it means in docs? >>>>>>>> >>>>>>>> I have some fields in my station but I'm not sure which field >>>>>>>> should be mapped to which field in DB. >>>>>>>> >>>>>>>> rain_mm => Currently mapped to 'rain' >>>>>>>> temperature_C => outTemp >>>>>>>> humidity => outHumidity >>>>>>>> >>>>>>>> wind_avg_km_h => not mapped, I'm not sure which is the correct >>>>>>>> field in DB >>>>>>>> wind_max_km_h => not mapped, I'm not sure which is the correct >>>>>>>> field in DB >>>>>>>> wind_dir_deg => not mapped, I'm not sure which is the correct field >>>>>>>> in DB >>>>>>>> >>>>>>>> >>>>>>>> I'm not an expert, so I don't have idea if I should use >>>>>>>> wind_avg_km_h for windSpeed, for example. >>>>>>>> >>>>>>>> I'm sorry if it's a dumb 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/weewx-user/ad3fe2f1-b6a6-4fc3-a2ce-23389815d8a0n%40googlegroups.com >>>>>>> <https://groups.google.com/d/msgid/weewx-user/ad3fe2f1-b6a6-4fc3-a2ce-23389815d8a0n%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>>> 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/0c40c0f0-9894-4794-a4b4-8e2e0e3d9fban%40googlegroups.com >>>>> <https://groups.google.com/d/msgid/weewx-user/0c40c0f0-9894-4794-a4b4-8e2e0e3d9fban%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>>> >>> 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 >>>> [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/weewx-user/CAPq0zEB%3D0a4LUzY9c%2Boav9mVcXLCN_L9kr2GzpWntBY6MsziSg%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/weewx-user/CAPq0zEB%3D0a4LUzY9c%2Boav9mVcXLCN_L9kr2GzpWntBY6MsziSg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> 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 >> [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/weewx-user/87c74ce7-6991-46da-bdca-ef6eab5451acn%40googlegroups.com >> <https://groups.google.com/d/msgid/weewx-user/87c74ce7-6991-46da-bdca-ef6eab5451acn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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/CACK8wijoHPpRQLMoQkODBCkDzWa1LhP%3DebSapX1AdhUqfqMpYQ%40mail.gmail.com > <https://groups.google.com/d/msgid/weewx-user/CACK8wijoHPpRQLMoQkODBCkDzWa1LhP%3DebSapX1AdhUqfqMpYQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAPq0zEAPAap-9zsRevPSOg60%3DrBwXoabSwFkG9is%3D9Jd0TSkoA%40mail.gmail.com.
