Ok, I will try this, and yes I should update the extension....thanks for 
the heads up.

On Wednesday, 25 October 2017 09:24:17 UTC-4, gjr80 wrote:
>
> The error below is due to a bug in the trend calculation code in the 
> realtime gauge-data extension. In this case the historical observation 
> being used in the trend calculation is None and that is throwing the error. 
> I will raise an issue and fix it in the next realtime gauge-data extension 
> release. In the meantime if you are up to it you can make the following 
> change to bin/user/rtgd.py line 1956 fix the problem:
>
>     if then_record is None:
>         return None
>     else:
>         if obs_type not in then_record or then_record[obs_type] is None:
>             return None
>         else:
>             then_vt = weewx.units.as_value_tuple(then_record, obs_type)
>             now = convert(now_vt, group).value
>             then = convert(then_vt, group).value
>             return now - then
>
> You will need to restart weeWX after saving the change.
>
> It looks as if you are using v0.2.10 of the extension, the current release 
> is v0.3.0 which fixes a number of issues (not the one above) and adds a 
> number of new features.
>
> Gary
>
>
> On Wednesday, 25 October 2017 11:55:40 UTC+10, Robert Mantel wrote:
>>
>> Hey Fredric, I implemented your version of the wxMesh driver, but 
>> sometimes I'm getting this error and I'm not sure if it's the realtime 
>> gauge data issue or the wxMesh issue but sometimes I'll get multiple cycles 
>> of this:
>>
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: **** Traceback (most 
>> recent call last):
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****   File 
>> "/usr/share/weewx/user/rtgd.py", line 875, in process_packet
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****     data = 
>> self.calculate(cached_packet)
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****   File 
>> "/usr/share/weewx/user/rtgd.py", line 1030, in calculate
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****    
>>  self.db_manager, ts - 3600, 300)
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****   File 
>> "/usr/share/weewx/user/rtgd.py", line 1962, in calc_trend
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: ****     return now 
>> - then
>> Oct 24 21:48:22 raspberrypi weewx[1298]: rtgdthread: **** TypeError: 
>> unsupported operand type(s) for -: 'float' and 'NoneType'
>>
>> Now I'm getting updates from my Moteino powered weather station about 
>> every 3-4 seconds and have wxmesh setup to take loop packets as quickly as 
>> it gets them, I'm wondering if it's getting out of sync somehow?  Maybe 
>> someone else has seen this?  Over all this works great.  I love having the 
>> information available in mqtt which makes it usable not just for weewx but 
>> for anything else where you'd like to use that data.
>>
>> On Monday, 7 August 2017 09:56:08 UTC-4, Wysiwyg wrote:
>>>
>>> Hello,
>>>
>>> The initial driver from Bill is working (as far as I know).
>>> It is subscribing to a single mqtt topic which should contain a long 
>>> string looking like this:
>>> TIME:0,AMBT: 7.23,BARP:1001.97,RHUM:70.92,HUMT: 4.44,IRRA:12,BATV:974,
>>> PHOV:673,SYST:33.20,WIND:  0.0,WDIR:  0.0
>>>
>>> In the conf file, it is set the dictionnary to convert labels like 
>>> "HUMT" to weewx database schema 'outHumidity'.
>>>
>>>
>>>
>>> My own modification if based on Bill's job, but I modified a bit to use 
>>> separated mqtt topics for each sensor.
>>> for example I have the following mqtt topics:  "weewx/outTempature" , 
>>> "weewx/barometer" etc...
>>> the sensors publish the measurement value a string in the topics. for 
>>> example "23.42" for temperature (when it's 23.42°C).
>>> weewx is subscribing to all topics below "weewx/" (but you can choose 
>>> something else as root topic).
>>>
>>> I have done this modification because my sensors are at different 
>>> locations and different rates.
>>> for example, temperature is published  every few minutes, rain is 
>>> published only when it's raining.
>>>
>>> to make it simple, as I am a python noob, I use as right part of the 
>>> mqtt topic exactly weewx database schema : 
>>> for example, in the topic " weewx/outTemperature"  the "outTemperature" 
>>> is the same label as weewx use.
>>>
>>> in case you publish some topics not available in the schema, weewx will 
>>> just not consider them.
>>> For example, I have published some topics like "www/Vsolar" which is the 
>>> voltage of the solar panel supplying the sensor. 
>>> This value Vsolar is rejected by weewx unless you add it in the schema.
>>>
>>> This is working pretty well for some time now on my setup (barometer, 
>>> inTemperature, outTemperature, outHumidity, rain & UV are working well.)
>>>
>>>
>>>
>>>
>>> I hope that helps ?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Le lundi 7 août 2017 14:21:57 UTC+2, Neil Trimboy a écrit :
>>>>
>>>> I am wanting to get some remote sensors data into weewx and was 
>>>> considering mqtt.
>>>> It seems there are currently at least 2 threads of development on 
>>>> drivers/services to load data into weewx ?
>>>>
>>>> Could someone summarize their differences and statuses please?. Are 
>>>> they forks and work fundamentally differently, or is one a more mature 
>>>> version ?
>>>>
>>>> thanks
>>>>
>>>> On Friday, 7 July 2017 07:10:03 UTC+12, Wysiwyg wrote:
>>>>>
>>>>> Hi There!
>>>>>
>>>>> I just wanted to share a bit the news on this project.
>>>>>
>>>>> The mqtt driver works since a few monthes now with pressure, barometer 
>>>>> & intemp like a charm !
>>>>> Since a few days, I introduced outTemp, outHumidity, rain & UV. it 
>>>>> works perfectly !
>>>>>
>>>>> Best regards,
>>>>> Frederic
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Le jeudi 6 avril 2017 22:58:22 UTC+2, Wysiwyg a écrit :
>>>>>>
>>>>>> Thx for feedback Andy !!
>>>>>> Nice to hear it works fine !
>>>>>>
>>>>>> the MQTT driver works fine also on my side, with barometer & inTemp 
>>>>>> sensors.
>>>>>> Still slowly but not stopping developping the other sensors
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

Reply via email to