Re: [weewx-user] Live weather on iOS

2020-12-12 Thread Constantine Samaklis 
The latest build is now available in the Apple store: 
https://apps.apple.com/us/app/weather-mqtt/id1542679289 

On Wednesday, December 9, 2020 at 3:45:33 PM UTC-5 bell...@gmail.com wrote:

> Sorry, I wasn’t clear.  I am all set now. The problem was the format of my 
> payload. It was originally strings.  Now I am publishing floats.  Here is 
> an example of what is working.
>
> Subscribing to weather/individual/# has a mid 1 and rc 0
> Subscribed to topic mid: 1 is size 1 has a QOS of 0
> topic: weather/individual/monthET
> payload: b'0.12'
> topic: weather/individual/heatindex_F
> payload: b'30.8'
> topic: weather/individual/outHumidity
> payload: b'93.0'
> topic: weather/individual/dayET
> payload: b'0.005'
> topic: weather/individual/maxSolarRad_Wpm2
> payload: b'5.01839449489'
> topic: weather/individual/consBatteryVoltage_volt
> payload: b'4.54'
> topic: weather/individual/monthRain_in
> payload: b'0.16'
> topic: weather/individual/insideAlarm
> payload: b'0.0'
> topic: weather/individual/barometer_inHg
> payload: b'29.087'
> topic: weather/individual/dayRain_in
> payload: b'0.02'
> topic: weather/individual/stormRain_in
> payload: b'0.02'
> topic: weather/individual/sunrise
> payload: b'1607515920.0'
>
> Again, thanks.
>
> On Wednesday, 9 December 2020 at 14:52:35 UTC-5 sama...@gmail.com wrote:
>
>> Also just to make sure, delete the app first in case the settings files 
>> are persisting from the original version you may have tried 
>>
>> On Wed, Dec 9, 2020 at 14:47 Constantine Samaklis  
>> wrote:
>>
>>> Just to confirm your topic in the application settings is set to 
>>> weather/individual right?
>>>
>>>
>>>
>>> On Wed, Dec 9, 2020 at 11:39 bell...@gmail.com  
>>> wrote:
>>>
>>>> I did. Since then I have tried the following.
>>>> 1. Publish as metric and change the application configuration back to 
>>>> metric.
>>>> 2. Only publish outTemp_C and configure only an ‘Outside Temperature’ 
>>>> gauge.
>>>> I’m sure I’m missing something obvious. I’ll keep experimenting. 
>>>> rich
>>>>
>>>> On Wednesday, 9 December 2020 at 05:54:49 UTC-5 sama...@gmail.com 
>>>> wrote:
>>>>
>>>>> In the application configuration have you turned your station units to 
>>>>> imperial? (I think they default to metric) 
>>>>>
>>>>> That would make a difference between looking for example between 
>>>>> heatindex_F and headindex_C which is part of the whole topic string
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>> On Tue, Dec 8, 2020 at 7:44 PM bell...@gmail.com  
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> Interesting. The first time I clicked on the link it only installed 
>>>>>> TestFlight.  But I digress. I must be doing something wrong. I get the 
>>>>>> green dot, so I think I am connected. I entered weather/individual as my 
>>>>>> topic.
>>>>>> Here is some output from some test code
>>>>>> Connected with result code 0
>>>>>> Connected flags {'session present': 0}
>>>>>> Subscribing to weather/individual/# has a mid 1 and rc 0
>>>>>> Subscribed to topic mid: 1 is size 1 has a QOS of 0
>>>>>> topic: weather/individual/monthET
>>>>>> payload: b'"0.11"'
>>>>>> topic: weather/individual/heatindex_F
>>>>>> payload: b'"22.5"'
>>>>>> topic: weather/individual/outHumidity
>>>>>> payload: b'"86.0"'
>>>>>> topic: weather/individual/dayET
>>>>>> payload: b'"0.006"'
>>>>>> topic: weather/individual/maxSolarRad_Wpm2
>>>>>> payload: b'"0.0"'
>>>>>> topic: weather/individual/consBatteryVoltage_volt
>>>>>> payload: b'"4.54"'
>>>>>> topic: weather/individual/monthRain_in
>>>>>> payload: b'"0.14"'
>>>>>> topic: weather/individual/insideAlarm
>>>>>> payload: b'"0.0"'
>>>>>> topic: weather/individual/barometer_inHg
>>>>>> payload: b'"29.282"'
>>>>>> topic: weather/individual/dayRain_in
>>>>>> payload: b'"0.0"'
>>>>>> topic: weather/individual/stormRain_in
>>>>>> payload:

Re: [weewx-user] Live weather on iOS

2020-12-09 Thread Constantine Samaklis 
Also just to make sure, delete the app first in case the settings files are
persisting from the original version you may have tried

On Wed, Dec 9, 2020 at 14:47 Constantine Samaklis 
wrote:

> Just to confirm your topic in the application settings is set to
> weather/individual right?
>
>
>
> On Wed, Dec 9, 2020 at 11:39 bell...@gmail.com 
> wrote:
>
>> I did. Since then I have tried the following.
>> 1. Publish as metric and change the application configuration back to
>> metric.
>> 2. Only publish outTemp_C and configure only an ‘Outside Temperature’
>> gauge.
>> I’m sure I’m missing something obvious. I’ll keep experimenting.
>> rich
>>
>> On Wednesday, 9 December 2020 at 05:54:49 UTC-5 sama...@gmail.com wrote:
>>
>>> In the application configuration have you turned your station units to
>>> imperial? (I think they default to metric)
>>>
>>> That would make a difference between looking for example between
>>> heatindex_F and headindex_C which is part of the whole topic string
>>>
>>>
>>> Thanks
>>>
>>> On Tue, Dec 8, 2020 at 7:44 PM bell...@gmail.com 
>>> wrote:
>>>
>>>>
>>>> Interesting. The first time I clicked on the link it only installed
>>>> TestFlight.  But I digress. I must be doing something wrong. I get the
>>>> green dot, so I think I am connected. I entered weather/individual as my
>>>> topic.
>>>> Here is some output from some test code
>>>> Connected with result code 0
>>>> Connected flags {'session present': 0}
>>>> Subscribing to weather/individual/# has a mid 1 and rc 0
>>>> Subscribed to topic mid: 1 is size 1 has a QOS of 0
>>>> topic: weather/individual/monthET
>>>> payload: b'"0.11"'
>>>> topic: weather/individual/heatindex_F
>>>> payload: b'"22.5"'
>>>> topic: weather/individual/outHumidity
>>>> payload: b'"86.0"'
>>>> topic: weather/individual/dayET
>>>> payload: b'"0.006"'
>>>> topic: weather/individual/maxSolarRad_Wpm2
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/consBatteryVoltage_volt
>>>> payload: b'"4.54"'
>>>> topic: weather/individual/monthRain_in
>>>> payload: b'"0.14"'
>>>> topic: weather/individual/insideAlarm
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/barometer_inHg
>>>> payload: b'"29.282"'
>>>> topic: weather/individual/dayRain_in
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/stormRain_in
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/sunrise
>>>> payload: b'"1607429520.0"'
>>>> topic: weather/individual/windchill_F
>>>> payload: b'"22.5"'
>>>> topic: weather/individual/dewpoint_F
>>>> payload: b'"18.9577377882"'
>>>> topic: weather/individual/outsideAlarm1
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/soilLeafAlarm2
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/outsideAlarm2
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/radiation_Wpm2
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/forecastRule
>>>> payload: b'"192.0"'
>>>> topic: weather/individual/rainAlarm
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/inTemp_F
>>>> payload: b'"67.4"'
>>>> topic: weather/individual/inHumidity
>>>> payload: b'"38.0"'
>>>> topic: weather/individual/windSpeed10_mph
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/yearRain_in
>>>> payload: b'"23.37"'
>>>> topic: weather/individual/inDewpoint_F
>>>> payload: b'"40.9048059523 <(904)%20805-9523>"'
>>>> topic: weather/individual/extraAlarm1
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/extraAlarm2
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/extraAlarm3
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/extraAlarm4
>>>> payload: b'"0.0"'
>>>> topic: weather/individual/extraAlarm5
>>>> payload: b'"0.0"'
>>>> topic:

Re: [weewx-user] Live weather on iOS

