date:20210126

done that mulitple times alreadyand more weirdness.

index web page is good - shows correct todays date (sessions template out 
of box)
day is good - shows todays date

week/month/year - shows date of 31.01 with simulator data.

On Tuesday, January 26, 2021 at 7:10:48 AM UTC+1 gjr80 wrote:

> Delete the html directory again (definitely on the WeeWX machine and also 
> delete the html/png files on your web server if applicable), delete the 
> database and restart WeeWX. Monitor the log, confirm a new database is 
> created (it will be logged) and which driver is being used. Confirm report 
> generation. If you still get old simulator data in a browser it’s a browser 
> cache issue or you have more than one WeeWX instance running or remnants 
> from another WeeWX instance. You can also take the browser out of the 
> equation and view the report output in an editor or cat it to your console.
>
> Gary
>
> On Tuesday, 26 January 2021 at 15:51:11 UTC+10 sjr4...@gmail.com wrote:
>
>> deleted the entire html directory and run wee_reports and it is back with 
>> the simulator data... even though a db we deleted and created again
>>
>> On Monday, January 25, 2021 at 11:20:26 PM UTC+1 peterq...@gmail.com 
>> wrote:
>>
>>> There are .html pages on the web server public directory that your seeing
>>>
>>> On Mon, Jan 25, 2021, 1:16 PM S R  wrote:
>>>
 I just deleted the .sdb and then run wee_database --create. 

 i don't see any cache data for nginx on either the ubuntu or freebsd 
 versions i setup for testing, but they both show the same problem 


 On Monday, January 25, 2021 at 10:10:47 PM UTC+1 gjr80 wrote:

> Did you delete any previously generated reports on both your WeeWX 
> machine and web server?
>
> Gary
>
> On Tuesday, 26 January 2021 at 06:40:48 UTC+10 sjr4...@gmail.com 
> wrote:
>
>> I've got the same problem. finished testing with the simulator, 
>> deleted the db and created again. 
>> cleared the browser cache on both chrome and firefox, but i goto the 
>> page and it shows 28.01 even though today is 25.01 and the data from 
>> when 
>> the simulator run
>>
>>
>> On Sunday, November 22, 2015 at 8:13:23 AM UTC+1 bjale...@gmail.com 
>> wrote:
>>
>>> Haha magic indeed!
>>>
>>> I completely overlooked the internal logger in the station itself - 
>>> thanks very much for that.
>>>
>>>
>>> On Sunday, 22 November 2015 13:15:32 UTC+13, Tom Keffer wrote:

 Magic. :-)

 Your hardware must have an onboard logger. If you truly want a 
 fresh start, you'll have to clear it. Specific instructions depends on 
 the 
 make of your hardware.

 -tk

 On Sat, Nov 21, 2015 at 3:52 PM, George Alexander <
 bjale...@gmail.com> wrote:

>
>
> On Monday, 13 July 2015 09:28:49 UTC+12, mwall wrote:
>>
>> On Sunday, July 12, 2015 at 5:16:55 PM UTC-4, Dave Jeffries wrote:
>>>
>>> I used the setup.py method, just thought there may be a simple 
>>> command  to remove all the existing data.
>>> I guess the weewx.conf and skin.conf will be overwritten so will 
>>> have to take a copy first?
>>>
>>
>> if you do not care about any of the data in the database, then 
>> just stop weewx, delete the database file 
>> (/home/weewx/archive/weewx.sdb), 
>> then start weewx.
>>
>> if you want to surgically remove data from the database, do 
>> something like this:
>>
>>
>> *sqlite3 /home/weewx/archive/weewx.sdb*sqlite> *delete from 
>> archive where dateTime < X;*
>>
>> where X is the timestamp (unix epoch) after which you started 
>> collecting data from the real weather station.
>>
>> m 
>>
>
> After trying the "Delete weewx.sdb" method for a refresh, when I 
> restarted weewx, the syslog showed it happily re-populating the 
> database 
> with all my old data - where on earth did it get that from and how do 
> I 
> stop it doing it again? 
>
> -- 
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

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

Re: [weewx-user] How do I remove all the existing data and start again

2021-01-26 Thread gjr80

What skin are we talking about Seasons? Standard or something else. ‘Index 
page has correct date’ what about observations? Plots? ‘week/month/year - 
shows date of 31.01 with simulator data’ so date is wrong but is data 
correct. What do the plots show? What is the timestamp under the x axis of 
the plots? Seeing a startup log after deleting everything would help. What 
about time stamps on generated files? Is there a link to your site?

You are looking at your pages we are not, so you need to give us a detailed 
picture.

Gary
On Tuesday, 26 January 2021 at 18:24:56 UTC+10 sjr4...@gmail.com wrote:

> done that mulitple times alreadyand more weirdness.
>
> index web page is good - shows correct todays date (sessions template out 
> of box)
> day is good - shows todays date
>
> week/month/year - shows date of 31.01 with simulator data.
>
> On Tuesday, January 26, 2021 at 7:10:48 AM UTC+1 gjr80 wrote:
>
>> Delete the html directory again (definitely on the WeeWX machine and also 
>> delete the html/png files on your web server if applicable), delete the 
>> database and restart WeeWX. Monitor the log, confirm a new database is 
>> created (it will be logged) and which driver is being used. Confirm report 
>> generation. If you still get old simulator data in a browser it’s a browser 
>> cache issue or you have more than one WeeWX instance running or remnants 
>> from another WeeWX instance. You can also take the browser out of the 
>> equation and view the report output in an editor or cat it to your console.
>>
>> Gary
>>
>> On Tuesday, 26 January 2021 at 15:51:11 UTC+10 sjr4...@gmail.com wrote:
>>
>>> deleted the entire html directory and run wee_reports and it is back 
>>> with the simulator data... even though a db we deleted and created again
>>>
>>> On Monday, January 25, 2021 at 11:20:26 PM UTC+1 peterq...@gmail.com 
>>> wrote:
>>>
 There are .html pages on the web server public directory that your 
 seeing

 On Mon, Jan 25, 2021, 1:16 PM S R  wrote:

> I just deleted the .sdb and then run wee_database --create. 
>
> i don't see any cache data for nginx on either the ubuntu or freebsd 
> versions i setup for testing, but they both show the same problem 
>
>
> On Monday, January 25, 2021 at 10:10:47 PM UTC+1 gjr80 wrote:
>
>> Did you delete any previously generated reports on both your WeeWX 
>> machine and web server?
>>
>> Gary
>>
>> On Tuesday, 26 January 2021 at 06:40:48 UTC+10 sjr4...@gmail.com 
>> wrote:
>>
>>> I've got the same problem. finished testing with the simulator, 
>>> deleted the db and created again. 
>>> cleared the browser cache on both chrome and firefox, but i goto the 
>>> page and it shows 28.01 even though today is 25.01 and the data from 
>>> when 
>>> the simulator run
>>>
>>>
>>> On Sunday, November 22, 2015 at 8:13:23 AM UTC+1 bjale...@gmail.com 
>>> wrote:
>>>
 Haha magic indeed!

 I completely overlooked the internal logger in the station itself - 
 thanks very much for that.


 On Sunday, 22 November 2015 13:15:32 UTC+13, Tom Keffer wrote:
>
> Magic. :-)
>
> Your hardware must have an onboard logger. If you truly want a 
> fresh start, you'll have to clear it. Specific instructions depends 
> on the 
> make of your hardware.
>
> -tk
>
> On Sat, Nov 21, 2015 at 3:52 PM, George Alexander <
> bjale...@gmail.com> wrote:
>
>>
>>
>> On Monday, 13 July 2015 09:28:49 UTC+12, mwall wrote:
>>>
>>> On Sunday, July 12, 2015 at 5:16:55 PM UTC-4, Dave Jeffries 
>>> wrote:

 I used the setup.py method, just thought there may be a simple 
 command  to remove all the existing data.
 I guess the weewx.conf and skin.conf will be overwritten so 
 will have to take a copy first?

>>>
>>> if you do not care about any of the data in the database, then 
>>> just stop weewx, delete the database file 
>>> (/home/weewx/archive/weewx.sdb), 
>>> then start weewx.
>>>
>>> if you want to surgically remove data from the database, do 
>>> something like this:
>>>
>>>
>>> *sqlite3 /home/weewx/archive/weewx.sdb*sqlite> *delete from 
>>> archive where dateTime < X;*
>>>
>>> where X is the timestamp (unix epoch) after which you started 
>>> collecting data from the real weather station.
>>>
>>> m 
>>>
>>
>> After trying the "Delete weewx.sdb" method for a refresh, when I 
>> restarted weewx, the syslog showed it happily re-populating the 
>> database 
>> with all my old data - where on earth did it get that from and h

Re: [weewx-user] simulator - generator critical crash

2021-01-26 Thread gjr80

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

On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com wrote:

> 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
>
> On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:
>
>> 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
>>
>> On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com wrote:
>>
>>> 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"
>>>
>>> On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com wrote:
>>>
 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 "ö"?

>>>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/614395f3-d991-45f9-ad80-dba7fe59168en%40googlegroups.com.

Re: [weewx-user] How do I remove all the existing data and start again

yes. i did fresh install (Standard Seasons skin) with the simulator to make 
get it working. Then i added the interceptor driver. 
Simulator in generator mode created data up to 31.01.21. I have the ecowitt 
unit inside, so only inside temperature, humidity and pressure is being 
sent at the moment. 
index.html page time/date is showing correct. inside temp/hum is correct 
and all other values are NA/0 
day graphs are showing correctly for the collection time the system has 
been up. as in today 26.01
week/month/year graphs are still showing plots for 26 -> 31.01.21 






On Tuesday, January 26, 2021 at 9:39:48 AM UTC+1 gjr80 wrote:

> What skin are we talking about Seasons? Standard or something else. ‘Index 
> page has correct date’ what about observations? Plots? ‘week/month/year - 
> shows date of 31.01 with simulator data’ so date is wrong but is data 
> correct. What do the plots show? What is the timestamp under the x axis of 
> the plots? Seeing a startup log after deleting everything would help. What 
> about time stamps on generated files? Is there a link to your site?
>
> You are looking at your pages we are not, so you need to give us a 
> detailed picture.
>
> Gary
> On Tuesday, 26 January 2021 at 18:24:56 UTC+10 sjr4...@gmail.com wrote:
>
>> done that mulitple times alreadyand more weirdness.
>>
>> index web page is good - shows correct todays date (sessions template out 
>> of box)
>> day is good - shows todays date
>>
>> week/month/year - shows date of 31.01 with simulator data.
>>
>> On Tuesday, January 26, 2021 at 7:10:48 AM UTC+1 gjr80 wrote:
>>
>>> Delete the html directory again (definitely on the WeeWX machine and 
>>> also delete the html/png files on your web server if applicable), delete 
>>> the database and restart WeeWX. Monitor the log, confirm a new database is 
>>> created (it will be logged) and which driver is being used. Confirm report 
>>> generation. If you still get old simulator data in a browser it’s a browser 
>>> cache issue or you have more than one WeeWX instance running or remnants 
>>> from another WeeWX instance. You can also take the browser out of the 
>>> equation and view the report output in an editor or cat it to your console.
>>>
>>> Gary
>>>
>>> On Tuesday, 26 January 2021 at 15:51:11 UTC+10 sjr4...@gmail.com wrote:
>>>
 deleted the entire html directory and run wee_reports and it is back 
 with the simulator data... even though a db we deleted and created again

 On Monday, January 25, 2021 at 11:20:26 PM UTC+1 peterq...@gmail.com 
 wrote:

> There are .html pages on the web server public directory that your 
> seeing
>
> On Mon, Jan 25, 2021, 1:16 PM S R  wrote:
>
>> I just deleted the .sdb and then run wee_database --create. 
>>
>> i don't see any cache data for nginx on either the ubuntu or freebsd 
>> versions i setup for testing, but they both show the same problem 
>>
>>
>> On Monday, January 25, 2021 at 10:10:47 PM UTC+1 gjr80 wrote:
>>
>>> Did you delete any previously generated reports on both your WeeWX 
>>> machine and web server?
>>>
>>> Gary
>>>
>>> On Tuesday, 26 January 2021 at 06:40:48 UTC+10 sjr4...@gmail.com 
>>> wrote:
>>>
 I've got the same problem. finished testing with the simulator, 
 deleted the db and created again. 
 cleared the browser cache on both chrome and firefox, but i goto 
 the page and it shows 28.01 even though today is 25.01 and the data 
 from 
 when the simulator run


 On Sunday, November 22, 2015 at 8:13:23 AM UTC+1 bjale...@gmail.com 
 wrote:

> Haha magic indeed!
>
> I completely overlooked the internal logger in the station itself 
> - thanks very much for that.
>
>
> On Sunday, 22 November 2015 13:15:32 UTC+13, Tom Keffer wrote:
>>
>> Magic. :-)
>>
>> Your hardware must have an onboard logger. If you truly want a 
>> fresh start, you'll have to clear it. Specific instructions depends 
>> on the 
>> make of your hardware.
>>
>> -tk
>>
>> On Sat, Nov 21, 2015 at 3:52 PM, George Alexander <
>> bjale...@gmail.com> wrote:
>>
>>>
>>>
>>> On Monday, 13 July 2015 09:28:49 UTC+12, mwall wrote:

 On Sunday, July 12, 2015 at 5:16:55 PM UTC-4, Dave Jeffries 
 wrote:
