mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jun 25, 2018 10:08:22 GMT -8
After upgrading to v32, it appears I have 2 new issues:
Board Freezing: Since upgrading to v32, the board has frozen 2 out of the last 5 days. I started rebooting my OurWeather board at midnight everyday so I can manually reset the rain_total values. The OurWeather board seems to freeze up around 4 hours after the reboot. It's not everyday, but 2 of the last 5 days it has locked up. As soon as I cycle the power (just as I do with the automated reboot each night), it works fine. I have not had locking issues before and I've been rebooting the OurWeather board nightly with no issues.
Lightning Distance Issue: Maybe it is just a tuning issue, but the OurWeather board is returning 0km distance values while my Lightning Detector build is returning values > 0 and much fewer strikes. I've been running my Lightning Detector build for a while now and have decent trust in its values. The OurWeather Lightning data is never close to what the Lightning Detector builds values are. I'm sure it's a tuning issue (not sure the 0 values are a tuning issue though).
A Lightning Tuning video has been mentioned as something that is being worked on. Would it be possible to post some basic details on how to tune the ThunderBoard for OurWeather until the video is released? It's nearly impossible to try and tune the board with no information on what the values should be or what they do.
I don't really have anything I can test other than halting the nightly reboots of the OurWeather board. I will try that for the next week and see what I find.
Thanks,
Richard
|
|
|
Post by SDL on Jun 25, 2018 10:42:19 GMT -8
Richard,
Are you hitting the REST interface a lot during these four hours? Especially from a browser. Browsers (and some software) will hang that.
Is the system totally hung (the OLED is not working either) or is it just the WiFi interface?
BP
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jun 25, 2018 11:16:04 GMT -8
There is nothing going on in those four hours that is different than the rest of the day.
The only system hitting the OurWeather board is the DataLogger which pulls data from the FullDataString. However, I've been doing that for several months now with no issues. I'm using the default setting in the DataLogger of 60 seconds between sample times, which has been fine for quite a long time now.
The OLED is frozen (as is wifi) but the lights on the board flash when I manually spin the wind speed sensor on the weather rack.
The only time I ever hit the board with a browser is to check when something appears to not be working. When I do, I use Safari on my Mac which is the only one I've found to not cause the board to hang.
|
|
|
Post by SDL on Jun 25, 2018 16:41:52 GMT -8
Richard,
OK. Sounds like the whole OurWeather board is hung. Run an experiment for me. Turn off the DataLogger and see if it still hangs after 4 hours.
BP
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jun 29, 2018 6:32:16 GMT -8
I did not see your last post regarding turning off DataLogger. I will do that, but the Weather Board seems to hang every other day or so. I have 3 troubleshooting steps that I plan to take.
1. Turn off DataLogger for 4 hours and see if it hangs. Since the Weather Board runs fine with the DataLogger running for all the other hours, I don't expect it to hang after 4 hours.
2. Discontinue the scheduled automated power off / power on of the Weather Board. I've started a scheduled reboot each night at 12:00am so that I can manually reset the rain_total count for now. You mentioned that v33 may include a 24 hour rain total, but for now I'm trying to get it this way.
3. I have a backup Weather Board that I believe is still running v28. If tests 1 and 2 fail to correct the problem, I will swap out the board and see if I suddenly have a hardware issue.
I have been working on the DataLogger code and am adding MySQL (MariaDB) statements to fetch data from my database server. DataLogger and database server are on their own Raspberry Pi 3B+s). The data is then published to PubNub for my dashboard.
The only 2 other things that have changed are the nightly reboots and upgrading to v32. If the reboot is causing the problem, I will see if I can figure out a way to do a reboot via software instead of just cycling the power. The thing there is, whenever I've had to reboot the board in the last year or so, cycling the power never caused board hangs in the near future.
Edit: Wanted to make sure it was clear, the only code I've changed or worked on is the DataLogger code. Within the DataLogger code, the logic and timing of the DataLogger polling the Weather Board has not changed, so I'm not hitting the REST interface any differently than a stock version.
Thanks,
Richard
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jun 29, 2018 11:30:52 GMT -8
I've decided to change the order of my troubleshooting:
1. Replace the Weather Board running v32 with my backup board that is running v31. I know this is changing 2 variables at once, but it should be a quicker way to determine if the DataLogger process is the culprit.
2. Stop the DataLogger process for 4 days (I have not gone more that 2 days without a freeze since update to v32).
3. Stop the nightly reboots.
Again, I will report back what I find.
|
|
|
Post by SDL on Jun 29, 2018 16:54:16 GMT -8
Excellent. V032 software has been uploaded to the repository.
BP
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jul 6, 2018 10:57:57 GMT -8
So the results of my testing are in, and as I expected, it was not the DataLogger or nightly reboots of the OurWeather Board that was causing the freezing issue. The Lightning Extender Kit that I added back at the start of April 2018 was causing the problem. This has been reported in another tread here and my findings support their issue. When I switched to my backup OurWeather board running V031, I had the Lightning Extender kit attached. After the 12am reboot, it froze at 1:30am. I woke up for some reason around 1:40am and decided to see if it was working. I went outside at 2am to work on it. I removed the Lightning Extender kit from the OurWeather kit and it has been running with zero issues with the DataLogger and nightly reboots for a week now. Before, it was freezing if not every day, every other day.
So here is where I stand. Given that we are still waiting on any type of documentation in regards to how to tune the ThunderBoard when connected to the OurWeather Board, I have zero desire to troubleshoot the problem. I'm really disappointed that the Lightning Extender Kit was released for people to spend good money on and is seemingly not supported in any way at all. There has been talk of a video on how to tune the ThunderBoard using the OurWeather Admin page since it was released, however, we are still waiting. I've asked for even a few tips on some basic tuning methods while waiting for the video and nothing but silence. Now that the tuning section of the Admin page is actually working (that was down for 3 to 4 weeks), trying to tune the ThunderBoard with no documentation at all is literally like trying to figure out a combination lock without knowing the combination.
I'm one of the seemingly growing number of frustrated customers of SwitchDoc Labs. I have spent in the neighborhood of $500 to probably north of $600 on kits and parts in the last year. I have 2 OurWeather Kits, 1 GroveWeatherPi kit (with all sensors except solar - I have all the solar parts but don't want to add to my frustrations) and the Lightning Detector kit. The only kit that has ever worked as described in the description of the product is the Lightning Detector kit.
GroveWeatherPi I have had a fully built and ready to go GroveWeatherPi sitting on a shelf since the start of the year because of the following issues: 1. The sunlight / UV sensor does not work. 2. The Air Quality sensor does not work. 3. The AM2315 reportedly has the same reliability / accuracy issues that it had with the OurWeather kit. It was fixed for the OurWeather kit last February and there was mention of either fixing the driver or starting over with the driver for GroveWeatherPi.
It was mentioned somewhere that the next version of the GroveWeatherPi software to address these issues would be out in June 2018.
OurWeather Kit + Lightning Extender Kit As mentioned above, the ThunderBoard is causing the OurWeather board to freeze up. It was working for a while on V031, but it is now freezing on V031 and V032.
Since there appears to be little or no support for the ThunderBoard Extender kit on OurWeather, I have no desire to spend any addtional time trying to get that to work. The last time it froze, I was working on it outside at 2am.
When I saw the launch of the new LED project, I was a bit disappointed because I knew that with a new product coming out, there would be even less chance of getting the other products working as there would be less time available to work on existing issues. There is a thread with the 2 (or more) very frustrated LED project users trying to get the LED project to work and the documentation to be a large problem.
I'm actively researching other vendors or solutions to get the weather data I'm looking for. As mentioned in another thread, you guys make very interesting products. There is an implied level of DIY with your products, which is fine. However, based on the product description on your website selling the product, they don't work as described. The consistent question or complaints about documentation should be something that I really hope you guys hear and can address. If you don't, there will be others like me that get fed up and move on.
I think you guys are good people and are trying to provide a good product. Please find someone to help you with support and documentation.
Thank you,
Richard
|
|
|
Post by SDL on Jul 6, 2018 13:32:16 GMT -8
Richard, Well, I can't argue with some of what you have said. Let's start with the GWP issues. Do you have the latest software downloaded and installed? We fixed #1 in V3.01 in June. I had a bug listed for OurWeather and the Air Quality Sensor which we fixed. I don't have a bug on my list for the Air Quality sensor on the GroveWeather Pi. Could you tell us what you are seeing (and forgive me if I missed this in a different posting. If I don't write the bug note up immediately, I forget things.) github.com/switchdoclabs/SDL_Pi_GroveWeatherPi#3 is still an issue, but we have not been able to duplicated the problem on our test units. Finally, we have just decided to modify the software anyway to implement the same reliability algorithm that we are using on OurWeather. It can't hurt. The Thundeboard should work with V031 or V032. Our test unit does NOT freeze. Would you please post a pic of the setup so I can check your wiring? I'm the engineer that is working on the GroveWeather Pi software and OurWeather software. John Shovic is off on the LED project and the Weather station that will come out of that, so I'm the right guy to be complain to for sure. I've got a theory from your data. Maybe the Thunderboard is interfering with the REST interface. Here's my theory. The Thudneboard is being periodically polled for lighting bolts due to a lack of available GPIO on the ESP8266. No problem usually, but I'm wondering if the REST interface (which uses a lot of deep WiFi software in the ESP8266 is interfering with the I2C reads for the Thunderboard). If you feel like running the test, the test would be to connect up the Thunderboard and then don't run the REST interface at all (no datalogging) and see if it still hangs. I *think* that might be the problem, because our system doesn't hang at all, but we aren't hitting the REST interface nearly as often. When I get back to the office next Wednesday, I will start the datalogging system and the thunderbird and see if I can duplicate it. There are so many variables in this kind of a system that sometimes it takes a lucky break to figure out the problem. If I can duplicate it, I can fix it. BP
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jul 6, 2018 14:06:24 GMT -8
Hi BP.
I hate writing things like I did above, I really do. There are additional factors at play in what I'm going to do going forward. I have not mentioned this yet, but my rain amount is always lower than anyone else's in my area. Unfortunately, I don't have a great, or maybe not even a good location to place the weather station. However, a few days ago, we had a slow drizzle, straight down, no wind. My station (OurWeather) reported .002" of rain. There is a weather station about 1/4 mile from me that I compare my readings to. His station reported .004". While I know that rain can differ in short distances, this happens 100% of time. Rain is the data point I am most interested in and I have diligently watched for this and compare my totals to others in the area.
I'm at a cross roads with my project right now. I just found a way to get all the data I'm looking for to build my dashboard without having to have my own PWS. This would eliminate all my issues with the systems, however, I would be relying on a PWS that I don't control or have access to to evaluate the accuracy.
I don't need the Lightning Extender on the OurWeather kit since my Lightning Detector system is working great. So for my issues above, as of now, there is no testing that you need to do for me.
I will give some thought about working on the GWP side of things. The biggest question for me is how much time and effort do I put into this when I know I don't have a placement location that will provide a good chance for accurate data. If I can get the data from other PWS's, that's good. However, I've invested a lot of time and money into what I have.
I do apologize if I have come off as a jerk in all of this. I appreciate you getting back to me on these issues.
Thanks,
Richard
|
|
|
Post by SDL on Jul 8, 2018 14:46:15 GMT -8
I've got a theory from your data. Maybe the Thunderboard is interfering with the REST interface. Here's my theory. The Thudneboard is being periodically polled for lighting bolts due to a lack of available GPIO on the ESP8266. No problem usually, but I'm wondering if the REST interface (which uses a lot of deep WiFi software in the ESP8266 is interfering with the I2C reads for the Thunderboard).
Read more: forum.switchdoc.com/thread/587/ourweather-board-freezing-value-lightning#ixzz5KhpKiGbYI talked to Laurie and John about this potential problem and they have given me the go ahead to pursue this theory of mine. It seems to fit the data and John always has a sixth sense about this. BP
|
|
mcinflyre
Junior Member
Posts: 53
Raspberry Pi: Yes
Other Device: PC, Mac and Android devices.
|
Post by mcinflyre on Jul 9, 2018 7:42:39 GMT -8
Sounds good BP. 2 things from my side:
1. I will be sourcing my main weather data from another product going forward, so you don't need to do any testing for me. If the theory about the Thunderboard interfering with the REST interface is correct (and it makes sense), that would be good for other's that may be trying to do the same thing.
2. While testing with my 2 OurWeather boards, I noticed the barometric pressure is now reporting a value + 0.06 inhg or 0.07 inhg higher than it should be. I don't know when this started, but it is happening on both OurWeather boards, one running V031 and the other, V032. The higher value is always +0.06 or 0.07 ingh.
The OurWeather board(s) are in the standard plastic water tight box that most people use and nothing has changed that I'm aware of to make the pressure change. The problem very well could be on my side with some environmental issue.
I will try and use the GroveWeatherPi build for sunlight / uv data and air quality.
Thanks,
Richard
|
|