2020-12-09 Thread Constantine Samaklis 
; payload: b'"18.0"'
>>> topic: weather/individual/pressure_inHg
>>> payload: b'"28.7311013367"'
>>> topic: weather/individual/soilLeafAlarm4
>>> payload: b'"0.0"'
>>> topic: weather/individual/trendIcon
>>> payload: b'"0.0"'
>>> topic: weather/individual/altimeter_inHg
>>> payload: b'"29.2387383925"'
>>> topic: weather/individual/soilLeafAlarm3
>>> payload: b'"0.0"'
>>> topic: weather/individual/usUnits
>>> payload: b'"1.0"'
>>> topic: weather/individual/soilLeafAlarm1
>>> payload: b'"0.0"'
>>> topic: weather/individual/leafWet4
>>> payload: b'"0.0"'
>>> topic: weather/individual/yearET
>>> payload: b'"25.01"'
>>> topic: weather/individual/txBatteryStatus
>>> payload: b'"0.0"'
>>> topic: weather/individual/appTemp_F
>>> payload: b'"17.4069618021 <(406)%20961-8021>"'
>>> topic: weather/individual/UV
>>> payload: b'"0.0"'
>>> topic: weather/individual/dateTime
>>> payload: b'"1607474098.0"'
>>> topic: weather/individual/outTemp_F
>>> payload: b'"22.5"'
>>> topic: weather/individual/windSpeed_mph
>>> payload: b'"0.0"'
>>> topic: weather/individual/sunset
>>> payload: b'"1607464200.0"'
>>> topic: weather/individual/windGust_mph
>>> payload: b'"0.0"'
>>> topic: weather/individual/cloudbase_foot
>>> payload: b'"1295.05959359"'
>>> topic: weather/individual/hourRain_in
>>> payload: b'"0.0"'
>>> topic: weather/individual/rain24_in
>>> payload: b'"0.0"'
>>> Exception in thread Thread-4:
>>> Traceback (most recent call last):
>>>   File
>>> "/var/containers/Bundle/Application/98214C3F-7429-489D-8C5B-62EBF1A92501/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/threading.py",
>>> line 917, in _bootstrap_inner
>>> self.run()
>>>   File
>>> "/var/containers/Bundle/Application/98214C3F-7429-489D-8C5B-62EBF1A92501/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/threading.py",
>>> line 865, in run
>>> self._target(*self._args, **self._kwargs)
>>>   File
>>> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
>>> line 3428, in _thread_main
>>> self.loop_forever(retry_first_connection=True)
>>>   File
>>> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
>>> line 1782, in loop_forever
>>> rc = self.loop(timeout, max_packets)
>>>   File
>>> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
>>> line 1163, in loop
>>> socklist = select.select(rlist, wlist, [], timeout)
>>> KeyboardInterrupt
>>>
>>>
>>> On Tuesday, 8 December 2020 at 19:23:48 UTC-5 sama...@gmail.com wrote:
>>>
>>>> *https://testflight.apple.com/join/EPwi6NBP
>>>> <https://testflight.apple.com/join/EPwi6NBP>*  <-- This is the link.
>>>> (also in the previous post) you can visit it from your iOS device and it
>>>> will open testflight and ask you to open the application, etc.
>>>>
>>>> On Tuesday, December 8, 2020 at 7:20:46 PM UTC-5 bell...@gmail.com
>>>> wrote:
>>>>
>>>>> OK, I’m new to this. I’ve installed TestFlight, but it seems like I
>>>>> need a link or something to your app...
>>>>> rich
>>>>>
>>>>> On Tuesday, 8 December 2020 at 17:14:52 UTC-5 sama...@gmail.com wrote:
>>>>>
>>>>>> TestFlight link for testing the build:
>>>>>> https://testflight.apple.com/join/EPwi6NBP
>>>>>>
>>>>>> Let me know if that works for you with the custom topic name and I
>>>>>> will push to the Apple store if it does.
>>>>>>
>>>>>> On Mon, Dec 7, 2020 at 17:26 Constantine Samaklis 
>>>>>> wrote:
>>>>>>
>>>>>>> I have submitted a new build where the topic can be specified. As
>>>>>>> soon as it get

Re: [weewx-user] Live weather on iOS

2020-12-09 Thread Constantine Samaklis 
ph
> payload: b'"0.0"'
> topic: weather/individual/cloudbase_foot
> payload: b'"1295.05959359"'
> topic: weather/individual/hourRain_in
> payload: b'"0.0"'
> topic: weather/individual/rain24_in
> payload: b'"0.0"'
> Exception in thread Thread-4:
> Traceback (most recent call last):
>   File
> "/var/containers/Bundle/Application/98214C3F-7429-489D-8C5B-62EBF1A92501/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/threading.py",
> line 917, in _bootstrap_inner
> self.run()
>   File
> "/var/containers/Bundle/Application/98214C3F-7429-489D-8C5B-62EBF1A92501/Pythonista3.app/Frameworks/Py3Kit.framework/pylib/threading.py",
> line 865, in run
> self._target(*self._args, **self._kwargs)
>   File
> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
> line 3428, in _thread_main
> self.loop_forever(retry_first_connection=True)
>   File
> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
> line 1782, in loop_forever
> rc = self.loop(timeout, max_packets)
>   File
> "/private/var/mobile/Containers/Shared/AppGroup/03C7B2FF-1C6F-474E-A5E4-35A11C6986BE/Pythonista3/Documents/site-packages-3/paho/mqtt/client.py",
> line 1163, in loop
> socklist = select.select(rlist, wlist, [], timeout)
> KeyboardInterrupt
>
>
> On Tuesday, 8 December 2020 at 19:23:48 UTC-5 sama...@gmail.com wrote:
>
>> *https://testflight.apple.com/join/EPwi6NBP
>> <https://testflight.apple.com/join/EPwi6NBP>*  <-- This is the link.
>> (also in the previous post) you can visit it from your iOS device and it
>> will open testflight and ask you to open the application, etc.
>>
>> On Tuesday, December 8, 2020 at 7:20:46 PM UTC-5 bell...@gmail.com wrote:
>>
>>> OK, I’m new to this. I’ve installed TestFlight, but it seems like I need
>>> a link or something to your app...
>>> rich
>>>
>>> On Tuesday, 8 December 2020 at 17:14:52 UTC-5 sama...@gmail.com wrote:
>>>
>>>> TestFlight link for testing the build:
>>>> https://testflight.apple.com/join/EPwi6NBP
>>>>
>>>> Let me know if that works for you with the custom topic name and I will
>>>> push to the Apple store if it does.
>>>>
>>>> On Mon, Dec 7, 2020 at 17:26 Constantine Samaklis 
>>>> wrote:
>>>>
>>>>> I have submitted a new build where the topic can be specified. As soon
>>>>> as it gets approved, I will post a link where you can use testflight for
>>>>> you to test it and see if it works as expected.
>>>>>
>>>>> On Sunday, December 6, 2020 at 7:42:20 PM UTC-5 bell...@gmail.com
>>>>> wrote:
>>>>>
>>>>>> This looks really cool. I too am anxiously awaiting to be able to
>>>>>> specify the topic.  In my case, I am publishing json loop data to
>>>>>> weather/loop, json archive data to weather/archive, both to
>>>>>> weather/looparchive.  So if I could specify something like
>>>>>> weather/loop-individual/#... but I could easily publish to almost 
>>>>>> anything
>>>>>> but weather/#.
>>>>>> Again, thanks for sharing! If I can help in any way, let me know.
>>>>>> rich
>>>>>>
>>>>>> On Sunday, 6 December 2020 at 18:37:04 UTC-5 blu...@gmail.com wrote:
>>>>>>
>>>>>>> Ok understood; my topics are published as weather/corbett and
>>>>>>> weather/williams for different locations.  I look forward to that
>>>>>>> enhancement!  This looks like a cool app.
>>>>>>>
>>>>>>> On Dec 6, 2020, at 3:27 PM, Constantine Samaklis 
>>>>>>> wrote:
>>>>>>>
>>>>>>> Currently no. It defaults to weather/#. The gauges are also limited
>>>>>>> to the topics published by the MQTT extension so for example if you have
>>>>>>> configured the extension to run in metric, you will
>>>>>>> have weather/windchill_C for windchill and if you have it configured for
>>>>>>> imperial units, then it will listen for weather/windchill_F.
>>>>>>>
>>>>>>>
>>>>>>> The pattern is similar across all the available gauges.
>>>>>>>
>&

Re: [weewx-user] Live weather on iOS

2020-12-08 Thread Constantine Samaklis 
TestFlight link for testing the build:
https://testflight.apple.com/join/EPwi6NBP