>
> I used the setup.py method, just thought there may be a simple 
> command  to remove all the existing data.
> I guess the weewx.conf and skin.conf will be overwritten so 
> will have to take a copy first?
>

 if you do not care about any of the data in the database, then 
 just stop weewx, delete the database file 
 (/

Re: [weewx-user] How do I remove all the existing data and start again

2021-01-26 Thread gjr80

Sounds like all is fine except for week/month/year plots? By default week 
plots are generated once per hour, month every three hours and year every 
24 hours. Did you delete all of the generated plot image files (xxx.png)? 
This forces WeeWX to regenerate them all on the next report cycle.

Gary

On Tuesday, 26 January 2021 at 19:26:36 UTC+10 sjr4...@gmail.com wrote:

> yes. i did fresh install (Standard Seasons skin) with the simulator to 
> make get it working. Then i added the interceptor driver. 
> Simulator in generator mode created data up to 31.01.21. I have the 
> ecowitt unit inside, so only inside temperature, humidity and pressure is 
> being sent at the moment. 
> index.html page time/date is showing correct. inside temp/hum is correct 
> and all other values are NA/0 
> day graphs are showing correctly for the collection time the system has 
> been up. as in today 26.01
> week/month/year graphs are still showing plots for 26 -> 31.01.21 
>
>
>
>
>
>
> On Tuesday, January 26, 2021 at 9:39:48 AM UTC+1 gjr80 wrote:
>
>> What skin are we talking about Seasons? Standard or something else. 
>> ‘Index page has correct date’ what about observations? Plots? 
>> ‘week/month/year - shows date of 31.01 with simulator data’ so date is 
>> wrong but is data correct. What do the plots show? What is the timestamp 
>> under the x axis of the plots? Seeing a startup log after deleting 
>> everything would help. What about time stamps on generated files? Is there 
>> a link to your site?
>>
>> You are looking at your pages we are not, so you need to give us a 
>> detailed picture.
>>
>> Gary
>> On Tuesday, 26 January 2021 at 18:24:56 UTC+10 sjr4...@gmail.com wrote:
>>
>>> done that mulitple times alreadyand more weirdness.
>>>
>>> index web page is good - shows correct todays date (sessions template 
>>> out of box)
>>> day is good - shows todays date
>>>
>>> week/month/year - shows date of 31.01 with simulator data.
>>>
>>> On Tuesday, January 26, 2021 at 7:10:48 AM UTC+1 gjr80 wrote:
>>>
 Delete the html directory again (definitely on the WeeWX machine and 
 also delete the html/png files on your web server if applicable), delete 
 the database and restart WeeWX. Monitor the log, confirm a new database is 
 created (it will be logged) and which driver is being used. Confirm report 
 generation. If you still get old simulator data in a browser it’s a 
 browser 
 cache issue or you have more than one WeeWX instance running or remnants 
 from another WeeWX instance. You can also take the browser out of the 
 equation and view the report output in an editor or cat it to your console.

 Gary

 On Tuesday, 26 January 2021 at 15:51:11 UTC+10 sjr4...@gmail.com wrote:

> deleted the entire html directory and run wee_reports and it is back 
> with the simulator data... even though a db we deleted and created again
>
> On Monday, January 25, 2021 at 11:20:26 PM UTC+1 peterq...@gmail.com 
> wrote:
>
>> There are .html pages on the web server public directory that your 
>> seeing
>>
>> On Mon, Jan 25, 2021, 1:16 PM S R  wrote:
>>
>>> I just deleted the .sdb and then run wee_database --create. 
>>>
>>> i don't see any cache data for nginx on either the ubuntu or freebsd 
>>> versions i setup for testing, but they both show the same problem 
>>>
>>>
>>> On Monday, January 25, 2021 at 10:10:47 PM UTC+1 gjr80 wrote:
>>>
 Did you delete any previously generated reports on both your WeeWX 
 machine and web server?

 Gary

 On Tuesday, 26 January 2021 at 06:40:48 UTC+10 sjr4...@gmail.com 
 wrote:

> I've got the same problem. finished testing with the simulator, 
> deleted the db and created again. 
> cleared the browser cache on both chrome and firefox, but i goto 
> the page and it shows 28.01 even though today is 25.01 and the data 
> from 
> when the simulator run
>
>
> On Sunday, November 22, 2015 at 8:13:23 AM UTC+1 
> bjale...@gmail.com wrote:
>
>> Haha magic indeed!
>>
>> I completely overlooked the internal logger in the station itself 
>> - thanks very much for that.
>>
>>
>> On Sunday, 22 November 2015 13:15:32 UTC+13, Tom Keffer wrote:
>>>
>>> Magic. :-)
>>>
>>> Your hardware must have an onboard logger. If you truly want a 
>>> fresh start, you'll have to clear it. Specific instructions depends 
>>> on the 
>>> make of your hardware.
>>>
>>> -tk
>>>
>>> On Sat, Nov 21, 2015 at 3:52 PM, George Alexander <
>>> bjale...@gmail.com> wrote:
>>>


 On Monday, 13 July 2015 09:28:49 UTC+12, mwall wrote:
>
> On Sunday, July

Re: [weewx-user] Re: Database vs MQTT published data

