[weewx-user] Re: Forecast Extension and Python 3
I thought I had the latest version of the Forecast extension but I only had the latest version from the project branch with a link in the weewx Forecast extension WIKI article. Had forgotten about the other branch. Thanks for pointing me to the a post with a link to the correct branch. On Sunday, June 14, 2020 at 7:41:50 PM UTC-7, Tony Deets wrote: > > I recently move weewx form a Pi 3 running Stretch with weewx using Python > 2.7 to a Pi 4 running Buster using Python 3.whatever. The new Pi 4 weewx > setup is almost exact copy of Pi 3 setup. The one difference is that when > the Forecast extension installed and enabled I get the following syslog > error: > > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: Caught > unrecoverable exception: > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: '>' > not supported between instances of 'float' and 'NoneType' > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > Traceback (most recent call last): > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 195, in run > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > self.dispatchEvent(weewx.Event(weewx.CHECK_LOOP, packet=packet)) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > callback(event) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 578, in check_loop > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > raise BreakLoop > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > weewx.engine.BreakLoop > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > During handling of the above exception, another exception occurred: > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > Traceback (most recent call last): > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewxd", line 154, in main > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > engine.run() > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 202, in run > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > self.dispatchEvent(weewx.Event(weewx.POST_LOOP)) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > callback(event) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 594, in post_loop > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > self._catchup(self.engine.console.genArchiveRecords) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 643, in _catchup > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > origin='hardware')) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/weewx/engine.py", line 224, in dispatchEvent > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > callback(event) > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > File "/usr/share/weewx/user/forecast.py", line 1212, in update_forecast > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > elif time.time() - self.interval > self.last_ts: > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > TypeError: '>' not supported between instances of 'float' and 'NoneType' > Jun 14 07:55:18 raspberrypi weewx[11874] CRITICAL __main__: > Exiting. > > When the Forecast extension is uninstalled the problem disappears and > weewx executes without issue. > > I suspect that there might be a compatibility problem between the Forecast > extension and Python 3.7 but have no direct evidence that that is the case. > I am curious to know if any other users of the above are having this issue > and is their a known workaround for this problem? If not, I guess it will > require taking a look at the source and seeing how badly I can muck things > up... > -- 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
[weewx-user] Re: MySQL DB issue, connection was killed error, which casues weewx to stop
Looks like this was already solved, just needed to update my code. All set.
Thanks for listening. :)
https://github.com/weewx/weewx/commit/d1b15032f743c4f35205a2b273731ae49b318db9
On Sunday, June 14, 2020 at 8:19:51 PM UTC-4, bdf0506 wrote:
>
> Hello all. I ran into an issue where MySQL was shut down, and as a result
> it kills the connection to weewx. But weewx doesn't seem to have logic to
> understand when the database comes back. It seems we could implement a
> sleep and retry.
>
> This is similar to this thread from 2018 that I reported:
> https://groups.google.com/forum/#!msg/weewx-user/GN5lCvsQ-sU/2Ukh8ftfCAAJ
>
> It looks like there is no reference to reason code 1927 as I see in my
> logs.
> https://github.com/weewx/weewx/blob/development/bin/weedb/NOTES.md
>
> Log file:
>
> Jun 14 20:00:19 weewx weewx[1294]: manager: Added record 2020-06-14 20:00:
> 00 EDT (1592179200) to database 'weewx'
> Jun 14 20:00:19 weewx weewx[1294]: manager: Added record 2020-06-14 20:00:
> 00 EDT (1592179200) to daily summary in 'weewx'
> Jun 14 20:00:19 weewx weewx[1294]: restx: Wunderground-PWS: Published
> record 2020-06-14 20:00:00 EDT (1592179200)
> Jun 14 20:00:20 weewx weewx[1294]: cheetahgenerator: Generated 5 files for
> report StandardReport in 1.28 seconds
> Jun 14 20:00:20 weewx weewx[1294]: copygenerator: copied 0 files to /opt/
> weewx/public_html
> Jun 14 20:02:50 weewx weewx[1294]: restx: Influx: Unexpected exception of
> type
> Jun 14 20:02:50 weewx weewx[1294]: restx: MQTT: Unexpected exception of
> type
> Jun 14 20:02:51 weewx weewx[1294]: restx: Influx: Thread exiting. Reason:
> (1927, 'Connection was killed')
> Jun 14 20:02:51 weewx weewx[1294]: restx: MQTT: Thread exiting. Reason: (
> 1927, 'Connection was killed')
> Jun 14 20:05:23 weewx weewx[1294]: engine: Shutting down StdReport thread
> Jun 14 20:05:23 weewx weewx[1294]: sdr: MainThread: shutdown process
> rtl_433 -q -U -F json -R40
> Jun 14 20:05:36 weewx weewx[1294]: sdr: MainThread: timed out waiting for
> stderr-thread
> Jun 14 20:05:36 weewx weewx[1294]: engine: Caught unrecoverable exception
> in engine:
> Jun 14 20:05:36 weewx weewx[1294]: (1927, 'Connection was killed')
> Jun 14 20:05:36 weewx weewx[1294]: Traceback (most recent call last):
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/engine.py", line 871, in main
> Jun 14 20:05:36 weewx weewx[1294]: engine.run()
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/engine.py", line 201, in run
> Jun 14 20:05:36 weewx weewx[1294]: self.dispatchEvent(weewx.Event(
> weewx.POST_LOOP))
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/engine.py", line 223, in dispatchEvent
> Jun 14 20:05:36 weewx weewx[1294]: callback(event)
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/engine.py", line 567, in post_loop
> Jun 14 20:05:36 weewx weewx[1294]: self._catchup(self.engine.console.
> genArchiveRecords)
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/engine.py", line 614, in _catchup
> Jun 14 20:05:36 weewx weewx[1294]: lastgood_ts = dbmanager.
> lastGoodStamp()
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/manager.py", line 206, in lastGoodStamp
> Jun 14 20:05:36 weewx weewx[1294]: _row = self.getSql("SELECT
> MAX(dateTime) FROM %s" % self.table_name)
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weewx/manager.py", line 394, in getSql
> Jun 14 20:05:36 weewx weewx[1294]: _cursor.execute(sql, sqlargs)
> Jun 14 20:05:36 weewx weewx[1294]: File
> "/opt/weewx/bin/weedb/mysql.py", line 49, in guarded_fn
> Jun 14 20:05:36 weewx weewx[1294]: raise klass(e)
> Jun 14 20:05:36 weewx weewx[1294]: DatabaseError: (1927, 'Connection
> was killed')
> Jun 14 20:05:36 weewx weewx[1294]: Exiting.
>
> Anything we can do to help remediate this situation?
>
>
--
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/a11f7aca-221b-471c-a496-d5b01923b691o%40googlegroups.com.
[weewx-user] Re: WS6in1 driver 0.3
I have released 0.7 of the WS6in1 driver The main change is to cope with bad data when reading the data buffer when weewx starts. This is fairly rare but has been an issue for Remy. Release 0.6 tried to replace bad data with nulls, but unfortunately missing data meant data was being associated with the wrong parameters. Instead 0.7 discards the complete data entry for that time if any bad data is detected. Discovery of pyflakes and pylint has hopefully further tidied the code, sorted a few issues, and hopefully not broken anything. Also I have written a standalone python3 program csv_ws6in1 which dumps the content of the weather station buffer into a csv file for spreadsheet analysis. See the readme.txt Have fun Bob -- 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/89d884b7-87ab-434c-bcb1-ef405bcaf24co%40googlegroups.com.
Re: [weewx-user] Rsync issue
Awesome, thanks so much for being so patient and providing crystal clear instrustions. I believe I was 99% there, but had not reset the permissions on roots ssh folder. In the meantime I have found that following the instructions for systemd to https://github.com/weewx/weewx/wiki/systemd with a bit of additional permsission changing got me running weewx as a non root user, then the next part of creating the ssh keys and ssh-copy-id etc was very easy and it just worked. I have been doing this on a test virtual machine to make sure all is good before I touch the live system. Thanks again! Oz On Sunday, 14 June 2020 19:59:37 UTC+2, mwall wrote: > > On Sunday, June 14, 2020 at 12:18:28 PM UTC-4, Ossian wrote: >> >> I am having a similar issue. I keep seeing mention of the need or >> possibility to provide correct keys etc for root to use, but have not found >> anything concrete to go on. >> > > there are many ways to do this, for example, one approach is with > command-line arguments, while another approach is to use the ssh config > file. > > lets say that you connect to the server 'server.example.com' via rsync as > the user 'weewx' using the credentials in these files: > > /home/pi/.ssh/id_rsa_weewx > /home/pi/.ssh/id_rsa_weewx.pub > > lets say that you are running weewx as the the user 'root', whose home > directory is /root > > 1) ensure that root has an ssh directory > > sudo mkdir -p /root/.ssh > > 2) copy the credential files into root's ssh space > > sudo cp /home/pi/.ssh/id_rsa_weewx /root/.ssh > sudo cp /home/pi/.ssh/id_rsa_weewx.pub /root/.ssh > > 3) create the ssh configuration file /home/root/.ssh/config with these > contents: > > Host server.example.com > User weewx # this is the username used to connect to the server > IdentityFile /home/root/.ssh/id_rsa_weewx # credentials used to > connect to the server > > 4) finally, ensure that permissions are correct: > > sudo chown root.root /home/root/.ssh > sudo chmod 700 /home/root/.ssh > sudo chmod 600 /home/root/.ssh/config > sudo chmod 600 /home/root/.ssh/id_rsa* > > now when the user 'root' attempts a connection to server.example.com, it > will use the correct credentials, no matter how ssh, scp, or rsync is > invoked > > if you run weewx as some other, user say 'pi' or 'weewx', then put the > files into that user's .ssh directory instead of root's .ssh directory. > > m > -- 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/b9596ca1-8b6c-4c1c-84f8-3284993b6974o%40googlegroups.com.
Re: [weewx-user] Belchertown MQTT
That did it.
Thank you, Thank you, Thank you.
> On Jun 15, 2020, at 12:43 PM, Garry A Lockyer wrote:
>
> Try setting websockets topic to frogs/loop.
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686
> H: +1.250.495.5343
> E: Garry.Lockyer.ca
>
>> On Jun 15, 2020, at 09:39, Ken Walker wrote:
>>
>> OK, now I get it. Thanks Garry and Pat.
>>
>> Almost there.
>>
>> I have added the MQTT extension and can verify that data is being published
>> to my mqtt broker by using the command line to subscribe to the topic.
>>
>> The web page now says “Connected. Waiting for data….” , but does appear to
>> update. I have the following in the skin.conf:
>> # MQTT Websockets defaults
>> mqtt_websockets_enabled = 1
>> mqtt_websockets_host = "10.0.1.32"
>> mqtt_websockets_port = 9001
>> mqtt_websockets_ssl = 0
>> mqtt_websockets_topic = "frogs"
>> disconnect_live_website_visitor = 180
>>
>> mqtt_websocets_topic is same as the [[MQTT]] topic in weewx.conf. BTW, I’m
>> just using the “frogs” topic as a test
>>
>> Here is a sample message being posted to “frogs”:
>> {"usUnits": "1.0", "dateTime": "1592238928.0", "rainRate_inch_per_hour":
>> "0.0", "hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in": "0.0",
>> "extraTemp1_F": "89.4", "barometer_inHg": "29.9"}
>>
>> This must be being posted to a subtopic. I can only see these messages with:
>>mosquitto_sub -h 10.0.1.32 -t frogs/#
>>
>>
>>> On Jun 15, 2020, at 9:47 AM, Pat >> > wrote:
>>>
>>> Belchertown expects the weather data to be in the same format as the weewx
>>> mqtt extension. If you're not publishing from the weewx mqtt extension,
>>> then you'll need to have your publisher emulate that extension's output.
>>> (rough example below, not all observations need to be in the same packet)
>>>
>>> Your mqtt broker needs to have websockets enabled as well. Then you'll set
>>> your skin to connect to the websocket port to get the data.
>>>
>>> MQTT: {"dateTime": "1592228732.0", "usUnits": "1.0", "outTemp_F":
>>> "65.9","rain_in": "0.0", "rainRate_inch_per_hour": "0.0",
>>> "barometer_inHg":"30.514", "radiation_Wpm2": "691.0", "inTemp_F": "75.5",
>>> "inHumidity":"36.0", "outHumidity": "53.0", "windSpeed_mph": "5.0",
>>> "windGust_mph":"5.0", "UV": "4.1", "forecastRule": "9.0",
>>> "txBatteryStatus": "0.0","consBatteryVoltage_volt": "4.71", "windDir":
>>> "11.0", "windGustDir": "11.0","pressure_inHg": "30.05007732814778",
>>> "altimeter_inHg":"30.522342546117084", "windchill_F": "65.9",
>>> "heatindex_F": "65.9","dewpoint_F": "48.27895673606349", "inDewpoint_F":
>>> "46.66006121573143","appTemp_F": "62.71298653227457", "maxSolarRad_Wpm2":
>>> "725.56944104572","cloudbase_foot": "4434.782559985571", "humidex_F":
>>> "67.42878362134785","hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in":
>>> "0.0","windSpeed10_mph": "2.0", "stormRain_in": "0.0", "monthRain_in":
>>> "1.07","yearRain_in": "14.82", "dayET": "0.023", "monthET": "2.04",
>>> "yearET":"14.19", "leafWet4": "0.0", "insideAlarm": "0.0", "rainAlarm":
>>> "0.0","outsideAlarm1": "0.0", "outsideAlarm2": "0.0", "extraAlarm1":
>>> "0.0","extraAlarm2": "0.0", "extraAlarm3": "0.0", "extraAlarm4":
>>> "0.0","extraAlarm5": "0.0", "extraAlarm6": "0.0", "extraAlarm7":
>>> "0.0","extraAlarm8": "0.0", "soilLeafAlarm1": "0.0", "soilLeafAlarm2":
>>> "0.0","soilLeafAlarm3": "0.0", "soilLeafAlarm4": "0.0", "forecastIcon":
>>> "6.0","sunrise": "1592212752.0", "sunset": "1592268288.0"}
>>>
>>>
>>>
>>> On Sunday, June 14, 2020 at 11:39:15 PM UTC-4, Garry A Lockyer wrote:
>>> Seems to me you have to publish MQTT data (under [StdRESTful][[MQTT]] so
>>> that you can later retrieve the data in
>>> [StdReport][[Belchertown]][[[Extras]]]. I suppose it’s possible to have
>>> one instance of weewx publish data and another instance subscribe to it,
>>> but there has to be at least one publisher somewhere.
>>>
>>> I can’t explain the “lost connection “ message. If I turn off MQTT
>>> publishing, I get a “Failed connecting...” message after a minute or so.
>>>
>>> Regards,
>>>
>>> Garry Lockyer
>>> C: +1.250.689.0686
>>>
>>>
On Jun 14, 2020, at 19:40, Ken Walker gmail.com
Re: [weewx-user] Belchertown MQTT
Try setting websockets topic to frogs/loop.
Regards,
Garry Lockyer
C: +1.250.689.0686
H: +1.250.495.5343
E: Garry.Lockyer.ca
>> On Jun 15, 2020, at 09:39, Ken Walker wrote:
> OK, now I get it. Thanks Garry and Pat.
>
> Almost there.
>
> I have added the MQTT extension and can verify that data is being published
> to my mqtt broker by using the command line to subscribe to the topic.
>
> The web page now says “Connected. Waiting for data….” , but does appear to
> update. I have the following in the skin.conf:
> # MQTT Websockets defaults
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "10.0.1.32"
> mqtt_websockets_port = 9001
> mqtt_websockets_ssl = 0
> mqtt_websockets_topic = "frogs"
> disconnect_live_website_visitor = 180
>
> mqtt_websocets_topic is same as the [[MQTT]] topic in weewx.conf. BTW, I’m
> just using the “frogs” topic as a test
>
> Here is a sample message being posted to “frogs”:
> {"usUnits": "1.0", "dateTime": "1592238928.0", "rainRate_inch_per_hour":
> "0.0", "hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in": "0.0",
> "extraTemp1_F": "89.4", "barometer_inHg": "29.9"}
>
> This must be being posted to a subtopic. I can only see these messages with:
>mosquitto_sub -h 10.0.1.32 -t frogs/#
>
>
>> On Jun 15, 2020, at 9:47 AM, Pat wrote:
>>
>> Belchertown expects the weather data to be in the same format as the weewx
>> mqtt extension. If you're not publishing from the weewx mqtt extension, then
>> you'll need to have your publisher emulate that extension's output. (rough
>> example below, not all observations need to be in the same packet)
>>
>> Your mqtt broker needs to have websockets enabled as well. Then you'll set
>> your skin to connect to the websocket port to get the data.
>>
>> MQTT: {"dateTime": "1592228732.0", "usUnits": "1.0", "outTemp_F":
>> "65.9","rain_in": "0.0", "rainRate_inch_per_hour": "0.0",
>> "barometer_inHg":"30.514", "radiation_Wpm2": "691.0", "inTemp_F": "75.5",
>> "inHumidity":"36.0", "outHumidity": "53.0", "windSpeed_mph": "5.0",
>> "windGust_mph":"5.0", "UV": "4.1", "forecastRule": "9.0", "txBatteryStatus":
>> "0.0","consBatteryVoltage_volt": "4.71", "windDir": "11.0", "windGustDir":
>> "11.0","pressure_inHg": "30.05007732814778",
>> "altimeter_inHg":"30.522342546117084", "windchill_F": "65.9", "heatindex_F":
>> "65.9","dewpoint_F": "48.27895673606349", "inDewpoint_F":
>> "46.66006121573143","appTemp_F": "62.71298653227457", "maxSolarRad_Wpm2":
>> "725.56944104572","cloudbase_foot": "4434.782559985571", "humidex_F":
>> "67.42878362134785","hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in":
>> "0.0","windSpeed10_mph": "2.0", "stormRain_in": "0.0", "monthRain_in":
>> "1.07","yearRain_in": "14.82", "dayET": "0.023", "monthET": "2.04",
>> "yearET":"14.19", "leafWet4": "0.0", "insideAlarm": "0.0", "rainAlarm":
>> "0.0","outsideAlarm1": "0.0", "outsideAlarm2": "0.0", "extraAlarm1":
>> "0.0","extraAlarm2": "0.0", "extraAlarm3": "0.0", "extraAlarm4":
>> "0.0","extraAlarm5": "0.0", "extraAlarm6": "0.0", "extraAlarm7":
>> "0.0","extraAlarm8": "0.0", "soilLeafAlarm1": "0.0", "soilLeafAlarm2":
>> "0.0","soilLeafAlarm3": "0.0", "soilLeafAlarm4": "0.0", "forecastIcon":
>> "6.0","sunrise": "1592212752.0", "sunset": "1592268288.0"}
>>
>>
>>
>>> On Sunday, June 14, 2020 at 11:39:15 PM UTC-4, Garry A Lockyer wrote:
>>> Seems to me you have to publish MQTT data (under [StdRESTful][[MQTT]] so
>>> that you can later retrieve the data in
>>> [StdReport][[Belchertown]][[[Extras]]]. I suppose it’s possible to have
>>> one instance of weewx publish data and another instance subscribe to it,
>>> but there has to be at least one publisher somewhere.
>>>
>>> I can’t explain the “lost connection “ message. If I turn off MQTT
>>> publishing, I get a “Failed connecting...” message after a minute or so.
>>>
>>> Regards,
>>>
>>> Garry Lockyer
>>> C: +1.250.689.0686
>>>
>>>
> On Jun 14, 2020, at 19:40, Ken Walker wrote:
Thanks. I don’t want to publish since I’m already getting data from
MQTT. My subscribe settings are the same as yours(other than host and
topic obviously). But it does not work.
I’m perplexed :)
> On Jun 14, 2020, at 8:54 PM, garrya...@gmail.com wrote:
>
> Here’re the settings I’m currently using successfully:
>
> [[MQTT]]
> # This is to PUBLISH MQTT topics - username and password are
> required, on my system.
>
> server_url = mqtt://username:password@192.168.1.140:1883/
> topic = weather/OsoyoosLakeNorthEast
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
>
> # This is to SUBSCRIBE to MQTT topics - a username and
> password are not required – at least not on my system.
>
> mqtt_websockets_enabled = 1
> mqtt_websockets_host =
Re: [weewx-user] Belchertown MQTT
OK, now I get it. Thanks Garry and Pat.
Almost there.
I have added the MQTT extension and can verify that data is being published to
my mqtt broker by using the command line to subscribe to the topic.
The web page now says “Connected. Waiting for data….” , but does appear to
update. I have the following in the skin.conf:
# MQTT Websockets defaults
mqtt_websockets_enabled = 1
mqtt_websockets_host = "10.0.1.32"
mqtt_websockets_port = 9001
mqtt_websockets_ssl = 0
mqtt_websockets_topic = "frogs"
disconnect_live_website_visitor = 180
mqtt_websocets_topic is same as the [[MQTT]] topic in weewx.conf. BTW, I’m
just using the “frogs” topic as a test
Here is a sample message being posted to “frogs”:
{"usUnits": "1.0", "dateTime": "1592238928.0", "rainRate_inch_per_hour": "0.0",
"hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in": "0.0", "extraTemp1_F":
"89.4", "barometer_inHg": "29.9"}
This must be being posted to a subtopic. I can only see these messages with:
mosquitto_sub -h 10.0.1.32 -t frogs/#
> On Jun 15, 2020, at 9:47 AM, Pat wrote:
>
> Belchertown expects the weather data to be in the same format as the weewx
> mqtt extension. If you're not publishing from the weewx mqtt extension, then
> you'll need to have your publisher emulate that extension's output. (rough
> example below, not all observations need to be in the same packet)
>
> Your mqtt broker needs to have websockets enabled as well. Then you'll set
> your skin to connect to the websocket port to get the data.
>
> MQTT: {"dateTime": "1592228732.0", "usUnits": "1.0", "outTemp_F":
> "65.9","rain_in": "0.0", "rainRate_inch_per_hour": "0.0",
> "barometer_inHg":"30.514", "radiation_Wpm2": "691.0", "inTemp_F": "75.5",
> "inHumidity":"36.0", "outHumidity": "53.0", "windSpeed_mph": "5.0",
> "windGust_mph":"5.0", "UV": "4.1", "forecastRule": "9.0", "txBatteryStatus":
> "0.0","consBatteryVoltage_volt": "4.71", "windDir": "11.0", "windGustDir":
> "11.0","pressure_inHg": "30.05007732814778",
> "altimeter_inHg":"30.522342546117084", "windchill_F": "65.9", "heatindex_F":
> "65.9","dewpoint_F": "48.27895673606349", "inDewpoint_F":
> "46.66006121573143","appTemp_F": "62.71298653227457", "maxSolarRad_Wpm2":
> "725.56944104572","cloudbase_foot": "4434.782559985571", "humidex_F":
> "67.42878362134785","hourRain_in": "0.0", "rain24_in": "0.0", "dayRain_in":
> "0.0","windSpeed10_mph": "2.0", "stormRain_in": "0.0", "monthRain_in":
> "1.07","yearRain_in": "14.82", "dayET": "0.023", "monthET": "2.04",
> "yearET":"14.19", "leafWet4": "0.0", "insideAlarm": "0.0", "rainAlarm":
> "0.0","outsideAlarm1": "0.0", "outsideAlarm2": "0.0", "extraAlarm1":
> "0.0","extraAlarm2": "0.0", "extraAlarm3": "0.0", "extraAlarm4":
> "0.0","extraAlarm5": "0.0", "extraAlarm6": "0.0", "extraAlarm7":
> "0.0","extraAlarm8": "0.0", "soilLeafAlarm1": "0.0", "soilLeafAlarm2":
> "0.0","soilLeafAlarm3": "0.0", "soilLeafAlarm4": "0.0", "forecastIcon":
> "6.0","sunrise": "1592212752.0", "sunset": "1592268288.0"}
>
>
>
> On Sunday, June 14, 2020 at 11:39:15 PM UTC-4, Garry A Lockyer wrote:
> Seems to me you have to publish MQTT data (under [StdRESTful][[MQTT]] so that
> you can later retrieve the data in [StdReport][[Belchertown]][[[Extras]]]. I
> suppose it’s possible to have one instance of weewx publish data and another
> instance subscribe to it, but there has to be at least one publisher
> somewhere.
>
> I can’t explain the “lost connection “ message. If I turn off MQTT
> publishing, I get a “Failed connecting...” message after a minute or so.
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686
>
>
>> On Jun 14, 2020, at 19:40, Ken Walker gmail.com
>>
[weewx-user] Re: weewx and opensprinkler
Put me down as a happy RainMachine user. You have the direct from WeeWX capability or if you feed data to Aeris, the ability to use their API to get the data. No cloud required if you don't wish, capable if you do. I didn't like that other commercial brands required internet to function as advertised. Didn't want to cobble a homebrew controller. RainMachine was (and is I think) my sole choice. I have a Mini-8 but as you say it has been discontinued in favor of the Pro-8 https://www.rainmachine.com/products/rainmachine-pro.html On Saturday, June 13, 2020 at 5:49:03 PM UTC-4, Xant wrote: > > > Mike > > Agree. Greetings for those going DIY, but in this case will go turnkey as > well. > > Per my recent research, Rachio tops most of reviews, but some complains > about Advertising inside own app to other company products. On the other > side, RainMachine owners feedback are most positive (like yourself). And... > extensive connectivity to HomeAssistant, WeeWX, among others, while > data remains local - "cloudless" (to note, the weewx link seems to be > written by HomeMachine own developers). > > RainMachine Mini-8 ($159) announced End-Of-Life, leaving only their most > expensive options available. But still, I may go this route... > > Xant > (your neighbor at Clifton Park/NY) > -- 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/ee051e97-e466-42ac-bbaa-24eebd3fb82do%40googlegroups.com.
Re: [weewx-user] Belchertown MQTT
Belchertown expects the weather data to be in the same format as the weewx
mqtt extension. If you're not publishing from the weewx mqtt extension,
then you'll need to have your publisher emulate that extension's output.
(rough example below, not all observations need to be in the same packet)
Your mqtt broker needs to have websockets enabled as well. Then you'll set
your skin to connect to the websocket port to get the data.
MQTT: {"dateTime": "1592228732.0", "usUnits": "1.0", "outTemp_F": "65.9",
"rain_in": "0.0", "rainRate_inch_per_hour": "0.0", "barometer_inHg":
"30.514", "radiation_Wpm2": "691.0", "inTemp_F": "75.5", "inHumidity":
"36.0", "outHumidity": "53.0", "windSpeed_mph": "5.0", "windGust_mph": "5.0"
, "UV": "4.1", "forecastRule": "9.0", "txBatteryStatus": "0.0",
"consBatteryVoltage_volt": "4.71", "windDir": "11.0", "windGustDir": "11.0",
"pressure_inHg": "30.05007732814778", "altimeter_inHg": "30.522342546117084"
, "windchill_F": "65.9", "heatindex_F": "65.9", "dewpoint_F":
"48.27895673606349", "inDewpoint_F": "46.66006121573143", "appTemp_F":
"62.71298653227457", "maxSolarRad_Wpm2": "725.56944104572", "cloudbase_foot"
: "4434.782559985571", "humidex_F": "67.42878362134785", "hourRain_in":
"0.0", "rain24_in": "0.0", "dayRain_in": "0.0", "windSpeed10_mph": "2.0",
"stormRain_in": "0.0", "monthRain_in": "1.07", "yearRain_in": "14.82",
"dayET": "0.023", "monthET": "2.04", "yearET": "14.19", "leafWet4": "0.0",
"insideAlarm": "0.0", "rainAlarm": "0.0", "outsideAlarm1": "0.0",
"outsideAlarm2": "0.0", "extraAlarm1": "0.0", "extraAlarm2": "0.0",
"extraAlarm3": "0.0", "extraAlarm4": "0.0", "extraAlarm5": "0.0",
"extraAlarm6": "0.0", "extraAlarm7": "0.0", "extraAlarm8": "0.0",
"soilLeafAlarm1": "0.0", "soilLeafAlarm2": "0.0", "soilLeafAlarm3": "0.0",
"soilLeafAlarm4": "0.0", "forecastIcon": "6.0", "sunrise": "1592212752.0",
"sunset": "1592268288.0"}
On Sunday, June 14, 2020 at 11:39:15 PM UTC-4, Garry A Lockyer wrote:
>
> Seems to me you have to publish MQTT data (under [StdRESTful][[MQTT]] so
> that you can later retrieve the data in
> [StdReport][[Belchertown]][[[Extras]]]. I suppose it’s possible to have
> one instance of weewx publish data and another instance subscribe to it,
> but there has to be at least one publisher somewhere.
>
> I can’t explain the “lost connection “ message. If I turn off MQTT
> publishing, I get a “Failed connecting...” message after a minute or so.
>
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686
>
>
> On Jun 14, 2020, at 19:40, Ken Walker >
> wrote:
>
> Thanks. I don’t want to publish since I’m already getting data from
> MQTT. My subscribe settings are the same as yours(other than host and
> topic obviously). But it does not work.
>
> I’m perplexed :)
>
> On Jun 14, 2020, at 8:54 PM, garrya...@gmail.com wrote:
>
> Here’re the settings I’m currently using successfully:
>
> [[MQTT]]
> # This is to PUBLISH MQTT topics - username and password are
> required, on my system.
>
> server_url = mqtt://username:password@192.168.1.140:1883/
> topic = weather/OsoyoosLakeNorthEast
> unit_system = METRIC
> binding = archive, loop
> aggregation = aggregate
>
> # This is to SUBSCRIBE to MQTT topics - a username and
> password are not required – at least not on my system.
>
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "192.168.1.140”
> mqtt_websockets_topic = "weather/OsoyoosLakeNorthEast/loop"
> mqtt_websockets_port = 9001
> disconnect_live_website_visitor = 180
>
> The “aggregation” option above controls publishing one variable at a time,
> or publishing them all in a single connection (an aggregate).
>
> Regards,
>
> Garry
>
>
> *From:* weewx...@googlegroups.com > *On Behalf Of *Ken Walker
> *Sent:* June 14, 2020 5:11 PM
> *To:* weewx...@googlegroups.com
> *Subject:* Re: [weewx-user] Belchertown MQTT
>
> Is the implementation expecting one observation at a time returned from
> the broker. I am returning from 1 - 5 observations in one json string
>
>
> On Jun 14, 2020, at 7:47 PM, Garry A Lockyer > wrote:
>
>
> The websockets port probably should be 9001. 1883 is usually the MQTT
> broker.
> Regards,
>
> Garry Lockyer
> C: +1.250.689.0686
> E: ga...@lockyer.ca
>
>
>
> On Jun 14, 2020, at 16:43, Ken Walker >
> wrote:
>
>
> I'm getting my data from an internal MQTT server using the wxMesh driver
> and all is working well.
>
> I would like to enable the MQTT updates, but cannot get them to work.
>
> I get a failed to connect message. All items are on my internal network.
>
> I have no trouble connecting from my weewx box(Raspberry Pi) with the
> mosquito_sub client.
>
> Am I missing something obvious?
>
>
> I have the following in my skin.conf:
>
> mqtt_websockets_enabled = 1
> mqtt_websockets_host = "xx.xx.xx.xxx"
> mqtt_websockets_port = 1883
Re: [weewx-user] Re: Full day highcharts question
Awesome! Glad that it worked for you On Monday, June 15, 2020 at 5:29:59 AM UTC-4, didier@gmail.com wrote: > > Thanks it's work > > > Le lundi 15 juin 2020 à 11:12:27 UTC+2, Manfred Maier a écrit : > >> Thanks, Gary, for this comprehensive explanation. >> >> Based on what you wrote I was now able to plot an entire day. >> >> [image: Bildschirmfoto 2020-06-15 um 11.07.53.png] >> >> The trick is quite simple: I just had to define an aggregation for the >> daily charts. I.e. adding the following two lines to the graphs.conf: >> >> aggregate_type = max >> >> aggregate_interval = 300 >> >> >> >> -- 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/bd1200b8-fae3-4715-b5ec-47797a9a9ae7o%40googlegroups.com.
[weewx-user] Re: Having yesterday's rain listed right under Rain Rate, Rain Today in the Current Conditions section
Correct just reading from the database won't hurt anything. The code will trigger a Data base read and in this case a sum of the data for yesterday. >From a CPU perspective it seems to have little effect on the Rpi 3 I use, I actually pull rain for the last 24 hours, last week, and last month. As for the SD Card life I can't say much since I use an old spinning USB Hard drive to store my data, but data reads are not very hard on an SD it is the writes I believe are the issue. If you search through the posts I think you'll find info on SD card life, plus ways to minimize the writes. It may be possible to run a query on the DB at say 5 past midnight and save the data to a text file or a DB record and then not have to run the query every report cycle, but it beyond what I have done -- 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/447278e2-0a1f-4f29-951f-bca43fd04107o%40googlegroups.com.
[weewx-user] Re: Weewx 4.1.1 silently stops updating DB and Graphs
by the way, the interceptor.py I enclosed includes also this patch: https://github.com/matthewwall/weewx-interceptor/pull/64 Regards, Matthias Am Montag, 15. Juni 2020 12:27:11 UTC+2 schrieb NanoG5Kite: > > As it works for me, > > [Interceptor] > # This section is for the network traffic interceptor driver. > > # The driver to use: > driver = user.interceptor > > # Specify the hardware device to capture. Options include: > # acurite-bridge - acurite internet bridge, smarthub, or access > # observer - fine offset WH2600/HP1000/HP1003, ambient WS2902 > # lw30x - oregon scientific LW301/LW302 > # lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge > # ecowitt-client - any hardware that uses the ecowitt protocol > # wu-client - any hardware that uses the weather underground protocol > # device_type = fineoffset-bridge > device_type = ecowitt-client > port = 8000 (take your port) > > And possible the patched interceptor.py - enclosed... > > Pattched according to the one from Oliver: > https://github.com/matthewwall/weewx-interceptor/issues/69 > > > > > > > > Am Montag, 15. Juni 2020 12:11:43 UTC+2 schrieb Russell Cutcliffe: >> >> Interesting... >> >> I'll check further into that. >> >> As to the custom feed, check the attached screenshot from my phone screen. >> >> This is a newish feature that rolled out to these weather stations, and >> seems to work (with maybe some time issues ;^). >> >> Russell C >> > -- 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/bff5a38d-a356-4dc0-a8d9-01bbceda14e7o%40googlegroups.com.
[weewx-user] Re: retrieving old data from DAVIS VANTAGE PRO2
That seems odd, the error shown is the driver encountering a crc error on data downloaded from the station. The driver has no access to the database so I can’t see how the database in use could cause a driver crc error. If you change back to MySQL again does it work? Gary -- 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/ea084c54-8f4a-486f-964e-35116a0af917o%40googlegroups.com.
[weewx-user] Re: Weewx 4.1.1 silently stops updating DB and Graphs
As it works for me, [Interceptor] # This section is for the network traffic interceptor driver. # The driver to use: driver = user.interceptor # Specify the hardware device to capture. Options include: # acurite-bridge - acurite internet bridge, smarthub, or access # observer - fine offset WH2600/HP1000/HP1003, ambient WS2902 # lw30x - oregon scientific LW301/LW302 # lacrosse-bridge - lacrosse GW1000U/C84612 internet bridge # ecowitt-client - any hardware that uses the ecowitt protocol # wu-client - any hardware that uses the weather underground protocol # device_type = fineoffset-bridge device_type = ecowitt-client port = 8000 (take your port) And possible the patched interceptor.py - enclosed... Pattched according to the one from Oliver: https://github.com/matthewwall/weewx-interceptor/issues/69 Am Montag, 15. Juni 2020 12:11:43 UTC+2 schrieb Russell Cutcliffe: > > Interesting... > > I'll check further into that. > > As to the custom feed, check the attached screenshot from my phone screen. > > This is a newish feature that rolled out to these weather stations, and > seems to work (with maybe some time issues ;^). > > Russell C > -- 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/2f946d3c-6418-4c0d-8f69-9ce1612bcda7o%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
[weewx-user] Re: Weewx 4.1.1 silently stops updating DB and Graphs
Might be worth giving the ecowitt format a go. You would need to set device_type = ecowitt-client under [Interceptor] in weewx.conf. Gary -- 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/7da6228a-fb1c-4c73-b0c8-c483f0cdfa82o%40googlegroups.com.
[weewx-user] Re: Weewx 4.1.1 silently stops updating DB and Graphs
Interesting... I'll check further into that. As to the custom feed, check the attached screenshot from my phone screen. This is a newish feature that rolled out to these weather stations, and seems to work (with maybe some time issues ;^). Russell C -- 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/cab7cbea-ed71-4044-8bdb-335178652074o%40googlegroups.com.
[weewx-user] Re: retrieving old data from DAVIS VANTAGE PRO2
swapping back to SQLite, it runs into the db without a problem. So it has something to do with the SSH Tunnel and the external MySQL, connection to slow? -- 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/9aa7d345-8575-4ccd-9e7c-44a103404815o%40googlegroups.com.
[weewx-user] Outlook for any better support/implementation of the Ecowitt/Froggit GW1000/DP1500 WIFI Dongle & Sensors?
I´m wondering if it´s planned/in progress, that Weewx will support the GW1000 better than today? The interceptor driver´s developments/updates seem to stagnate since months, new sensors like the WH57 Lightning not yet supported. What´s about the Ecowitt/GW1000 API? Question if the Weewx developers are in contact/process with Ecowitt? Regards, Matthias -- 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/128c08e2-eacc-44c2-8a81-c1f3ab1aeb85o%40googlegroups.com.
Re: [weewx-user] Re: Full day highcharts question
Thanks it's work Le lundi 15 juin 2020 à 11:12:27 UTC+2, Manfred Maier a écrit : > Thanks, Gary, for this comprehensive explanation. > > Based on what you wrote I was now able to plot an entire day. > > [image: Bildschirmfoto 2020-06-15 um 11.07.53.png] > > The trick is quite simple: I just had to define an aggregation for the > daily charts. I.e. adding the following two lines to the graphs.conf: > > aggregate_type = max > > aggregate_interval = 300 > > > > -- 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/e6f55596-fb95-4621-8599-dac0c18e7540n%40googlegroups.com.
[weewx-user] Re: Weewx 4.1.1 silently stops updating DB and Graphs
Hi,
Here is what is causing the strange record generation/reporting behaviour
with WeeWX. The 15:02:54 packet has a timestamp of 1592197317 (derived from
dateutc=2020-06-15%2005:01:57
- 2020-06-15 05:01:57):
Jun 15 15:02:54 pete weewx[11155] DEBUG user.interceptor: GET: ID=number10&
PASSWORD==73.6=74.3=62.6=74.3&
indoorhumidity=63=67=0.0=0.0=137&
absbaromin=30.080=30.024=0.000=0.008
=1.268=1.480=283.69=3=2020-06-15%
2005:01:57=EasyWeatherV1.4.9=updateraw=1
=5
That packet is properly decoded and a loop packet created (the mapped
packet at 15:02:54):
Jun 15 15:02:54 pete weewx[11155] DEBUG user.interceptor: mapped packet: {
'dateTime': 1592197317, 'usUnits': 1, 'pressure': 30.08, 'barometer': 30.024
, 'outHumidity': 67.0, 'inHumidity': 63.0, 'outTemp': 74.3, 'inTemp': 73.6,
'windSpeed': 0.0, 'windGust': 0.0, 'windDir': 137.0, 'radiation': 283.69,
'dewpoint': 62.6, 'windchill': 74.3, 'rain': 0.0, 'UV': 3.0}
If you look at the next packet at 15:03:58 you will see the packet has a
timestamp of 1592229600 (derived from dateutc=2020-06-15%2014:00:00 -
2020-06-15 14:00:00), some nine hours later:
Jun 15 15:03:58 pete weewx[11155] DEBUG user.interceptor: GET: ID=number10&
PASSWORD==73.6=74.5=62.1=74.5&
indoorhumidity=63=65=1.3=2.2=211&
absbaromin=30.089=30.033=0.000=0.008
=1.268=1.480=284.06=3=2020-06-15%
2014:00:00=EasyWeatherV1.4.9=updateraw=1
=5
Such a jump in timestamps has the effect of causing WeeWX to synthesise an
archive record at 15:03:58. The record is saved to database and the report
cycle initiated. Subsequent packets jump back to the correct time but
because WeeWX has seen the much later packet WeeWX effectively ignores the
subsequent data (in truth it is probably being accumulated but WeeWX will
not synthesise another archive record until it sees a loop packet with a
timestamp of at least 1592229900 (which will be five minutes after midnight
on 16 June local time)). The report cycle does not occur as the report
cycle is kicked off when an archive record is produced and no archive
record is being produced.
Chances are if you left well enough alone an archive record will be
synthesised at five minutes after midnight on 16 June (provided no more
future dated packets are recieved) and the recport cycle initiated but that
is not really an acceptable situation.
So that is the mechanism that causes the odd behaviour but what is the
fundamental cause? The WeeWX interceptor driver dumps the raw GET data it
picks up from your station to log, the interceptor does not adjust/decode
times when displaying the raw GET data so we have to assume your station
emitted the packet with the future dated timestamp. I have no idea why,
your config file seems reasonable. I have not used/seen the EasyWeather
software so I don't know if there are any configuration changes there that
might help. I do get toey when i see things like rtfreq=5 (at the end of
each GET data/raw packet) as that indicates to me WeatherUnderground
rapidfire (I have a natural suspicion of WU and/or rapidfire) is being used
and this implies an update every 5 seconds, but we are only seeing packets
being emitted every 60 odd seconds (granted there are some empty queue log
entries but not every five seconds). Perhaps that is something worth
looking at - can the update frequency be set within EasyWeather?
You mention a 'custom WU protocol feed' - exactly what do you mean by that?
Gary
On Monday, 15 June 2020 16:56:15 UTC+10, Russell Cutcliffe wrote:
>
> Hi,
>
> I have a long standing issue with Weewx 4.x, where the process will
> spontaneously stop adding database records and updating the graphs.
>
> The attached syslog snippet should contain enough detail to show that
> everything looks okay, except that the report generation just seems to stop.
>
> For completeness, I should point out that the process will generally stop
> just after midnight local time, or occasionally around 3am/pm.
>
> The system is now running on a dedicated Ubuntu 20.04 VM, with its own
> Mariadb instance. The install was via the Ubuntu repo (now 4.1.1), and is
> running with Python 3.8.2, also from the repo.
>
> Data comes in via an interceptor, listening on port 80 and being fed from
> a custom WU protocol feed from my WH2905.
>
> I've been looking for some external influence, but I'm at my wit's end.
> Certainly syslog never shows anything. I've turned off unattended-updates
> after I caught it restarting my VM, but the problem remains.
>
> I've gotten to the point where I have Node Red watching the database and
> restarting Weewx when updates stop, so I'm not completely desperate, but
> the gaps in the graphs are a bit annoying.
>
> From my reading, it appears that I'm alone with this particular issue, so
> any fault finding hints would be appreciated.
>
> Russell C
>
--
You received this message because you are subscribed to the Google Groups
"weewx-user" group.
To unsubscribe from this group and stop
Re: [weewx-user] Re: Full day highcharts question
Thanks, Gary, for this comprehensive explanation. Based on what you wrote I was now able to plot an entire day. [image: Bildschirmfoto 2020-06-15 um 11.07.53.png] The trick is quite simple: I just had to define an aggregation for the daily charts. I.e. adding the following two lines to the graphs.conf: aggregate_type = max aggregate_interval = 300 -- 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/2cdeaecb-279e-42d4-af61-a1c0038333bbo%40googlegroups.com.
[weewx-user] Re: Weather station GARNI 935PC - compatibility with Weewx?
Hi Ondrej I don't understand the behaviour you are seeing and I need a bit more information. Are you trying to run with the weewx Simulator and the WS6in1 at the same time ? You should only be using WS6in1. The results you are seeing cannot be conversion errors they are something completely different. Could you set the debug to '1' (in the weewx.conf file), restart weewx and then post the relevant output from the /var/log/syslog If you are familiar with databases it might be worth looking at the entries in the database to see whats actually been stored (i.e is it what you are expecting from the console or the same as the erroneous data being displayed) Good luck Bob -- 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/1d18b31b-8813-4397-9046-df27bc109801o%40googlegroups.com.
[weewx-user] Weewx 4.1.1 silently stops updating DB and Graphs
Hi, I have a long standing issue with Weewx 4.x, where the process will spontaneously stop adding database records and updating the graphs. The attached syslog snippet should contain enough detail to show that everything looks okay, except that the report generation just seems to stop. For completeness, I should point out that the process will generally stop just after midnight local time, or occasionally around 3am/pm. The system is now running on a dedicated Ubuntu 20.04 VM, with its own Mariadb instance. The install was via the Ubuntu repo (now 4.1.1), and is running with Python 3.8.2, also from the repo. Data comes in via an interceptor, listening on port 80 and being fed from a custom WU protocol feed from my WH2905. I've been looking for some external influence, but I'm at my wit's end. Certainly syslog never shows anything. I've turned off unattended-updates after I caught it restarting my VM, but the problem remains. I've gotten to the point where I have Node Red watching the database and restarting Weewx when updates stop, so I'm not completely desperate, but the gaps in the graphs are a bit annoying. >From my reading, it appears that I'm alone with this particular issue, so any fault finding hints would be appreciated. Russell C -- 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/be3da6dd-06e1-4ac1-90e7-1adeda996019o%40googlegroups.com. weewx.log.1506 Description: Binary data weewx.conf.sanitised Description: Binary data
[weewx-user] Re: Weather station GARNI 935PC - compatibility with Weewx?
Hello Bob, First af all, thanks for the WS6in1 driver! You have done great job. I can see how you helped to Jarda and Pave. Maybe you can give me some advise to my problem. I am having some difficulty to get proper values of my Garni 935PC out to the html output. I use Raspberry Pi 4, it is running Raspbian, but I tested also Ubuntu. The version of driver is 0.6. In both OS versions the driver works, but a bit differently. In Raspbian the "Simulator" is not on the top position under "0" index, but on a thrid position with index "3". My problem is, that values for Out temperature and humidity are strange. The display shows 17 degrees of Celsia from external sensor, but the html output shows -0.3. The humidity outside last night was on display 98%, but the html output was showing 80% for outside. Also rain precip rate was showing zero even though the sensore detected about 30mm as well as the wind was showing always zero. Additionally, the external temperature and humidity was copied to the place where should be values from internal sensor. So values for internal sensor were those from the external 6in1 unit. Can you please help how to troubleshoot this? Thanks in advance. Regards - Ondrej Dňa piatok, 8. mája 2020 10:07:02 UTC+2 Bob Atchley napísal(a): > > Hi Jarda, Pavel, > > I'm extremely happy that the updated driver is working ... I might even > buy myself an extra sensor at some point ! > > I do know how to download the data history stored on the console, but I > haven't explored how to use this. I think weewx can use this to fill in > missing data in case of a server outage etc. So probably a 0.3 version of > the driver in the near future. I might explore a standalone tool just to > download the data into a csv file (suitable for import into weewx) as well. > > I'll post a WS6in1 update message when I add any features > > Many thanks for helping with the testing > > Bob > -- 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/094c15f8-36d0-4c89-9600-434e80d8a5c4o%40googlegroups.com.