Let me know if that works for you with the custom topic name and I will
push to the Apple store if it does.

On Mon, Dec 7, 2020 at 17:26 Constantine Samaklis 
wrote:

> I have submitted a new build where the topic can be specified. As soon as
> it gets approved, I will post a link where you can use testflight for you
> to test it and see if it works as expected.
>
> On Sunday, December 6, 2020 at 7:42:20 PM UTC-5 bell...@gmail.com wrote:
>
>> This looks really cool. I too am anxiously awaiting to be able to specify
>> the topic.  In my case, I am publishing json loop data to weather/loop,
>> json archive data to weather/archive, both to weather/looparchive.  So if I
>> could specify something like weather/loop-individual/#... but I could
>> easily publish to almost anything but weather/#.
>> Again, thanks for sharing! If I can help in any way, let me know.
>> rich
>>
>> On Sunday, 6 December 2020 at 18:37:04 UTC-5 blu...@gmail.com wrote:
>>
>>> Ok understood; my topics are published as weather/corbett and
>>> weather/williams for different locations.  I look forward to that
>>> enhancement!  This looks like a cool app.
>>>
>>> On Dec 6, 2020, at 3:27 PM, Constantine Samaklis 
>>> wrote:
>>>
>>> Currently no. It defaults to weather/#. The gauges are also limited to
>>> the topics published by the MQTT extension so for example if you have
>>> configured the extension to run in metric, you will
>>> have weather/windchill_C for windchill and if you have it configured for
>>> imperial units, then it will listen for weather/windchill_F.
>>>
>>>
>>> The pattern is similar across all the available gauges.
>>>
>>> I have also left some topics as soil alarm and other alarm ones out, as
>>> they are present only in professional weather stations such as Vantage Pro,
>>> and have not seen them used, outside of farming applications. (On my todo
>>> list at some point though.)
>>>
>>> On Sunday, December 6, 2020 at 6:15:19 PM UTC-5 blu...@gmail.com wrote:
>>>
>>>> I love this!  Is there a way to change the topic name to look for?
>>>>
>>>> On Dec 6, 2020, at 12:42 PM, Christopher Joseph Alemany <
>>>> chri...@gmail.com> wrote:
>>>>
>>>> Very cool! Thank you Constantine and great work!  I’ll install the
>>>> mqtt extension just for this. Consider this friendly and appreciative
>>>> encouragement to port it to Swift!
>>>>
>>>>
>>>> Cheers
>>>> Chris
>>>> www.Alberniweather.ca
>>>> “They always tell me it takes time. How much more time do you
>>>> want...for your progress?”
>>>> James Baldwin
>>>>
>>>> Chris Alemany
>>>> 3854 6th Ave
>>>> Port Alberni, BC
>>>> V9Y4M2
>>>> h:250-723-0889
>>>> w: 250-753-3245 x2106 <250-753-3245;2106>
>>>> e: chri...@gmail.com
>>>> w: www.chrisalemany.ca
>>>> w: www.alberniweather.ca
>>>> w: www.vifreightbyrail.ca
>>>>
>>>> On Dec 6, 2020, at 08:30, Constantine Samaklis 
>>>> wrote:
>>>>
>>>> I have been using WeeWX for seven years or so and I have been inspired
>>>> by the work that Tom and others have put into making this software better
>>>> and also expandable.
>>>>
>>>> Ever since I added the MQTT extension to WeeWX I was able to
>>>> incorporate live weather data from my Vantage Pro weather station, which I
>>>> think it is very cool.
>>>>
>>>> I wanted to give back something to the community, so I spent some time
>>>> writing a GUI in Pythonista on my iPad, and I have ported it over to the
>>>> Apple store as a free application, in hopes that it can be useful to
>>>> others.
>>>>
>>>> I am always mesmerized by moving dials and I also find that the
>>>> application, apart from giving you quick access to your weather station's
>>>> data, it looks quite good as a make shift screen, especially on larger iPad
>>>> screens. :-)
>>>>
>>>> You can fetch the application from the app store from the below link or
>>>> look for "weather mqtt"
>>>>
>>>> https://apps.apple.com/us/app/weather-mqtt/id1542679289
>>>>
>>>> I have also put together a qui

Re: [weewx-user] Live weather on iOS

2020-12-07 Thread Constantine Samaklis 
I have submitted a new build where the topic can be specified. As soon as 
it gets approved, I will post a link where you can use testflight for you 
to test it and see if it works as expected.

On Sunday, December 6, 2020 at 7:42:20 PM UTC-5 bell...@gmail.com wrote:

> This looks really cool. I too am anxiously awaiting to be able to specify 
> the topic.  In my case, I am publishing json loop data to weather/loop, 
> json archive data to weather/archive, both to weather/looparchive.  So if I 
> could specify something like weather/loop-individual/#... but I could 
> easily publish to almost anything but weather/#. 
> Again, thanks for sharing! If I can help in any way, let me know.
> rich
>
> On Sunday, 6 December 2020 at 18:37:04 UTC-5 blu...@gmail.com wrote:
>
>> Ok understood; my topics are published as weather/corbett and 
>> weather/williams for different locations.  I look forward to that 
>> enhancement!  This looks like a cool app.  
>>
>> On Dec 6, 2020, at 3:27 PM, Constantine Samaklis  
>> wrote:
>>
>> Currently no. It defaults to weather/#. The gauges are also limited to 
>> the topics published by the MQTT extension so for example if you have 
>> configured the extension to run in metric, you will 
>> have weather/windchill_C for windchill and if you have it configured for 
>> imperial units, then it will listen for weather/windchill_F.
>>
>>
>> The pattern is similar across all the available gauges. 
>>
>> I have also left some topics as soil alarm and other alarm ones out, as 
>> they are present only in professional weather stations such as Vantage Pro, 
>> and have not seen them used, outside of farming applications. (On my todo 
>> list at some point though.)
>>
>> On Sunday, December 6, 2020 at 6:15:19 PM UTC-5 blu...@gmail.com wrote:
>>
>>> I love this!  Is there a way to change the topic name to look for? 
>>>
>>> On Dec 6, 2020, at 12:42 PM, Christopher Joseph Alemany <
>>> chri...@gmail.com> wrote:
>>>
>>> Very cool! Thank you Constantine and great work!  I’ll install the mqtt 
>>> extension just for this. Consider this friendly and appreciative 
>>> encouragement to port it to Swift! 
>>>
>>>
>>> Cheers
>>> Chris
>>> www.Alberniweather.ca
>>> “They always tell me it takes time. How much more time do you want...for 
>>> your progress?”
>>> James Baldwin
>>>
>>> Chris Alemany
>>> 3854 6th Ave
>>> Port Alberni, BC
>>> V9Y4M2
>>> h:250-723-0889
>>> w: 250-753-3245 x2106 <250-753-3245;2106>
>>> e: chri...@gmail.com
>>> w: www.chrisalemany.ca
>>> w: www.alberniweather.ca
>>> w: www.vifreightbyrail.ca
>>>
>>> On Dec 6, 2020, at 08:30, Constantine Samaklis  
>>> wrote:
>>>
>>> I have been using WeeWX for seven years or so and I have been inspired 
>>> by the work that Tom and others have put into making this software better 
>>> and also expandable.
>>>
>>> Ever since I added the MQTT extension to WeeWX I was able to incorporate 
>>> live weather data from my Vantage Pro weather station, which I think it is 
>>> very cool.
>>>
>>> I wanted to give back something to the community, so I spent some time 
>>> writing a GUI in Pythonista on my iPad, and I have ported it over to the 
>>> Apple store as a free application, in hopes that it can be useful to 
>>> others. 
>>>
>>> I am always mesmerized by moving dials and I also find that the 
>>> application, apart from giving you quick access to your weather station's 
>>> data, it looks quite good as a make shift screen, especially on larger iPad 
>>> screens. :-)
>>>
>>> You can fetch the application from the app store from the below link or 
>>> look for "weather mqtt" 
>>>
>>> https://apps.apple.com/us/app/weather-mqtt/id1542679289 
>>>
>>> I have also put together a quick user guide at; 
>>> https://www.samaklis.com/confluence/display/WEAT/2020/12/05/Weather+MQTT+Support
>>>  
>>>
>>> PS The application is a port from Python to Objective C, so you may 
>>> experience a crash from time to time as it is not OS native. I am in the 
>>> process of looking into SWIFT and in time, based on community interest, I 
>>> will try and put some work on porting the application to it. so it is iOS 
>>> native.
>>>
>>> Thanks again to all the weather enthusiasts out there that make 
>>&

