[weewx-user] Re: Weewx stopped running after 4 days
On Wednesday, February 6, 2019 at 5:51:15 AM UTC-8, Andy Hudson-Smith wrote: > > Thanks for the replies ref hardware and report intervals - I was running > on a Pi A+ - turns out they halved the ram so its now been moved to a Pi3 > and its running ok so far. I will look into a longer term upgrade but glad > the Pi3 seems to be coping. > > > Andy - FWIW, I'm running weewx on a Seagate Dockstar (an original SheevaPlug, just with half the memory - only 128MB) and it runs literally years with no problems, but I 'did' run into problems previously when I loaded it up with things like weewx-wd and the Saratoga templates etc. Some of the extensions and complicated skins can really pound an underpowered system into the ground if you're not careful. Moving your storage out to non-SD media will also help speed things up a lot. If you get a pi3 or (better yet) a pi3b+ you can even boot off external SSD with 'no' SD at all on the system, assuming you have a good power supply so the disk gets appropriately powered. I've had one running my WeatherFlow UDP based site for a number of months now. Just plain works, if you power it sufficiently. -- 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: Weewx stopped running after 4 days
Thanks for the replies ref hardware and report intervals - I was running on a Pi A+ - turns out they halved the ram so its now been moved to a Pi3 and its running ok so far. I will look into a longer term upgrade but glad the Pi3 seems to be coping. Andy On Tuesday, 5 February 2019 08:34:54 UTC, Andrew Milner wrote: > > Gary - the point I was really trying to make was that - especially where > an RPi is involved - it is likely that one cannot necessarily do all that > one wishes - but compromising does not necessarily mean a significant loss > of information. What people often forget is that midnight in particular > results in more load for reports as the yearly plots and pages are > regenerated together with the monthly, weekly, current etc also and this > can result in more issues when small archive intervals are being used. > > I think we are really on the same page Gary, even if I may appear a > luddite and a pedant at times. > > Andrew > > > On Tuesday, 5 February 2019 07:49:34 UTC+2, gjr80 wrote: >> >> I beg to disagree. I learnt a long time ago to not impose my views on a >> user's requirements; maybe the user needs to generate a report every >> minute, maybe they need to record the number of widgets every minute, maybe >> they just like lots of dots in their plots. At the end of the day it does >> not matter, WeeWX supports a 1 minute archive interval. Now if a user >> chooses to use a 1 minute archive interval that may impose some limits on >> the user, but that is a different matter. I know the old chestnut about >> wind speeds and directions gets dragged out every now and then. I think we >> need to keep in mind that the period over which an observation is made does >> not necessarily bear any relationship to how often you may wish to record >> the value. >> >> Gary >> >> On Tuesday, 5 February 2019 14:22:12 UTC+10, Andrew Milner wrote: >>> >>> I continue to find it almost impossible to conceive a situation where an >>> archive interval of under 5 minutes serves any useful purpose. As long as >>> a gust value is recorded for the 5 minute period the average speed >>> value/direction over the period is more than sufficient - even for an >>> airfield - and the other readings are unlikely to alter over 5 minutes >>> anyway. So with a Pi a 5 minute interval is more than sufficient. >>> >>> I found the following whilst googling wind gust which I thought useful >>> since the implication is that wind measurements over short periods of time >>> (if the rest of the world is right) are error prone anyway: >>> >>> "Wind gusts (which last only a few seconds) make it hard to determine >>> the overall wind speed of storms whose winds don't always blow at constant >>> speeds. This is especially the case for tropical cyclones and hurricanes. >>> To estimate the overall wind speed, the wind and wind gusts are measured >>> over some period of time (typically 1 minute) and are then averaged >>> together. The result is the highest average wind observed within the >>> weather event, also called the *maximum sustained wind speed*. >>> >>> Here in the U.S., maximum sustained winds are always measured by >>> anemometers at a standard height of 33 feet (10 m) above ground for a >>> duration of 1 minute. The rest of the world averages their winds over a >>> period of 10 minutes. This difference is significant because measurements >>> averaged over just one minute are about 14% higher than those averaged over >>> the course of ten minutes." >>> >>> >>> On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote: Yes the NoneType error is certainly due to the realtime clientraw extension not handling a None value correctly, by the looks of it a wind related field so quite possibly brought on by your battery/connectivity issue. That extension was written over 2 years ago and never formally released (and judging by the lack of user questions I assume not used by too many). So that means it is probably not too robust. It maybe easiest to just disable it until I can get to have a look at it in the next 2-3 weeks (as per other thread). Some good advice above about getting a machine to work reliably, the only thing I would add is chose your archive interval carefully as that also has an impact on stability when you start to add in a number of extensions. A 5 minute archive period means there is 5 minutes between report cycles so arguably WeeWX has around 5 minutes to get all of its report processing completed, cut that down to 1 minute and WeeWX now only has 1/5 the time. You don't want your reports taking longer to run than your archive interval, that would be bad on many fronts. Some folks think that having the shortest possible archive interval is essential, that may be the case in some circumstances but there are other secondary effects that need to be kept in
[weewx-user] Re: Weewx stopped running after 4 days
Gary - the point I was really trying to make was that - especially where an RPi is involved - it is likely that one cannot necessarily do all that one wishes - but compromising does not necessarily mean a significant loss of information. What people often forget is that midnight in particular results in more load for reports as the yearly plots and pages are regenerated together with the monthly, weekly, current etc also and this can result in more issues when small archive intervals are being used. I think we are really on the same page Gary, even if I may appear a luddite and a pedant at times. Andrew On Tuesday, 5 February 2019 07:49:34 UTC+2, gjr80 wrote: > > I beg to disagree. I learnt a long time ago to not impose my views on a > user's requirements; maybe the user needs to generate a report every > minute, maybe they need to record the number of widgets every minute, maybe > they just like lots of dots in their plots. At the end of the day it does > not matter, WeeWX supports a 1 minute archive interval. Now if a user > chooses to use a 1 minute archive interval that may impose some limits on > the user, but that is a different matter. I know the old chestnut about > wind speeds and directions gets dragged out every now and then. I think we > need to keep in mind that the period over which an observation is made does > not necessarily bear any relationship to how often you may wish to record > the value. > > Gary > > On Tuesday, 5 February 2019 14:22:12 UTC+10, Andrew Milner wrote: >> >> I continue to find it almost impossible to conceive a situation where an >> archive interval of under 5 minutes serves any useful purpose. As long as >> a gust value is recorded for the 5 minute period the average speed >> value/direction over the period is more than sufficient - even for an >> airfield - and the other readings are unlikely to alter over 5 minutes >> anyway. So with a Pi a 5 minute interval is more than sufficient. >> >> I found the following whilst googling wind gust which I thought useful >> since the implication is that wind measurements over short periods of time >> (if the rest of the world is right) are error prone anyway: >> >> "Wind gusts (which last only a few seconds) make it hard to determine the >> overall wind speed of storms whose winds don't always blow at constant >> speeds. This is especially the case for tropical cyclones and hurricanes. >> To estimate the overall wind speed, the wind and wind gusts are measured >> over some period of time (typically 1 minute) and are then averaged >> together. The result is the highest average wind observed within the >> weather event, also called the *maximum sustained wind speed*. >> >> Here in the U.S., maximum sustained winds are always measured by >> anemometers at a standard height of 33 feet (10 m) above ground for a >> duration of 1 minute. The rest of the world averages their winds over a >> period of 10 minutes. This difference is significant because measurements >> averaged over just one minute are about 14% higher than those averaged over >> the course of ten minutes." >> >> >> On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote: >>> >>> Yes the NoneType error is certainly due to the realtime clientraw >>> extension not handling a None value correctly, by the looks of it a wind >>> related field so quite possibly brought on by your battery/connectivity >>> issue. That extension was written over 2 years ago and never formally >>> released (and judging by the lack of user questions I assume not used by >>> too many). So that means it is probably not too robust. It maybe easiest to >>> just disable it until I can get to have a look at it in the next 2-3 weeks >>> (as per other thread). >>> >>> Some good advice above about getting a machine to work reliably, the >>> only thing I would add is chose your archive interval carefully as that >>> also has an impact on stability when you start to add in a number of >>> extensions. A 5 minute archive period means there is 5 minutes between >>> report cycles so arguably WeeWX has around 5 minutes to get all of its >>> report processing completed, cut that down to 1 minute and WeeWX now only >>> has 1/5 the time. You don't want your reports taking longer to run than >>> your archive interval, that would be bad on many fronts. Some folks think >>> that having the shortest possible archive interval is essential, that may >>> be the case in some circumstances but there are other secondary effects >>> that need to be kept in mind. Basically, to run a 1 minute archive WeeWX >>> needs to be fairly lean extension wise. >>> >>> Gary >>> >>> On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote: On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote: > > Noted the use of skins and mqtt on a pi, i kind of assumed it was up > to the job, i do like the weewx system so may well move up to a more >
[weewx-user] Re: Weewx stopped running after 4 days
I beg to disagree. I learnt a long time ago to not impose my views on a user's requirements; maybe the user needs to generate a report every minute, maybe they need to record the number of widgets every minute, maybe they just like lots of dots in their plots. At the end of the day it does not matter, WeeWX supports a 1 minute archive interval. Now if a user chooses to use a 1 minute archive interval that may impose some limits on the user, but that is a different matter. I know the old chestnut about wind speeds and directions gets dragged out every now and then. I think we need to keep in mind that the period over which an observation is made does not necessarily bear any relationship to how often you may wish to record the value. Gary On Tuesday, 5 February 2019 14:22:12 UTC+10, Andrew Milner wrote: > > I continue to find it almost impossible to conceive a situation where an > archive interval of under 5 minutes serves any useful purpose. As long as > a gust value is recorded for the 5 minute period the average speed > value/direction over the period is more than sufficient - even for an > airfield - and the other readings are unlikely to alter over 5 minutes > anyway. So with a Pi a 5 minute interval is more than sufficient. > > I found the following whilst googling wind gust which I thought useful > since the implication is that wind measurements over short periods of time > (if the rest of the world is right) are error prone anyway: > > "Wind gusts (which last only a few seconds) make it hard to determine the > overall wind speed of storms whose winds don't always blow at constant > speeds. This is especially the case for tropical cyclones and hurricanes. > To estimate the overall wind speed, the wind and wind gusts are measured > over some period of time (typically 1 minute) and are then averaged > together. The result is the highest average wind observed within the > weather event, also called the *maximum sustained wind speed*. > > Here in the U.S., maximum sustained winds are always measured by > anemometers at a standard height of 33 feet (10 m) above ground for a > duration of 1 minute. The rest of the world averages their winds over a > period of 10 minutes. This difference is significant because measurements > averaged over just one minute are about 14% higher than those averaged over > the course of ten minutes." > > > On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote: >> >> Yes the NoneType error is certainly due to the realtime clientraw >> extension not handling a None value correctly, by the looks of it a wind >> related field so quite possibly brought on by your battery/connectivity >> issue. That extension was written over 2 years ago and never formally >> released (and judging by the lack of user questions I assume not used by >> too many). So that means it is probably not too robust. It maybe easiest to >> just disable it until I can get to have a look at it in the next 2-3 weeks >> (as per other thread). >> >> Some good advice above about getting a machine to work reliably, the only >> thing I would add is chose your archive interval carefully as that also has >> an impact on stability when you start to add in a number of extensions. A 5 >> minute archive period means there is 5 minutes between report cycles so >> arguably WeeWX has around 5 minutes to get all of its report processing >> completed, cut that down to 1 minute and WeeWX now only has 1/5 the time. >> You don't want your reports taking longer to run than your archive >> interval, that would be bad on many fronts. Some folks think that having >> the shortest possible archive interval is essential, that may be the case >> in some circumstances but there are other secondary effects that need to be >> kept in mind. Basically, to run a 1 minute archive WeeWX needs to be fairly >> lean extension wise. >> >> Gary >> >> On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote: >>> >>> On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote: Noted the use of skins and mqtt on a pi, i kind of assumed it was up to the job, i do like the weewx system so may well move up to a more useful machine - coming from Windows into this world means i know little beyond Dells and Win 10 which is what i have been trying to avoid due to frequent updates and crashes of other systems. Any advice on what sort of system weewx needs to run would be good (again i should Google this first!). >>> >>> here are some suggestions: >>> >>> https://github.com/weewx/weewx/wiki/hardware >>> >>> data collection is almost never a problem. uploading data is not cpu, >>> i/o, or network intensive. most reports will run just fine on a pi or >>> other low-power machine - you should have no problems with 1 or 2 reports. >>> however, you might have issues if you try to run 3 or 4 query-intensive >>> reports with a short archive interval
[weewx-user] Re: Weewx stopped running after 4 days
I continue to find it almost impossible to conceive a situation where an archive interval of under 5 minutes serves any useful purpose. As long as a gust value is recorded for the 5 minute period the average speed value/direction over the period is more than sufficient - even for an airfield - and the other readings are unlikely to alter over 5 minutes anyway. So with a Pi a 5 minute interval is more than sufficient. I found the following whilst googling wind gust which I thought useful since the implication is that wind measurements over short periods of time (if the rest of the world is right) are error prone anyway: "Wind gusts (which last only a few seconds) make it hard to determine the overall wind speed of storms whose winds don't always blow at constant speeds. This is especially the case for tropical cyclones and hurricanes. To estimate the overall wind speed, the wind and wind gusts are measured over some period of time (typically 1 minute) and are then averaged together. The result is the highest average wind observed within the weather event, also called the *maximum sustained wind speed*. Here in the U.S., maximum sustained winds are always measured by anemometers at a standard height of 33 feet (10 m) above ground for a duration of 1 minute. The rest of the world averages their winds over a period of 10 minutes. This difference is significant because measurements averaged over just one minute are about 14% higher than those averaged over the course of ten minutes." On Tuesday, 5 February 2019 01:29:23 UTC+2, gjr80 wrote: > > Yes the NoneType error is certainly due to the realtime clientraw > extension not handling a None value correctly, by the looks of it a wind > related field so quite possibly brought on by your battery/connectivity > issue. That extension was written over 2 years ago and never formally > released (and judging by the lack of user questions I assume not used by > too many). So that means it is probably not too robust. It maybe easiest to > just disable it until I can get to have a look at it in the next 2-3 weeks > (as per other thread). > > Some good advice above about getting a machine to work reliably, the only > thing I would add is chose your archive interval carefully as that also has > an impact on stability when you start to add in a number of extensions. A 5 > minute archive period means there is 5 minutes between report cycles so > arguably WeeWX has around 5 minutes to get all of its report processing > completed, cut that down to 1 minute and WeeWX now only has 1/5 the time. > You don't want your reports taking longer to run than your archive > interval, that would be bad on many fronts. Some folks think that having > the shortest possible archive interval is essential, that may be the case > in some circumstances but there are other secondary effects that need to be > kept in mind. Basically, to run a 1 minute archive WeeWX needs to be fairly > lean extension wise. > > Gary > > On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote: >> >> On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote: >>> >>> Noted the use of skins and mqtt on a pi, i kind of assumed it was up to >>> the job, i do like the weewx system so may well move up to a more useful >>> machine - coming from Windows into this world means i know little beyond >>> Dells and Win 10 which is what i have been trying to avoid due to frequent >>> updates and crashes of other systems. >>> >>> Any advice on what sort of system weewx needs to run would be good >>> (again i should Google this first!). >>> >> >> here are some suggestions: >> >> https://github.com/weewx/weewx/wiki/hardware >> >> data collection is almost never a problem. uploading data is not cpu, >> i/o, or network intensive. most reports will run just fine on a pi or >> other low-power machine - you should have no problems with 1 or 2 reports. >> however, you might have issues if you try to run 3 or 4 query-intensive >> reports with a short archive interval. >> >> in some configurations, the crt (cumulus realtime) and wdcr (clientraw) >> extensions can be problematic on low-end hardware, since they query the >> database each report cycle (archive interval) to get the data they need. >> if you run them on archive intervals you should be ok, but if you run them >> on loop packets you can easily run into the 'database locked' problems. >> >> the NoneType error is almost certainly due to a bug in rtcr.py - it is >> getting a value of None but does not handle it properly. >> >> 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Weewx stopped running after 4 days
Yes the NoneType error is certainly due to the realtime clientraw extension not handling a None value correctly, by the looks of it a wind related field so quite possibly brought on by your battery/connectivity issue. That extension was written over 2 years ago and never formally released (and judging by the lack of user questions I assume not used by too many). So that means it is probably not too robust. It maybe easiest to just disable it until I can get to have a look at it in the next 2-3 weeks (as per other thread). Some good advice above about getting a machine to work reliably, the only thing I would add is chose your archive interval carefully as that also has an impact on stability when you start to add in a number of extensions. A 5 minute archive period means there is 5 minutes between report cycles so arguably WeeWX has around 5 minutes to get all of its report processing completed, cut that down to 1 minute and WeeWX now only has 1/5 the time. You don't want your reports taking longer to run than your archive interval, that would be bad on many fronts. Some folks think that having the shortest possible archive interval is essential, that may be the case in some circumstances but there are other secondary effects that need to be kept in mind. Basically, to run a 1 minute archive WeeWX needs to be fairly lean extension wise. Gary On Tuesday, 5 February 2019 08:19:58 UTC+10, mwall wrote: > > On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote: >> >> Noted the use of skins and mqtt on a pi, i kind of assumed it was up to >> the job, i do like the weewx system so may well move up to a more useful >> machine - coming from Windows into this world means i know little beyond >> Dells and Win 10 which is what i have been trying to avoid due to frequent >> updates and crashes of other systems. >> >> Any advice on what sort of system weewx needs to run would be good (again >> i should Google this first!). >> > > here are some suggestions: > > https://github.com/weewx/weewx/wiki/hardware > > data collection is almost never a problem. uploading data is not cpu, > i/o, or network intensive. most reports will run just fine on a pi or > other low-power machine - you should have no problems with 1 or 2 reports. > however, you might have issues if you try to run 3 or 4 query-intensive > reports with a short archive interval. > > in some configurations, the crt (cumulus realtime) and wdcr (clientraw) > extensions can be problematic on low-end hardware, since they query the > database each report cycle (archive interval) to get the data they need. > if you run them on archive intervals you should be ok, but if you run them > on loop packets you can easily run into the 'database locked' problems. > > the NoneType error is almost certainly due to a bug in rtcr.py - it is > getting a value of None but does not handle it properly. > > 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Weewx stopped running after 4 days
On Monday, February 4, 2019 at 4:42:52 PM UTC-5, Andy Hudson-Smith wrote: > > Noted the use of skins and mqtt on a pi, i kind of assumed it was up to > the job, i do like the weewx system so may well move up to a more useful > machine - coming from Windows into this world means i know little beyond > Dells and Win 10 which is what i have been trying to avoid due to frequent > updates and crashes of other systems. > > Any advice on what sort of system weewx needs to run would be good (again > i should Google this first!). > here are some suggestions: https://github.com/weewx/weewx/wiki/hardware data collection is almost never a problem. uploading data is not cpu, i/o, or network intensive. most reports will run just fine on a pi or other low-power machine - you should have no problems with 1 or 2 reports. however, you might have issues if you try to run 3 or 4 query-intensive reports with a short archive interval. in some configurations, the crt (cumulus realtime) and wdcr (clientraw) extensions can be problematic on low-end hardware, since they query the database each report cycle (archive interval) to get the data they need. if you run them on archive intervals you should be ok, but if you run them on loop packets you can easily run into the 'database locked' problems. the NoneType error is almost certainly due to a bug in rtcr.py - it is getting a value of None but does not handle it properly. 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. For more options, visit https://groups.google.com/d/optout.
[weewx-user] Re: Weewx stopped running after 4 days
Thanks for the reply Vince - I was not sure what to search for but yep thinking about a quick search for database locked before posting would have been wise. Noted the use of skins and mqtt on a pi, i kind of assumed it was up to the job, i do like the weewx system so may well move up to a more useful machine - coming from Windows into this world means i know little beyond Dells and Win 10 which is what i have been trying to avoid due to frequent updates and crashes of other systems. Any advice on what sort of system weewx needs to run would be good (again i should Google this first!). Andy -- 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: Weewx stopped running after 4 days
On Monday, February 4, 2019 at 1:15:51 PM UTC-8, Andy Hudson-Smith wrote: > > Evening - my recent install of Weewx on a Pi listening for UDP data from > Weather Flow and publishing to MQTT suddenly stopped working this evening. > I am new to Weewx so any help would be great as i cant get it to start > reporting again. The recent log file is below if that helps: > > Andy > > Feb 4 21:04:23 weewx weewx[661]: weatherflowudp: MainThread: Listening > for UDP broadcasts to IP address 0.0.0.0 on port 50222, with timeout 90 and > share_socket True... > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: Traceback (most recent > call last): > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: File > "/usr/share/weewx/user/rtcr.py", line 770, in process_packet > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: data = > self.calculate(cached_packet) > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: File > "/usr/share/weewx/user/rtcr.py", line 921, in calculate > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: > age=self.gust_period).value > Feb 4 21:04:23 weewx weewx[403]: rtcrthread: AttributeError: > 'NoneType' object has no attribute 'value' > oh - and user/rtcr.py has nothing to do with MQTT nor Weatherflow, so you have an extension installed that has bugguessing you're fiddling with clientraw or something like that ? Whatever you're running is struggling decoding malformed or missing input data I think -- 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: Weewx stopped running after 4 days
On Monday, February 4, 2019 at 1:15:51 PM UTC-8, Andy Hudson-Smith wrote: > > Evening - my recent install of Weewx on a Pi listening for UDP data from > Weather Flow and publishing to MQTT suddenly stopped working this evening. > I am new to Weewx so any help would be great as i cant get it to start > reporting again. The recent log file is below if that helps: > > Feb 4 21:05:23 weewx weewx[403]: manager: Replace failed for database > weewx.sdb: database is locked > Andy, you might want to work on your google-fu a bit more. This has been discussed 'many' times in the past, so it's searchable in the group archives. "database is locked" happens all the time on a pi, generally when you run too complicated a weewx skin (or set of skins or extensions) and they don't process fast enough on the limited pi resources. The file is indeed locked and in use when weewx needs to update it. You need to lighten the load on the pi: - do less - run less skins, run less extensions, set your WF to power-save to not do rapid_wind every 3 seconds - do easier things - run less compute/disk intensive skins (don't run weather34 or Belchertown or Belchertown+MQTT) - do it faster - reconfigure to use a SSD disk, not a SD disk (requires pi3 or pi3b+ and a better power supply) - or get a better computer than a pi if you want to do a lot of stuff Regarding the WF gear specifically, I found the weatherflow UDP driver 'very' stable running just vanilla weewx on something as weak as a pi-zero. I've had it running similarly on pi3 for almost 3 months now, so your problem is you are almost certainly trying to do too much on the wimpy pi platform. -- 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.
