Improved Zipcode handling - and clarity on what Sunrise/Sunset source being used

Okay - so thats 2 features requests.
More than I ever wanted to know...

I started my day deciding to write a SR/SS app to pull from an API so I could standardize. As I began my research I learned why Alexa is different from Google which is different from Hubitat.

There is something called 'Apparent' vs 'Actual' sunrise. The reason Alexa is 2-3 minutes off is due to Amazon's use of 'Actual' sunrise. Unlike MOST services which seem to calculate based on 'Apparent', Amazon uses Actual.
The calculation of the difference, as I understand it is based on this refractions formula:

As I understand it, my HE allows me to only enter a 5 digit zip. When I attempt to enter a 5+4 (for higher accuracy delivery segments) it truncates.
The value of handling a 5+4 would give a more precise Long / Lat without the need to have the user do it manually.

When long lat is used to position on a 5 digit zipcode, it centers on the approximate middle of the zipcode. a 9 digit (5+4) has a much higher accuracy when running any geocodelookup. For me:
97128 - returns 45.1835° N, 123.2842° W
97128-7686 - returns 45.197125 |-123.220081|
and finally a google maps "pin location" of my exact location:
returns 45.197166434968615, -123.22007453063723

The sunrise / sunset fields on the HE display would benefit by having a small note on screen that 'Apparent' is used and additionally if possible, the source of the data (assumedly a gmap call?).

In the end - in my case, I will be ignoring the Alexa sunrise / sunset triggers as they seem to be 'odd man out'. Thankfully I happen to have both Alexa and G-mini and can run triggered routines on the google mini so I don't have to write this device/app!

You didn’t answer me in the other thread you created about this, but why do your sunrise-based automations need to be accurate to less than 2-3 minutes?


No, these have been calculated locally on the hub since early 1.x firmware dayts, IIRC (and they are local now in any case).

If it's important that you have automations on different system that happen at the exact same time with regard to sunset/sunrise, I think you'd be better off by relying on one source (e.g., Hubitat) as definitive, then getting that information into the other systems via that system. In the case of Hubitat, you could expose a virtual contact or motion sensor to Alexa, then use that to trigger whatever automations (you can't use a switch, though IMHO that would make sense...). Even if you were able to get all the systems to agree on a calculation and time, you may still run into more issues--what if one system uses the top of the minute (I think Hubitat does), while another uses the exact calcualted second?

Since we can't control what formula/source every system uses, I'd start by looking at what we can control: how the automations work or why it matters. Yes, I know this isn't exactly what you're asking, but since there's no guarantee of if/when any of that may happen, I'd concentrate on what we already can do. :smiley:


How about using HE's sunrise/sunset as per your zip code settings.
If you know they are out by, say, 2 minutes, then use sunrise +2 for example in your automations. Then you will get the exact time.

Personally though, as others have said, is it really that important. For me it isn't but of course your needs may be different.
Just a thought.


Agree with this statement.

For a giggle I just checked the Weather Channel app on my phone along with Wunderground and even though both are owned by IBM the times are off by a minute. Not sure what to trust though I have never needed this level of accuracy either.


Totally agree. But since they can’t implement all feature requests, and time spent working on one is time they can’t do other things, not all requests should be prioritized.

I am genuinely curious why this is something that should matter enough to be addressed.


The times aren't always off by 2 mins. sometimes its 1 sometimes 3. I don't use sr/ss on the hub and moved all my routines to Alexa with virtual switches - that was until I found out they were wrong too.
In the end - I stopped using SR/SS as was mentioned. I just hard set the time and got rid of 2 more HE rules that way and a lot of headache.

Please keep in mind - I didn't come here for help. This is the Feedback / feature request dump. I make note here in case HE decides its worthy. I truly wish the Feedback and/or feature requests forums didn't take responses from the community. I get the HE staff having the ability to respond and make it public, but in this specific forum(s) everyone is trying to solve a problem for me as opposed to improving HE (if possible). I do appreciate the community help - I've relied on it too many times - but feedback. is feedback imho.

@bertabcd1234 That info is exactly the sort of info that should be on a help screen or in a note field under the sr/ss times! I get that folks debated this stuff before - but then didn't document it in a way that new folks can find it (or find it easily anyways). Recently was told by a well known person around here that he'd already answered a particular question. and he had. 7 months ago. digging through 1000 forum posts isn't working for me - HE forums have gotten too big and hard to sift.
Anyways. thanks for that info.

See that’s the thing. It’s unclear to me (and others I think) how this would actually improve Hubitat.

If you don’t want to discuss why you think this is important, then don’t. But you can’t reasonably expect other people not to ask a simple question: “why is this important?”

Perhaps if you sent your feature requests to staff in an email or PM, it would avoid this issue.


I used an app called GPS logger to get the exact GPS coordinates at the location of the hub itself ( this is probably as close to highly accurate, as you can get without getting into high dollar equipment) ). I verified the sunrise/set times using an app called Suntimes (btw, who knew there are so many times for sunrise, sunset ?) My general observations are that the Time the hub uses is Actual Sunset.

Where's the fun in that :wink:

I wouldn't take others questioning a request personally, ideally HE staff will (hopefully) ask themselves or each other similar questions posed here by those more experienced users....

I expect the offering of a request up for public comment and criticism provides HE staff with a valuable indicator for the acceptance amongst users, including an indicator for the number of users who may find it useful.