[weewx-user] Re: Sunrise/Sunset times off on Vantage Pro 2

2020-07-01 Thread Constantine Samaklis 
Thanks for taking the time and putting in the effort to troubleshoot.

On Tuesday, June 30, 2020 at 8:47:25 AM UTC-4, Jacques Terrettaz wrote:
>
> HI,
>
> I checked with my Davis station and I am observing exactly the same kind 
> of differences. I think the problem is coming from the vantage weewx driver 
> :
>
> Here are my data concerning sunrise :
>
>- the console displays 05:46 for sunrise. This is correct
>- the raw loop data for sunrise, as received by Weewx , is 546 
>- weewx vantage driver is converting the raw loop data into seconds 
>using this function 
>'sunrise' : lambda p, k: 3600 * (p[k] / 100) + 60 * (p[k] % 100
>),
> giving :  3600 * (546/100) + 60 * 46 =* 22416*.   This is wrong, it 
>should be 3600 * (*500*/100) + 60 * 46 = *20760*
>
> Should the right formulas be :
> 'sunrise' : lambda p, k: 3600 * (p[k] // 100) + 60 * (p[k] % 100),
> 'sunset'  : lambda p, k: 3600 * (p[k] // 100) + 60 * (p[k] % 100),
>
>
> ?
>
>
> Le mardi 30 juin 2020 13:03:37 UTC+2, Constantine Samaklis a écrit :
>>
>> I did what you suggested (settings where fine to begin with) but still 
>> getting 20min discrepancies which are not explained by the loss of accuracy 
>> on the lon/lat.
>>
>> Wondering what to try next.
>>
>> On Tuesday, June 30, 2020 at 6:44:53 AM UTC-4, gjr80 wrote:
>>>
>>> No problems, it's just that sunrise/sunset can come from up to three 
>>> different sources and you need to to know which source is the problem in 
>>> order to troubleshoot.
>>>
>>> You are right that the sunrise/sunset in loop packets comes from the 
>>> console.  So in this case pyephem does not come into play nor does the 
>>> lat/long settings in weewx.conf. You need to check/set the lat/long 
>>> settings in your console, either via the console buttons or through use of 
>>> the wee_device <http://weewx.com/docs/hardware.htm#vantage_notes> 
>>> utility (note the if using wee_device you need to stop WeeWX first). From 
>>> memory the console (via buttons or wee_device) accepts decimal degrees with 
>>> a max resolution of 0.1 degree. Not sure a 0.1 degree resolution should 
>>> result in an inaccuracy of 20+ minutes though. 
>>>
>>> Gary
>>>
>>> On Tuesday, 30 June 2020 20:19:21 UTC+10, Constantine Samaklis wrote:
>>>>
>>>> My bad, I should have been more thorough with details. I was under the 
>>>> impression that the sunrise/sunset times were provided directly by the 
>>>> Davis console and not calculated.
>>>>
>>>> The values I am getting are coming from the LOOP when running weewxd
>>>>
>>>> LOOP:   2020-06-30 06:07:56 EDT (1593511676) altimeter: 
>>>> 29.887106231687923, barometer: 29.88, cloudbase: 1238.2237428350452, 
>>>> consBatteryVoltage: 3.75, dateTime: 1593511676, dayET: 0.0, dayRain: 0.0, 
>>>> dewpoint: 64.5434155315258, extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 
>>>> 0, 
>>>> extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, 
>>>> extraAlarm8: 0, forecastIcon: 6, forecastRule: 45, heatindex: 69.6, 
>>>> inDewpoint: 45.1326136300073, inHumidity: 53.0, insideAlarm: 0, inTemp: 
>>>> 62.5, leafWet4: 0.0, monthET: 0.0, monthRain: 1.89, outHumidity: 84.0, 
>>>> outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 69.6, pressure: 
>>>> 29.788405301826174, rain: 0.0, rainAlarm: 0, rainRate: 0.0, 
>>>> soilLeafAlarm1: 
>>>> 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0, stormRain: 
>>>> 0.0, 
>>>> sunrise: 1593510480.0, sunset: 1593564480.0, txBatteryStatus: 0, 
>>>> usUnits: 1, windchill: 69.6, windDir: None, windGust: 0.0, windGustDir: 
>>>> None, windSpeed: 0.0, windSpeed10: 1.0, yearET: 0.0, yearRain: 14.08
>>>>
>>>> I do have the following version of ephem: python3-ephem 
>>>>3.7.6.0-7+b1 
>>>>
>>>> Weewx is running on Python 3.7 
>>>>
>>>> # Latitude and longitude in decimal degrees
>>>> latitude = 40.624573
>>>> longitude = -74.012931
>>>>
>>>> On Monday, June 29, 2020 at 10:23:36 PM UTC-4, gjr80 wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I think we need to sort the apples from the oranges and bananas. 
>>>>> Exactly what are you showing us? Is that the sunrise/sunset times as 
>>>>> displayed on the console

Re: [weewx-user] Re: Sunrise/Sunset times off on Vantage Pro 2

2020-07-01 Thread Constantine Samaklis 
Thanks Gary. I have an application that reads the console values which are
pushed to a Mosquitto MQTT server in real time so this will address the
issue until the update is out.

On Wed, Jul 1, 2020 at 01:20 gjr80  wrote:

> Just to close this off I installed the updated vantage driver on my system
> and sunrise/sunset from the console is spot on today. If the anomaly
> bothers you and you can't wait for 4.1.2 to be released you can download
> the patched vantage driver here
> .
> Just use
>
> $ wget -P /var/tmp https://
> raw.githubusercontent.com/weewx/weewx/master/bin/weewx/drivers/vantage.py
>
> to download to /var/tmp and then copy in place of the existing driver (
> /home/weewx/bin/weewx/drivers/vantage.py or
> /usr/share/weewx/weewx/drivers/vantage.py) and restart WeeWX. You will
> need to run WeeWX directly and observer the sunrise/sunset values in the
> loop packets or use some other means to view the loop data as WeeWX does
> not normally display/use the console provided sunrise/sunset times.
>
> Gary
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/5IZfZge3RxU/unsubscribe.
> To unsubscribe from this group and all its topics, 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/672bf2e7-4403-47d9-8bef-5a763ae618f1o%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/CA%2BKRpVwnQ4XZvGr6nc3vdnD5%2BFGvxAnsNFgwys14a6iSqaENfw%40mail.gmail.com.

[weewx-user] Re: Sunrise/Sunset times off on Vantage Pro 2

2020-06-30 Thread Constantine Samaklis 
I did what you suggested (settings where fine to begin with) but still 
getting 20min discrepancies which are not explained by the loss of accuracy 
on the lon/lat.

Wondering what to try next.

On Tuesday, June 30, 2020 at 6:44:53 AM UTC-4, gjr80 wrote:
>
> No problems, it's just that sunrise/sunset can come from up to three 
> different sources and you need to to know which source is the problem in 
> order to troubleshoot.
>
> You are right that the sunrise/sunset in loop packets comes from the 
> console.  So in this case pyephem does not come into play nor does the 
> lat/long settings in weewx.conf. You need to check/set the lat/long 
> settings in your console, either via the console buttons or through use of 
> the wee_device <http://weewx.com/docs/hardware.htm#vantage_notes> utility 
> (note the if using wee_device you need to stop WeeWX first). From memory 
> the console (via buttons or wee_device) accepts decimal degrees with a max 
> resolution of 0.1 degree. Not sure a 0.1 degree resolution should result in 
> an inaccuracy of 20+ minutes though. 
>
> Gary
>
> On Tuesday, 30 June 2020 20:19:21 UTC+10, Constantine Samaklis wrote:
>>
>> My bad, I should have been more thorough with details. I was under the 
>> impression that the sunrise/sunset times were provided directly by the 
>> Davis console and not calculated.
>>
>> The values I am getting are coming from the LOOP when running weewxd
>>
>> LOOP:   2020-06-30 06:07:56 EDT (1593511676) altimeter: 
>> 29.887106231687923, barometer: 29.88, cloudbase: 1238.2237428350452, 
>> consBatteryVoltage: 3.75, dateTime: 1593511676, dayET: 0.0, dayRain: 0.0, 
>> dewpoint: 64.5434155315258, extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 0, 
>> extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, 
>> extraAlarm8: 0, forecastIcon: 6, forecastRule: 45, heatindex: 69.6, 
>> inDewpoint: 45.1326136300073, inHumidity: 53.0, insideAlarm: 0, inTemp: 
>> 62.5, leafWet4: 0.0, monthET: 0.0, monthRain: 1.89, outHumidity: 84.0, 
>> outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 69.6, pressure: 
>> 29.788405301826174, rain: 0.0, rainAlarm: 0, rainRate: 0.0, soilLeafAlarm1: 
>> 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0, stormRain: 0.0, 
>> sunrise: 1593510480.0, sunset: 1593564480.0, txBatteryStatus: 0, 
>> usUnits: 1, windchill: 69.6, windDir: None, windGust: 0.0, windGustDir: 
>> None, windSpeed: 0.0, windSpeed10: 1.0, yearET: 0.0, yearRain: 14.08
>>
>> I do have the following version of ephem: python3-ephem   
>>  3.7.6.0-7+b1 
>>
>> Weewx is running on Python 3.7 
>>
>> # Latitude and longitude in decimal degrees
>> latitude = 40.624573
>> longitude = -74.012931
>>
>> On Monday, June 29, 2020 at 10:23:36 PM UTC-4, gjr80 wrote:
>>>
>>> Hi,
>>>
>>> I think we need to sort the apples from the oranges and bananas. Exactly 
>>> what are you showing us? Is that the sunrise/sunset times as displayed on 
>>> the console or as displayed in loop packet/archive record or as returned by 
>>> a tag in a report? What latitude/longitude do you have set in your console 
>>> and in weewx.conf? Do you have pyephem installed for the version of 
>>> python that WeeWX is being run under?
>>>
>>> Sorry for the questions, but it's a bit like the 'pressures'; there are 
>>> a number of moving parts to this and unless you know exactly what is being 
>>> looked at it is hard to give a meaningful answer.
>>>
>>> Gary
>>>
>>>
>>>
>>>
>>> On Tuesday, 30 June 2020 11:16:33 UTC+10, Constantine Samaklis wrote:
>>>>
>>>> Wondering if anyone is having the same issue. In the last 3-4 days my 
>>>> Vantage pro is showing the wrong sunrise and sunset times. I am in NY and 
>>>> the console is set to EST daylight savings and the current time value is 
>>>> displayed correctly. 
>>>>
>>>> For sunset I get: 1593478080, which is 8:48PM EST and for sunrise I 
>>>> get: 1593424080 which is 5:48am EST.
>>>>
>>>> These timings are off by 20+ minutes. Not sure if this is something 
>>>> that anyone else is experiencing. 
>>>>
>>>

-- 
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/9deecd62-c5bc-4095-8ccf-6f0bcbf7f0e2o%40googlegroups.com.

[weewx-user] Re: Sunrise/Sunset times off on Vantage Pro 2

2020-06-30 Thread Constantine Samaklis 
My bad, I should have been more thorough with details. I was under the 
impression that the sunrise/sunset times were provided directly by the 
Davis console and not calculated.

The values I am getting are coming from the LOOP when running weewxd

LOOP:   2020-06-30 06:07:56 EDT (1593511676) altimeter: 29.887106231687923, 
barometer: 29.88, cloudbase: 1238.2237428350452, consBatteryVoltage: 3.75, 
dateTime: 1593511676, dayET: 0.0, dayRain: 0.0, dewpoint: 64.5434155315258, 
extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 0, extraAlarm4: 0, 
extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, extraAlarm8: 0, 
forecastIcon: 6, forecastRule: 45, heatindex: 69.6, inDewpoint: 
45.1326136300073, inHumidity: 53.0, insideAlarm: 0, inTemp: 62.5, leafWet4: 
0.0, monthET: 0.0, monthRain: 1.89, outHumidity: 84.0, outsideAlarm1: 0, 
outsideAlarm2: 0, outTemp: 69.6, pressure: 29.788405301826174, rain: 0.0, 
rainAlarm: 0, rainRate: 0.0, soilLeafAlarm1: 0, soilLeafAlarm2: 0, 
soilLeafAlarm3: 0, soilLeafAlarm4: 0, stormRain: 0.0, sunrise: 1593510480.0, 
sunset: 1593564480.0, txBatteryStatus: 0, usUnits: 1, windchill: 69.6, 
windDir: None, windGust: 0.0, windGustDir: None, windSpeed: 0.0, 
windSpeed10: 1.0, yearET: 0.0, yearRain: 14.08

I do have the following version of ephem: python3-ephem 
   3.7.6.0-7+b1 

Weewx is running on Python 3.7 

# Latitude and longitude in decimal degrees
latitude = 40.624573
longitude = -74.012931

On Monday, June 29, 2020 at 10:23:36 PM UTC-4, gjr80 wrote:
>
> Hi,
>
> I think we need to sort the apples from the oranges and bananas. Exactly 
> what are you showing us? Is that the sunrise/sunset times as displayed on 
> the console or as displayed in loop packet/archive record or as returned by 
> a tag in a report? What latitude/longitude do you have set in your console 
> and in weewx.conf? Do you have pyephem installed for the version of 
> python that WeeWX is being run under?
>
> Sorry for the questions, but it's a bit like the 'pressures'; there are a 
> number of moving parts to this and unless you know exactly what is being 
> looked at it is hard to give a meaningful answer.
>
> Gary
>
>
>
>
> On Tuesday, 30 June 2020 11:16:33 UTC+10, Constantine Samaklis wrote:
>>
>> Wondering if anyone is having the same issue. In the last 3-4 days my 
>> Vantage pro is showing the wrong sunrise and sunset times. I am in NY and 
>> the console is set to EST daylight savings and the current time value is 
>> displayed correctly. 
>>
>> For sunset I get: 1593478080, which is 8:48PM EST and for sunrise I get: 
>> 1593424080 which is 5:48am EST.
>>
>> These timings are off by 20+ minutes. Not sure if this is something that 
>> anyone else is experiencing. 
>>
>

-- 
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/20e36ef4-2d97-4b49-9064-44820203d815o%40googlegroups.com.

[weewx-user] Sunrise/Sunset times off on Vantage Pro 2

2020-06-29 Thread Constantine Samaklis 
Wondering if anyone is having the same issue. In the last 3-4 days my 
Vantage pro is showing the wrong sunrise and sunset times. I am in NY and 
the console is set to EST daylight savings and the current time value is 
displayed correctly. 

For sunset I get: 1593478080, which is 8:48PM EST and for sunrise I get: 
1593424080 which is 5:48am EST.

These timings are off by 20+ minutes. Not sure if this is something that 
anyone else is experiencing. 

-- 
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/bc84ce53-f40e-4e05-bed7-99a3a7acb2eao%40googlegroups.com.

[weewx-user] Re: Davis Vantage Pro 2 no cloudbase reading

2020-06-29 Thread Constantine Samaklis 
First off, thanks cause that worked :-) 
I do keep a copy of all my weewx.conf in svn and my Calculations section 
had not changed, which is odd...
This is what I had before adding the line you suggested:

[image: Capture.PNG]




On Monday, June 29, 2020 at 6:09:51 PM UTC-4, gjr80 wrote:
>
> Ok, here is the clue:
>
> Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.wxservices: The 
> following values will be calculated: pressure=prefer_hardware, 
> barometer=prefer_hardware, altimeter=prefer_hardware, 
> windchill=prefer_hardware, heatindex=prefer_hardware, 
> dewpoint=prefer_hardware, inDewpoint=prefer_hardware, 
> rainRate=prefer_hardware
>
> StdWXCalculate is not set to calculate cloudbase for some reason 
> (cloudbase is usually calculated by WeeWX not the station/driver). Have a 
> look at [StdWXCalculate] [[Calculations]] in weewx.conf, is there any entry 
> for cloudbase? If not add one, something like:
>
> cloudbase = prefer_hardware
>
> Save weewx.conf and restart WeeWX (probably easiest to check at first by 
> running WeeWX directly). If a cloudbase entry does exist please post a copy 
> of your [Calculations] stanza.
>
> 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/5049bf38-8c24-44ec-b064-959f73ca232co%40googlegroups.com.

[weewx-user] Re: Davis Vantage Pro 2 no cloudbase reading

2020-06-29 Thread Constantine Samaklis 
Not sure if this is any help but nonetheless here you go. (I have just 
taken out personal weather station info)

Jun 29 17:53:48 raspberrypi weewx[25047] INFO __main__: Initializing weewx 
version 4.1.1
Jun 29 17:53:48 raspberrypi weewx[25047] INFO __main__: Using Python 3.7.3 
(default, Dec 20 2019, 18:57:59) #012[GCC 8.3.0]
Jun 29 17:53:48 raspberrypi weewx[25047] INFO __main__: Platform 
Linux-4.19.118-v7l+-armv7l-with-debian-10.4
Jun 29 17:53:48 raspberrypi weewx[25047] INFO __main__: Locale is 
'en_US.UTF-8'
Jun 29 17:53:48 raspberrypi weewx[25047] INFO __main__: PID file is 
/var/run/weewx.pid
Jun 29 17:53:48 raspberrypi weewx[25051] INFO __main__: Using configuration 
file /home/weewx/weewx.conf
Jun 29 17:53:48 raspberrypi weewx[25051] INFO __main__: Debug is 1
Jun 29 17:53:48 raspberrypi weewx[25051] INFO weewx.engine: Loading station 
type Vantage (weewx.drivers.vantage)
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: StdConvert 
target unit is 0x1
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.wxservices: The 
following values will be calculated: pressure=prefer_hardware, 
barometer=prefer_hardware, altimeter=prefer_hardware, 
windchill=prefer_hardware, heatindex=prefer_hardware, 
dewpoint=prefer_hardware, inDewpoint=prefer_hardware, 
rainRate=prefer_hardware
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.wxservices: The 
following algorithms will be used for calculations: altimeter=aaASOS, 
maxSolarRad=RS
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Archive will 
use data binding wx_binding
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Record 
generation will be attempted in 'hardware'
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Using archive 
interval of 300 seconds (specified by hardware)
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: StationRegistry: 
Station will be registered.
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: Wunderground-RF: 
Data for station XXX will be posted
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: PWSweather: 
Posting not enabled.
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: CWOP: Data for 
station XXX will be posted
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: WOW: Posting not 
enabled.
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.restx: AWEKAS: Posting 
not enabled.
Jun 29 17:53:49 raspberrypi weewx[25051] INFO user.mqtt: service version is 
0.23
Jun 29 17:53:49 raspberrypi weewx[25051] INFO user.mqtt: binding to loop
Jun 29 17:53:49 raspberrypi weewx[25051] INFO user.mqtt: topic is weather
Jun 29 17:53:49 raspberrypi weewx[25051] INFO user.mqtt: desired unit 
system is METRIC
Jun 29 17:53:49 raspberrypi weewx[25051] INFO user.mqtt: data will be 
uploaded to mqtt://weewx:xxx@localhost:1883/
Jun 29 17:53:49 raspberrypi /weewxd: alarm: Alarm set for expression: 
'outTemp < 32.0 or outTemp > 95.0 or windchill < 14.0 or heatindex > 100.4'
Jun 29 17:53:49 raspberrypi weewx[25051] INFO __main__: Starting up weewx 
version 4.1.1
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Clock error is 
0.73 seconds (positive is fast)
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Using binding 
'wx_binding' to database 'weewx'
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.manager: Starting 
backfill of daily summaries
Jun 29 17:53:49 raspberrypi weewx[25051] INFO weewx.engine: Starting main 
packet loop.
Jun 29 17:55:16 raspberrypi weewx[25051] INFO weewx.manager: Added record 
2020-06-29 17:55:00 EDT (1593467700) to database 'weewx'
Jun 29 17:55:16 raspberrypi weewx[25051] INFO weewx.manager: Added record 
2020-06-29 17:55:00 EDT (1593467700) to daily summary in 'weewx'
Jun 29 17:55:16 raspberrypi weewx[25051] INFO weewx.restx: CWOP: Published 
record 2020-06-29 17:55:00 EDT (1593467700)
Jun 29 17:55:17 raspberrypi weewx[25051] INFO weewx.restx: StationRegistry: 
Published record 2020-06-29 17:55:00 EDT (1593467700)
Jun 29 17:55:19 raspberrypi weewx[25051] INFO weewx.cheetahgenerator: 
Generated 14 files for report StandardReport in 3.01 seconds
Jun 29 17:55:20 raspberrypi weewx[25051] INFO weewx.imagegenerator: 
Generated 12 images for report StandardReport in 0.63 seconds
Jun 29 17:55:20 raspberrypi weewx[25051] INFO weewx.reportengine: Copied 14 
files to /home/weewx/../../var/log/public_html

On Monday, June 29, 2020 at 6:52:45 AM UTC-4, Constantine Samaklis wrote:
>
> Hi,
>
> My Davis Vantage Pro 2 has stopped reporting cloudbase readings. Stopping 
> weewx and running weewxd confirms as per below loop:
>
> LOOP:   2020-06-29 06:49:05 EDT (1593427745) altimeter: 
> 29.799844642173294, barometer: 29.793, consBatteryVoltage: 4.2, dateTime: 
> 1593427745, dayET: 0.0, dayRain: 0.0, dewpoint: 66.4241691277547, 
> extraAlarm1: 0, extraAlarm2: 0, extraAlarm3: 0, extraAlarm4: 0, 
> extraAlarm5: 0, extraAlarm6: 0, extraAlarm7: 0, extraAlarm8: 0, 
> for

[weewx-user] Davis Vantage Pro 2 no cloudbase reading

2020-06-29 Thread Constantine Samaklis 
Hi,

My Davis Vantage Pro 2 has stopped reporting cloudbase readings. Stopping 
weewx and running weewxd confirms as per below loop:

LOOP:   2020-06-29 06:49:05 EDT (1593427745) altimeter: 29.799844642173294, 
barometer: 29.793, consBatteryVoltage: 4.2, dateTime: 1593427745, dayET: 
0.0, dayRain: 0.0, dewpoint: 66.4241691277547, extraAlarm1: 0, extraAlarm2: 
0, extraAlarm3: 0, extraAlarm4: 0, extraAlarm5: 0, extraAlarm6: 0, 
extraAlarm7: 0, extraAlarm8: 0, forecastIcon: 3, forecastRule: 192, 
heatindex: 72.6, inDewpoint: 45.16123986940858, inHumidity: 54.0, 
insideAlarm: 0, inTemp: 62.0, leafWet4: 0.0, monthET: 0.0, monthRain: 1.89, 
outHumidity: 81.0, outsideAlarm1: 0, outsideAlarm2: 0, outTemp: 72.6, 
pressure: 29.701380980145647, rain: 0.0, rainAlarm: 0, rainRate: 0.0, 
soilLeafAlarm1: 0, soilLeafAlarm2: 0, soilLeafAlarm3: 0, soilLeafAlarm4: 0, 
stormRain: 0.06, stormStart: 1593316800, sunrise: 1593423984.0, sunset: 
1593478080.0, txBatteryStatus: 0, usUnits: 1, windchill: 72.6, windDir: 
None, windGust: 0.0, windGustDir: None, windSpeed: 0.0, windSpeed10: 0.0, 
yearET: 0.0, yearRain: 14.08

Any ideas on how to resolve this? 

Thanks,

-- 
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/603c8ef7-0267-489f-941f-410cf29cfb91o%40googlegroups.com.

Re: [weewx-user] Re: Small Python 'daemon' script to check if weewx is running

2020-06-19 Thread Constantine Samaklis 
Yes, that is correct. The idea is that there is something really going
wrong if you have this happening multiple times. (You can bypass that by
setting the restarts in the config to a higher number but I would not
advise to do so)

If it is a one off, then resetting the number in the flag file to 0 would
work best and is a safer approach.

On Fri, Jun 19, 2020 at 5:04 PM James Bellanca  wrote:

> I know this threads a little old, but thanks for the script. I just
> implemented it now.
>
> It appears that after it detects WeeWx is down, it restarts it, but then
> leaves the weewxNotRunning.txt file out there with the number of retries in
> it. So, say it has to restart WeeWx, successfully does so, and a week later
> does it again, etc. After the 3rd week, because it counts as a "retry" and
> the file's left out there, it will stop. So, in other words, you have to
> know, if you get the email, make sure you go out there and delete
> the weewxNotRunning.txt manually to reset the counter, or it'll stop
> working after the 3rd time it happens. I'm not missing anything, right?
>
>
> On Friday, September 13, 2013 at 7:44:28 PM UTC-4, Constantine Samaklis
> wrote:
>>
>> I thought I would give something back to the group since I have gotten
>> good help to my questions. I have created a Python utility script that can
>> be ran periodically (cron?) to check if weewx is running and if it is not,
>> it will send out an email with a number of lines from the end of the log
>> (/var/log/messages, or whatever log you want) that would show the error
>> that weewx encountered. The script will try to restart weex a number of pre
>> configurable times, in case the error was a fluke rather than a fatal one.
>>
>> The script will stop trying to send messages after it has reached the
>> indicated *restarts* times in the configuration times, and you will need
>> to delete the *flagFile* that has been created. (or write a 0 in it).
>> The script has a configurable log rotation, where you can indicate the log
>> rotation interval (in days) and the days of logs to keep.
>>
>> *logOutput* is the temporary tail of the messages log (or could be the
>> syslog or whatever you specify) that will be emailed as an attachment if
>> weewx is found not to be running.
>>
>> I hope everyone finds this somewhat useful. If you are somewhat paranoid
>> about your weather station being up 24/7 like me then you probably will. :-)
>>
>> Questions and comments are welcome.
>>
>>
>> #configuration file for checking routine
>> [mail]
>> fromaddr=us...@gmail.com
>> toaddr=tou...@gmail.com
>> msgSubj=weewx process is not running
>> body=weewx process is not running. Please check the attached log and
>> address the issue
>> userName=gmailu...@gmail.com
>> password=yourPwd
>> smtpServer=smtp.gmail.com:587
>>
>> [logging]
>> logDir=/home/user/scripts
>> logFile=checkWeewx.log
>> logOutput=tail.log
>> linesToTail=200
>> logToTail=/var/log/messages
>> logRotationDayInterval=1
>> logDaysToKeep=5
>>
>> [weewx]
>> #how many times to try and restart the weewx process
>> restarts=3
>> flagLogDir=/home/user/scripts
>> flagFile=weewxNotRunning.txt
>> startCommand=sudo /etc/init.d/weewx start
>>
>> You can launch the script by typing: Python ./checkWeewx.py
>> /pathToConfigFile/checkWeewx.config
>>
>> The configuration format:
>>
>> #configuration file for checking routine
>> [mail]
>> fromaddr=us...@gmail.com
>> toaddr=tou...@gmail.com
>> msgSubj=weewx process is not running
>> body=weewx process is not running. Please check the attached log and
>> address the issue
>> userName=gmailu...@gmail.com
>> password=yourPwd
>> smtpServer=smtp.gmail.com:587
>>
>> [logging]
>> logDir=/home/user/scripts
>> logFile=checkWeewx.log
>> logOutput=tail.log
>> linesToTail=200
>> logToTail=/var/log/messages
>> logRotationDayInterval=1
>> logDaysToKeep=5
>>
>> [weewx]
>> #how many times to try and restart the weewx process
>> restarts=3
>> flagLogDir=/home/user/scripts
>> flagFile=weewxNotRunning.txt
>> startCommand=sudo /etc/init.d/weewx start
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/9yskDGu9vI0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@googlegroups.com.
> To view t

