My HA green is a brick

Installation Home Assistant OS
1

I’ve tried the reset of the operating system as they

described in the HA community forms and I’ve also tried the SD card process without any results. I checked my router for a place to make sure that the time is set correctly and there’s no functional ability to do that on a Cox modem. I don’t know what else to try, I’ve tried resetting and installing an operating system, probably 10 or 15 times and it always hangs up at the very end. Is there anybody out there that actually provides the service that can reinstall the software for me?

2

Is the optional cell battery, the one that stores the time until network NTP connectivity is functional, installed?

A simple hardware fix to a complex software problem the developers are finding difficult to remedy for a few scenarios. Until it gets a valid time, the default epoch time is 1/1/1970 for Linux on your green on power up. This is where the battery backed-up time comes in. If the time is incorrect, and not able to be updated, either via NTP on your internet connection or via the hardware clock onboard, a lot of software updates and certificate expiry comparisons may fail during the time the software updates to bring the system up to full operating status is done. This can be a lengthy process on a slow connection, taking many hours. Many beginners get impatient, and interrupt the process part way through and repeatedly start again, or fail to connect their green to a functional internet connection early enough. There have been recent changes to show installation update progress on the screen (which the green does not have… grrr!) The recommendation to leave it running overnight to catch up can be tried - most times it works.

Is your green connected to your router via Ethernet (recommended), or WiFi (not recommended as it can contribute to your scenario)?

You may need to do a bit of perusal on the green’s vendor support site (Nabu Casa) for workarounds and contact their support team for troubleshooting. This also provides valuable feedback to guide them in product improvement for the benefit of all other green users as well as yourself.

The green is heavily advertised as being able to run ‘out from the box’, appliance style. That you are experiencing difficulties may point to a faulty unit needing to be replaced under warranty.

Finally: Please come back and tell us what solved your problem so the thread can be closed and others encountering your issue can find it when searching here for clues, like you have done.

3

you can reach their support here https://support.nabucasa.com/hc/en-us/categories/24638797677853

4

The battery only keeps the time synched after the device has connected to an NTP server at least once. It’s not gonna magically grab the time if this is the first boot & connections to NTP servers are failing.

Can you elaborate on this? Do you see anything on the screen if you connect it to a monitor?

5

I Never bothered to open “The Box” to add an “Optional” Battery ( Hint: Optional for a reason )
I have had power-cuts , and accidentally unplugged it, had it down for a day etc.
Didn’t had issues on setting it up either thou, other than the “peculiar” experience of such a Device

6

When a Home Assistant Green is first set up, it needs to be connected to the Internet and needs to download updates and to get the correct time. Without the correct time, how would it know what updates to download?

The Green boots with epoch 1970 (Unix time zero) until NTP works, TLS certificates fail when the clock is wrong, the Supervisor stalls and the install appears “hung at the very end”.

Your router shouldn’t matter unless it blocks NTP in the firewall. You can test this from a Linux computer using sudo ntpdate -q pool.ntp.org on on a PC using Powershell: w32tm /stripchart /computer:pool.ntp.org /dataonly /samples:5 .

You mentioned Cox router… Most ISP‑provided routers (Cox, Comcast, Spectrum, AT&T, etc.) are low‑performance, under‑powered, and memory‑constrained. They are provided by the low-bidder and good only for the average non-technical home with no more than a couple of dozen IP clients. After 20-30 clients they run out of RAM for the routing tables.

7

Thanks to everyone who responded. I found out (with your help) that the issue was my modem/router apparently have no NTP access so I couldnt address the time issue there. But when I added a battery, it all started doing what I have been fighting for hours to do. I flashed a SD card with the files recommended and this time it worked and after taking out the SD card and starting it back up again it went to downloading updates and IOS files so now its all good! SO happy

8

To the router ???
That makes no sense. A router should not have anything to do with NTP.

9

And Why is that, what if your isp provide an ntp-service,where does that "service/setting occur ?, where do you configured which ntp-service you want ?,if your isp don’t provide this ?
Every decent ISP has a preferred NTP-provider , As well as for DNS-Service, and they caches local so often faster than the overrated google and cloud-flare etc.
Just leave everything to your Router( And ISP ), They have an interest in providing a fast reliable Service, in There Network …For their Customers

10

Battery in router? No, in the green, which lists the cell battery as “optional” but in this case was able to ‘fix’ the time issue that can cause onboarding issues.

Your router doesn’t have a NTP page in the configuration? Most do - you may stumble over it in the same panel where you set the time zone and time and date. At least the router should correctly pass time data on the standard UDP port 123, else you will have time sync challenges, overcome by the use of a battery backed RTC like provided on the green in this instance.

I strongly recommend you become familiar with your router user guide, and explore the various functionality options most vendors provide, and the original poster hinted their ISP supplied router doesn’t. Whether you have a NTP Time Server on your LAN, use the one provided by your ISP, at your national level, or just the generic one it cones with from the factory, you will agree that correct time is critical for computer operations.

