simulator - generator critical crash

127 views
Skip to first unread message

S R

unread,
Jan 24, 2021, 4:31:30 PM1/24/21
to weewx-user
really can't get anything to work.

simulator - simulator mode. weewx uptime =0
simulator - genarator mode - has below crash.

python3[41323]: weewx[41323] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/manager.py", line 272, in addRecord
python3[41323]: weewx[41323] CRITICAL __main__:     ****      self._updateHiLo(accumulator, cursor)
python3[41323]: weewx[41323] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/manager.py", line 933, in _updateHiLo
python3[41323]: weewx[41323] CRITICAL __main__:     ****      _stats_dict.updateHiLo(accumulator)
python3[41323]: weewx[41323] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/accum.py", line 444, in updateHiLo
python3[41323]: weewx[41323] CRITICAL __main__:     ****      self._check_units(accumulator.unit_system)
python3[41323]: weewx[41323] CRITICAL __main__:     ****    File "/usr/share/weewx/weewx/accum.py", line 615, in _check_units
python3[41323]: weewx[41323] CRITICAL __main__:     ****      raise ValueError("Unit system mismatch %d v. %d" % (self.unit_system,
python3[41323]: weewx[41323] CRITICAL __main__:     ****  ValueError: Unit system mismatch 16 v. 1
python3[41323]: weewx[41323] CRITICAL __main__:     ****  Exiting.

are there any other alternatives to weewx? i'm ready to give up on it

Tom Keffer

unread,
Jan 24, 2021, 6:59:18 PM1/24/21
to weewx-user
Have you modified the simulator at all?

It would be helpful if we saw the log from startup. Set debug=1 (in weewx.conf), restart weewx, then post the log from startup to when it crashed.

If it makes you feel any better, this is the first time I've seen this.

-tk

--
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/76dc716b-8806-4100-aacb-448927d65ef0n%40googlegroups.com.

S R

unread,
Jan 24, 2021, 8:22:49 PM1/24/21
to weewx-user
Hi Tom,
I did a fresh install using the debian package method on Ubuntu 20.10.
I selected simulator during the prompted install and only added debug=1

The version of python3 is 3.8.6 from ubuntu

One thing of note, is:

sudo apt install python3-sqlite
Reading package lists... Done
Building dependency tree        
Reading state information... Done
Package python3-sqlite is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
E: Package 'python3-sqlite' has no installation candidate

debug enclosed

thx

S R

unread,
Jan 24, 2021, 8:23:42 PM1/24/21
to weewx-user
now with the log
weewx_debug.log

vince

unread,
Jan 24, 2021, 10:30:55 PM1/24/21
to weewx-user
Does the "Unit system mismatch 16 v. 1" mean anything ?

FWIW, I did a clean install of the packaged version under Vagrant/VirtualBox using ubuntu-2010 and see no problems when installing with --no-prompt.   I also found no references to  'python3-sqlite' which does not seem to exist.  It didn't appear to be autorequired on my clean ubuntu-2010 VM.

Tom Keffer

unread,
Jan 25, 2021, 2:01:01 AM1/25/21
to weewx-user
Please set debug=1 (in weewx.conf), restart weewx, then post the log from startup to when it crashed.

S R

unread,
Jan 25, 2021, 6:10:32 AM1/25/21
to weewx-user
Hi tom, as requested.
@Vince, no doesn't mean anything to me. also, i should have been more specific. it is actually Kubuntu 20.10 that i am using.

Bear in mind, i am trying to get this to work on Kubuntu, because i wasn't having any luck with a freebsd jail.
so i thought i would prove the system on the more common linux.
weewx_debug.log

Tom Keffer

unread,
Jan 25, 2021, 1:03:54 PM1/25/21
to weewx-user
Thanks.

What happened is that you started with a database that used METRIC units, then later changed it to US. Unfortunately, you have to pick a unit system, then stick with it.

See the section [StdConvert] in the User's Guide.

-tk

S R

unread,
Jan 25, 2021, 1:23:34 PM1/25/21
to weewx-user
Hi Tom, yes. that sounds right. We use metric here, but I found the data being sent was in imperial, despite the device app setting being in metric.
is the solution, delete the db and create a new one?

What settings should i use; when the device sends imperial, and i want metric.

p.s. maybe an error handling routine in order?

Thanks

Tom Keffer

unread,
Jan 25, 2021, 1:31:06 PM1/25/21
to weewx-user
1. You will need to either delete the database and start all over, or set the database unit system back to METRIC. 

2, Yes, the simulator emits packets in US, but if you use a METRIC database, the packets will get converted. There is no need to try to match device to database. The only requirement is to pick a database unit system, then stick with it.

3. I do not know what you mean by "error handling routine."

-tk



S R

unread,
Jan 25, 2021, 6:30:24 PM1/25/21
to weewx-user
Hey tom, thanks.
I re-created the db with US units and set metric in the reports. Simulator is working on ubuntu now.
I will try to get this setup working in my freebsd jail before adding the interceptor to linux.

dumb question. the climatogical report & summary - Name, is missing "ö" looks like it did not like UTF-8.
is there a way to manually fix this?

Tom Keffer

unread,
Jan 25, 2021, 10:52:49 PM1/25/21
to weewx-user
dumb question. the climatogical report & summary - Name, is missing "ö" looks like it did not like UTF-8. 
is there a way to manually fix this?

Not a dumb question at all, but I don't understand it either. What "ö"?

S R

unread,
Jan 26, 2021, 5:53:23 AM1/26/21
to weewx-user
The staion name has a German umlaut in it. It shows correctly on the web pages, but in the NOAA files it misses the letter completely.
e.g. name = "Köln", NOAA file has "Kln"

gjr80

unread,
Jan 26, 2021, 6:02:00 AM1/26/21
to weewx-user
NOAA files use strict_ascii encoding so no umlauts or other accented characters unfortunately. You can change the encoding but as the NOAA format reports are tabulated reports it will mess up the format of the report.

Gary

S R

unread,
Jan 26, 2021, 7:55:23 AM1/26/21
to weewx-user
wouldn't that make more sense to drop the umlaut and Düsseldorf = Dusseldorf - that is what other webservices do that can't deal with non-ascii characters. would be better than dropping the character completely

gjr80

unread,
Jan 26, 2021, 8:42:20 AM1/26/21
to weewx-user
Yes it would but the current code base is limited to what we can do with the python string encode() function. However, I have an idea for something we could do to hopefully improve things, let me discuss with Tom.

Gary

Tom Keffer

unread,
Jan 26, 2021, 2:18:19 PM1/26/21
to weewx-user
Easy fix to allow characters with an umlaut. In the skin.conf file that you are using, change this

    [[SummaryByMonth]]
        # Reports that summarize "by month"
        [[[NOAA_month]]]
            encoding = strict_ascii
            template = NOAA/NOAA-%Y-%m.txt.tmpl

    [[SummaryByYear]]
        # Reports that summarize "by year"
        [[[NOAA_year]]]
            encoding = strict_ascii
            template = NOAA/NOAA-%Y.txt.tmpl

to this

    [[SummaryByMonth]]
        # Reports that summarize "by month"
        [[[NOAA_month]]]
            encoding = utf8
            template = NOAA/NOAA-%Y-%m.txt.tmpl

    [[SummaryByYear]]
        # Reports that summarize "by year"
        [[[NOAA_year]]]
            encoding = utf8
            template = NOAA/NOAA-%Y.txt.tmpl



--
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.

S R

unread,
Jan 26, 2021, 2:33:51 PM1/26/21
to weewx-user
worked like a charm....thank you.

With the Seasons skin, i am not getting any barometer info because the template seems to use baromabsin but i see the ecowitt-client in interceptor is writing to the pressure field.
Is it possible to tell the skin via the conf file which is the correct field to pull the pressure from?
also, the ecowitt client also supports baromrelin - relative pressure, can we get the db extended to support that field too pls?

Tom Keffer

unread,
Jan 26, 2021, 2:42:42 PM1/26/21
to weewx-user
I have not been following the Ecowitt barometer discussion. 

As for the database, it already supports three kinds of barometric pressure: fields 'pressure', 'altimeter', and 'barometer'. See the wiki article Barometer, pressure, altimeter for the differences between them.

What does relative pressure offer that these fields don't already do? In any case, it's easy enough for you to add a new field in your own database. See the section Adding a new type to the database in the Customizing Guide.



S R

unread,
Jan 26, 2021, 2:55:41 PM1/26/21
to weewx-user
if you look into the interceptor.py code, you will find under IGNORED LABELS - 'baromrelin'.

my unit is sending
POST: PASSKEY=XXXX&stationtype=EasyWeatherV1.5.6&dateutc=2021-01-26+12:16:31&tempinf=73.9&humidityin=39&baromrelin=30.115&baromabsin=29.599&freq=433M&model=WS2900C_V2.01.10

The other issue i have, the seasons skin is not showing anything for pressure, but interceptor.py is mapping baromabsin to "pressure" - which is not what is used in the template

S R

unread,
Jan 26, 2021, 3:26:34 PM1/26/21
to weewx-user
A quick search around and baromrelin = altimeter. don't know why it is an ignored field in interceptor.py.
I modified interceptor.py and the database is updating both pressure measures.

But i am still not displaying any pressure values in the Seasons skin
Reply all
Reply to author
Forward
0 new messages