Re: [weewx-user] Re: Small Python 'daemon' script to check if weewx is running

2019-04-30 Thread Constantine Samaklis 
You are definitely on the right path :-)

On Tue, Apr 30, 2019 at 6:11 PM Leon Shaner  wrote:

> Hi, hi,
>
> I didn't look at the mechanics of the script too closely, but before you
> had shown:
>
> flagLogDir=/home/pliggen/scripts
>
> And just now you showed:
>
> logOutput=/var/log/syslog.txt
>
> Which I glean from the error is being concatenated to:
>
>  /home/pliggen/scripts//var/log/syslog.txt
>
> And that can't work if you don't first "mkdir -p  
> /home/pliggen/scripts//var/log/"
> except I doubt very much you really want such a convoluted path down to the
> checkWeewx.log.  ;-)
>
> If you want to keep the log in your home dir, you probably want:
>
> logOutput=checkWeewx.log
>
> But it will be owned by root in your home dir.
>
> I wouldn't be messing with the syslog directly, but if you want the
> checkWeewx.log to be next to syslog, you could do this:
>
> flagLogDir=/var/log
> logOutput=checkWeewx.log
>
> So if I have gleaned correctly, that will give you a log owned by root,
> here:
>
> /var/log/checkWeewx.log
>
> The author of the script can validate the above, if I have it right or
> wrong.  ;-)
>
> Regards,
> Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On Apr 30, 2019, at 5:10 PM, pliggen...@gmail.com wrote:
>
> Hi Leon,
>
> and thanks for the help! I was running my own non-root crontab. So I tried
> to put the command in sudo crontab -e.
> Stopped the service and tried it and now the service started as expected.
> Great! And it worked with /etc/init.d/weewx start as startcommand.
> I'm not sure I understood everything you wrote, I'm quite new at this, but
> you made it clear what to try.
>
> One more question, it seems that when I run it via sudo crontab there were
> some issue with the logging,
> hade to remove home/pliggen/scripts from the "logDir=" line.
>
> Got this email message:
>
> sh: 1: cannot create /home/pliggen/scripts//var/log/syslog.txt: Directory
> nonexistent
> Starting program...
> Traceback (most recent call last):
>  File "/var/www/html/scripts/checkWeewx/checkWeewx.py", line 159, in
> 
>sendMailFailure(logDir + "/" + logOutput, config, additionalText)
>  File "/var/www/html/scripts/checkWeewx/checkWeewx.py", line 86, in
> sendMailFailure
>f = file(filename)
> IOError: [Errno 2] No such file or directory:
> '/home/pliggen/scripts//var/log/syslog.txt'
>
>
> So I removed the logDir file-path so it looks like this now:
>
> [logging]
> logDir=
> logFile=checkWeewx.log
> logOutput=/var/log/syslog.txt
> linesToTail=200
> logToTail=/var/log/messages
> logRotationDayInterval=1
> logDaysToKeep=5
>
> And now I get this message in the email when the cronjob runs if the
> service is stopped:
>
> sh: echo: I/O error
> sh: echo: I/O error
> Starting program...
>
> It doesn't matter as long as the service now seems to start but if you see
> something obvious I'm glad to hear!
>
> Thanks, and sorry for my bad english.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/9yskDGu9vI0/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: Small Python 'daemon' script to check if weewx is running