Hard to say without seeing the log. Is the MySQL server located on an
unreliable network link? Unfortunately, WeeWX cannot recover from a MySQL
write error (see issue #259 ).

Take a look in your system log for any WeeWX errors, and in the MySQL log
for any database errors.

On Mon, Jan 25, 2021 at 5:45 PM Zsolt Máté  wrote:

> I am missing the data in mysql.
> See the two attachments. The last hour in phpmysql vs grafana.
> There are just 7 records in the last hour, but AFAIK my interceptor gets
> data every ~16 seconds - see the graph drawn by grafana using influxdb data.
> [image: 2021-01-26 14_36_41 chrome_daC10v9WCb.png]
> [image: 2021-01-26 14_37_31 chrome_YnEe2grkwc.png]
>
> On Tuesday, January 26, 2021 at 2:08:22 PM UTC+13 vince wrote:
>
>> Are you sure you're not just seeing gaps in the 'graphs' of the data ?
>>
>> See if you're really missing intervals in the db by querying your db
>> directly.
>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/fd9dab82-7f31-450e-9f0c-44e1d136e6a4n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEBOR_wt84KWpezX_BZiZoN_ZJU1qfBZur0QdkvCOgHWqg%40mail.gmail.com.

Re: [weewx-user] Unable to wake up Vantage console

Try running this very simple program. Substitute whatever port you are
using for '/dev/ttyS0'.

import serial
import time

s = serial.Serial('/dev/ttyS0', 19200, timeout=3)

s.write(b'\n')
time.sleep(0.5)
s.write(b'TEST\n')
time.sleep(0.5)
buf = s.read(10)
print(buf)

This little program will do the standard Davis test for connectivity by
asking the console to echo the word "TEST". It should print out something
like:

response: b'\n\r\n\rTEST\n\r'

If not, then you are either on the wrong port, or the logger is not acting
like a true clone.

-tk



On Mon, Jan 25, 2021 at 11:07 PM Txo  wrote:

> @Vince
> This had already been done for a top hat with serial port.
>
> @Chris
> I made the changes recommended by Chris and no more «@Vince
> Unable to wake up Vantage console
> This had already been done for a top hat with serial port.
>
> @Chris
> I made the changes recommended by Chris and no more «Unable to wake up
> Vantage console» but now
>
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine:   self.serial_port = serial.Serial(self.port,
> self.baudrate, timeout=self.timeout)
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine: File
> "/usr/lib/python3/dist-packages/serial/serialutil.py", line 240, in __init__
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine:   self.open()
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine: File
> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 272, in open
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine:   self._reconfigure_port(force_update=True)
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine: File
> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 326, in
> _reconfigure_port
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine:   raise SerialException("Could not configure
> port: {}".format(msg))
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
> weewx.engine:   serial.serialutil.SerialException: Could not
> configure port: (5, "Erreur d'entrée/sortie")
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL __main__:
> Unable to load driver: Could not configure port: (5, "Erreur
> d'entrée/sortie")
> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL __main__:
>   Exiting...
>
> ls -l /dev/ttyS*
> crw-rw 1 root dialout 4, 64 janv. 26 07:34 /dev/ttyS0
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  Traceback (most recent call last):
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 323, in
> _reconfigure_port
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  orig_attr = termios.tcgetattr(self.fd)
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  termios.error: (5, "Erreur d'entrée/sortie")
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  During handling of the above exception, another exception occurred:
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  Traceback (most recent call last):
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/share/weewx/weewx/engine.py", line 119, in setupStation
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  self.console = loader_function(config_dict, self)
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/share/weewx/weewx/drivers/vantage.py", line 39, in loader
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  return VantageService(engine, config_dict)
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/share/weewx/weewx/drivers/vantage.py", line 1898, in __init__
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  Vantage.__init__(self, **config_dict[DRIVER_NAME])
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/share/weewx/weewx/drivers/vantage.py", line 512, in __init__
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  self.port.openPort()
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/share/weewx/weewx/drivers/vantage.py", line 307, in openPort
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  self.serial_port = serial.Serial(self.port, self.baudrate,
> timeout=self.timeout)
> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>  File "/usr/lib/python3/dist-packag

Re: [weewx-user] How do I remove all the existing data and start again

all is good now only there is no pressure. i think this is because the 
skin is using barometer, but the ecowitt is directing baromabsin to pressure

On Tuesday, January 26, 2021 at 10:31:10 AM UTC+1 gjr80 wrote:

> Sounds like all is fine except for week/month/year plots? By default week 
> plots are generated once per hour, month every three hours and year every 
> 24 hours. Did you delete all of the generated plot image files (xxx.png)? 
> This forces WeeWX to regenerate them all on the next report cycle.
>
> Gary
>
> On Tuesday, 26 January 2021 at 19:26:36 UTC+10 sjr4...@gmail.com wrote:
>
>> yes. i did fresh install (Standard Seasons skin) with the simulator to 
>> make get it working. Then i added the interceptor driver. 
>> Simulator in generator mode created data up to 31.01.21. I have the 
>> ecowitt unit inside, so only inside temperature, humidity and pressure is 
>> being sent at the moment. 
>> index.html page time/date is showing correct. inside temp/hum is correct 
>> and all other values are NA/0 
>> day graphs are showing correctly for the collection time the system has 
>> been up. as in today 26.01
>> week/month/year graphs are still showing plots for 26 -> 31.01.21 
>>
>>
>>
>>
>>
>>
>> On Tuesday, January 26, 2021 at 9:39:48 AM UTC+1 gjr80 wrote:
>>
>>> What skin are we talking about Seasons? Standard or something else. 
>>> ‘Index page has correct date’ what about observations? Plots? 
>>> ‘week/month/year - shows date of 31.01 with simulator data’ so date is 
>>> wrong but is data correct. What do the plots show? What is the timestamp 
>>> under the x axis of the plots? Seeing a startup log after deleting 
>>> everything would help. What about time stamps on generated files? Is there 
>>> a link to your site?
>>>
>>> You are looking at your pages we are not, so you need to give us a 
>>> detailed picture.
>>>
>>> Gary
>>> On Tuesday, 26 January 2021 at 18:24:56 UTC+10 sjr4...@gmail.com wrote:
>>>
 done that mulitple times alreadyand more weirdness.

 index web page is good - shows correct todays date (sessions template 
 out of box)
 day is good - shows todays date

 week/month/year - shows date of 31.01 with simulator data.

 On Tuesday, January 26, 2021 at 7:10:48 AM UTC+1 gjr80 wrote:

> Delete the html directory again (definitely on the WeeWX machine and 
> also delete the html/png files on your web server if applicable), delete 
> the database and restart WeeWX. Monitor the log, confirm a new database 
> is 
> created (it will be logged) and which driver is being used. Confirm 
> report 
> generation. If you still get old simulator data in a browser it’s a 
> browser 
> cache issue or you have more than one WeeWX instance running or remnants 
> from another WeeWX instance. You can also take the browser out of the 
> equation and view the report output in an editor or cat it to your 
> console.
>
> Gary
>
> On Tuesday, 26 January 2021 at 15:51:11 UTC+10 sjr4...@gmail.com 
> wrote:
>
>> deleted the entire html directory and run wee_reports and it is back 
>> with the simulator data... even though a db we deleted and created again
>>
>> On Monday, January 25, 2021 at 11:20:26 PM UTC+1 peterq...@gmail.com 
>> wrote:
>>
>>> There are .html pages on the web server public directory that your 
>>> seeing
>>>
>>> On Mon, Jan 25, 2021, 1:16 PM S R  wrote:
>>>
 I just deleted the .sdb and then run wee_database --create. 

 i don't see any cache data for nginx on either the ubuntu or 
 freebsd versions i setup for testing, but they both show the same 
 problem 


 On Monday, January 25, 2021 at 10:10:47 PM UTC+1 gjr80 wrote:

> Did you delete any previously generated reports on both your WeeWX 
> machine and web server?
>
> Gary
>
> On Tuesday, 26 January 2021 at 06:40:48 UTC+10 sjr4...@gmail.com 
> wrote:
>
>> I've got the same problem. finished testing with the simulator, 
>> deleted the db and created again. 
>> cleared the browser cache on both chrome and firefox, but i goto 
>> the page and it shows 28.01 even though today is 25.01 and the data 
>> from 
>> when the simulator run
>>
>>
>> On Sunday, November 22, 2015 at 8:13:23 AM UTC+1 
>> bjale...@gmail.com wrote:
>>
>>> Haha magic indeed!
>>>
>>> I completely overlooked the internal logger in the station 
>>> itself - thanks very much for that.
>>>
>>>
>>> On Sunday, 22 November 2015 13:15:32 UTC+13, Tom Keffer wrote:

 Magic. :-)

 Your hardware must have an onboard logger. If you truly want a 
 fresh start, you'll have to clear it.

Re: [weewx-user] Re: MQTT Connection Refused

2021-01-26 Thread Greg Troxel

Jeff Beckman  writes:

> OK, that produced some interesting results.  For your first suggestion, my 
> broker computer is running Hass.io (Home Assistant), which doesn't have the 
> ss command.  I'll keep digging there to see if there's another way to 
> double check that the port is open, but the log seems to indicate it's 
> listening on 1883.  
>
> I installed  mosquitto-clients on a raspberry pi that I'm not using for 
> Weewx or my broker.  So far everything I try there results in the same 
> connection refused error.  I've tried both as anonymous and as a user.  
> Here's an example of an attempt:
> pi@piopolis:~ $ mosquitto_sub -h 192.168.1.35 -t test -u homeassistant -P 
> reallylongpassword
> Error: Connection refused

That's great progress; you have shown that your MQTT setup is troubled
without even involving weewx.

It's time to:

  check the config file for the broker to see if it is listening on
  localhost only (which doesn't make a lot of sense) or to *:* or to
  that address specifically.   Setup questions for a hass.io broker are
  probably best posed to some HA forum.

  check all your firewall configurations.   Firewalls are notorious for
  breaking intended communication, and the fun you have fixing that is
  the tradeoff for whatever protection you get.   I would do this by:

reading the firewall configs

querying the firewall stats and logs of filtered packets

running tcpdump on both the weewx computer and the hass.io computer.
If either is some kind of container, also add the computer hosting
that container.

> Checking the log on the broker, I see no evidence of the attempt, which 
> would point to the port not actually being open.  But then I try to connect 

No, it points to the operating system not doing all of receiving a SYN and
successfully completing the TCP 3-way handshake.   Brokers more or less
all just use accept(2) to listen for connections and don't process TCP.

> from my windows machine using MQTT Explorer and everything works.  I can 
> publish messages and see them pop up on my broker machine.  The log looks 
> normal.  

That's an intersting clue that perhaps the problem is a firewall that
affects the weewx machine and not the windows machine.

You might also try basic things like ping of the broker from the weewx machine.

> 1611639012: New connection from 172.30.32.1 on port 1883. [INFO] found 
> homeassistant on local database 
> 1611639012: New client connected from 172.30.32.1 as 5yoX9kmQROmBbxG2B0yAct 
> (p2, c1, k60, u'homeassistant'). 
> 1611639366: New connection from 192.168.1.185 on port 1883. [INFO] found 
> homeassistant on local database 
> 1611639366: New client connected from 192.168.1.185 as 
> mqtt-explorer-a18267b6 (p2, c1, k60, u'homeassistant').  

That certainly looks like it is accepting connections from off machine.

An interesting mix of RFC1918 addresses, but maybe that's intended.

Make sure your entire home LAN setup has a consistent addressing plan,
with no reuse.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/rmift2nddc5.fsf%40s1.lexort.com.

signature.asc
Description: PGP signature

Re: [weewx-user] Questions about weewx-loopdata

i was easily installed the loop-data extension yesterday. i use weewx 4.3 
with wh1080 weather station, but data refresh every 5 minutes, with the 
rest skins of weewx

Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> Thanks for letting me know.
>
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
> Works great. Here is what I added to the loop-data.py
>
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
> wrote:
>
>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>> problem. I can just hard code the entire Davis loop which will work for my 
>> needs.
>>
>> Thanks you,
>>
>> Geoff
>>
>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>> wrote:
>>
>>> In the general case, including keys in the loop packet for non-existent 
>>> data is not a good idea.  This would break existing code (e.g., JavaScript 
>>> code I use in my skins).
>>>
>>> You could easily fork the extension and add in what you need.  At line 
>>> 736, right before write_packet_to_file is called, simply check for the keys 
>>> you need to exist, and add them if they are not there. The following should 
>>> work.  Just replace the keys I’ve listed with the ones you need in the 
>>> packet.
>>>
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> If you don’t want to hard code the keys, you’ll have a bigger task; but 
>>> you could just copy the code used to process the ‘fields’ entry in the 
>>> LoopData section of weewx.conf.
>>>
>>> Cheers,
>>> John
>>>
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>>> wrote:
>>>
>>> Hi John,
>>>
>>>
>>> This is a great extension. I'm wondering if there is a way to be able to 
>>> include sending data that is null  or none for a particular key? I'm using 
>>> a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON output 
>>> that can be ingested into a home automation system. So far it works great 
>>> as long as the data is available to be sent, but I have not figured out how 
>>> to send a key with a Null or none value. It looks like a key with a null or 
>>> none value gets cleaved off the JSON output. If a battery dies on a sensor 
>>> and it just disappears from the JSON output, that is much harder for the HA 
>>> system to handle than a null, none or zero value. 
>>>
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
>>> wrote:
>>>
 A fix is released (v2.7.2).  There is no hurry to install the new 
 release; but once you’ve installed it, you can remove the field I asked 
 you 
 to add to weewx.conf.

 On Nov 16, 2020, at 9:04 AM, Geni  wrote:

 Ok, works


 Thank you

 jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
 UTC+1:

> I can duplicate this problem and will issue a fix.
>
> In the meantime, you can add:
> rainyear.outTemp.max
> to the fields clause in the LoopData section of weewx.conf?
>
> That will stop this problem.  If you get similar errors for other 
> periods where you have no fields listed, you’ll have to temporarily add a 
> field for those periods also.
>
> I should have a fix shortly.  I don’t know that this is related to 
> WeeWX 4.2, not that that really matters. 
>
> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>
> 
>
>
> Hi john
> since weewx 4.2.0 the loop-data.txt is no longer generated?
> regards Geni
>
>
> -- 
> 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/3f89791f-c06b-43d1-beac-0afa58df59d6n%40googlegroups.com
>  
> 
> .
> 
>
> -- 
 You received this message because you are subscribed to the Google 
 Groups "weewx-user" group.
 T

Re: [weewx-user] simulator - generator critical crash

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



On Tue, Jan 26, 2021 at 12:42 AM gjr80  wrote:

> 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
>
> On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com wrote:
>
>> 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
>>
>> On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:
>>
>>> 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
>>>
>>> On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com wrote:
>>>
 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"

 On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com
 wrote:

> 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
> "ö"?
>
 --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/614395f3-d991-45f9-ad80-dba7fe59168en%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEDZdUrj-sZ%2B3x%2BeSfOeH4kxC6T%2BoCBWu2KnqVJrfW-OAQ%40mail.gmail.com.

Re: [weewx-user] simulator - generator critical crash

worked like a charmthank 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?

On Tuesday, January 26, 2021 at 3:18:19 PM UTC+1 tke...@gmail.com wrote:

> 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
>
>
>
> On Tue, Jan 26, 2021 at 12:42 AM gjr80  wrote:
>
>> 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
>>
>> On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com wrote:
>>
>>> 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
>>>
>>> On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:
>>>
 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

 On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com wrote:

> 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"
>
> On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com 
> wrote:
>
>> 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 
>> "ö"?
>>
> -- 
>>
> 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/614395f3-d991-45f9-ad80-dba7fe59168en%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/c7414cf9-7067-4d24-8d8d-1ebeb4bb3892n%40googlegroups.com.

Re: [weewx-user] simulator - generator critical crash

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.



On Tue, Jan 26, 2021 at 6:34 AM S R  wrote:

> worked like a charmthank 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?
>
> On Tuesday, January 26, 2021 at 3:18:19 PM UTC+1 tke...@gmail.com wrote:
>
>> 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
>>
>>
>>
>> On Tue, Jan 26, 2021 at 12:42 AM gjr80  wrote:
>>
>>> 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
>>>
>>> On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com wrote:
>>>
 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

 On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:

> 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
>
> On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com
> wrote:
>
>> 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"
>>
>> On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com
>> wrote:
>>
>>> 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
>>> "ö"?
>>>
>> --
>>>
>> 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/614395f3-d991-45f9-ad80-dba7fe59168en%40googlegroups.com
>>> 
>>> .
>>>
>> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/c7414cf9-7067-4d24-8d8d-1ebeb4bb3892n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"weewx-user" group.
To unsubscribe from this grou

Re: [weewx-user] simulator - generator critical crash

if you look into the interceptor.py code, you will find under IGNORED 
LABELS - 'baromrelin'.

my unit is sending
POST: 
PASSKEY=&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

On Tuesday, January 26, 2021 at 3:42:42 PM UTC+1 tke...@gmail.com wrote:

> 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.
>
>
>
> On Tue, Jan 26, 2021 at 6:34 AM S R  wrote:
>
>> worked like a charmthank 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?
>>
>> On Tuesday, January 26, 2021 at 3:18:19 PM UTC+1 tke...@gmail.com wrote:
>>
>>> 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
>>>
>>>
>>>
>>> On Tue, Jan 26, 2021 at 12:42 AM gjr80  wrote:
>>>
 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

 On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com wrote:

> 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
>
> On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:
>
>> 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
>>
>> On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com 
>> wrote:
>>
>>> 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"
>>>
>>> On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com 
>>> wrote:
>>>
 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 
 "ö"?

>>> -- 

>>> 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/614395f3-d991-45f9-ad80-dba7fe59168en%40googlegroups.com

Re: [weewx-user] Questions about weewx-loopdata

> but data refresh every 5 minutes, with the rest skins of weewx

Exactly what data are you talking about that refreshes every five minutes?

> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
> 
> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
> with wh1080 weather station, but data refresh every 5 minutes, with the rest 
> skins of weewx
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data available in 
>>> loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
 wrote:
 Awesome! This is sort of what I suspected that most use cases, NULL is a 
 problem. I can just hard code the entire Davis loop which will work for my 
 needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
> wrote:
> In the general case, including keys in the loop packet for non-existent 
> data is not a good idea.  This would break existing code (e.g., 
> JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys you need to exist, and add them if they are not there. The following 
> should work.  Just replace the keys I’ve listed with the ones you need in 
> the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; but 
> you could just copy the code used to process the ‘fields’ entry in the 
> LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>>> wrote:
>>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be able to 
>> include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON output that can be ingested into a home automation system. So far 
>> it works great as long as the data is available to be sent, but I have 
>> not figured out how to send a key with a Null or none value. It looks 
>> like a key with a null or none value gets cleaved off the JSON output. 
>> If a battery dies on a sensor and it just disappears from the JSON 
>> output, that is much harder for the HA system to handle than a null, 
>> none or zero value. 
>> 
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
>>> wrote:
>>> A fix is released (v2.7.2).  There is no hurry to install the new 
>>> release; but once you’ve installed it, you can remove the field I asked 
>>> you to add to weewx.conf.
>>> 
 On Nov 16, 2020, at 9:04 AM, Geni  wrote:
 
 Ok, works
>>> 
 
 Thank you
 
 jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
 UTC+1:
> I can duplicate this problem and will issue a fix.
> 
> In the meantime, you can add:
> rainyear.outTemp.max
> to the fields clause in the LoopData section of weewx.conf?
> 
> That will stop this problem.  If you get similar errors for other 
> periods where you have no fields listed, you’ll have to temporarily 
> add a field for those periods also.
> 
> I should have a fix shortly.  I don’t know that this is related to 
> WeeWX 4.2, not that that really matters. 
> 
>>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>> 
>> 
> 
>> 
>> Hi john
>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>> regards Geni
>> 
>> 
> 
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.
>

Re: [weewx-user] Questions about weewx-loopdata

the loop-data.txt 

https://kairos.moudania.com/kolxiko/loopdata/

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> > but data refresh every 5 minutes, with the rest skins of weewx
>
> Exactly what data are you talking about that refreshes every five minutes?
>
> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>
> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
> with wh1080 weather station, but data refresh every 5 minutes, with the 
> rest skins of weewx
>
>
>
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> Thanks for letting me know.
>>
>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>> wrote:
>>
>> Hi John,
>>
>> Works great. Here is what I added to the loop-data.py
>>
>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>> # Added to allow specific null keys if no data available 
>> in loop packet
>> must_have_keys = [ 'current.dateTime', 
>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>> for must_have_key in must_have_keys:
>> if must_have_key not in loopdata_pkt:
>> loopdata_pkt[must_have_key] = None
>>
>> Thanks!
>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>> wrote:
>>
>>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>>> problem. I can just hard code the entire Davis loop which will work for my 
>>> needs.
>>>
>>> Thanks you,
>>>
>>> Geoff
>>>
>>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>>> wrote:
>>>
 In the general case, including keys in the loop packet for non-existent 
 data is not a good idea.  This would break existing code (e.g., JavaScript 
 code I use in my skins).

 You could easily fork the extension and add in what you need.  At line 
 736, right before write_packet_to_file is called, simply check for the 
 keys 
 you need to exist, and add them if they are not there. The following 
 should 
 work.  Just replace the keys I’ve listed with the ones you need in the 
 packet.

 must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
 for must_have_key in must_have_keys:
 if must_have_key not in loopdata_pkt:
 loopdata_pkt[must_have_key] = None

 If you don’t want to hard code the keys, you’ll have a bigger task; but 
 you could just copy the code used to process the ‘fields’ entry in the 
 LoopData section of weewx.conf.

 Cheers,
 John

 On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
 wrote:

 Hi John,


 This is a great extension. I'm wondering if there is a way to be able 
 to include sending data that is null  or none for a particular key? I'm 
 using a davis vantage pro2, weewx 4.2. I'd like to use this to make a JSON 
 output that can be ingested into a home automation system. So far it works 
 great as long as the data is available to be sent, but I have not figured 
 out how to send a key with a Null or none value. It looks like a key with 
 a 
 null or none value gets cleaved off the JSON output. If a battery dies on 
 a 
 sensor and it just disappears from the JSON output, that is much harder 
 for 
 the HA system to handle than a null, none or zero value. 

 On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
 wrote:

> A fix is released (v2.7.2).  There is no hurry to install the new 
> release; but once you’ve installed it, you can remove the field I asked 
> you 
> to add to weewx.conf.
>
> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>
> Ok, works
>
>
> Thank you
>
> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
> UTC+1:
>
>> I can duplicate this problem and will issue a fix.
>>
>> In the meantime, you can add:
>> rainyear.outTemp.max
>> to the fields clause in the LoopData section of weewx.conf?
>>
>> That will stop this problem.  If you get similar errors for other 
>> periods where you have no fields listed, you’ll have to temporarily add 
>> a 
>> field for those periods also.
>>
>> I should have a fix shortly.  I don’t know that this is related to 
>> WeeWX 4.2, not that that really matters. 
>>
>> On Nov 16, 2020, at 2:45 AM, Geni  wrote:
>>
>> 
>>
>>
>> Hi john
>> since weewx 4.2.0 the loop-data.txt is no longer generated?
>> regards Geni
>>
>>
>> -- 
>> You received this message because you are subscribed to the Google 
>> Groups "weewx-user" group.
>> To unsubscribe from this group and

Re: [weewx-user] Questions about weewx-loopdata

How often does your driver write loop records?
Would you please check the actual loop-data.txt file, rather than the skin’s 
report, to see if that file is being updated on every loop record?

> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
> 
> the loop-data.txt 
> 
> https://kairos.moudania.com/kolxiko/loopdata/
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> > but data refresh every 5 minutes, with the rest skins of weewx
>> 
>> Exactly what data are you talking about that refreshes every five minutes?
>> 
 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
 
>>> i was easily installed the loop-data extension yesterday. i use weewx 4.3 
>>> with wh1080 weather station, but data refresh every 5 minutes, with the 
>>> rest skins of weewx
>> 
>>> 
>>> 
>>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 Thanks for letting me know.
 
>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>> wrote:
>> 
> Hi John,
> 
> Works great. Here is what I added to the loop-data.py
> 
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> Thanks!
>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>> wrote:
>> Awesome! This is sort of what I suspected that most use cases, NULL is a 
>> problem. I can just hard code the entire Davis loop which will work for 
>> my needs.
>> 
>> Thanks you,
>> 
>> Geoff
>> 
>>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
>>> wrote:
>>> In the general case, including keys in the loop packet for non-existent 
>>> data is not a good idea.  This would break existing code (e.g., 
>>> JavaScript code I use in my skins).
>>> 
>>> You could easily fork the extension and add in what you need.  At line 
>>> 736, right before write_packet_to_file is called, simply check for the 
>>> keys you need to exist, and add them if they are not there. The 
>>> following should work.  Just replace the keys I’ve listed with the ones 
>>> you need in the packet.
>>> 
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> If you don’t want to hard code the keys, you’ll have a bigger task; but 
>>> you could just copy the code used to process the ‘fields’ entry in the 
>>> LoopData section of weewx.conf.
>>> 
>>> Cheers,
>>> John
>>> 
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com 
>  wrote:
> 
 Hi John,
>>> 
 
 This is a great extension. I'm wondering if there is a way to be able 
 to include sending data that is null  or none for a particular key? 
 I'm using a davis vantage pro2, weewx 4.2. I'd like to use this to 
 make a JSON output that can be ingested into a home automation system. 
 So far it works great as long as the data is available to be sent, but 
 I have not figured out how to send a key with a Null or none value. It 
 looks like a key with a null or none value gets cleaved off the JSON 
 output. If a battery dies on a sensor and it just disappears from the 
 JSON output, that is much harder for the HA system to handle than a 
 null, none or zero value. 
 
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
> A fix is released (v2.7.2).  There is no hurry to install the new 
> release; but once you’ve installed it, you can remove the field I 
> asked you to add to weewx.conf.
> 
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>> 
>> Ok, works
> 
>> 
>> Thank you
>> 
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>> I can duplicate this problem and will issue a fix.
>>> 
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>> 
>>> That will stop this problem.  If you get similar errors for other 
>>

Re: [weewx-user] simulator - generator critical crash

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


On Tuesday, January 26, 2021 at 3:55:41 PM UTC+1 S R wrote:

> if you look into the interceptor.py code, you will find under IGNORED 
> LABELS - 'baromrelin'.
>
> my unit is sending
> POST: 
> PASSKEY=&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
>
> On Tuesday, January 26, 2021 at 3:42:42 PM UTC+1 tke...@gmail.com wrote:
>
>> 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.
>>
>>
>>
>> On Tue, Jan 26, 2021 at 6:34 AM S R  wrote:
>>
>>> worked like a charmthank 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?
>>>
>>> On Tuesday, January 26, 2021 at 3:18:19 PM UTC+1 tke...@gmail.com wrote:
>>>
 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



 On Tue, Jan 26, 2021 at 12:42 AM gjr80  wrote:

> 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
>
> On Tuesday, 26 January 2021 at 17:55:23 UTC+10 sjr4...@gmail.com 
> wrote:
>
>> 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
>>
>> On Tuesday, January 26, 2021 at 7:02:00 AM UTC+1 gjr80 wrote:
>>
>>> 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
>>>
>>> On Tuesday, 26 January 2021 at 15:53:23 UTC+10 sjr4...@gmail.com 
>>> wrote:
>>>
 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"

 On Monday, January 25, 2021 at 11:52:49 PM UTC+1 tke...@gmail.com 
 wrote:

> 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 
> "ö"?
>
 -- 
>
>

Re: [weewx-user] Re: MQTT Connection Refused

2021-01-26 Thread Jeff Beckman

I feel like I might not get much sleep this week, this is driving me nuts.  
I installed linux on a VM on my desktop (the one that has working MQTT 
Explorer) and it worked.  The default (oracle virtualbox) was to just 
attach to my NAT, so it got an IP of 10.0.2.15 (which my desktop passes 
through to 192.168.1.185?).  Changing it to a bridge adapter, it picked up 
a DHCP address of 192.168.1.218, and then it did not work.

Here's my full setup:  Router is a stand-alone box running pfsense.  I have 
a server that runs freebsd doing virtualization (static, 192.168.1.30).  
Home Assistant is a VM (static, 192.168.1.35).  Weewx is a raspberry pi 2 
(static, 192.168.1.17).  Desktop windows machine (DHCP, 192.168.1.185).

I have another unrelated VM running on that free bsd machine for a 
minecraft server (static, 192.168.1.36).  Remoting in there gives the same 
problems trying to publish a message.  This machine's network setup is 
almost identical to the Home Assistant machine and it is able to accept 
connections on its minecraft port, 1935 or something.  

I tried moving the Weewx machine to DHCP since it's an easy test, but no 
change.  

So the working tests are: DHCP on 192.168.1.185, windows and linux mint, 
MQTT Explorer and mosquitto-clients

The non-working tests are: static and dynamic on 192.168.1.*, linux mint 
and raspbian, mosquitto-clients

So the answer may be that I should be asking in a home networking forum, or 
possibly a Hass.io forum.  Maybe I'll do some more tests from other 
machines to try and gather some more information.  




On Tuesday, January 26, 2021 at 6:42:25 AM UTC-7 Greg Troxel wrote:

>
> Jeff Beckman  writes:
>
> > OK, that produced some interesting results. For your first suggestion, 
> my 
> > broker computer is running Hass.io (Home Assistant), which doesn't have 
> the 
> > ss command. I'll keep digging there to see if there's another way to 
> > double check that the port is open, but the log seems to indicate it's 
> > listening on 1883. 
> >
> > I installed mosquitto-clients on a raspberry pi that I'm not using for 
> > Weewx or my broker. So far everything I try there results in the same 
> > connection refused error. I've tried both as anonymous and as a user. 
> > Here's an example of an attempt:
> > pi@piopolis:~ $ mosquitto_sub -h 192.168.1.35 -t test -u homeassistant 
> -P 
> > reallylongpassword
> > Error: Connection refused
>
> That's great progress; you have shown that your MQTT setup is troubled
> without even involving weewx.
>
> It's time to:
>
> check the config file for the broker to see if it is listening on
> localhost only (which doesn't make a lot of sense) or to *:* or to
> that address specifically. Setup questions for a hass.io broker are
> probably best posed to some HA forum.
>
> check all your firewall configurations. Firewalls are notorious for
> breaking intended communication, and the fun you have fixing that is
> the tradeoff for whatever protection you get. I would do this by:
>
> reading the firewall configs
>
> querying the firewall stats and logs of filtered packets
>
> running tcpdump on both the weewx computer and the hass.io computer.
> If either is some kind of container, also add the computer hosting
> that container.
>
> > Checking the log on the broker, I see no evidence of the attempt, which 
> > would point to the port not actually being open. But then I try to 
> connect 
>
> No, it points to the operating system not doing all of receiving a SYN and
> successfully completing the TCP 3-way handshake. Brokers more or less
> all just use accept(2) to listen for connections and don't process TCP.
>
> > from my windows machine using MQTT Explorer and everything works. I can 
> > publish messages and see them pop up on my broker machine. The log looks 
> > normal. 
>
> That's an intersting clue that perhaps the problem is a firewall that
> affects the weewx machine and not the windows machine.
>
> You might also try basic things like ping of the broker from the weewx 
> machine.
>
> > 1611639012: New connection from 172.30.32.1 on port 1883. [INFO] found 
> > homeassistant on local database 
> > 1611639012: New client connected from 172.30.32.1 as 
> 5yoX9kmQROmBbxG2B0yAct 
> > (p2, c1, k60, u'homeassistant'). 
> > 1611639366: New connection from 192.168.1.185 on port 1883. [INFO] found 
> > homeassistant on local database 
> > 1611639366: New client connected from 192.168.1.185 as 
> > mqtt-explorer-a18267b6 (p2, c1, k60, u'homeassistant'). 
>
> That certainly looks like it is accepting connections from off machine.
>
> An interesting mix of RFC1918 addresses, but maybe that's intended.
>
> Make sure your entire home LAN setup has a consistent addressing plan,
> with no reuse.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on

[weewx-user] Re: Missing image when forecast_aeris_use_metar = 0

2021-01-26 Thread didier....@gmail.com

I think it's not a bug, I have found in belchertown.py
___
   if (
len(data["current"][0]["response"]) > 0
and self.generator.skin_dict["Extras"]
*["forecast_aeris_use_metar"]*
*== "0"*
):
# Non-metar responses do not contain these values. Set them 
to empty.
current_obs_summary = ""
*current_obs_icon = ""*
visibility = "N/A"
visibility_unit = ""
elif (
len(data["current"][0]["response"]) > 0
and 
self.generator.skin_dict["Extras"]["forecast_aeris_use_metar"]
== "1"
):
current_obs_summary = aeris_coded_weather(

data["current"][0]["response"]["ob"]["weatherPrimaryCoded"]
)
current_obs_icon = (

aeris_icon(data["current"][0]["response"]["ob"]["icon"]) + ".png"
)
___

If aeris_use_metar =0 then no icon displayed, right, but my question is:
What does mean "metar" and why we cannot display an icon without metar?
It is for a best understanding of this information

many thanks
Le mardi 26 janvier 2021 à 00:39:16 UTC+1, vince a écrit :

> We would have to see your entire [[Belchertown]] stanza without 
> usernames/passwords/keys to debug this.
>
> On Monday, January 25, 2021 at 2:30:05 PM UTC-8 didier@gmail.com 
> wrote:
>
>> Hi
>> Just a question:
>> Why the weather condition image is not displayed 
>> when forecast_aeris_use_metar = 0 ?
>> (I use Belchertown skin)
>>
>> Many thanks
>>
>> [image: missing.jpg]
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/8c3c8a38-868c-436a-9d44-793ace24e78en%40googlegroups.com.

Re: [weewx-user] Questions about weewx-loopdata

loop-data.txt updates every 5 minutes in web page. but in log see 
loop-data.txt every 60 secs

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> How often does your driver write loop records?
> Would you please check the actual loop-data.txt file, rather than the 
> skin’s report, to see if that file is being updated on every loop record?
>
> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>
> the loop-data.txt 
>
>
> https://kairos.moudania.com/kolxiko/loopdata/
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> > but data refresh every 5 minutes, with the rest skins of weewx
>>
>> Exactly what data are you talking about that refreshes every five minutes?
>>
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>>
>> i was easily installed the loop-data extension yesterday. i use weewx 
>> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with the 
>> rest skins of weewx
>>
>>
>>
>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> Thanks for letting me know.
>>>
>>> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
>>> wrote:
>>>
>>> Hi John,
>>>
>>> Works great. Here is what I added to the loop-data.py
>>>
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data available 
>>> in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> Thanks!
>>> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
>>> wrote:
>>>
 Awesome! This is sort of what I suspected that most use cases, NULL is 
 a problem. I can just hard code the entire Davis loop which will work for 
 my needs.

 Thanks you,

 Geoff

 On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
 wrote:

> In the general case, including keys in the loop packet for 
> non-existent data is not a good idea.  This would break existing code 
> (e.g., JavaScript code I use in my skins).
>
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys 
> you need to exist, and add them if they are not there. The following 
> should 
> work.  Just replace the keys I’ve listed with the ones you need in the 
> packet.
>
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> If you don’t want to hard code the keys, you’ll have a bigger task; 
> but you could just copy the code used to process the ‘fields’ entry in 
> the 
> LoopData section of weewx.conf.
>
> Cheers,
> John
>
> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
>
> This is a great extension. I'm wondering if there is a way to be able 
> to include sending data that is null  or none for a particular key? I'm 
> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
> JSON 
> output that can be ingested into a home automation system. So far it 
> works 
> great as long as the data is available to be sent, but I have not figured 
> out how to send a key with a Null or none value. It looks like a key with 
> a 
> null or none value gets cleaved off the JSON output. If a battery dies on 
> a 
> sensor and it just disappears from the JSON output, that is much harder 
> for 
> the HA system to handle than a null, none or zero value. 
>
> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 jo...@johnkline.com 
> wrote:
>
>> A fix is released (v2.7.2).  There is no hurry to install the new 
>> release; but once you’ve installed it, you can remove the field I asked 
>> you 
>> to add to weewx.conf.
>>
>> On Nov 16, 2020, at 9:04 AM, Geni  wrote:
>>
>> Ok, works
>>
>>
>> Thank you
>>
>> jo...@johnkline.com schrieb am Montag, 16. November 2020 um 16:05:21 
>> UTC+1:
>>
>>> I can duplicate this problem and will issue a fix.
>>>
>>> In the meantime, you can add:
>>> rainyear.outTemp.max
>>> to the fields clause in the LoopData section of weewx.conf?
>>>
>>> That will stop this problem.  If you get similar errors for other 
>>> periods wher

[weewx-user] Microsoft Edge with Steel Guages

2021-01-26 Thread philip....@gmail.com

Dont normally use Edge but a school that uses my website has just reported 
that the Steel Gauge's look a bit odd.
If you view www.sheringhamweathercentre.uk you will see what I mean
Firefox and Chrome are OK but the school cant use these for reasons I cant 
remember.
I know that Edge is a bit strange sometimes but just wondered if anybody 
had come across this.
Cheers Phil 

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/18e7f4c1-4901-4735-8210-924963fcf43bn%40googlegroups.com.

Re: [weewx-user] Questions about weewx-loopdata

Again, how often does your driver write loop records?

loop-data.txt is not written in reporting cycles.  I am asking you to look at 
the actual loop-data.txt file that is written to the .../loopdata directory.  
How often does the contents of that file change.

Also, please show what entries you are seeing in the log every one minute.

> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
> 
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the skin’s 
>> report, to see if that file is being updated on every loop record?
>> 
 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 > but data refresh every 5 minutes, with the rest skins of weewx
 
 Exactly what data are you talking about that refreshes every five minutes?
 
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>> 
> i was easily installed the loop-data extension yesterday. i use weewx 
> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with 
> the rest skins of weewx
 
> 
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data 
>>> available in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
 geoffs...@gmail.com wrote:
 Awesome! This is sort of what I suspected that most use cases, NULL is 
 a problem. I can just hard code the entire Davis loop which will work 
 for my needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
> In the general case, including keys in the loop packet for 
> non-existent data is not a good idea.  This would break existing code 
> (e.g., JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At 
> line 736, right before write_packet_to_file is called, simply check 
> for the keys you need to exist, and add them if they are not there. 
> The following should work.  Just replace the keys I’ve listed with 
> the ones you need in the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; 
> but you could just copy the code used to process the ‘fields’ entry 
> in the LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com 
>>>  wrote:
>>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be 
>> able to include sending data that is null  or none for a particular 
>> key? I'm using a davis vantage pro2, weewx 4.2. I'd like to use this 
>> to make a JSON output that can be ingested into a home automation 
>> system. So far it works great as long as the data is available to be 
>> sent, but I have not figured out how to send a key with a Null or 
>> none value. It looks like a key with a null or none value gets 
>> cleaved off the JSON output. If a battery dies on a sensor and it 
>> just disappears from the JSON output, that is much harder for the HA 
>> system to handle than a null, none or zero value. 
>> 
>>> On Monday, November 16, 2020 at 2:57:13 PM UTC-8 
>

Re: [weewx-user] Questions about weewx-loopdata

well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
60 seconds its ok. but in weather page  refreshing every 5 minutes

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> Again, how often does your driver write loop records?
>
> loop-data.txt is not written in reporting cycles.  I am asking you to look 
> at the actual loop-data.txt file that is written to the .../loopdata 
> directory.  How often does the contents of that file change.
>
> Also, please show what entries you are seeing in the log every one minute.
>
> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
>
>
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the 
>> skin’s report, to see if that file is being updated on every loop record?
>>
>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>>
>> the loop-data.txt 
>>
>>
>> https://kairos.moudania.com/kolxiko/loopdata/
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> > but data refresh every 5 minutes, with the rest skins of weewx
>>>
>>> Exactly what data are you talking about that refreshes every five 
>>> minutes?
>>>
>>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  wrote:
>>>
>>> i was easily installed the loop-data extension yesterday. i use weewx 
>>> 4.3 with wh1080 weather station, but data refresh every 5 minutes, with the 
>>> rest skins of weewx
>>>
>>>
>>>
>>> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 Thanks for letting me know.

 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
 wrote:

 Hi John,

 Works great. Here is what I added to the loop-data.py

 Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
 # Added to allow specific null keys if no data 
 available in loop packet
 must_have_keys = [ 'current.dateTime', 
 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
 for must_have_key in must_have_keys:
 if must_have_key not in loopdata_pkt:
 loopdata_pkt[must_have_key] = None

 Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
 wrote:

> Awesome! This is sort of what I suspected that most use cases, NULL is 
> a problem. I can just hard code the entire Davis loop which will work for 
> my needs.
>
> Thanks you,
>
> Geoff
>
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
>
>> In the general case, including keys in the loop packet for 
>> non-existent data is not a good idea.  This would break existing code 
>> (e.g., JavaScript code I use in my skins).
>>
>> You could easily fork the extension and add in what you need.  At 
>> line 736, right before write_packet_to_file is called, simply check for 
>> the 
>> keys you need to exist, and add them if they are not there. The 
>> following 
>> should work.  Just replace the keys I’ve listed with the ones you need 
>> in 
>> the packet.
>>
>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>> for must_have_key in must_have_keys:
>> if must_have_key not in loopdata_pkt:
>> loopdata_pkt[must_have_key] = None
>>
>> If you don’t want to hard code the keys, you’ll have a bigger task; 
>> but you could just copy the code used to process the ‘fields’ entry in 
>> the 
>> LoopData section of weewx.conf.
>>
>> Cheers,
>> John
>>
>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com  
>> wrote:
>>
>> Hi John,
>>
>>
>> This is a great extension. I'm wondering if there is a way to be able 
>> to include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON 
>> output that can be ingested into a home automation system. So far it 
>> works 
>> great as long as the data is available to be sent, but I have not 
>> figured 
>> out how to send a key with a Null or none value. It looks like a key 
>> with a 
>> null or none value gets cleaved off the JSON output. If a battery dies 
>> on a 
>> sensor and it just disappears from the JSON output, that is much harder 
>> for 
>> the HA system to handle than a null, none or zero value. 
>>
>> On Monday,

[weewx-user] Re: Microsoft Edge with Steel Guages

i think its css issue dont edge. i see with chromiun your gauges bit odd. 
seiing your http://www.sheringhamweathercentre.uk/ss/css/gauges-ss.css  

.gaugeSizeStd { width: 99%; height: 99%; }   you can try width and heiht in 
pixels  for example  .gaugeSizeStd{width:221px;height:221px}  you can play 
with width and height.  

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:43:35 μ.μ. UTC+2, ο χρήστης 
philip@gmail.com έγραψε:

> Dont normally use Edge but a school that uses my website has just reported 
> that the Steel Gauge's look a bit odd.
> If you view www.sheringhamweathercentre.uk you will see what I mean
> Firefox and Chrome are OK but the school cant use these for reasons I cant 
> remember.
> I know that Edge is a bit strange sometimes but just wondered if anybody 
> had come across this.
> Cheers Phil 
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/d061a530-3c55-4516-bb68-5012efe858dfn%40googlegroups.com.

Re: [weewx-user] Unable to wake up Vantage console

2021-01-26 Thread Txo

Thanks. With  /dev/ttyS0 I get:
pi@raspledeuix:~ $ python /home/pi/samsung/serie.py

pi@raspledeuix:~ $ 

nothing

Same answer with /dev/AMA0


$ dmesg | grep serial

[0.928774] uart-pl011 3f201000.serial: cts_event_workaround enabled
[0.931796] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, 
base_baud = 0) is a PL011 rev2
[0.939379] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud = 
5000) is a 16550
[  595.077242] uart-pl011 3f201000.serial: no DMA platform data

But I find:
weewx.WakeupError: Unable to wake up Vantage console

Le mardi 26 janvier 2021 à 12:59:18 UTC+1, tke...@gmail.com a écrit :

> Try running this very simple program. Substitute whatever port you are 
> using for '/dev/ttyS0'.
>
> import serial
> import time
>
> s = serial.Serial('/dev/ttyS0', 19200, timeout=3)
>
> s.write(b'\n')
> time.sleep(0.5)
> s.write(b'TEST\n')
> time.sleep(0.5)
> buf = s.read(10)
> print(buf)
>
> This little program will do the standard Davis test for connectivity by 
> asking the console to echo the word "TEST". It should print out something 
> like:
>
> response: b'\n\r\n\rTEST\n\r'
>
> If not, then you are either on the wrong port, or the logger is not acting 
> like a true clone.
>
> -tk
>
>
>
> On Mon, Jan 25, 2021 at 11:07 PM Txo  wrote:
>
>> @Vince
>> This had already been done for a top hat with serial port.
>>
>> @Chris
>> I made the changes recommended by Chris and no more «@Vince
>> Unable to wake up Vantage console
>> This had already been done for a top hat with serial port.
>>
>> @Chris
>> I made the changes recommended by Chris and no more «Unable to wake up 
>> Vantage console» but now
>>
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine:   self.serial_port = serial.Serial(self.port, 
>> self.baudrate, timeout=self.timeout)
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine: File 
>> "/usr/lib/python3/dist-packages/serial/serialutil.py", line 240, in __init__
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine:   self.open()
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine: File 
>> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 272, in open
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine:   self._reconfigure_port(force_update=True)
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine: File 
>> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 326, in 
>> _reconfigure_port
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine:   raise SerialException("Could not configure 
>> port: {}".format(msg))
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL 
>> weewx.engine:   serial.serialutil.SerialException: Could not 
>> configure port: (5, "Erreur d'entrée/sortie")
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL __main__: 
>> Unable to load driver: Could not configure port: (5, "Erreur 
>> d'entrée/sortie")
>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL __main__: 
>>   Exiting...
>>
>> ls -l /dev/ttyS*
>> crw-rw 1 root dialout 4, 64 janv. 26 07:34 /dev/ttyS0
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:  
>>  Traceback (most recent call last):
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 323, in 
>> _reconfigure_port
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>orig_attr = termios.tcgetattr(self.fd)
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:  
>>  termios.error: (5, "Erreur d'entrée/sortie")
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:   
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:  
>>  During handling of the above exception, another exception occurred:
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:   
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:  
>>  Traceback (most recent call last):
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/weewx/engine.py", line 119, in setupStation
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>self.console = loader_function(config_dict, self)
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/weewx/drivers/vantage.py", line 39, in loader
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>return VantageService(engine, config_dict)
>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine:    
>>  File "/usr/share/weewx/weewx/drivers/vantage.py"

Re: [weewx-user] Questions about weewx-loopdata

OK, the behavior we are seeing leads me to believe your web server is on a 
remote machine; i.e., not on the same machine as weewx.  Is that correct?  If 
so, you’ll need to use rsync by filling out and enabling it under:

[LoopData]
[[RsyncSpec]]


> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
> 
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 60 
> seconds its ok. but in weather page  refreshing every 5 minutes
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
> Again, how often does your driver write loop records?
> 
> loop-data.txt is not written in reporting cycles.  I am asking you to look at 
> the actual loop-data.txt file that is written to the .../loopdata directory.  
> How often does the contents of that file change.
> 
> Also, please show what entries you are seeing in the log every one minute.
> 
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος > > wrote:
>> 
>> loop-data.txt updates every 5 minutes in web page. but in log see 
>> loop-data.txt every 60 secs
> 
>> 
>> 
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com  
>> έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the skin’s 
>> report, to see if that file is being updated on every loop record?
>> 
>>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος > wrote:
>>> 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/ 
>>> 
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com <> έγραψε:
>>> > but data refresh every 5 minutes, with the rest skins of weewx
>>> 
>>> Exactly what data are you talking about that refreshes every five minutes?
>>> 
 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος > wrote:
 
 i was easily installed the loop-data extension yesterday. i use weewx 4.3 
 with wh1080 weather station, but data refresh every 5 minutes, with the 
 rest skins of weewx
>>> 
 
 
 Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
 jo...@johnkline.com <> έγραψε:
 Thanks for letting me know.
 
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com <>  <>> wrote:
> 
 
> Hi John,
> 
> Works great. Here is what I added to the loop-data.py
> 
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data available 
> in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 geoffs...@gmail.com 
> <> wrote:
> Awesome! This is sort of what I suspected that most use cases, NULL is a 
> problem. I can just hard code the entire Davis loop which will work for 
> my needs.
> 
> Thanks you,
> 
> Geoff
> 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 jo...@johnkline.com 
> <> wrote:
> In the general case, including keys in the loop packet for non-existent 
> data is not a good idea.  This would break existing code (e.g., 
> JavaScript code I use in my skins).
> 
> You could easily fork the extension and add in what you need.  At line 
> 736, right before write_packet_to_file is called, simply check for the 
> keys you need to exist, and add them if they are not there. The following 
> should work.  Just replace the keys I’ve listed with the ones you need in 
> the packet.
> 
> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
> 
> If you don’t want to hard code the keys, you’ll have a bigger task; but 
> you could just copy the code used to process the ‘fields’ entry in the 
> LoopData section of weewx.conf.
> 
> Cheers,
> John
> 
>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com <> > <>> wrote:
>> 
>> Hi John,
> 
>> 
>> This is a great extension. I'm wondering if there is a way to be able to 
>> include sending data that is null  or none for a particular key? I'm 
>> using a davis vantage pro2, weewx 4.2. I'd like to use this to make a 
>> JSON output that can be ingested into a home automation system. So far 
>> it works great as long as the data is available to be sent, but I

Re: [weewx-user] Unable to wake up Vantage console

1, Nothing? Under Python 3, it should have at least printed a null string.
Something like

b''

2. You are on the right track for figuring out which serial port your
Meteo-pi is using. However, by using 'grep serial' you are excluding usb
converter messages. Instead, try

dmesg | grep 'tty'

3. Assuming you have the right port, your Meteo-pi is not acting like a
Davis clone.

-tk


On Tue, Jan 26, 2021 at 8:13 AM Txo  wrote:

> Thanks. With  /dev/ttyS0 I get:
> pi@raspledeuix:~ $ python /home/pi/samsung/serie.py
>
> pi@raspledeuix:~ $
>
> nothing
>
> Same answer with /dev/AMA0
>
>
> $ dmesg | grep serial
>
> [0.928774] uart-pl011 3f201000.serial: cts_event_workaround enabled
> [0.931796] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81,
> base_baud = 0) is a PL011 rev2
> [0.939379] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud =
> 5000) is a 16550
> [  595.077242] uart-pl011 3f201000.serial: no DMA platform data
>
> But I find:
> weewx.WakeupError: Unable to wake up Vantage console
>
> Le mardi 26 janvier 2021 à 12:59:18 UTC+1, tke...@gmail.com a écrit :
>
>> Try running this very simple program. Substitute whatever port you are
>> using for '/dev/ttyS0'.
>>
>> import serial
>> import time
>>
>> s = serial.Serial('/dev/ttyS0', 19200, timeout=3)
>>
>> s.write(b'\n')
>> time.sleep(0.5)
>> s.write(b'TEST\n')
>> time.sleep(0.5)
>> buf = s.read(10)
>> print(buf)
>>
>> This little program will do the standard Davis test for connectivity by
>> asking the console to echo the word "TEST". It should print out something
>> like:
>>
>> response: b'\n\r\n\rTEST\n\r'
>>
>> If not, then you are either on the wrong port, or the logger is not
>> acting like a true clone.
>>
>> -tk
>>
>>
>>
>> On Mon, Jan 25, 2021 at 11:07 PM Txo  wrote:
>>
>>> @Vince
>>> This had already been done for a top hat with serial port.
>>>
>>> @Chris
>>> I made the changes recommended by Chris and no more «@Vince
>>> Unable to wake up Vantage console
>>> This had already been done for a top hat with serial port.
>>>
>>> @Chris
>>> I made the changes recommended by Chris and no more «Unable to wake up
>>> Vantage console» but now
>>>
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine:   self.serial_port = serial.Serial(self.port,
>>> self.baudrate, timeout=self.timeout)
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine: File
>>> "/usr/lib/python3/dist-packages/serial/serialutil.py", line 240, in __init__
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine:   self.open()
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine: File
>>> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 272, in open
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine:   self._reconfigure_port(force_update=True)
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine: File
>>> "/usr/lib/python3/dist-packages/serial/serialposix.py", line 326, in
>>> _reconfigure_port
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine:   raise SerialException("Could not configure
>>> port: {}".format(msg))
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> weewx.engine:   serial.serialutil.SerialException: Could not
>>> configure port: (5, "Erreur d'entrée/sortie")
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> __main__: Unable to load driver: Could not configure port: (5, "Erreur
>>> d'entrée/sortie")
>>> janv. 26 07:35:15 raspledeuix python3[826]: weewx[826] CRITICAL
>>> __main__:   Exiting...
>>>
>>> ls -l /dev/ttyS*
>>> crw-rw 1 root dialout 4, 64 janv. 26 07:34 /dev/ttyS0
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  Traceback (most recent call last):
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  File "/usr/lib/python3/dist-packages/serial/serialposix.py", line 323, in
>>> _reconfigure_port
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>orig_attr = termios.tcgetattr(self.fd)
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  termios.error: (5, "Erreur d'entrée/sortie")
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  During handling of the above exception, another exception occurred:
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  Traceback (most recent call last):
>>> Jan 26 07:35:15 raspledeuix weewx[826] CRITICAL weewx.engine: 
>>>  File "/usr/share/weewx/weewx/engine.py", line 119, in setupStation
>>> Jan 26 07:35:15 ras

[weewx-user] belchertown skin

2021-01-26 Thread orders

Hi what would be causing all this as I get a good webpage to display after
each update but with this in log every loop?

 

 

 

 

an 26 08:22:02 

raspberrypi weewx[5] INFO weewx.restx: Wunderground:Posting not enabled.
Jan 26 08:22:02 raspberrypi weewx[5] INFOweewx.restx: 

PWSweather: Posting not enabled. Jan 26 08:22:02 raspberrypi
weewx[5]INFO weewx.restx: 

CWOP: Posting not enabled.

Jan 26 08:22:02 raspberrypi weewx[5] INFO weewx.restx: WOW: Posting not
enabled. Jan 26 08:22:02 raspberrypi weewx[5] INFO weewx.restx:

AWEKAS: Posting not enabled. Jan 26 08:22:02 raspberrypi weewx[5] INFO
__main__: Starting up weewx version 4.3.0 Jan 26 08:22:03 raspberrypi
weewx[5] INFO weewx.engine: Clock error is 3.18 seconds (positive is
fast) Jan 26 08:22:03 raspberrypi weewx[5] INFO

weewx.engine: Using binding 'wx_binding' to database 'weewx.sdb' Jan 26

08:22:03 raspberrypi weewx[5] INFO weewx.manager: Starting backfill of
daily summaries Jan 26 08:22:05 raspberrypi weewx[5] INFO

weewx.engine: Starting main packet loop. Jan 26 08:25:14 raspberrypi
weewx[5] INFO weewx.manager: Added record 2021-01-26 08:25:00 MST

(1611674700) to database 'weewx.sdb' Jan 26 08:25:14 raspberrypi
weewx[5] INFO weewx.manager: Added record 2021-01-26 08:25:00 MST

(1611674700) to daily summary in 'weewx.sdb' Jan 26 08:25:17 raspberrypi
weewx[5] INFO weewx.cheetahgenerator: Generated 8 files for report
SeasonsReport in 1.77 seconds Jan 26 08:25:17 raspberrypi weewx[5] INFO
weewx.imagegenerator: Generated 15 images for report SeasonsReport in 0.67
seconds Jan 26 08:25:17 raspberrypi weewx[5] INFO weewx.reportengine:
Copied 5 files to /var/www/html/weewx Jan 26

08:25:17 raspberrypi weewx[5] INFO user.belchertown: version 1.2 Jan 26
08:25:17 raspberrypi weewx[5] ERROR user.belchertown: Error getting AQI
from Aeris weather. The error was:#012list index out of range#012The
response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=***

Jan 26 08:25:18 raspberrypi weewx[5] ERROR user.belchertown: Error
getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=*

getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=

Jan 26 08:25:19 raspberrypi weewx[5] ERROR user.belchertown: Error
getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=**

Jan 26 08:25:19 raspberrypi weewx[5] ERROR user.belchertown: Error
getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=*

Jan 26 08:25:19 raspberrypi weewx[5] ERROR user.belchertown: Error
getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from the Aeris AQI server was:#012[{'success':

True, 'error': {'code': 'warn_no_data', 'description': 'Valid request.

No results available based on your query parameters.'}, 'response':

[]}]#012The URL being used

is:#012https://api.aerisapi.com/airquality/closest?p=42.8375,-103.0094&forma
t=json&radius=50mi&limit=1&client_id=*

Jan 26 08:25:19 raspberrypi weewx[5] ERROR user.belchertown: Error
getting AQI from Aeris weather. The error was:#012list index out of
range#012The response from t

[weewx-user] Re: Missing image when forecast_aeris_use_metar = 0

2021-01-26 Thread vince

On Tuesday, January 26, 2021 at 7:34:30 AM UTC-8 didier@gmail.com wrote:

> If aeris_use_metar =0 then no icon displayed, right, but my question is:
> What does mean "metar" and why we cannot display an icon without metar?
> It is for a best understanding of this information
>
>
The Belchertown forecast options are documented 
at https://github.com/poblabs/weewx-belchertown#forecast-options

If you set forecast_aeris_use_metar = 0 there is no icon.
If you set forecast_aeris_use_metar = 1 there 'is' an icon.

The actual code is within lines 1581-1634 
in 
https://github.com/poblabs/weewx-belchertown/blob/master/bin/user/belchertown.py


-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/3b94266a-a3e7-433d-8b77-db87a3261c10n%40googlegroups.com.

Re: [weewx-user] Unable to wake up Vantage console

2021-01-26 Thread Txo


Le 26/01/2021 à 17:37, Tom Keffer a écrit :

1, Nothing? Under Python 3, it should have at least printed a null
string. Something like

b''


No more an empty row.Sometime "[]"



2. You are on the right track for figuring out which serial port
your Meteo-pi is using. However, by using 'grep serial' you are
excluding usb converter messages. Instead, try

dmesg | grep 'tty



$ dmesg | grep 'tty'
[0.00] Kernel command line: coherent_pool=1M 8250.nr_uarts=1
bcm2708_fb.fbwidth=720 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1
vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000
dwc_otg.lpm_enable=0  console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4
elevator=deadline fsck.repair=yes rootwait
[0.000906] console [tty1] enabled
[0.931796] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81,
base_baud = 0) is a PL011 rev2
[0.939379] 3f215040.serial: ttyS0 at MMIO 0x0 (irq = 53, base_baud =
5000) is a 16550



3. Assuming you have the right port, your Meteo-pi is not acting like
a Davis clone.



The seller answered and sent me a manual for … Cumulus. I will try
anyway tomorrow.

--
-- Dominique Marin http://txodom.free.fr  --
  «Sous les pavés y'a plus la plage, il y a l'enfer et la Sécurité.»
--   Léo Ferré Il n'y a plus rien --

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/e44c679b-cdd6-9a5b-e47e-54e3ac8bf629%40gmail.com.

Re: [weewx-user] Re: Missing image when forecast_aeris_use_metar = 0

2021-01-26 Thread Didier Decoodt

Thank you Vince

Le mar. 26 janv. 2021 à 18:07, vince  a écrit :

> On Tuesday, January 26, 2021 at 7:34:30 AM UTC-8 didier@gmail.com
> wrote:
>
>> If aeris_use_metar =0 then no icon displayed, right, but my question is:
>> What does mean "metar" and why we cannot display an icon without metar?
>> It is for a best understanding of this information
>>
>>
> The Belchertown forecast options are documented at
> https://github.com/poblabs/weewx-belchertown#forecast-options
>
> If you set forecast_aeris_use_metar = 0 there is no icon.
> If you set forecast_aeris_use_metar = 1 there 'is' an icon.
>
> The actual code is within lines 1581-1634 in
> https://github.com/poblabs/weewx-belchertown/blob/master/bin/user/belchertown.py
>
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/3b94266a-a3e7-433d-8b77-db87a3261c10n%40googlegroups.com
> 
> .
>


-- 
Quel temps fait-il à Auffargis  ?

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAAvt3%3DSQCBkXr0gPLHFJrRv0045WjLR61%2BWxVrQjYz%3DhQXjWdg%40mail.gmail.com.

Re: [weewx-user] Questions about weewx-loopdata

its correct i have remote server. in remote server uploading the 
loop-data.txt but uploadind every 5 minutes . 

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> OK, the behavior we are seeing leads me to believe your web server is on a 
> remote machine; i.e., not on the same machine as weewx.  Is that correct? 
>  If so, you’ll need to use rsync by filling out and enabling it under:
>
> [LoopData]
> [[RsyncSpec]]
>
>
> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
> 60 seconds its ok. but in weather page  refreshing every 5 minutes
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης jo...@
> johnkline.com έγραψε:
>
>> Again, how often does your driver write loop records?
>>
>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>> look at the actual loop-data.txt file that is written to the .../loopdata 
>> directory.  How often does the contents of that file change.
>>
>> Also, please show what entries you are seeing in the log every one minute.
>>
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>>
>> loop-data.txt updates every 5 minutes in web page. but in log see 
>> loop-data.txt every 60 secs
>>
>>
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>> jo...@johnkline.com έγραψε:
>>
>>> How often does your driver write loop records?
>>> Would you please check the actual loop-data.txt file, rather than the 
>>> skin’s report, to see if that file is being updated on every loop record?
>>>
>>> On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  wrote:
>>>
>>> the loop-data.txt 
>>>
>>>
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>>
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 > but data refresh every 5 minutes, with the rest skins of weewx

 Exactly what data are you talking about that refreshes every five 
 minutes?

 On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  
 wrote:

 i was easily installed the loop-data extension yesterday. i use weewx 
 4.3 with wh1080 weather station, but data refresh every 5 minutes, with 
 the 
 rest skins of weewx



 Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
 jo...@johnkline.com έγραψε:

> Thanks for letting me know.
>
> On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com  
> wrote:
>
> Hi John,
>
> Works great. Here is what I added to the loop-data.py
>
> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
> # Added to allow specific null keys if no data 
> available in loop packet
> must_have_keys = [ 'current.dateTime', 
> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
> for must_have_key in must_have_keys:
> if must_have_key not in loopdata_pkt:
> loopdata_pkt[must_have_key] = None
>
> Thanks!
> On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
> geoffs...@gmail.com wrote:
>
>> Awesome! This is sort of what I suspected that most use cases, NULL 
>> is a problem. I can just hard code the entire Davis loop which will work 
>> for my needs.
>>
>> Thanks you,
>>
>> Geoff
>>
>> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
>> jo...@johnkline.com wrote:
>>
>>> In the general case, including keys in the loop packet for 
>>> non-existent data is not a good idea.  This would break existing code 
>>> (e.g., JavaScript code I use in my skins).
>>>
>>> You could easily fork the extension and add in what you need.  At 
>>> line 736, right before write_packet_to_file is called, simply check for 
>>> the 
>>> keys you need to exist, and add them if they are not there. The 
>>> following 
>>> should work.  Just replace the keys I’ve listed with the ones you need 
>>> in 
>>> the packet.
>>>
>>> must_have_keys = [ 'current.outTemp', 'current.outHumidity' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>>
>>> If you don’t want to hard code the keys, you’ll have a bigger task; 
>>> but you could just copy the code used to process the ‘fields’ entry in 
>>> the 
>>> LoopData section of weewx.conf.
>>>
>>> Cheers,
>>> John
>>>
>>> On Nov 24, 2020, at 8:54 PM, geoffs...@gmail.com <
>>> geoffs...@gmail.com> wrote:
>>>
>>> Hi John,
>>>
>>>
>>> This is a great extension. I'm wondering if there is a way to be 
>>> able to include sending

Re: [weewx-user] Questions about weewx-loopdata

As the README states:
If you need the loop-data.txt file pushed to a remote webserver, you will also 
need to fill in the RsyncSpec fields; but one can fill that in later, after 
LoopData is up and running.

It appears loopdata is up and running and working on the local machine.  Have 
you set up rsync for loopdata?

Please see the following sections of the README:

https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf

https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help

https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server

https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log

> On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
> 
> its correct i have remote server. in remote server uploading the 
> loop-data.txt but uploadind every 5 minutes . 
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> OK, the behavior we are seeing leads me to believe your web server is on a 
>> remote machine; i.e., not on the same machine as weewx.  Is that correct?  
>> If so, you’ll need to use rsync by filling out and enabling it under:
>> 
>> [LoopData]
>> [[RsyncSpec]]
>> 
>> 
 On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
 
>>> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing every 
>>> 60 seconds its ok. but in weather page  refreshing every 5 minutes
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 Again, how often does your driver write loop records?
 
 loop-data.txt is not written in reporting cycles.  I am asking you to look 
 at the actual loop-data.txt file that is written to the .../loopdata 
 directory.  How often does the contents of that file change.
 
 Also, please show what entries you are seeing in the log every one minute.
 
>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>> 
> loop-data.txt updates every 5 minutes in web page. but in log see 
> loop-data.txt every 60 secs
 
> 
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> How often does your driver write loop records?
>> Would you please check the actual loop-data.txt file, rather than the 
>> skin’s report, to see if that file is being updated on every loop record?
>> 
 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  
 wrote:
 
>>> the loop-data.txt 
>> 
>>> 
>>> https://kairos.moudania.com/kolxiko/loopdata/
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:07:58 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 > but data refresh every 5 minutes, with the rest skins of weewx
 
 Exactly what data are you talking about that refreshes every five 
 minutes?
 
>> On Jan 26, 2021, at 6:02 AM, Δημήτρης Βήχος  
>> wrote:
>> 
> i was easily installed the loop-data extension yesterday. i use 
> weewx 4.3 with wh1080 weather station, but data refresh every 5 
> minutes, with the rest skins of weewx
 
> 
> 
> Στις Πέμπτη, 26 Νοεμβρίου 2020 στις 6:46:10 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Thanks for letting me know.
>> 
 On Nov 26, 2020, at 7:32 AM, geoffs...@gmail.com 
  wrote:
 
>>> Hi John,
>>> 
>>> Works great. Here is what I added to the loop-data.py
>>> 
>>> Line 735 self.ten_min_packets, self.cfg.ten_min_obstypes)
>>> # Added to allow specific null keys if no data 
>>> available in loop packet
>>> must_have_keys = [ 'current.dateTime', 
>>> 'current.extraTemp1.raw', 'current.extraTemp2.raw', 
>>> 'current.extraTemp3.raw', 'current.extraHumid1.raw', 
>>> 'current.extraHumid2.raw', 'current.extraHumid3.raw' ]
>>> for must_have_key in must_have_keys:
>>> if must_have_key not in loopdata_pkt:
>>> loopdata_pkt[must_have_key] = None
>>> 
>>> Thanks!
 On Wednesday, November 25, 2020 at 7:06:46 AM UTC-8 
 geoffs...@gmail.com wrote:
 Awesome! This is sort of what I suspected that most use cases, 
 NULL is a problem. I can just hard code the entire Davis loop 
 which will work for my needs.
 
 Thanks you,
 
 Geoff
 
> On Wednesday, November 25, 2020 at 6:45:44 AM UTC-8 
> jo...@johnkline.com wrote:
> In the general case, including keys in the loop packet for 
> non-e

RE: [weewx-user] Re: Acurite 5in1 and rtl_sdr

2021-01-26 Thread clayj

Hi, Sean – I have a 5-in-1, and it normally sends every 20-30 seconds.  
However,  I had to buy one of the Acurite repeaters to get a reliable 
connection to my base, I have lots of metal between the sensor and my receiver, 
AND I’m a ham radio operator with LOTS of RF devices, so I’m in an “RF-Rich” 
environment.I’d recommend looking at the signal strength bars on your base; 
and making sure your base is receiving correctly.

 

Good luck!

 

Clay

 

 

From: weewx-user@googlegroups.com  On Behalf Of 
seano...@gmail.com
Sent: Monday, January 25, 2021 1:22 AM
To: weewx-user 
Subject: [weewx-user] Re: Acurite 5in1 and rtl_sdr

 

Hi,

 

Just a quick nudge about this. The Acurite 5-in-1 and the SDR are working, but 
there are still times when minutes or hours can pass where the SDR is not 
receiving any packets from the sensor, and therefore no broadcasts to wind 
guru. Has anyone got any good ideas on troubleshooting this? Here is a lot of 
the last few hours 
https://u.pcloud.link/publink/show?code=XZiEH8XZD0glneQHykh8633IJuS6Xbc3fyzk

 

It's just so strange that sometimes the sensor will send a packet every 
20-seconds, and other times a few minutes will pass without a packet being 
received. One would think that the packets should be consistent and regular.

 

Does anyone have any insight into how the Acurite 5-in-1 sensor sends packets - 
should it be at a set time every x seconds, or is erratic normal?

 

I don't understand SDR much, could there be another device nearby that is 
interfering with the receiving of packets?

 

Pulling my hair out trying to troubleshoot this problem!!

 

Thanks,

Sean.

-- 
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+unsubscr...@googlegroups.com 
 .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/2965896c-090b-4e59-a2ef-52dcfe744fa8n%40googlegroups.com
 

 .

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/03d201d6f41a%24cfbc4ec0%246f34ec40%24%40n7qnm.net.

Re: [weewx-user] Questions about weewx-loopdata

i have setup for loopdata

[LoopData]
[[FileSpec]]
loop_data_dir = .
filename = loop-data.txt
[[Formatting]]
target_report = LoopDataReport
[[LoopFrequency]]
seconds = 30
[[RsyncSpec]]
enable = true
remote_server = ftpupload.net
remote_user = epiz_27298028
remote_dir = /htdocs/test
compress = true
log_success = true
ssh_options = -o ConnectTimeout=1
timeout = 1
skip_if_older_than = 3
[[Include]]
fields = trend.outTemp, trend.barometer.desc, current.barometer, 
current.dateTime.raw, current.dewpoint, current.dewpoint.formatted, 
current.heatindex, current.outHumidity, current.outTemp, 
current.outTemp.formatted, current.rain, current.rainRate, 
current.rainRate.formatted, current.windchill, 
current.windDir.ordinal_compass, current.windSpeed, 
current.windSpeed.formatted, current.windSpeed.raw, 
10m.outTemp.max.formatted, 10m.outTemp.min.formatted, 
10m.rain.sum.formatted, 10m.wind.rms.formatted, 10m.windGust.max, 
10m.windGust.max.formatted, day.outTemp.max.formatted, 
day.outTemp.min.formatted, day.rain.sum, day.rain.sum.formatted, 
day.wind.rms.formatted, day.windGust.max, day.windGust.max.formatted, 
week.outTemp.max.formatted, week.outTemp.min.formatted, 
week.rain.sum.formatted, week.wind.rms.formatted, 
week.windGust.max.formatted, month.outTemp.max.formatted, 
month.outTemp.min.formatted, month.rain.sum.formatted, 
month.wind.rms.formatted, month.windGust.max.formatted, 
year.outTemp.max.formatted, year.outTemp.min.formatted, 
year.rain.sum.formatted, year.wind.rms.formatted, 
year.windGust.max.formatted, rainyear.outTemp.max.formatted, 
rainyear.outTemp.min.formatted, rainyear.rain.sum.formatted, 
rainyear.wind.rms.formatted, rainyear.windGust.max.formatted
[[BarometerTrendDescriptions]]
RISING_VERY_RAPIDLY = Rising Very Rapidly
RISING_QUICKLY = Rising Quickly
RISING = Rising
RISING_SLOWLY = Rising Slowly
STEADY = Steady
FALLING_SLOWLY = Falling Slowly
FALLING = Falling
FALLING_QUICKLY = Falling Quickly
FALLING_VERY_RAPIDLY = Falling Very Rapidly

Στις Τρίτη, 26 Ιανουαρίου 2021 στις 9:12:55 μ.μ. UTC+2, ο χρήστης 
jo...@johnkline.com έγραψε:

> As the README states:
>
>- If you need the loop-data.txt file pushed to a remote webserver, you 
>will also need to fill in the RsyncSpec fields; but one can fill that 
>in later, after LoopData is up and running.
>
>
> It appears loopdata is up and running and working on the local machine. 
>  Have you set up rsync for loopdata?
>
> Please see the following sections of the README:
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server
>
>
> https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log
>
> On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
>
> its correct i have remote server. in remote server uploading the 
> loop-data.txt but uploadind every 5 minutes . 
>
>
>
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>
>> OK, the behavior we are seeing leads me to believe your web server is on 
>> a remote machine; i.e., not on the same machine as weewx.  Is that correct? 
>>  If so, you’ll need to use rsync by filling out and enabling it under:
>>
>> [LoopData]
>> [[RsyncSpec]]
>>
>>
>> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>>
>> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing 
>> every 60 seconds its ok. but in weather page  refreshing every 5 minutes
>>
>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης jo...@
>> johnkline.com έγραψε:
>>
>>> Again, how often does your driver write loop records?
>>>
>>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>>> look at the actual loop-data.txt file that is written to the .../loopdata 
>>> directory.  How often does the contents of that file change.
>>>
>>> Also, please show what entries you are seeing in the log every one 
>>> minute.
>>>
>>> On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  wrote:
>>>
>>> loop-data.txt updates every 5 minutes in web page. but in log see 
>>> loop-data.txt every 60 secs
>>>
>>>
>>>
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:19:17 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
>>>
 How often does your driver write loop records?
 Would you please check the actual loop-data.txt file, rather than the 
 skin’s report, to see if that file is being updated on every loop record?

 On Jan 26, 2021, at 7:15 AM, Δημήτρης Βήχος  
 wrote:

 the loop-data.txt 

 https://kairos.moudania.com/kolxiko/loopdata/

>

Re: [weewx-user] Questions about weewx-loopdata

> remote_server = ftpupload.net
I would expect the remote server to be kairos.moudania.com
It looks like you are trying to use an ftp server.  If so, that simply won’t 
work.
If you don’t have ssh access to your server, such that you can get rsync to 
work, you will not be able to use the loopdata extension.

> On Jan 26, 2021, at 12:00 PM, Δημήτρης Βήχος  wrote:
> 
> i have setup for loopdata
> 
> [LoopData]
> [[FileSpec]]
> loop_data_dir = .
> filename = loop-data.txt
> [[Formatting]]
> target_report = LoopDataReport
> [[LoopFrequency]]
> seconds = 30
> [[RsyncSpec]]
> enable = true
> remote_server = ftpupload.net
> remote_user = epiz_27298028
> remote_dir = /htdocs/test
> compress = true
> log_success = true
> ssh_options = -o ConnectTimeout=1
> timeout = 1
> skip_if_older_than = 3
> [[Include]]
> fields = trend.outTemp, trend.barometer.desc, current.barometer, 
> current.dateTime.raw, current.dewpoint, current.dewpoint.formatted, 
> current.heatindex, current.outHumidity, current.outTemp, 
> current.outTemp.formatted, current.rain, current.rainRate, 
> current.rainRate.formatted, current.windchill, 
> current.windDir.ordinal_compass, current.windSpeed, 
> current.windSpeed.formatted, current.windSpeed.raw, 
> 10m.outTemp.max.formatted, 10m.outTemp.min.formatted, 10m.rain.sum.formatted, 
> 10m.wind.rms.formatted, 10m.windGust.max, 10m.windGust.max.formatted, 
> day.outTemp.max.formatted, day.outTemp.min.formatted, day.rain.sum, 
> day.rain.sum.formatted, day.wind.rms.formatted, day.windGust.max, 
> day.windGust.max.formatted, week.outTemp.max.formatted, 
> week.outTemp.min.formatted, week.rain.sum.formatted, week.wind.rms.formatted, 
> week.windGust.max.formatted, month.outTemp.max.formatted, 
> month.outTemp.min.formatted, month.rain.sum.formatted, 
> month.wind.rms.formatted, month.windGust.max.formatted, 
> year.outTemp.max.formatted, year.outTemp.min.formatted, 
> year.rain.sum.formatted, year.wind.rms.formatted, 
> year.windGust.max.formatted, rainyear.outTemp.max.formatted, 
> rainyear.outTemp.min.formatted, rainyear.rain.sum.formatted, 
> rainyear.wind.rms.formatted, rainyear.windGust.max.formatted
> [[BarometerTrendDescriptions]]
> RISING_VERY_RAPIDLY = Rising Very Rapidly
> RISING_QUICKLY = Rising Quickly
> RISING = Rising
> RISING_SLOWLY = Rising Slowly
> STEADY = Steady
> FALLING_SLOWLY = Falling Slowly
> FALLING = Falling
> FALLING_QUICKLY = Falling Quickly
> FALLING_VERY_RAPIDLY = Falling Very Rapidly
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 9:12:55 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> As the README states:
>> If you need the loop-data.txt file pushed to a remote webserver, you will 
>> also need to fill in the RsyncSpec fields; but one can fill that in later, 
>> after LoopData is up and running.
>> 
>> It appears loopdata is up and running and working on the local machine.  
>> Have you set up rsync for loopdata?
>> 
>> Please see the following sections of the README:
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#entries-in-loopdata-sections-of-weewxconf
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#rsync-isnt-working-for-me-help
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#do-i-have-to-use-rsync-to-sync-loop-datatxt-to-a-remote-server
>> 
>> https://github.com/chaunceygardiner/weewx-loopdata#what-about-those-rsync-errors-in-the-log
>> 
 On Jan 26, 2021, at 10:34 AM, Δημήτρης Βήχος  wrote:
 
>>> its correct i have remote server. in remote server uploading the 
>>> loop-data.txt but uploadind every 5 minutes . 
>> 
>>> 
>>> 
>>> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 6:20:42 μ.μ. UTC+2, ο χρήστης 
>>> jo...@johnkline.com έγραψε:
 OK, the behavior we are seeing leads me to believe your web server is on a 
 remote machine; i.e., not on the same machine as weewx.  Is that correct?  
 If so, you’ll need to use rsync by filling out and enabling it under:
 
 [LoopData]
 [[RsyncSpec]]
 
 
>> On Jan 26, 2021, at 7:57 AM, Δημήτρης Βήχος  wrote:
>> 
> well the actuall  /loopdata   localhost/weewx/loopdata  , refreshing 
> every 60 seconds its ok. but in weather page  refreshing every 5 minutes
> 
> Στις Τρίτη, 26 Ιανουαρίου 2021 στις 5:45:32 μ.μ. UTC+2, ο χρήστης 
> jo...@johnkline.com έγραψε:
>> Again, how often does your driver write loop records?
>> 
>> loop-data.txt is not written in reporting cycles.  I am asking you to 
>> look at the actual loop-data.txt file that is written to the 
>> .../loopdata directory.  How often does the contents of that file change.
>> 
>> Also, please show what entries you are seeing in the log every one 
>> minute.
>> 
 On Jan 26, 2021, at 7:37 AM, Δημήτρης Βήχος  
 wrote:
 
>>

Re: [weewx-user] Re: Database vs MQTT published data

2021-01-26 Thread Zsolt Máté

Since 04:30AM the data stream is continuous again, see attachment. For the 
record, the dropouts were 30 minutes long, followed by a 30 minutes good 
data logs.
The mysql server is running on the same raspberry pi as weewx. I think this 
rules out the possibility of having an unreliable network link.
I've restarted weewex after setting the debug flag to 1. I'll keep an eye 
on the server and check the log when it happens again.

/var/log/mysql/error.log is empty

[image: 2021-01-27 10_29_04 chrome_Wf7wVUdOQL.png]
On Wednesday, January 27, 2021 at 12:35:03 AM UTC+13 tke...@gmail.com wrote:

> Hard to say without seeing the log. Is the MySQL server located on an 
> unreliable network link? Unfortunately, WeeWX cannot recover from a MySQL 
> write error (see issue #259 ).
>
> Take a look in your system log for any WeeWX errors, and in the MySQL log 
> for any database errors.
>
> On Mon, Jan 25, 2021 at 5:45 PM Zsolt Máté  wrote:
>
>> I am missing the data in mysql.
>> See the two attachments. The last hour in phpmysql vs grafana.
>> There are just 7 records in the last hour, but AFAIK my interceptor gets 
>> data every ~16 seconds - see the graph drawn by grafana using influxdb data.
>> [image: 2021-01-26 14_36_41 chrome_daC10v9WCb.png]
>> [image: 2021-01-26 14_37_31 chrome_YnEe2grkwc.png]
>>
>> On Tuesday, January 26, 2021 at 2:08:22 PM UTC+13 vince wrote:
>>
>>> Are you sure you're not just seeing gaps in the 'graphs' of the data ?
>>>
>>> See if you're really missing intervals in the db by querying your db 
>>> directly.
>>>
>>> -- 
>> 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/fd9dab82-7f31-450e-9f0c-44e1d136e6a4n%40googlegroups.com
>>  
>> 
>> .
>>
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/08529f65-a866-430f-b05d-a8cda42de4e9n%40googlegroups.com.

[weewx-user] How to change weewx service from python2 to python3 on Debian

2021-01-26 Thread Gordon Dickens

How do I make weewx use python3 instead of python2?  I initially installed 
weewx on Debian using the Debian package over a year ago and it was 
originally setup to use python2. I recently upgraded to weewx 4.3.0 with 
the Belchertown skin version 1.2 and so I want to also upgrade to python3. 
  The normal way to change default packages in Debian is with the 
update-alternatives command, however, when I set python3 as the default, 
weewx continues to use python2 as seen from the command, "ps aux | grep 
weewx" whose output contains:

python2 /usr/share/weewx/weewxd --daemon --pidfile=/var/run/weewx.pid 
/etc/weewx/weewx.conf

So, the service is started with python2.  How do I change the weewx service 
to use python3?

Thanks,

Gordon

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/807bfd14-5724-4116-b369-c7d2d49f15b9n%40googlegroups.com.

Re: [weewx-user] How to change weewx service from python2 to python3 on Debian

Easiest is to just follow the install directions in the Debian guide
:




*wget -qO - https://weewx.com/apt/weewx-python3.list
 | sudo tee
/etc/apt/sources.list.d/weewx.listsudo apt-get updatesudo apt-get install
weewx*


On Tue, Jan 26, 2021 at 1:58 PM Gordon Dickens  wrote:

> How do I make weewx use python3 instead of python2?  I initially installed
> weewx on Debian using the Debian package over a year ago and it was
> originally setup to use python2. I recently upgraded to weewx 4.3.0 with
> the Belchertown skin version 1.2 and so I want to also upgrade to python3.
>   The normal way to change default packages in Debian is with the
> update-alternatives command, however, when I set python3 as the default,
> weewx continues to use python2 as seen from the command, "ps aux | grep
> weewx" whose output contains:
>
> python2 /usr/share/weewx/weewxd --daemon --pidfile=/var/run/weewx.pid
> /etc/weewx/weewx.conf
>
> So, the service is started with python2.  How do I change the weewx
> service to use python3?
>
> Thanks,
>
> Gordon
>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/807bfd14-5724-4116-b369-c7d2d49f15b9n%40googlegroups.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEA76i1OPAqpLZqC4AYf%2BxLY%3DTiu2FB%3DgD51Fc635PpHuQ%40mail.gmail.com.

[weewx-user] interceptor + WH2900C (ecowitt comptible)

I finally got interceptor working with the Seasons template on both Ubuntu
python 3.8 and FreeBSD (freenas jail) python 3.7
Enclosed is the interceptor.py consolidating the fixes posted in;
- #82 do_GET(self): change
- #80 def do_POST(self)

plus a change from myself to map the baromrelin' : 'altimeter' fields

--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/weewx-user/040f846e-6fc0-4d0e-aee8-de8cbe31cae0n%40googlegroups.com.
#!/usr/bin/env python
# Copyright 2016-2020 Matthew Wall
# Distributed under the terms of the GNU Public License (GPLv3)

"""
This driver runs a simple web server or sniffs network traffic in order to
capture data directly from an internet weather reporting device including:

- Acurite Internet Bridge (also known as the SmartHub) (acurite protocol)
- Acurite Access (wu protocol)
- Oregon Scientific LW301/302 (OS protocol)
- Fine Offset HP1000/WH2600
- Fine Offset GW1000 (ecowitt protocol or wu protocol)
- Fine Offset wifi consoles (including Ambient)
- LaCrosse GW1000U (LaCrosse protocol)

When this driver was first written (early 2016), there were many different
firmware versions using different variations of the weather underground
protocol. The WU protocol has stabilized, and other protocols similar to it
have been developed (e.g., ambient, ecowitt) to provide functionality not
available in the WU protocol.

See the readme file for configuration examples. The sections below include
details about and quirks of various supported hardware models.

Thanks to rich of modern toil and george nincehelser for acurite parsing
http://moderntoil.com/?p=794
http://nincehelser.com/ipwx/

Thanks to Pat at obrienlabs.net for the fine offset parsing
http://obrienlabs.net/redirecting-weather-station-data-from-observerip/

Thanks to sergei and waebi for the LW301/LW302 samples
http://www.silent-gardens.com/blog/shark-hunt-lw301/

Thanks to Sam Roza for packet captures from the LW301

Thanks to skydvrz, keckec, mycal, kennkong for publishing their lacrosse work
http://www.wxforum.net/index.php?topic=14299.0
https://github.com/lowerpower/LaCrosse
https://github.com/kennkong/Weather-ERF-Gateway-1000U

Thanks to Jerome Helbert for the pypcap option.

===
SniffServer vs TCPServer

The driver can obtain packets by sniffing network traffic using pcap, or by
listening for TCP/IP requests. The pcap approach requires the python pypcap
module, which in turn requires libpcap. This means a separate installation
on most platforms.

https://github.com/pynetwork/pypcap

To run a listener, specify an address and port. This is the default mode.
For example:

[Interceptor]
mode = listen
address = localhost
port =

To run a sniffer, specify an interface and filter. For example:

[Interceptor]
mode = sniff
iface = eth0
pcap_filter = src host 192.168.1.5 && dst port 80

The following sections provide some details about each type of hardware.

===
WUClient

This is not a specific type of hardware, but rather *any* hardware that
communicates data using the weather underground protocol. The protocol is
defined here:

https://feedback.weather.com/customer/en/portal/articles/2924682-pws-upload-protocol?b_id=17298

Since that protocol has changed over the years, a PDF version of the protocol
as of 03jun2019 is incuded in this distribution in the doc directory.

===
Acurite Bridge

The Acurite bridge communicates with Acurite 5-in-1, 3-in-1, temperature, and
temperature/humidity sensors. It receives signals from any number of sensors,
even though Acurite's web interface is limited to 3 devices (or 10 as of the
July 2016 firmware update).

By default, the bridge transmits data to www.acu-link.com. Acurite requires
registration of the bridge's MAC address in order to use acu-link.com.
However, the bridge will function even if it is not registered, as long as it
receives the proper response.

The bridge sends data as soon as it receives an observation from the sensors.

Chaney did a firmware update to the bridge in July 2016. This update made the
bridge emit data using the weather underground protocol instead of the
Chaney protocol.

The old firmware (acurite bridge) sends to aculink.com in a proprietary 'chaney
format'. The new firmware (smarthub) sends to hubapi.acurite.com as well as to
rtupdate.wunderground.com. The format for hubapi is similar to the rtupdate
format used at weather underground. The user interface of the aculink service
has been shut down, and it has been replaced

Re: [weewx-user] How to change weewx service from python2 to python3 on Debian

2021-01-26 Thread Colin Larsen

I remember I had to change /etc/default/weewx it to tell Weewx to start
with Python3

WEEWX_PYTHON=python2<== change to python3

WEEWX_BINDIR=/usr/share/weewx

WEEWX_BIN=/usr/bin/weewxd

WEEWX_CFG=/etc/weewx/weewx.conf

Colin

On Wed, 27 Jan 2021 at 11:04, Tom Keffer  wrote:

> Easiest is to just follow the install directions in the Debian guide
> :
>
>
>
>
> *wget -qO - https://weewx.com/apt/weewx-python3.list
>  | sudo tee
> /etc/apt/sources.list.d/weewx.listsudo apt-get updatesudo apt-get install
> weewx*
>
>
> On Tue, Jan 26, 2021 at 1:58 PM Gordon Dickens 
> wrote:
>
>> How do I make weewx use python3 instead of python2?  I initially
>> installed weewx on Debian using the Debian package over a year ago and it
>> was originally setup to use python2. I recently upgraded to weewx 4.3.0
>> with the Belchertown skin version 1.2 and so I want to also upgrade to
>> python3.   The normal way to change default packages in Debian is with the
>> update-alternatives command, however, when I set python3 as the default,
>> weewx continues to use python2 as seen from the command, "ps aux | grep
>> weewx" whose output contains:
>>
>> python2 /usr/share/weewx/weewxd --daemon --pidfile=/var/run/weewx.pid
>> /etc/weewx/weewx.conf
>>
>> So, the service is started with python2.  How do I change the weewx
>> service to use python3?
>>
>> Thanks,
>>
>> Gordon
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/807bfd14-5724-4116-b369-c7d2d49f15b9n%40googlegroups.com
>> 
>> .
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/CAPq0zEA76i1OPAqpLZqC4AYf%2BxLY%3DTiu2FB%3DgD51Fc635PpHuQ%40mail.gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CACjxfUv6LcGyjQWjPKfD6hPfyLJj8NuHeBBfxMx2_nPdrauw_A%40mail.gmail.com.

Re: [weewx-user] How to change weewx service from python2 to python3 on Debian

Yes, that will work, but it also assumes that all the prerequisites have
been installed. The Python 3 prereqs are different from Python 2.

On Tue, Jan 26, 2021 at 2:12 PM Colin Larsen  wrote:

> I remember I had to change /etc/default/weewx it to tell Weewx to start
> with Python3
>
> WEEWX_PYTHON=python2<== change to python3
>
> WEEWX_BINDIR=/usr/share/weewx
>
> WEEWX_BIN=/usr/bin/weewxd
>
> WEEWX_CFG=/etc/weewx/weewx.conf
>
> Colin
>
> On Wed, 27 Jan 2021 at 11:04, Tom Keffer  wrote:
>
>> Easiest is to just follow the install directions in the Debian guide
>> :
>>
>>
>>
>>
>> *wget -qO - https://weewx.com/apt/weewx-python3.list
>>  | sudo tee
>> /etc/apt/sources.list.d/weewx.listsudo apt-get updatesudo apt-get install
>> weewx*
>>
>>
>> On Tue, Jan 26, 2021 at 1:58 PM Gordon Dickens 
>> wrote:
>>
>>> How do I make weewx use python3 instead of python2?  I initially
>>> installed weewx on Debian using the Debian package over a year ago and it
>>> was originally setup to use python2. I recently upgraded to weewx 4.3.0
>>> with the Belchertown skin version 1.2 and so I want to also upgrade to
>>> python3.   The normal way to change default packages in Debian is with the
>>> update-alternatives command, however, when I set python3 as the default,
>>> weewx continues to use python2 as seen from the command, "ps aux | grep
>>> weewx" whose output contains:
>>>
>>> python2 /usr/share/weewx/weewxd --daemon --pidfile=/var/run/weewx.pid
>>> /etc/weewx/weewx.conf
>>>
>>> So, the service is started with python2.  How do I change the weewx
>>> service to use python3?
>>>
>>> Thanks,
>>>
>>> Gordon
>>>
>>> --
>>> 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+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/weewx-user/807bfd14-5724-4116-b369-c7d2d49f15b9n%40googlegroups.com
>>> 
>>> .
>>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/weewx-user/CAPq0zEA76i1OPAqpLZqC4AYf%2BxLY%3DTiu2FB%3DgD51Fc635PpHuQ%40mail.gmail.com
>> 
>> .
>>
> --
> 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+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/weewx-user/CACjxfUv6LcGyjQWjPKfD6hPfyLJj8NuHeBBfxMx2_nPdrauw_A%40mail.gmail.com
> 
> .
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/CAPq0zEC99a8DBc49jBKOeSeHD38UaOF8GZWNRDS-Ozt0ga%3DbuQ%40mail.gmail.com.

Re: [weewx-user] Re: Database vs MQTT published data

2021-01-26 Thread vince

On Tuesday, January 26, 2021 at 1:38:20 PM UTC-8 lop...@gmail.com wrote:

> Since 04:30AM the data stream is continuous again, see attachment. For the 
> record, the dropouts were 30 minutes long, followed by a 30 minutes good 
> data logs.
> The mysql server is running on the same raspberry pi as weewx. I think 
> this rules out the possibility of having an unreliable network link.

Can you provide more info on your exact setup ?

You have weewx and mysqld and influxdb and the interceptor driver all on 
the same raspi ?
What model pi ?   How much memory ?
What wifi band are you on (2.4 or 5 GHz) ?

I used to run a reasonably complicated pi3 or pi3+ setup with weewx, 
influxdb and MQTT and had lots of periodic issues with data loss. 
 Switching the pi to wired ethernet helped a lot.   Moving influxdb from 
the pi to a nice fast  i3 NUC with SSD that was also wired ethernet made 
the issue go away completely.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/51b19cf4-9bca-444c-9418-941615db303en%40googlegroups.com.

Re: [weewx-user] Re: MQTT Connection Refused

2021-01-26 Thread Greg Troxel


Jeff Beckman  writes:

> I feel like I might not get much sleep this week, this is driving me nuts.  
> I installed linux on a VM on my desktop (the one that has working MQTT 
> Explorer) and it worked.  The default (oracle virtualbox) was to just 
> attach to my NAT, so it got an IP of 10.0.2.15 (which my desktop passes 
> through to 192.168.1.185?).  Changing it to a bridge adapter, it picked up 
> a DHCP address of 192.168.1.218, and then it did not work.

Unless you really know what you are doing, it seems unlikely that having
10.0.2.15 and 192.168.1.85 on the same LAN is sensible.  Generally each
Ethernet, real or virtual, should have one prefix and at most one DHCP
server.   Once there is address confusion, i suspect routing confusion.

My advice is to first completely straighten out your home LANs
addressing plan.


> Here's my full setup:  Router is a stand-alone box running pfsense.  I have 
> a server that runs freebsd doing virtualization (static, 192.168.1.30).  
> Home Assistant is a VM (static, 192.168.1.35).  Weewx is a raspberry pi 2 
> (static, 192.168.1.17).  Desktop windows machine (DHCP, 192.168.1.185).
>
> I have another unrelated VM running on that free bsd machine for a 
> minecraft server (static, 192.168.1.36).  Remoting in there gives the same 
> problems trying to publish a message.  This machine's network setup is 
> almost identical to the Home Assistant machine and it is able to accept 
> connections on its minecraft port, 1935 or something.  

So where is 10/8?  That's a bug, IMHO, and perhaps related, perhaps not.

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/rmi5z3j9sjx.fsf%40s1.lexort.com.


signature.asc
Description: PGP signature

Re: [weewx-user] Re: MQTT Connection Refused

2021-01-26 Thread vince

10.0.2.15 is the default host-only address you get in VirtualBox with the 
default NAT out to your LAN.   You likely need to expose port 1883 on the 
outside (192.168.1.x side) so that something can answer the phone, so to 
speak. 

It would be helpful if you'd draw us a network picture with which 
systems+VMs are where and what ip addresses are on which interface.

One howto for VirtualBox is 
at 
https://www.howtogeek.com/122641/how-to-forward-ports-to-a-virtual-machine-and-use-it-as-a-server/
 
- ignore the bridged example and check out how to do the port forwarding in 
the NAT'd example.   I'm guessing there's a way to do the same thing 
without a gui on the VM but I never do native VirtualBox any more, I always 
use Vagrant as a front end and then it's trivial to expose ports through 
the underlying NAT'd VM.   One example for ubuntu is 
at https://github.com/vinceskahan/weewx-vagrant/tree/master/pkg/ubuntu2004 
if you wanted to see the Vagrantfile there.   The provision.sh script will 
install a Simulator weewx and nginx and expose the web on port 8105.

Short answer is that if you use a default VirtualBox setup then you'll be 
NAT'ing and you'll need to do port forwarding in VirtualBox so that port 
1883 on your host (incoming) gets to port 1883 in the running VM on that 
host.

I would recommend not doing a bridged VM for security reasons.  Just expose 
a port and it'll work.  Really.

On Tuesday, January 26, 2021 at 3:39:35 PM UTC-8 Greg Troxel wrote:

>
> Jeff Beckman  writes:
>
> > I feel like I might not get much sleep this week, this is driving me 
> nuts. 
> > I installed linux on a VM on my desktop (the one that has working MQTT 
> > Explorer) and it worked. The default (oracle virtualbox) was to just 
> > attach to my NAT, so it got an IP of 10.0.2.15 (which my desktop passes 
> > through to 192.168.1.185?). Changing it to a bridge adapter, it picked 
> up 
> > a DHCP address of 192.168.1.218, and then it did not work.
>
> Unless you really know what you are doing, it seems unlikely that having
> 10.0.2.15 and 192.168.1.85 on the same LAN is sensible. Generally each
> Ethernet, real or virtual, should have one prefix and at most one DHCP
> server. Once there is address confusion, i suspect routing confusion.
>
> My advice is to first completely straighten out your home LANs
> addressing plan.
>
>
> > Here's my full setup: Router is a stand-alone box running pfsense. I 
> have 
> > a server that runs freebsd doing virtualization (static, 192.168.1.30). 
> > Home Assistant is a VM (static, 192.168.1.35). Weewx is a raspberry pi 2 
> > (static, 192.168.1.17). Desktop windows machine (DHCP, 192.168.1.185).
> >
> > I have another unrelated VM running on that free bsd machine for a 
> > minecraft server (static, 192.168.1.36). Remoting in there gives the 
> same 
> > problems trying to publish a message. This machine's network setup is 
> > almost identical to the Home Assistant machine and it is able to accept 
> > connections on its minecraft port, 1935 or something. 
>
> So where is 10/8? That's a bug, IMHO, and perhaps related, perhaps not.
>

-- 
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/weewx-user/80cecfd3-1b76-4814-8a7f-186a001e9a4dn%40googlegroups.com.

[weewx-user] belchertown skin - errors with not out door sensors