Mike and I were talking about two very similar clock projects we’d both built recently: they both use ESP8266 modules to get the time over WiFi and NTP, and they both failed. Mike’s failed because he was visiting relatives in a different timezone with different WiFi credentials, and mine failed because daylight savings time caught me off-guard. In both cases, we hard-coded stuff that could obviously change, but we drew vastly different conclusions.
Mike thought he’d solve his WiFi problem with a fallback to a captive portal, and maybe would have to figure out some web interface for configuring the timezone. A very clean, professional solution. Me? I’ve got good comments in the code, can find the UTC offset (or the WiFi creds) in a few minutes, and flash the new version up simply by fetching a USB cable, for something that happens twice a year. It’s hardly worth the trouble to cobble together a web interface.
We’ve accidentally embodied a quandary that spans both the hardware and software worlds: should flexibility be exposed to the end-user or to the hacker who can peer under the hood or open up the source code? (And what if the end-user is the hacker?) What are the tradeoffs, in project complexity and in ease of use?
And in this, Mike is on the side of right and good, and I’m the heretic. I don’t always write my code to be extensible or re-usable. I sometimes write it to be quickly re-edited and patched whenever I need to. Is it full of magic numbers? Sure! But I know just where they are and how to change them. Heck, most are even well documented in their own header file. You could probably figure it out just about as fast. Would my father-in-law be able to tweak the timezone? Nope! But this ain’t his project anyway.
Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more. Don’t be afraid to edit code. Tweak, compile, and re-flash when the situation changes. After all, that’s how you got the code there in the first place.
And although I’m on the wrong end of history, in this case I was right. You see, before daylight savings time could come around again, and I could have made use of that captive portal that I didn’t bother coding up anyway, my son entered first grade. Everything needs to be changed, from the hardware to the software. Will I code up the next version with flexible time regimes? As flexible as I need it to be, but not more.
There are four solutions to this problem in order of importance of implementation, a clock should include at least one of these:
1. Have an interface for setting up time, preferably hardware one. It could be done with a single button.
2. Use RTCC, preferably with battery backup.
3. Have an interface for either manually configuring the Wi-Fi, or doing it automagically.
4. Have a subroutine that seeks open Wi-Fi access points and uses them for getting current time.
How about use a gps module to get time?
WWVB (in the US) will even tell you when DST is in effect. It can be a bit hard to receive indoors though. My preferred location for a particular clock on a particular shelf on an exterior wall had zero WWVB reception, and to make it worse, every few weeks the clock would glitch and one counter (usually the hours) would go wrong. On a table by the window where it’s harder to see the clock, and facing rotated 90 degrees (which may be the important difference), it always has the good signal indicator on.
Maybe I should build a clock around an STM32F10x, I’ve already done code to use its clock adjustment register, it would be accurate enough (after a month or two to determine the adjustment value) to use as a wall clock without messing with anything RF.
Another idea is a “DST ON/OFF” switch that you just flip twice a year, I have a few clocks like that. A time zone selector isn’t much harder, most WWVB clocks have a 4-way switch. Sometimes a switch or two is all the UI you need.
I am in the midst of building a GPS based altimeter for my truck. I could certainly extract and display time as well, but you still have the issue of converting to a local time zone (with the additional wrinkle of perhaps moving around among time zones). Most people want a clock that works indoors and GPS reception is problematic. NTP makes a lot more sense.
Could you use the GPS location and a lookup table to automatically adjust the timezone? A completely accurate system that accounts for all the deviations may be more work, but something based on longitude ranges could be a reasonable approximation in most instances.
Neither project had gps hardware in it. These are ~$5 boards.
Using tables for daylight savings time and timezone is no better than magic numbers, since both are subject to legislation. See Arizona and Indiana. Indiana is the worst, since at least at some point in the past, certain cities did DST differently from the state as a whole. Alaska, for some period, aligned its time zone with Hawaii’s, I think for the benefit of the TV networks. The DST date ranges have changed several times throughout the U.S. as well. You really do have to provide a way for the user to override whatever your table suggests.
Or simply accurate enough on its own *without* resorting to external stuff like NTP, WiFi, GPS, radio clock etc.
Don’t fall into trap that want everything things done automatically for you. The alternative is just setting the clock manually once every few years and save a lot of coding complexity and external dependency that can go wrong.
There are a handful good RTCC with integrated crystals that are decent. Or you can be like me, just use a regular crystal with firmware only RTC with a NCO for fine adjustment. Use a TCO if you have wide temperate range to deal with. I have calibrate it over long time to get to +/- 1 sec per month. I have implemented calendar, with leap year and day light saving time for my time zone.
https://github.com/FPGA-Computer/LED-Clock
UI (User Interface) in 6 digits is a pain, so some of the stuff is hard coded. I do have another project : Timer. It uses the same RTC core but with a bit more in the UI.
Some projects are one-off , personal use only, and those can have some more relaxed structure. But a little organization and forethought always pays off, when you revisit the thing down the line, or if what was meant to be only a small utility grows up to a medium sized project and then you need to spend time hunting for all of those “fixed decisions” of the past.
The above comments are excellent, but I’d like to focus on the thought that this article not really being about clocks. :-)
Both Elliot (and Mike, in absentia) make good arguments. But I tend to factor in another criterion when answering Elliot’s question … “how much will I learn or how much fun will I have by running down the rabbit hole of working on the ‘automation’ side project vs the original project?” I get as much out of some of the techno-ADHD side diversions as I did from the original project intent!
Fun is one thing, but the value of learning is in how much you’ll be able to retain. If you learn something and next time you need it is so far off that you’ll forget it, then you haven’t actually learned anything.
That’s partially true. I gain tremendous value in the diversions when I have to seek out and discover new hardware or software tools or techniques to complete the new project. Awareness of those being available always carry over into my database of “what’s possible” when the next project rears it’s head.
I think CMH62 has a good argument… but good plan!
Would love to see a bit of code for the web interface, if possible. Started to write a couple function to generate HTML code a couple years age. It used Ajax to get back basic parameter. However, I never finished something close to a library i could reuse. Didn’t search much for an existing library as I wanted to understand better how web pages works.
I’m just coding rudimentary HTML forms into the C code:
https://hackaday.io/project/171671/log/183838-prototyping-a-captive-portal
Currently I’m sidetracked with a couple of things that popped up:
It was fun exploring everything up to this point but I’m unsure I’ll continue on to integrate these experiments. I may have reached that point Elliot spoke about where it may not be “worth the trouble”.
This is all about picking a point of balance. Overgeneralizing is wasteful, but so is undergeneralizing. If you are willing to reflash code twice a year to handle DST, you have way fewer projects than I do. Time zones (including DST) are well understood and you can probably rip off code and tables and patch them in unless you are out of memory. You could at least make it automatic for your current location and if you move someday perhaps flash new code.
Larry Wall had it right when he said that laziness is one of the virtues of a good programmer. But he was talking about in the sense of using existing code and not creating the wheel over and over. Laziness can apply just to a clean programming style. I visit old projects after several years and often thank myself for not taking short cuts when I wrote the code. It is nice when some parameter is a #define up top and not some constant scattered here and there. Things like that.
Yes, Impatience, laziness, and hubris are useful attributes, when it comes to coding.
I fall into this trap a lot myself, I’ll start a project with the intent of making it nice and tidy, something I’d be proud enough of to share online. HOWEVER, as every technical detail pops up, it creates another rabbit hole, which I happily go down, as an opportunity for more learning.
I’ll get frustrated with spending too long on one project and then start cutting corners to “get it out of the way”, at which point I’m not enjoying the project anymore, and I’m not happy with the end result because of all the cut corners. Such is life with ADHD, I suppose.
There’s an XKCD about the fragility of hacking together scripts:
https://xkcd.com/2054/
Somewhat related
https://xkcd.com/224/
So by now xkcd is recursive: “There’s an xkcd for every xkcd…”
https://xkcd.com/1270/
Two more thoughts. One is that in many projects I do, the project is the goal itself. For this reason I write a lot of bare metal code, work up my own device drivers, and so on. If I just wanted to knock out the project in the shortest time I would use existing libraries and frameworks, but that is not the point. So you have to answer, what is the point? Maybe the point is creating your own wheel from scratch when others are available; nothing wrong with that.
The other thought is that I never relax my standards for any project. I write code for my personal projects using the same high standard I do for my professional projects. The decision, “should I cut corners here” is not an issue. I won’t ever say, I just threw that together because it was XYZ for me to use at home. Of course some peoples professional “standards” are pretty miserable, the only metric being, “I got it to work”.
And a final thought — all projects grow. What was neat and tidy in the first version becomes a mess. This is normal, and needs to be addressed (if you care, and you should). So the project will need a rewrite, maybe several. Probably not a total ground up rewrite, but maybe. This is part of the game and handling it well is one of the things that separates the men from the boys.
I can relate to every point you make; it’s exactly the same for me.
For example, instead of wiring and hot-gluing some Arduino-, or more likely, Blue-pill module with some other Ebay-modules or perf-board contraptions; I generally tend to make it a point to design a custom PCB for every project.
Why? It’s a lot of extra work; it means all projects will take 2-4 weeks instead of 2-4 hours to complete; but doing it the hard way is a goal in itself. I get to practice my PCB-skills, I can probably customize it to a smaller physical size, I can co-design the electrical and mechanical aspects – and in general, when it’s finally done – eventually – it just feels better. A solid feat instead of a quick hack.
But that’s just me; I also totally get why most ‘makers’ and people in general maybe just want something to ‘work’. However hack:y, however temporary, however proof-of-concept:y. And that’s fine; absolutely nothing wrong with that. Or even randomly copy/pasting someones existing Arduino-code without much of a clue about programming, or reading a datasheet. It’s fine, and it probably feels just as satisfying for anyone, beginner or not, that completes some small project in an afternoon or a weekend, as it feels for me to do it the over-engineered way in 50 – 100x more time.
For me, the over-engineering in itself IS a big part of the fun.
Mike wins without the slightest doubt. He can change the things that need changing with the tools available easily (ie a phone).
You, on the other hand need to remember to take an entire development environment and programmer with you whenever you go anywhere. Not practical.
If Mike has a phone, why does he need a clock?
For those times you are in an area where there is no phone coverage.
Or, when you reduce / remove all remote comms in an effort to maximise battery life.
My laptop is with me more than my cellphone, and the “development environment” is a makefile and a USB cable. These _are_ the tools easily available.
(And I bet Mike brought at least one laptop on a week’s trip to his relatives’.)
Why overcomplicate things?
I know Mike is right, and at work that’s the way I go – albeit sometimes reluctantly. But for my personal projects it’s Elliot all the way.
And my clock – it keeps suprisingly good time via the mains frequency and seldom drifting more than a minute or two between summertime changes.
My latest project code needs a tweak to the ffmpeg parameters depending on the type of film movie it is fed, and I change the code each time. I really should make that easier, better, slicker – and I will, one day. But for now another project has taken hold…
“timezone+daylight savings time”
I cannot count the number of bugs I have seen with those 2.
Too many.
My code is horrible, too. There’s a hard-coded epoch/offset and then everything else is mod-86400, because I only care about time of day, not date.
But on that topic: half of the web-based interfaces we use for Hackaday presume server time (L.A.) and the other half read your locale’s TZ somehow from the browser, and then insist on localizing it for you. Which means that I’m constantly having to do the math.
It gets really fun around the (offset) Daylight Savings Time changeovers. There was a fun bug where Soundcloud took the DST values from my Germany-based browser, but applied them to the Pacific TZ that I was scheduling the podcast to come out in. It ended up being an hour late until we figured that out…
This is an issue that I have been wrestling with for a long time. For the most part, I have two types of projects. One set is for things like my homebrew Locost car and the other are for my home. The Locost projects are generally straightforward and stand alone. Once built, coded and debugged they will likely never need to be touched again. If they break or if I need more functionality, it is usually easy to just start again. That is just as well because sometimes I can’t even find the source code after a couple of years, let alone understand it. With the house automation projects there are three issues. One is longevity: The hardware has to last at least 10 years, preferably 20. That means that you can’t really just hack the hardware even if it is one off. The second is what happens when I am not around to maintain the systems, for example when the house is sold. The third is that home automation is a complex system with many interdependent parts. All this means that home automation systems need to be built to high standards with good documentation, as little hard coding as possible and user interfaces for anything that could change over 10 or 20 years. Unfortunately, this quickly pushes the project to the point where it becomes too much to hack. In my case, it means that many of my home automation projects, although designed, are unlikely to ever be built. I have simply run out of resources. Maybe that is why a lot of hacking seems to be art projects or building “toys” as these can be “disposable”, one off projects. To some extent, open source hardware and software helps by sharing the load of creating complex, maintainable systems but that means that you have to wait until someone else has developed much of what is needed before you can build what you need. Maybe the solution is some sort of hacker “community” project system. This would be like open source but where the work is broken up into pieces with individuals taking on specific parts. Does anything like this exist?
This raises an issue I have yet to hear talked about much. Namely selling your house full of one-off hacker build home automation. This becomes pretty important when you start automating essential parts of the house. Of course we aren’t a lot better off when commercial products with cloud based “solutions” go belly up. But two wrongs don’t make a right either, as momma used to say.
I think outside of highly professional and highly integrated solutions or really simple off-the-shelf stuff, you’re best off generally assuming that home automation is ripped out when a house is sold, and plan for that by documenting how to return things to a “dumb” state where it isn’t obvious.
Jump over to GitHub, search for “smart home” and there you have it.
Larry Wall (the creator of Perl) has a view of languages that I think applies to this kind of decision: if two programming languages are Turing-complete, and therefore equivalent, we can’t compare them in terms of what they allow us to say. A more useful approach is to compare what they force us to say.. if you use C, you have to use semicolons; if you use Python, you have to use semantic whitespace, and so on.
The same principle applies to making code moddable. Instead of asking, “should I expose this control parameter to the end user?”, it’s more useful to ask, “does exposing this parameter force the user to learn it in detail before they can use the tool at all?”
Another useful question is, “what will the tool do if the user doesn’t know how to set this parameter?” Open the manpage for any ‘nix command line utility and count the command line options you couldn’t list from memory. Those are benign because the tool does something useful even if you don’t know all the alphabet soup.
An even more useful question, and one that exposes the cost of moddability to the developer, is “am I willing to write documentation that explains how to set and use this parameter without forcing the user to reverse engineer it by reading the source code?” Or, more succinctly, “am I willing to WTFM so I can say RTFM?”
(TL;DR: [Elliot] and [Mike] are both right. Or maybe both wrong.)
Essentially, what Elliot is talking about is feature creep, and it’s always a bigger issue with software than it is for hardware, because of course, “software doesn’t cost anything”. Mike’s position seems to be “do it right”, and Elliot’s is “get it done”.
But what leads most people (ME, I mean) to try to write the software for a project to be as comprehensive as possible, is the experience of having had to hack “quick and dirty” software to the point where it no longer makes sense. So yeah, you CAN modify and re-flash the clock every time you’re in a different timezone, but at some point you say, “I should have done this the right way in the first place.”
I would LIKE to take the [Mike] view of this: I DON’T want to have to re-flash my clock twice a year, and since I will eventually get tired of it and provide a mechanism that doesn’t require this, I might as well do so when the problem is first identified.
Of course, this has led to two things in my own hacking:
1) I have a now-decades-old “Grand Unified User Interface Library For All Things” project, and not that many decades left to live, and
2) I have hacks that “do the job” but nobody else in the world can figure out, because I DON’T have that GUUILFAT (see above) available.
Both of these are unacceptable! In the latter case, one example is a piece of companion software for OBS (Open Broadcast Software) that generates text to populate scoreboard graphics for live-streamed sports. The “right” way would have been to write something with a GUI interface like the commercial scoreboards have, with buttons to set, start, and stop the clock, increment or adjust the scores, and so on. But I needed it **the day after tomorrow**, so instead I wrote something that operates from the command line, that got me through the immediate need. Unfortunately, it isn’t scalable since it requires ME to be an active part of it, because nobody who didn’t write it is ever going to learn how to use it. On the [Elliot] side, I was able to re-hack this to do a proper baseball scoreboard a few months later, when THAT immediate need came up. ONE of these days I’ll hack a GUI front end onto it, and life will be good. SHOULD I have done that sometime between soccer and baseball season? Um, duh, but who has the time?
But that’s life, isn’t it. They say, “If you don’t have time do it right the first time, when will you have the time to redo it?”, but what it really comes down to is, when you really DON’T have the time to do it right, you have the choice of hacking together something that will work for now, or NOT having a solution at all. COULD I have managed to do something in javascript or Qt, instead of throwing something together in C? Maybe, but I’ve seen how even the simplest GUI projects can fall down the rabbit hole. So with a hard and close deadline, that was not an option. I simply wouldn’t have had a scoreboard when I needed it, and the hack job worked just fine, at least as far as anybody watching the stream could tell.
So yeah, I’m on both sides of this fence.
Me too! All of the above.
I tend to lean toward the “fix it once I discover how broken it is” end of things, personally.
I don’t see the relevance of the kid starting first grade.
Hardcoding stuff that could change is always a bad idea. Even in one-offs. No exceptions. You need no fancy UI. The most minimal thing you can do is to put your parameters in a text file. It’s an easy task in virtually any language and environment. So do yourself a favour and don’t hardcode things.
Just my 2ct.
The example was clocks. Not clock apps on a phone or a personal computer, just standalone clocks. These are in the class we call “embedded systems”, which at best have a few I/O lines to connect buttons and/or LEDs to a microcontroller for “user interface” purposes. No serial port, no “command” or “terminal” window. Just how do you edit the config file on such a system?
Bear with him, text file – dipswitches /jumpers/gpio
If you think ahead of your design, etc etc. Get-it-done mentality usually skips those things.
Of course if you already made the hardware, and didn’t make your unused gpios also available as config/spares, you need a software workaround. Having identified the issue you can then fix it properly.
My peeve with the ‘get it done’ mentality for dirty quick one off home projects is that is _very easily_ gets into the workplace. Doom follows :p
You’re right about the ‘get it done’ mentality, especially in the day of “we can fix any bugs in online updates”. But I think Elliot’s whole point is that maybe we shouldn’t set standards so high for projects we never intend to leave our own personal space.
And my point about embedded systems is that there is a different expectation of available resources than there is in a general-purpose computer (e.g., cellphone or home computer). Sure, there’s a functional equivalent to configuration files, which is jumpers or dipswitches, but where a text file on a computer costs practically nothing, a dipswitch actually costs something, once you include the extra PCB area and the means to make it accessible to the user. But I do agree that a clock that automatically updates from a time service, but does NOT allow for daylight savings time or even time zones, is pretty close to useless.
My point is that I can just about as easily modify
offset = 1600639200; // value from date -d “0:00” +%s
as I can
#define TIMEZONE “EU/Berlin”
include <"some abstruse TZ library, which is certainly bug-free">
tz = tz.constructor(TIMEZONE);
offset = tz.offset_getter_method();
You have to do into the code anyway. You _know_ how to go into the code anyway. Heck, you’re probably even _good_ at going into and modifying the code. What are you afraid of?
@Oliver: the workplace equivalent of “get it done” is just loading up some library that somebody recommended on Stack Overflow, figuring it probably works, and moving on.
But yeah, I totally agree that for almost all projects, it’s worth taking a little bit of time to think about what might change, and how to best handle the cost of changing with it. For me, it’s often easiest to just go back into the code and fix it. This is clearly _not_ the case when your end users aren’t coders.
@Elliot Williams said: “Dare to code for hackers! Don’t over-generalize or over-abstract. Less is more.”
Or, just have a better stocked toolbox:
1. Here’s a popular and proven drop-in solution for managing your ESP8266 WiFi settings and credentials over-the-air:
WiFiManager with ESP8266 – Autoconnect, Custom Parameter and Manage your SSID and Password:
https://randomnerdtutorials.com/wifimanager-with-esp8266-autoconnect-custom-parameter-and-manage-your-ssid-and-password/
https://github.com/tzapu/WiFiManager
2. Calculating DST roll-over dates is trivial for almost all of N. America, the UK, and EU:
http://delphiforfun.org/programs/math_topics/dstcalc.htm
https://en.wikipedia.org/wiki/Daylight_saving_time_in_the_United_States
Here is my simple N. America DST calculator demo code done in the Arduino IDE v1.8.12 and tested with a WeMos/LOLIN D1 R2 ESP8266 board. I use this code with a NTP disciplined Adafruit high accuracy MAXIM DS3231SN RTCC module. The DS3231SN chip handles leap years just fine, but like all other RTCC chips I’ve seen so far it does not do DST roll-overs:
https://pastebin.com/07VDTy7S
Note-1: I do NOT recommend buying buy cheap Amazon/Ebay/Banggood etc. Chinese DS3231x RTCC modules. I’ve tested at least a half dozen of these Chinese modules. They look like this:
* diymore DS3231 AT24C32 IIC RTC Module Clock Timer Memory Board Beats DS1307 for Arduino Without Battery Brand: diymore 4.5 out of 5 stars 61 ratings Price: $8.99:
https://www.amazon.com/gp/product/B01IXXACD0
A. In my experience many (if not most) of the Chinese DS3231 RTCC modules (like shown at the link immediately above) use the less accurate DS3231M chip, and many of those chips seem to be fake and/or rejects; they keep lousy time compared with a real DS3231M (which I have for comparison). Also, a real DS3231M chip has a MEMS oscillator which cannot be ageing compensated by the user. However, the DS3231SN chip (like used on my Adafruit DS3231 RTCC module) uses a more stable VCTCXO oscillator which can be ageing compensated by the user. But unless you you are obsessed with time-keeping, you are probably not going to be messing around with ageing compensation.
B. The cheap Chinese DS3231 RTCC modules have a simple 200 Ohm SMT series current-limit resistor followed by a series reverse-polarity protection SMT diode between Vcc and the backup battery’s positive terminal. Obviously, this simple charging circuit is designed to (badly) trickle charge a 3.6V rechargeable lithium-ion coin cell backup battery (typically an LIR2032), but ONLY when the RTCC module is powered by 3.3V. If you power the module from 5.0V, the backup battery will at best be damaged, and at worst it may explode. The solution to this mess is to remove the series resistor and/or diode from the charging circuit, then insert a non-rechargeable 3.0V coin cell backup battery (typically a CR2032). Now the RTCC module will work with either 5.0V or 3.3V and the non-rechargeable backup battery should last for years before needing replacement.
Note-2: This is the Adafruit DS3231 module I am using. (I have no affiliation with Adafruit or Amazon):
* Adafruit DS3231 Precision RTC FeatherWing – RTC Add-on For Feather Boards [ADA3028] by Adafruit $17.51:
https://www.amazon.com/gp/product/B01GQFWTTW
I see your toolbox. It takes me longer to select among tools, read the documentation, etc.
My code for the time-of-day was literally:
function get_modulo_seconds() sec, usec = rtctime.get() sec = sec - midnight sec = sec % 86400 return sec endwhere “midnight” was a defined constant # of seconds in whatever epoch/TZ/DST state you’re in, and is the result from a one-liner: date -d “0:00” +%s (That I _did_ have to look at the man page for — couldn’t remember if the time string was “-d” or “-s”, so I wrote it down in the comments.)
Works in the US. Works in the EU. As long as “date” is kept up to date. (You’ll notice that “date” has no longer been maintained when the entire Internet stops working…)
Nice….
Elliot: ..which is easier for you I’m sure, only because you WROTE that code. How many lines of code do I have to look at to find those seven? But maybe I’m not seeing the whole situation – if there was something like #define TIMEZONE_OFFSET near the top of the code, for example, and a second #define that calculates the constant used in the local time calculation, I would agree that this is pretty easy to find and adjust.
Even if you are the only person who is every going to see your code, magic numbers etc are evil.. Because there is always one other person that will be trying to understand your code – YOU in what could be quite a few years time.. .I’m still using some of the code I wrote 30 years ago (recompiled with different compilers), and if I open it up and want to change something I can tell not only what I did but why – unlike my code from 40 years ago (I don’t think any of it survives..)
Author says his code has good comments, and he can find the magic numbers quickly. Which I think is a big point in his favor. Well-commented code is easy to hack, in a couple of months from now or a couple of decades. I think his point is that if he’s the one doing the hacking on his own code, then why spend the time to set up a pretty interface? You could be spending that time on another project.
Unless of course you do it for the experience. If we didn’t enjoy the work, I think few of us would keep doing it. And that brings us back to good comments. Poorly documented code is painful to work on, so I agree with you 100% that good code is not good code until it has good comments.
Knew of a COBOL programmer, wizard class guy, super paranoid. Kept 2 copies of his code, one official copy that meet all company guidelines, but had comments and variable names that were at best misleading. And other that was easily understood that he kept private. Plus a program to translate between the two. Wizard and paranoid.
I know this post is not about clocks per se, but in case anyone is interested in clock code that contains the minimum requirements that Moryc suggests should take a look.
Moryc’s list:
1. Have an interface for setting up time, preferably hardware one. It could be done with a single button.
2. Use RTCC, preferably with battery backup.
3. Have an interface for either manually configuring the Wi-Fi, or doing it automagically.
4. Have a subroutine that seeks open Wi-Fi access points and uses them for getting current time
The code for our IOT Clock or ClockIOT has them all https://github.com/wyolum/ClockIOT.
Two clocks are combined into one “Doomsday” clock:
— RTC is implemented with the temperature compensated DS3231.
— NTP over WiFi if available is used occasionally to correct the RTC
The remaining two problmes are timezone and dailight savings time (DST). If WiFi is available, on startup and once a week early Sunday morning, the clock checks in to wyolum.com, which grabs and caches the timezone and DST status of the remote clock via ipapi.com. So once internet is established, the clock never needs to be set, even if the rules for DST change in the future. All of this can be confiured with buttons (PITA) or through a web interface.
Oh, great, so you have TWO websites that can break your code.
I was in need of a clock to see the time at night, put an old clock with dark (I said it was old) green 7-segment LED digits, about two meters from my bed. The height of the digits is 13mm, but that was not enough, without my glasses I can not see the time.
So I decided to built another clock with more readable digits, ie bigger. I took 3 8×8 matrices (sp?) where the digits is over 4 cm high and a ASP8266 module. In addition I added a blue LED for an one-LED clock as this article:
https://hackaday.com/2016/07/29/a-one-led-clock/
There is no keys at all, so was going to use a NTP-server to set the time, and here I have the same problem as Elliot: how to set the right time zone? My solution was to not use NTP but instead I wrote a simple perl script in my server that just output the current time and date.
The clock is working, still on veroboard, no case and has not left my working bench.
I can see the blinking blue LED and that is enough to read the time…
Ok Elliot your (and my problem) is soon solved, in a few year we have either CET or CEST here where we live.
My initial thought on this was “NO NO NO NO NO NO NO!”, mostly because, I have seen too much of this mentality seeping into professional life.
I do admit, however, that I have many personal hacker coded projects, where I do want to make them more professional, the time trade isn’t worth it.
In my clock, I went half way between the two of you, probably because I didn’t want to spend the time, but mine is also an alarm clock. Daylight savings handling was added after 2 years of being woke up at the wrong time. I decided I was sick of that, and implemented it. Though it has a web gui for setting the alarm time/duration/fade effect/etc, I didn’t add a timezone selector. Mostly because I never built a “case” for it, mostly because the cooling is pretty nutty (I have 30W of LED’s I’m controlling!) so it’s not portable.
That’s not to say the entire thing is magic numbers, ludicrous classes, and spaghetti code. I do have standards. I have a few abstractions that show the various iterations of the project. I also used it as a learning opportunity, so I made even the hardware way more complex than it needed to be just to get some experience…so again, interfaces and implementations for easy swapping out of various bits. It’s actually an ok project IMO, somewhere between hacker and professional. I had planned on releasing everything “some day” when it was “finished”….now its more like “some day” I might “finish it”…and of course, I have bigger and badder projects to work on :)
I do exactly the opposite. If I don’t intend to make it bulletproof, follow industry standards, and put a nice GUI on it(We’re talking months of work at least), I don’t code it at all unless I’m absolutely sure it will take less work than doing it manually, like renaming 10000 files or something.
“Hacker code” has pretty much no place in my life. I don’t want to spend my weekends debugging. And I certainly don’t want to spend my time play with sorting algorithms and obscure languages.