2019-04-30 Thread Constantine Samaklis 
Correct. The script should be called from the root crontab as only root can 
start the weex service without getting prompted for a password. The command 
should be either service weewx start or systemctl start weewx

On Tuesday, April 30, 2019 at 3:46:18 PM UTC-4, Leon Shaner wrote:
>
> Hi, hi,
>
> The sudo implies you have this in your own / non-root crontab.  Is that 
> correct?
> If instead, you use "sudo crontab -e" so root is calling your script, then 
> you can omit the sudo in the script.  That much alone may be the solution 
> to your problem.
>
> Meanwhile, you didn't say what OS you're running, but on newer systems, 
> those RC / init.d scripts are often presented via legacy wrappers for use 
> by systemctl.  In that case the systemctl mechanism for restarting the 
> service might be less susceptible to foreground vs. background / 
> disconnected usage.   Meaning where you are using "sudo /etc/init.d/weewx 
> start" from command-line and it works, but doesn't work from cron, 
> substituting the systemctl equivalent may be a way out.
>
> You could try these from command line to verify your system has the legacy 
> RC / init.d wrappers, then substitute the the "sudo systemctl start weewx" 
> of calling the init.d script directly...
>
> Here again, however, putting any of these in a script that runs from the 
> root crontab will avoid needing to prefix with sudo...
>
> # Check status:
> $ sudo systemctl status weewx
>
> # Restart
> $ sudo systemctl restart weewx
>
> # Stop
> $ sudo systemctl stop weewx
>
> # Start
> $ sudo systemctl start weewx
>
> Regards,
> Leon
> --
> Leon Shaner :: Dearborn, Michigan (iPad Pro)
>
> On Apr 30, 2019, at 3:10 PM, plig...@gmail.com  wrote:
>
> I got this running as a cronjob, and I get a mail when weewx is not 
> running when the cronjob is executed. But I don't get the script to start 
> weewx again.
>
> This is the last part of checkweewx.config:
>
> [weewx]
> #how many times to try and restart the weewx process
> restarts=3
> flagLogDir=/home/pliggen/scripts
> flagFile=weewxNotRunning.txt
> startCommand=sudo /etc/init.d/weewx start
>
> If I run /etc/init.d/weewx start in terminal it starts.
> Any tips where to check to get this working?
>
> Den söndag 11 oktober 2015 kl. 02:45:50 UTC+2 skrev Constantine Samaklis:
>>
>> The script file and configuration file can be anywhere you want.
>>
>> You can launch the script by typing: python /checkWeewx.py 
>> /checkWeewx.config
>>
>> There are no changes required in the weewx.conf. You will need to just 
>> fill the pertinent information for your setup in checkWeewx.config as it is 
>> the configuration file that drives the python script.
>>
>> On Saturday, October 10, 2015 at 5:22:12 PM UTC-4, Arild Halvorsen wrote:
>>>
>>> This looks exciting. How do I implement this solution in weewx? Where do 
>>> I put the files. Which information is nødvenidig in weewx.conf?
>>>
>> -- 
> 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...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: discrepancies between min/max on archive vs _archive tables

