Stefan-
New API for the time zone base
06/16/2017 at 20:16 • 0 commentsThe mechanism to determine the correct UTC time offset is a bit complicated. First the openweathermap.org API finds the coordinates to a given location and then the worldweatheronline.com API delivers the UTC offset to given coordinates. Of course I use the free developer pricing plan which allows some few API calls per day or per month.
Since 2 weeks my ForEx display didn't worked anymore. Soon I realized how much I rely on that gadget in my daily work. A quick check showed that the worldweatheronline.com API didn't work any more. Well using free API bears that risk as we are aware all of us. But worldweatheronline.com stopped that free offer without any notification mail or similar. That's pretty poor and if they deal like that, I seriously would think twice before using that API for a commercial application.
However I found the timezoneDB.com. It's free and unlimited, only for commercial usage a premium plan needs to be paid. This works fine but due the "one call per second" limitation the initial phase takes a bit longer as there are 7 API calls and a delay() call is require to prevent an API blockage with fast internet access.
The updated code is stored on Github
-
Watchdog
05/24/2016 at 19:50 • 0 commentsI'm using now my ForEx display while the daily work. But now and then it hangs up (approx. every other day) . Some times it's clear as wrong city entry or web-API not available but some times it's really not clear. Therefore I implemented a watchdog. My first try with the ESP8266 SDK watchdog (ESP.wdtEnable(WDTO_0MS)) didn't work at all and as my intention was to make it running and not to figure out mistakes I tried an other watchdog mechanism. I followed that instructions:
from Andreas Spiess
This works now (even it doesn't make always what it's intended to do) . Thanks Andreas
-> All Github files are updated
-
WebServer - analogRead conflict?
05/01/2016 at 10:54 • 0 commentsWhen programming this little gadget everything worked well. Then I removed all the debugging stuff did a quick check and uploaded it - fine. Since that it runs on my desk but as I required Singapore Dollars the web interface didn't responded last week. Restarting didn't helped a lot - no answer. Analyzing that matter isn't a big deal. There are only 4 activities in the main loop: 1. Refresh the entire screen every minute. 2. Request the information from the API's and NTP server every 24h. 3. Check whether there is a request from internet port 80 (which obviously didn't work). 4. Measure the brightness and adjust the current for the display back light. As 1&2 are executed only rarely and 3 is the matter to fix, it needs to be cased by 4. And indeed commenting out the brightness control the web interface worked perfectly. By further activate and deactivate elements of the brightness control sequence it became obvious that the analogRead function caused the conflict. Without the web server worked, with no response. I was able to solve the problem by adding a delay() statement after the analogRead statement. Playing a round with the length didn't give more insights. Pretty often the time delay(1) was already sufficient and I could place it before or after the analogRead. With delay(100) I had absolutely stable results. As the ESP8266 Arduino does quite some activities I guess this is based on this but finally haven't an idea why it's really the case. As the delay statement in this configuration (ESP8266 Arduino ) execute some other stuff in the background I tried the yield() function as well (as this should do the same) but without any impact. Even I'm not sure about the effective problem it's solved now and uploaded to GitHub
ForEx display
A stylish desktop widget shows you the actual foreign exchange rates and the time of different locations