|
Post by utantwx on Jan 26, 2019 10:09:54 GMT -8
So ive brought my unit indoors and this is the JSON response string currently {"variables": {"OurWeatherTime": "2018-12-08 17:32:53", "FullDataString": "19.40,nan,23.01,102534.00,56.68,0.00,0.00,270.00,0.00,0.00,0.00,0.00,0.00,270.00,270.00,0,2018-12-08 17:32:53,Utantwx98,0,-1,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,V:1,WXLMB ,0,,,0,,,0", "FirmwareVersion": "035", "IndoorTemperature": 23.01, "BarometricPressure": 102534.00, "Altitude": 56.68, "OutdoorTemperature": 19.40, "OutdoorHumidity": nan, "CurrentWindSpeed": 0.00, "CurrentWindGust": 0.00, "CurrentWindDirection": 270.00, "EnglishOrMetric": 0, "RainTotal": 0.00, "WindSpeedMin": 0.00, "WindSpeedMax": 0.00, "WindGustMin": 0.00, "WindGustMax": 0.00, "WindDirectionMin": 270.00, "WindDirectionMax": 270.00, "AirQualitySensor": 0, "ThunderBoardLast": ",,0,,,0", "ThunderBoardParams": "", "ESP8266HeapSize": 31696}, "id": "1", "name": "OurWeather", "hardware": "esp8266", "connected": true} you can see the date is incorrect and that the OutdoorHumidity value is 'NaN' Ive rebooted the unit several times. If i try and change the date via REST api i get 'success' yet the date does not change. Really hoping someone can guide me here. perrito if you can give more details on how you built your custom 035 to fix your issue ( which is errily similar to mine ) it would be appreciated.
|
|
|
Post by SDL on Jan 27, 2019 16:25:17 GMT -8
It remains NaN even after a power cycle?
BP
|
|
|
Post by utantwx on Jan 28, 2019 9:17:53 GMT -8
correct - at some point it will show a number, then it will revert to 'nan' - what i noticed is that at this point the temp will 'stick' and the dewpoint will plummit, until a good reading is obtained. Could I just have a bad temp/humdity probe?
|
|
|
Post by utantwx on Jan 28, 2019 9:25:19 GMT -8
now, of course, I just power cycled it and the NaN was replaced with '35.1' this time, but i assure you yesterday/day before I rebooted several times and received 'nan' post reboot as well as many times when it was installed outdoors.
|
|
|
Post by SDL on Jan 29, 2019 10:05:13 GMT -8
Rebooting and power cycling are two different things. Which were you doing?
If you are rebooting, then the data fits with what we are looking at. If you are power cycling with it still being NaN something else is going on.
BP
|
|
|
Post by utantwx on Jan 29, 2019 12:06:08 GMT -8
i have power cycled ( no power -> power ) and had the NaN situation remain. Not always, but it has happened.
|
|
|
Post by SDL on Jan 31, 2019 11:26:49 GMT -8
OK. I'll assume you are in the same failure category as the others and continue on the debug.
BP
|
|
|
Post by utantwx on Feb 1, 2019 12:42:02 GMT -8
an update here - i was able to flash the system back to v028 and I have the same issue with the date being corrupt about 30 seconds after boot and the humidity being NaN. Are these related items ? is the temp sensor bad? The RTC?
|
|
perrito
New Member
Posts: 22
Raspberry Pi: Yes
|
Post by perrito on Feb 1, 2019 12:51:17 GMT -8
utantwx To try my suggested fix you will need 027, my theory is that 028 actually introduced this. cheers.
|
|
|
Post by utantwx on Feb 4, 2019 5:39:03 GMT -8
ok so i put 027 on it and I still have the same issue, NaN, bad temps, and the date/time that is a bizarre string - does anyone point to some simple things i can do to test each component ? like a small program to test just the RTC? or just the temp/humidity probe?
|
|
|
Post by SDL on Feb 6, 2019 17:22:17 GMT -8
We have a little movement in this debug. I do not think it is V027 (this is Perrito's theory - and has some merit - but I can't reproduce it), I now think it has to do with the number of retries allowed for a bad read. It will be a bit before this fix moves into the OurWeather code. We will be trying it in GroveWeatherPi first.
BP
|
|
perrito
New Member
Posts: 22
Raspberry Pi: Yes
|
Post by perrito on Feb 6, 2019 17:29:18 GMT -8
Interesting, I am curious to know more if you care to elaborate, that would be consistent with my local happening, iirc I reverted to a point where there is less retrying on error. (cant recall the exact code now but I believe 027/28 (the one that improves the driver, adds a significant amount of retries on read when a missread is detected)
|
|
|
Post by SDL on Feb 6, 2019 18:14:39 GMT -8
What we are trying in GWP is to increase the number of Retrys to 10. This may also be related to the adafruit posting too. This *could* work too.
BP
|
|
|
Post by Scott K on Feb 17, 2019 11:46:01 GMT -8
I wanted to weigh in on this subject with my own experiences. I have had OurWeather kit running for a week and this is what I see.
Day 1 - Installed and working. Weather board laying flat on a surface at a distance of 70 feet from my Airport router. Day 2 - Frozen and not working via Blynk app. Power cycle to fix. Day 3 - Frozen and not working via Blynk app. Power cycle to fix. Day 4 - Frozen and not working via Blynk app. Power cycle to fix. Then my wifi and internet failed and I had to reset my router for unknown reasons. Changed the SSID. Day 5 - Disconnected Weather board from sensors and brought down to office to reconnect to wifi. Once connected to wifi, I reconnected weather board to sensors. This time I placed the board with the built in wifi antenna vertical instead of horizontal like the last installation. Day 6 - No issues Day 7 - No issues..so far.
I knew I was already at the maximum distance for a stable wifi connection given walls and other obstacles. I have no issue with other devices at that distance such as an iPhone and Wireless cameras. My experiences to date make me believe the freezing is caused by a weak wifi. Nothing changed about my installation except the orientation of the wifi antenna, having to reconnect the sensors, and the name of my wifi SSID.
|
|
|
Post by SDL on Feb 17, 2019 12:26:38 GMT -8
|
|