2018-01-08 Thread Constantine Samaklis 
Yes, makes sense. Thanks Andrew.

On Mon, Jan 8, 2018 at 8:52 AM Andrew Milner <andrew.s.r.mil...@gmail.com>
wrote:

> Archive records the average value for the archive period.
>
> Daily tables record archive value OR loop value for max and min -
> depending on the setting in weewx.conf for loop_hilo (I think that is the
> correct name)
>
> Does that help??
>
>
>
> On Monday, 8 January 2018 15:39:09 UTC+2, Constantine Samaklis wrote:
>
>> Hi,
>>
>> I have been going through my data and have noticed some discrepancies in
>> extreme (min/max) values between the archive table and the
>> _archive tables
>>
>> For example:
>>
>> select min(`windchill`) from archive;
>>
>> gives me a value of -15.84
>>
>> but when doing the same query on archive_day_windchill
>>
>> select min(`min`) from archive_day_windchill;
>>
>> gives me a value of -19.10
>>
>> I am using a Vantage pro weather station.
>>
>> I am not sure if the archive table records the value at the preset
>> interval where the archive_day_windchill records the min/max values
>> independently on the interval, based on what the weather station pushes
>> out. (The vantage pro fires multiple times per min where my interval is set
>> to 10 min)
>>
>> Any insight would be very helpful.
>>
>> Thanks
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/WfvRegyKAJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] discrepancies between min/max on archive vs _archive tables

