New Release (Finally) Uploaded. (Just in time to test Fall back, for those in areas that use DST)
http://linuxslate.com/files/VFD_Clock_Distribution_20171103.tar.gz Bug Fixes and Improvements:
-- Spring Forward and Fall Back were tied to wrong dates. Spring was in November, and Fall was in March.
Other not - as - glaring errors and optimizations in this section of the main code.
Still no promises, but at least the worst, and most obvious errors were fixed.
-- Another DST related error in the Daytime connection to the time server.
2 issues caused the initial connection to the Daytime server (port 13) and determination of whether DST was in effect to fail. -- Fixed. Initial Connection to the Daytime server, can of course fail due to external problems, but it seems to work most of the time.
-- Various code clean up and space (heap) savings
-- New feature: In Clock Only mode, the time moves around the display every minute. This helps keep screen brightness uniform on many (most) types of displays. (Note: The timer is caught and sync'ed the 1st minute, so it does not actually move the time until the second minute. This also means that alarms set for within less 2 minutes after a reboot may not work, but I do not consider that to be a bug.) (Note: There is still 1 or 2 characters at each end that is are used in 24HR mode.)
-- The 1 minute timer is now synced to seconds. Alarms occur on the minute, or approximately 1 second after. The movement of the display in clock only mode uses this, so the clock moves on the minute, and not at a random number of seconds.
Startup time reduced to 5 seconds. Depending on how you connect to the NodeMCU, this should not be a problem if you need to "file.rename("init.lua","not_init.lua")", or similar.
NOT Fixed:
When an alarm is playing, the relevant sound file is (obviously) open each time the sound is playing. If the user then requests (or refreshes) the web page, the webserver must open the relevant HTML file. While newer NodeMCU firmwares will allow 2 files to be open at once, the version I used did not. The result is that there is a very high probability of a crash when attempting to cancel an alarm or hitting snooze. While a crash serves (in a rather un-elegant way) to silence the alarm, and the clock resumes normal function after it reboots, this renders the snooze function unusable. Newer versions of NodeMCU have serious issues with End User Setup, so I have to stick with the old firmware for now. Given the current state of NodeMCU, this may never be fixed.
Setting the 2 alarms within 10 minutes of each other may still cause unpredictable results. (Code not checked/tested for this condition.)
Punctuation in the Alarm Messages still causes messages to be displayed "funny" (control character codes are displayed).
In addition to the above, more checks for valid inputs (settings) are needed. Ex: Proper format for Alarm Time.
Weather not yet implemented. Still anticipating possible memory problems when this code is added.