I can understand if you are not seeking input / solutions from "us" :slight_smile: But I can equally appreciate @marktheknife 's view that if you open the request up to the community, it is likely to encourage comments. Personally I would see commentary and questions as people having an interest in the topic and / or wanting to see an appropriate level of rigor put into the request made to HE developers, i.e. a positive indication.

The Community also can serve as a rich source of input into any request, providing the benefit of history in using the hub and history on the topic discussed here on the forum, particularly past comments and product direction provided by HE staff in the past.


Just curious, is your ZIP code that large it affects your sunrise and sunset values? I thought most ZIP were fairly compact with a few exceptions. I find this interesting that it would be noticeable to you.

This might be nice, but a note in documentation somewhere might suffice for the time being without rewriting the UI.

Not to get too far off topic, but the community can help form an idea, or give feedback for good and bad ideas. For example, if someone suggests all red and green fonts for the hub UI, the community can help the user to understand why Hubitat might not implement such a silly request, and how this might effect colorblind people.

I think the question we all have is how this really influences things. How is a couple minutes either way an issue? Can you give a more concrete example?

Is this something that needs "improving"? This is the first time I have seen someone bring this up. If this really was something that needed fixing, I would have thought someone might have brought this up before now. I am not opposed to having bugs identified and fixed, but I don't think any of us (at least not that have posted in this thread) understand why this needs improving?


I still don't understand, what the improvement would be... :no_mouth:

And if you've noticed such a difference on your hub and need more accuracy for a specific rule (and I really don't get what 3 minutes at such a big event would change), why not just implementing it in your rule?

1 Like

See that's your problem, you should be using Astrology instead...:stuck_out_tongue:


This reply is NOT targeted at any specific individual, even though specific quotes are used. They are shown only to provide context

For those genuinely interested here are a few things to consider:

HE also allows input of the ACTUAL long/lat. Using GPS coordinates will set the hub to it's specific location, not just the center of the zip code. The +4 is used for automated mail sorting *(see page 76) * and is no more geographically accurate that just the 5 digit zip.


How do I get a Unique ZIP+4®?

The ZIP+4® Code assigned by the Postal Service™ is unique for the category of Reply Mail you use. This unique ZIP+4 code enables Reply Mail to be sorted on postal automated equipment by specific size and weight (i.e., cards, 1oz. letters, 2 oz. letters, etc.). 1. Register your company and authorized users using Customer Registration.
2. Select the “Add ZIP+4 Code” option within the online Business Reply Mail (BRM) tool (accessible after clicking "Automated Business Reply Mail" upon logging on to the Business Customer Gateway).
3. Select the media type that you intend to use.
4. Provide complete delivery information for the BRM mailpieces that will be returned.
5. Submit your request.
6. The standardized delivery information (with the assigned unique ZIP+4®) will be sent to you for use on your mail piece.


Will a ZIP Code™ or ZIP+4® for a PO Box™ change? ZIP Codes for PO Boxes within the same city usually do not change. Please note that the ZIP+4 Code will likely include the actual PO Box number in the +4 part of the ZIP Code.

For further information on how ZIP Codes are assigned to PO Boxes, please contact your local Post Office™.

The ZIP Code™ or ZIP+4® where I live changed recently.

Due to an increase in population or to the improve postal operations, the US Postal Service® will occasionally add a new ZIP Code or change ZIP Code boundaries.

^^ For that reason alone I would rather use actual lat/long than an arbitrary number assigned by a government bureaucrat that could be changed at any time (unlikely, but still possible).

My casual observation (using the app I noted above) is that Hubitat also appears to use ACTUAL rather than apparent. That observation being that my sunrise/sunset rules (without any offsets) trigger in correlation to ACTUAL SUNRISE/SUNSET times listed in the Suntimes app.

From The NOAA Global Monitoring Website the definition of Apparent Sunrise/set:

  • apparent sunrise/sunset - Due to atmospheric refraction, sunrise occurs shortly before the sun crosses above the horizon. Light from the sun is bent, or refracted, as it enters earth's atmosphere. See Apparent Sunrise Figure. This effect causes the apparent sunrise to be earlier than the actual sunrise. Similarly, apparent sunset occurs slightly later than actual sunset. The sunrise and sunset times reported in our calculator have been corrected for the approximate effects of atmospheric refraction. However, it should be noted that due to changes in air pressure, relative humidity, and other quantities, we cannot predict the exact effects of atmospheric refraction on sunrise and sunset time. Also note that this possible error increases with higher (closer to the poles) latitudes.

It is really up to the individual to decide which susnrise/ sunset definition best suits their needs or use case. I would agree that APPARANT appears to be more common. A search for the term ACTUAL SUNSRISE/SUNSET yielded results discussing twilight.. I would take that to mean the time before sunrise and after sunset, in which the atmosphere is partially illuminated by the sun, being neither totally dark or completely lit. I would also note even the website in the original post states they cannot predict the exact times due to atmospheric conditions.


This goes back to my question, how does a couple of mins either way matter for an individual or for that matter Hubitat Elevation as a product? I like to think I'm a fairly intelligent person (my wife would likely disagree though) and I honestly cannot think of any home automation that it would matter unless you were a a morlock... I have friends who are very observant Jews and even they are not that dead accurate on the sabbath. I feel that @jshimota seeks to find a solution to a problem that doesn't exist and making an unneeded feature request for something so esoteric it really doesn't need to be made. That's just me though. Also @lcw731 nice find on the NOAA Definition :slight_smile:


And by doing so leave it open to discussion. I would also point out no one insulted you but you felt the need to do so...


Per OP request, this thread is providing feedback and not looking for further discussing opinions.

Download the Hubitat app