NTP is hierarchical. You can select your preferred server in your configuration. If you want more information, browse RFC 958, RFC 1305, RFC 5905 and RFC 8633 for further clarity.

Telstra, Australia’s biggest telco learnt the lesson in a big way the other day, putting a large portion of the nation, including emergency calls, mobile phone calls, and internet access off the air for most of a business day. A lot of the country just ground to a halt. It seems two key NTP primary servers stopped providing correct time after an overnight software update, and the GPS 10 bit (1024 week) rollover bug threw the time back twenty years to November 2006, plunging the entire nation into chaos - business losses running into the millions, lawyers gearing up for civil claims, and potential fines in the millions from the regulator. Maybe somebody that knew NTP and the 1024 week GPS rollover bug could have saved the day, but they were probably retired during cost saving measures in the last twenty years, and the Y2K lessons forgotten?

Could a $5 button cell have saved the day for them too? Surely, finding one for Sydney, and another for the Melbourne server at the corner store shouldn’t have been too hard, even if support staff had to raid the office kitchen biscuit tin money for cash?

NTP is a simple protocol, lurking silently in the background just providing a critical service in a reliable way across the globe. Only when it breaks do we realise how important it is and how it can disrupt our lives.

11

OK, mark this point in history. I was wrong.
(I know some of you will never let me forget it).
There is an NTP server in my Omada Controller. Buried so deep in my settings that I had never seen it.

12

There are so many things deeply embedded in our modern society that we take for granted, and for the average person in the street, non-existent till they don’t work or go missing.

The Telstra fiasco is a prime example - people that wrangled the Y2K terror into a near non-event (me included) are not part of the knowledge base and collective wisdom to be able to say ‘hang on, we have a problem coming up’ based on experience. Telstra’s corporate mind has forgotten about the GPS rollover bug. Their pocket will remember clearly at the next shareholder meeting.

Turn on a tap for running water. Flick the light switch. Wait for the traffic light to go green. All background processes, extremely complicated for the layman, but running in the background 24/7/365 five-nines uptime, mission critical, but taken for granted.

For you, NTP joins the list.

Edit: For further reading, see pool.ntp.org: the internet cluster of ntp servers and https://www.ntp.org/

13

Just to straighten out a few things. ( As You keep throwing around your peculiar associations) Thou in the 2 above statements you are clear and straight forward :slight_smile:

