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.
