Tried running weewx directly and found out some interesting things:
LOOP: 2017-01-20 08:53:54 EST (1484920434) altf: 797.8077, altimeter:
29.865984751, altm: 243.1718, appTemp: None, barometer: 29.856421862,
cloudbase: 6661.05106707, dailyrainin: 0.627, dateTime: 1484920434.0,
dewpoint: 43.9259, dewptc: 6.6255, heatindex: 69.98, hpa: 985.31, humidex:
69.98, inDewpoint: None, kilopascals: 98.532, maxSolarRad: None,
outHumidity: 39.0, outTemp: 69.98, pressure: 29.0965, rainmm: 0.0,
rainRate: 0.0, soc: 255.9961, tempc: 21.1, usUnits: 1, voltage: 5.1188,
windchill: None, winddir: 90.0, winddir_avg2m: 90.0, windGust: 0.0,
windGustDir: None, windspdmps_avg2m: 0.0, windspeedkmph: 0.0, windspeedmph:
0.0, windspeedmps: 0.0
So I definitely have some "None" data in there, but not sure what this
offending line blows up?
On Friday, 20 January 2017 08:48:24 UTC-5, Robert Mantel wrote:
>
> Ok, I found the offending line in the template and it's this one here:
>
> set $hour_rain_max = $hour.rain.max.raw * $rain_mult
>
> It's now populating the gauges with data, but for some strange reason the
> temperature and aparent temp gauges are cycling from some -5000 number up
> to the correct number once a second or so. Odd. So, maybe what I'm
> missing in weewx is the rain rate over one hour, so perhaps I have miss
> directed that info from the weather station to the wrong label in weewx?
>
> On Thursday, 19 January 2017 18:17:13 UTC-5, gjr80 wrote:
>>
>> Ok, some more thoughts. Delete the content between the {}, no *
>> opertaions in there so the error is not in there. Then work through the
>> 'chunks' of python in the template commenting out/deleting (keeping the
>> template open in an editor and using control-Z/undo is a great timesaver)
>> each one in turn until you find the culprit, eg; comment/delete the
>> appttemp calculations, then the humidex.
>>
>> Another thought, run weewx directly
>> <http://weewx.com/docs/usersguide.htm#Running_directly> and have a look
>> at what is coming out for each obs in the archive record (archive records
>> are identified with a REC and appear each archive interval). Look for any
>> obs used in the template that have None values. That might give you a clue.
>>
>> windDir (and the gust equivalent) are often a source of 'Nones' but in
>> this case I don't think any are used in a multiplication operation. But
>> that is the sort of thinking you need.
>>
>> I note your list has no Nones, but that is not what is used in the
>> template; the template uses the data in weewx, there is a subtle
>> difference. that is why we need to focus on what weewx 'sees' or 'has'.
>>
>> Gary
>>
>> On Friday, 20 January 2017 08:41:33 UTC+10, Robert Mantel wrote:
>>>
>>> Hey Gary, thanks for the reply. Yes I tried doing some troubleshooting
>>> by commenting out specific lines, especially the math.exp ones, but when I
>>> do cheetah just complains it can't find variable "x" whatever one I have
>>> commented out. But maybe your technique will yield more info. Here is the
>>> label map I'm using in fileparse:
>>>
>>> tempf = outTemp
>>> humidity = outHumidity
>>> inches = pressure
>>> dewptf = dewpoint
>>> windspdavg = windSpeed
>>> winddiravg = windDir
>>> rainin = rainRate
>>> timestamp = dateTime
>>> windgustmph = windGust
>>> windgustdir = windGustDir
>>>
>>> The values on the left come from a cron job I run every minute that does
>>> a jsonp query to my phant server which acts as my weather station data
>>> dump. The timestamp comes from the phant server and my cron job code
>>> converts it to epoch and the query itself grabs the EST version of the
>>> timestamp. While writing this I'm wondering if I should be using UTC?
>>> Anyways, my station is inside right now so no wind is being produced but I
>>> anticipated that the gauges would be able to deal with this condition,
>>> otherwise it would be complaining all the time about wind and rain and
>>> such. Here is a dump of my fileparse data file (the one that weewx
>>> imports), As you can see there are no null values:
>>>
>>> soc=255.9961
>>> rainin=0.1100
>>> voltage=5.1188
>>> humidity=35.0000
>>> windspeedmph=0.0000
>>> kilopascals=98.6170
>>> winddir_avg2m=90
>>> rainmm=2.7940
>>> windspeedmps=0.0000
>>> hpa=986.1700
>>> tempc=21.6800
>>> windgustmph=0.0000
>>> tempf=71.0240
>>> inches=29.1216
>>> timestamp=1484865589
>>> windspdmps_avg2m=0.0000
>>> windspeedkmph=0.0000
>>> winddir=90
>>> dewptf=42.0318
>>> dewptc=5.5732
>>> altm=235.6895
>>> altf=773.2595
>>> dailyrainin=0.6160
>>> windgustdir=0
>>>
>>> Obviously I'm not mapping all these to weewx as of yet. I'm hoping you
>>> can shed some light on this one.
>>>
>>> On Thursday, 19 January 2017 16:44:52 UTC-5, gjr80 wrote:
>>>>
>>>> Hi,
>>>>
>>>> Welcome to the joys of troubleshooting a Cheetah template! The best
>>>> Cheetah errors to have are those that crash in your non-template python
>>>> code as that way you tend to get a meaningfull error trace, if the crash
>>>> occurs in the in-template python code they can be very hard (well tedious)
>>>> to track down. As you have no doubt found out the line number quoted in
>>>> the
>>>> error trace is usesless, it refers to a temporary file we have no access
>>>> to. The best clue is the actual error message itself. in this case there
>>>> is
>>>> a multiplication operation occuring that is using an integer and the value
>>>> None which gives the TypeError. What you need to do is carefully look at
>>>> each multiplication operation in the template (there are 33 but some can
>>>> be
>>>> ruled out depending on your settings) and see if any of them could
>>>> possibly
>>>> be using a variable that is None. You have what sounds like a unique
>>>> setup,
>>>> I would look at what obs your setup is providing weewx and through
>>>> omission
>>>> could any of the common obs be None? This could cause some variable in the
>>>> template to be None (which does not trigger the error) but later on that
>>>> variable is used in an equation that does trigger the error. As you can
>>>> see
>>>> it can get complex. One technique I use is what I call the 'method of
>>>> halves':
>>>>
>>>> 1. make a backup of the template as this is destructive
>>>> 2. open the template
>>>> 3. delete the bottom half of the template
>>>> 4. save the template
>>>> 5. let weewx do a report cycle(no need to start/stop, just let
>>>> weewx continue to run, you could be here a while)
>>>> 6. did the error go away?
>>>> - yes - the error is in the bottom half of the template, repeat
>>>> but this time only delete half of what you last deleted
>>>> - no - the error is the top half of the template, delete half of
>>>> what is left and repeat
>>>>
>>>> As I said it can be tedious, also if you have a template with lots of
>>>> embedded python you need to be careful where you slice. Anyway I think you
>>>> should get the idea.
>>>>
>>>> Assuming you track down the issue do let us know what the cause was,
>>>> that way we can harden the gauge-data.txt template.
>>>>
>>>> Good luck
>>>>
>>>> Gary
>>>>
>>>> On Thursday, 19 January 2017 23:44:51 UTC+10, Robert Mantel wrote:
>>>>>
>>>>> I have a brand new Raspberry Pi running the latest version of weewx.
>>>>> I have it working with the default skin and also the Bootstrap skin with
>>>>> no issues. I'm using fileparse.py to grab data from a text file that
>>>>> gets
>>>>> generated from a python script that does a jsonp query to my phant server
>>>>> that is archiving the raw data from my particle photon weather hardware.
>>>>> Like probably everyone else I came across the SS gauges and love the
>>>>> look
>>>>> and feel of them so proceeded with the install and followed the
>>>>> instructions, modifying the gauges.js file and movnig all the appropriate
>>>>> files into my weewx install. The gauges are reproduced perfectly, but no
>>>>> data is being input and I get the following error in syslog:
>>>>>
>>>>>
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record
>>>>> 2017-01-19 08:26:00 EST (1484832360) to database 'weewx.sdb'
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: manager: added record
>>>>> 2017-01-19 08:26:00 EST (1484832360) to daily summary in 'weewx.sdb'
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: reportengine: copied 0 files
>>>>> to /var/www/html/weewx
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator: Generate
>>>>> failed with exception '<type 'exceptions.TypeError'>'
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator: ****
>>>>> Ignoring template /etc/weewx/skins/ss/gauge-data.txt.tmpl
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: cheetahgenerator: ****
>>>>> Reason: unsupported operand type(s) for *: 'NoneType' and 'int'
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** Traceback (most recent
>>>>> call last):
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** File
>>>>> "/usr/share/weewx/weewx/cheetahgenerator.py", line 315, in generate
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** print >> _file,
>>>>> text
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** File
>>>>> "/usr/lib/python2.7/dist-packages/Cheetah/Template.py", line 1005, in
>>>>> __str__
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** rc = getattr(self,
>>>>> mainMethName)()
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** File
>>>>> "cheetah__etc_weewx_skins_ss_gauge_data_txt_tmpl_1484791504_04_19193.py",
>>>>> line 326, in respond
>>>>> Jan 19 08:27:04 raspberrypi weewx[23078]: **** TypeError: unsupported
>>>>> operand type(s) for *: 'NoneType' and 'int'
>>>>>
>>>>>
>>>>> I'm wracking my brain trying to find in the gauge-data.txt.tmpl file
>>>>> what could be causing the operand error and obviously it's a bogus
>>>>> variable
>>>>> in one of the math functions. So I suspect that there is some missing
>>>>> data
>>>>> that I'm not supplying it? Also of note, when I set up weewx I chose
>>>>> metricwx for the display units, but the database is using US units. Is
>>>>> this my problem? Should I have stuck with US display units as well when
>>>>> I
>>>>> did the initial install?
>>>>>
>>>>
--
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].
For more options, visit https://groups.google.com/d/optout.