HA-Green works great without a Battery ! , whether it’s first time it’s started(years after it left the production-line)
The Battery is only for “keeping” a synced Time(shortly !) ( which it BTW can’t, during the years it lay on the shelf’s waiting to be unpacked and plugged in )
Any OS/NIC will request an IP( If not set to Static on the NIC(OS level) , and immediately upon startup, request a time-sync over NTP protocol from a Public NTP-Server(Or equivalent updated source)

Do the factories “sync” all devices before the leave the “Factory/Store” ? , doubtful
Have you Ever setting up an old PC ( Im sure you have :wink: , Yes the Time is Not synced ! , If it has been in the closet for 1-2 decades
( Battery is dead since long, And Time is Not been “synced” with “the outer world” either ! , for years or decades )( Regardless whether the battery still has a few v/amps left, or still fully “loaded”

However the PC works regardless ( Even i.e Windows OS , parts of)( As long as you don’t try to connect it to the outer world ) NO Battery needed
And the Hardware relies only on the Hardware Clock (ticking, and “counting time”, to adjust/calculating i.e frequencies etc) NO Battery needed

HAOS, startup process:
Check Hardware, found NIC, trying to connect ( For IP and NTP )
One of the very first things it does, with in a few second/minutes

What could possible go wrong ?

Sure COX seems to SucX , the Router seems lacking of this NTP-Service settings, So the initial Routers-DHCP gives HA an IP, and The Router have to rely on COX Internal Network to receive/request an updated NTP-Timestamp
Now HA cant request an external NTP, before it gets an IP ( No devices can’t )
HA relies on firstly getting this NTP, From The Routers(DHCP), as a fallback i believe it’s Cloudflare

How ever & What ever, IF some people doesn’t have enough experience or understanding of their Hardware and Network, there could be so many “pitfalls” In the Process of setting up an Device(which rely upon NTP, like an OS) ( With both an Hardware-Clock & A Software-Clock )
I.e
How many read the install/setting-up/get started carefully before the plug it in i.e their HA-Green ?
( So they basically fire it up/plug it in to see whether it lights up/start spinning/what ever ) … Before they even think of their next move
( i.e plug in a TP-Cable, and make sure their Device has Network -connection (nor confused with internet) , HA-Green ( or Hardly any Hardware/Software “Waits” for this, It just states " Ok, this didn’t work, … waiting 90seconds,move on " ( Software Clock tick on "watch the install process :wink: )
No Many people simply don’t take “precautions” do to lack of common Network/Hardware and Services experience

Op is not in the best situation, with his COX Hardware, and best would be to buy/install a Better Router, skip their COX “Modem”
However this will not change the fact that HA-Green will work without a battery, but it wont be able to connect to other Device on the internet, which rely and depends upon correct NTP-Time ( No Devices/OS will )
Even if they have a battery they will still need the correct Time, in basically seconds, for every i.e HTTP(s)-request

I Still Doubt it was the “Battery installment” which fixed OP’s situation, most likely it was just the fact the he remove/shut down his Green, and let it “rest for while” dropping out of his Router
And when he tried again ( with battery ) , he “Unintentionally” followed the guideline in a more “structured” approach
Im sure the Battery he installed didn’t has an NTP-Updated time stamp, so in fact it was the initial NTP request which failed, most likely do to the COX Hardware/Software, or inappropriate/faulty install/setup procedure in the first place

Just to make it clear, Next time you restart your Device, the OS/Nic will request an NTP-Time, It’s not coming from the “Clock” which the Battery stores the latest it “Had” , it’s Updating it ( NO Battery needed, again )
The specific requirements or Rules/Regulations for a Device-Clock is pretty clear, but having a battery to make the “Shutdown” Hardware “Clock” ticking , without getting regularly updated for years is Absolute Not 1 of those Rules/Regulations Nor Requirements, If it’s a Device( Function/Feature ) which rely Upon NTP
Battery or Not, You need the NTP-Service to work properly in your network

14

Hi, good it got solved!
Please take the time to mark the post that holds the solution.
You do that by selecting the three dots under the post:

image

Then select the check box:

image
By doing so:

  • this thread can be useful to other users as well (this thread comes up as solution when starting a thread which is similar to yours).
  • this prevents that someone else steps in trying to help

Thanks for giving back to the community! :+1:

15

You are right, until the update process starts checking for new versions against the current known database, and package validity of the downloaded files, based on security certificates, most of which have a start date (notBefore) as well as an expiry date (notAfter). If your date is not close to recent, and are out of range, or the certificates failed to download or update, you will have a problem. Linux is not monolithic, but based on different packages that build on each layer and interoperate to make the system work. Yes, you may have a ping-able IP address (a lower level network function), but the packages have failed to install (a higher level OS function), and are not running.

You are also correct that once the date can be accessed via NTP early enough, as happens in a ‘normal’ situation for most updates, the battery is superfluous. For the few that cannot punch through that barrier, the battery is the easiest low cost solution, and so cheap it should be mandatory, not optional on the green. Every green board has the PCF8563 RTC chip soldered on, but frustratingly the optional CR2032 coin cell battery is missing as it leaves the factory. Once the onboard hardware RTC gets the date, the battery should sustain it for many years. Batteryless? NTP Failing? Back to Linux epoch (1/1/1970) each time you do a cold start, and just keep rolling if a warm start until it updates.

The Linux boot startup process checks for the hardware RTC clock, and if present, sets the software system time from it which the background processes keep running. If not present, it updates the time once it is obtained via the network using NTP, both on the hardware RTC and the system time/date registers. Background processes during normal operations that run every ten minutes or so keep the two in sync. The NTP protocol is very robust and extremely accurate, even allowing for the vaguaries of transmission time in its calculations (see the NTP RFCs for how it does this).

Some detailed tracing by the core devs for these bottlenecks may find the offending dependencies, and whether they actually need to be enforced, or the checking stage to be executed later in the update cycle when valid time is assured. The trade-off between grinding to a halt if something is corrupted and blithely continuing is always going happen. The unfortunate thing is the console display to show the errors is not present on the green for newcomers to watch the process in real time.

After spending the added money to solder a relatively expensive hardware chip on every green PCB, the tiny added cost for adding the associated CR2032 coin cell battery to make it functional should be a given, not crippling it.

Embarassingly, it is not. It should be.

16

I certainly agree on this, that is a VERY peculiar way of saving few cents , and asking New users to “Open” their New Box ( Good-bye Warranty !!! ) :laughing:

PS: They could have saved more by skipping the useless 1m TP-Cord, which every D… Brands ships with their Ethernet-Devices ( Like every Devices is supposed to be installed 1 meter from the Router, Or Switch )
I Have a bunch of those Cables, i bet we all have :roll_eyes:

17

Bundling an Ethernet cable is wise, otherwise people would opt to go for a WiFi connection in their rush to get their new toy up and running instead of finding an Ethernet cable, WiFi server connection being something not recommended, and connection before configuring your SSID challenging.

I’ve got a few cables too…

18

In that case they also “forgot” to read the install/Setup Instruction , so they might be doomed either way

BTW. the Case the Green comes in , Has a VERY basic, easy to read instruction
With big Pictures and explanations
Starting with
1 Plug in a TP cable
2 Plug in the powercable and connect it to a power outles ( i bet some takes this first …opps )
3.Wait a few minutes,until the Yellow light start to blink

And Yes i know most people follow this “Approach” , but some(actually few, if you think of how many Greens is up and running, without initial Issues) but few ends up in similar situations as OP, for Various Reasons ( As mentioned )
Maybe this procedure fails not even 1 in a 1000 times

Most Often do to User/Network issues