2018-01-08 Thread Constantine Samaklis 
Hi,

I have been going through my data and have noticed some discrepancies in 
extreme (min/max) values between the archive table and the 
_archive tables

For example:

select min(`windchill`) from archive; 

gives me a value of -15.84

but when doing the same query on archive_day_windchill

select min(`min`) from archive_day_windchill;

gives me a value of -19.10

I am using a Vantage pro weather station.

I am not sure if the archive table records the value at the preset interval 
where the archive_day_windchill records the min/max values independently on 
the interval, based on what the weather station pushes out. (The vantage 
pro fires multiple times per min where my interval is set to 10 min)

Any insight would be very helpful.

Thanks

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Re: [weewx-user] Re: wee_database backfill only a range of dates

2017-03-19 Thread Constantine Samaklis 
It turns out I had a backup dir of an older version and I was looking at
that version of the script. Probably a good reminder of not to look at
things late at night. :-)

Thank you for the replies.

On Sun, Mar 19, 2017 at 12:40 AM Andrew Milner <andrew.s.r.mil...@gmail.com>
wrote:

> Constantine - doesn't this (for current version [3.7] of weewx) do exactly
> what you require?
>
> http://weewx.com/docs/utilities.htm#wee_database_utility
>
> where in the documentation on the weewx website did you read otherwise?
>
>
> On Sunday, 19 March 2017 05:29:06 UTC+2, gjr80 wrote:
>
> Hi,
>
> On Sunday, 19 March 2017 13:14:11 UTC+10, Constantine Samaklis wrote:
>
> I am looking for a way to backfill a range of dates into my summary
> tables. When I look at the weewx website, the documentation states that you
> can do this with wee_database but it seems that the latest version of the
> utility only allows for a backfill where data is not present already in the
> aggregation tables.
>
>
> What makes you say this? One of the features of the 3.7.0 wee_database
> was that users could now rebuild a limited period of their daily summaries
> using the --rebuild-daily command line option through use of the --date
> or --from and --to command line options. The paradigm of dropping the
> daily summaries then rebuilding (old term backfilling) them has been
> discarded and you can just rebuild them without dropping first. It should
> not matter what is or is not in the daily summary tables, if it does then I
> would say that is a bug.
>
>
> Is there a way to do this currently with wee_database or do I need to get
> an older version of the script? (would that even be available or safe?)
>
>
> You won't have much luck with old versions of wee_database, before 3.7.0
> wee_database could not backfill selected days only all or nothing.
>
> Gary
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "weewx-user" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/weewx-user/mZlwE4lRoaY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> weewx-user+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] wee_database backfill only a range of dates

2017-03-18 Thread Constantine Samaklis 
I am looking for a way to backfill a range of dates into my summary tables. 
When I look at the weewx website, the documentation states that you can do 
this with wee_database but it seems that the latest version of the utility 
only allows for a backfill where data is not present already in the 
aggregation tables.

I need to correct only a couple of days of bad data in my archive_day_rain 
table. 

Is there a way to do this currently with wee_database or do I need to get 
an older version of the script? (would that even be available or safe?)

Thanks

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] Re: no module named alarm

2017-03-13 Thread Constantine Samaklis 
I copied the alarm.py module to /bin/user and it works fine. I 
guess the examples dir is no longer included in the paths that modules 
could be loaded from...

On Monday, March 13, 2017 at 8:29:43 AM UTC-4, Constantine Samaklis wrote:
>
> Hi,
>
> One of the included examples for a "custom" service is alarm.py included 
> in the examples directory. 
>
> I just upgraded from 3.5 to 3.7 and I started getting the following error:
>
> Mar 13 08:10:44 raspberrypi weewx[18326]:   engine = 
> engine_class(config_dict)
> Mar 13 08:10:44 raspberrypi weewx[18326]: File 
> "/home/weewx/bin/weewx/engine.py", line 77, in __init__
> Mar 13 08:10:44 raspberrypi weewx[18326]:  
>  self.loadServices(config_dict)
> Mar 13 08:10:44 raspberrypi weewx[18326]: File 
> "/home/weewx/bin/weewx/engine.py", line 141, in loadServices
> Mar 13 08:10:44 raspberrypi weewx[18326]:  
>  self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
> config_dict))
> Mar 13 08:10:44 raspberrypi weewx[18326]: File 
> "/home/weewx/bin/weeutil/weeutil.py", line 1132, in _get_object
> Mar 13 08:10:44 raspberrypi weewx[18326]:   mod = 
> __import__(module)
> Mar 13 08:10:44 raspberrypi weewx[18326]:   ImportError: No module 
> named alarm
> Mar 13 08:10:44 raspberrypi weewx[18326]:   Exiting.
>
> The alarm module is present in the examples directory and my configuration 
> points to examples.alarm.MyAlarm in the report_services section
>
> This was working fine up to version 3.5
>
> What am I missing?
>
>
>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[weewx-user] no module named alarm

2017-03-13 Thread Constantine Samaklis 
Hi,

One of the included examples for a "custom" service is alarm.py included in 
the examples directory. 

I just upgraded from 3.5 to 3.7 and I started getting the following error:

Mar 13 08:10:44 raspberrypi weewx[18326]:   engine = 
engine_class(config_dict)
Mar 13 08:10:44 raspberrypi weewx[18326]: File 
"/home/weewx/bin/weewx/engine.py", line 77, in __init__
Mar 13 08:10:44 raspberrypi weewx[18326]:  
 self.loadServices(config_dict)
Mar 13 08:10:44 raspberrypi weewx[18326]: File 
"/home/weewx/bin/weewx/engine.py", line 141, in loadServices
Mar 13 08:10:44 raspberrypi weewx[18326]:  
 self.service_obj.append(weeutil.weeutil._get_object(svc)(self, 
config_dict))
Mar 13 08:10:44 raspberrypi weewx[18326]: File 
"/home/weewx/bin/weeutil/weeutil.py", line 1132, in _get_object
Mar 13 08:10:44 raspberrypi weewx[18326]:   mod = __import__(module)
Mar 13 08:10:44 raspberrypi weewx[18326]:   ImportError: No module 
named alarm
Mar 13 08:10:44 raspberrypi weewx[18326]:   Exiting.

The alarm module is present in the examples directory and my configuration 
points to examples.alarm.MyAlarm in the report_services section

This was working fine up to version 3.5

What am I missing?



-- 
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.
For more options, visit https://groups.google.com/d/optout.