I tried
www://homeassistant.local:8193
www://192.168.1.54:8193
even through DuckDNS.
All say “Unable to connect”.
Have you tried the “idiotic” things, that sometimes helped even back in the 90s:
- clear the brwoser cache or use a private tab?
- restart HA one or two times?
Can you hook up a monitor to the HDMI port and watch it boot? See if it is getting caught up on something.
Do you have a static IP? Or is that what your router assigned? The .54 is where you found it, BUT did your backup have a static IP set?
If your IP is dynamic then I am curious how your DuckDNS hairpin is setup on your router? Is it pointing to a specific IP? Is it pointing to homeassistant.local?
It is either a network issue OR it is not fully starting.
1 Like
More times than I can count.
Did you try that or http://(insert other stuff here)
www:// is not a protocol prefix
It boots normally into the CLI.
Both are DHCP with the router set to permanent lease (static).
The what? (Hairpin)? I installed the DuckDNS Add-on and in the router set up forwarding for 443 and 8123. But, you may be on to something. Looking at the Port Forwarding table in the router, I had forgotten that the forwarding was IP specific:
This might explain why nothing I do from the network was going to get me to 192.168.1.54 because of the DuckDns add-on. It would also explain why Home Assistant automations are running.
If this theory is correct, I have a couple of ideas. (Your input would be appreciated).
Option1:
- On NUC1: Make a backup as is with DuckDNS installed.
- Remove NUC1 from the network.
- On NUC2: Install Home Assistant as before then
- Set a fixed IP on NUC2 (Settings → System → Network) to NUC1’s old IP address (192.168.1.57).
- Perform a restore from the NUC1 backup.
- Reboot.
Since NUC2 will now have the IP address of NUC1, everything should work as before.
Option2:
Change the port forwarding table in the router from 192.168.1.57 to 192.168.1.54.
I am inclined to go with Option 2. Your thoughts?
Option 1 if it’s a permanent replacement
That would be true. It also occurred to me that many of my Node Red flows are hard coded with the 192.168.1.57 address.
It was originally going to be a temporary replacement while I analyze why NUC1 was crashing every day or so. But since the NUCs are identical otherwise it makes sense to make it a permanent replacement.
Does my analysis make sense with the symptoms presented?
Edit- It just occurred to me that I should set the static IP in NUC1 to 192.168.1.57 before making the backup. This way the configuration files will be pointing to the right IP before and after.
You might try a simple ping: ‘ping 192.168.1.54’ and if that works you can ping the port: ‘telnet 192.168.1.54 8193’. if telnet connects, it will return some escape characters because it it expecting to connect to a telnet server.
Your reasoning is correct. Although I wouldn’t make any changes.
Primary use of backup will be to restore from failure and I that case you want to change as LITTLE AS POSSIBLE.
Go back to your original backup and restore it again. Using new revised plan.
Take old off network pull new on network and use whatever IP tricks you used (i use a reservation myself) to give new box old ip address. See if everything comes up ok. If not figure out why. Repeat until good.
Welcome to your first Disaster Recovery (Dr) exercise. Get good at it and then you can upgrade your HA install with impunity knowing you always have a way out.
Ping to 192.168.1.54 works, telnet not so:
steve@Gallifrey:~$ telnet 192.168.1.54 8193
Trying 192.168.1.54...
telnet: Unable to connect to remote host: Connection refused
You mean like making NUC1 a static IP before backing up? I don’t see a problem there because when restoring the backup on NUC2, it will inherit the IP of NUC1.
I’ve used backup/restore dozens of times always to save my bacon from messed up experiments. But it was always to the same host. This is the first time I tried going to a new host.
1 Like
You can if you want. My point is don’t change your behavior for this instance.
The ONLY item you missed in your original process was to not change over the IP address.
If you go static that’s fine too but it brings it’s own problems to the table (like if you accidentally forget to pull off the old box. Colissions. I like the reservation change because depending on how you’re managing IPs it becomes self correcting.)
So just add the 'I have to make sure the IP reservation is still valid) step in your restore process and repeat. Done. No changes to behavior therefore fewer accidents…)
I do prefer IP reservations myself. I can easily change the reservation for NUC2 in the router after removing NUC1- in that case it should work after that minor change.
1 Like
Here is what you should see:
==> telnet 192.168.1.137 8123
Trying 192.168.1.137…
Connected to 192.168.1.137.
Escape character is ‘^]’.
^CConnection closed by foreign host
It connects but but HA closed the connection
Did you alter the port on NUC2 during the process?
8193 is not 8123, saw the already in the initial post in step 11, but I looked like a typo. But here you are using port 8193 in the telnet command?
Armin
No. Mostly a typo or copy-paste from an original typo. In post 11, the 8193 is definitely a typo. It should read www://homeassistant.local:8123, and port 8123 is the port forwarded in my router (post 12).
I don’t normally use telnet, but I ran the test that @timj.pdx recommended. Also telnet to port 8123 failed.
I set my static and permanent, and when I do the backup it pulls in the IP I want.
i do this for a couple of reasons:
- I can always remember what it is, and it makes it easier later when you are connecting it to other items
- From my experience DNS is a finicky beast. If I can set a static IP then the name-IP DNS entries are not as disturbed, and I do not have to run around flushing DNS to find a system with the same name.
That would be option 1 from above. It would really up to you if you do a couple steps before Step 1 of setting a Static IP, and then redoing your backup.
I hope you are back up and running. My apologies, but I started down a path of MQTT, Blue Iris and motion events last night myself and haven’t finalized that.
I do appreciate your inputs. I would not have thought of looking at the IP distribution until possibly going down the wrong rabbit hole too far to get out.
I am running into a new problem- full backup is failing because of a missing file in the Media directory. But that will be in another thread.
1 Like
Marked as the solution.
The fix was remarkably simple and I am posting this for anyone else who has a similar issue.
Background:
My Home Assistant installation was on an Intel Nuc8i3. Worked great for the past three years. However, in the past couple of weeks the host has been crashing. Once or twice a day, sometimes two days between crashes. The terminal on the NUC was indicating what looked like a memory or SSD issue.
My proposed solution:
I have an identical Intel NUC8i3 that was not used often, so I thought, just install HAOS to NUC2 then restore the last backup from NUC1. I had performed restores before with no issues, and I had advised people moving to a new host to do the same. I thought I was in good company.
The problem:
I was unable to connect a browser to Home Assistant running on NUC2. Nothing worked. HA on NUC2 worked fine until the restore. The Home Assistant CLI on NUC2 worked fine. The Home Assistant Observer on port 4357 said everything was fine. Even automations and Node-RED flows were working.
The solution:
@reotto posted a question that pointed me to the problem. I am not a fan of static IP addresses, preferring to let the router make fixed IP assignments. With almost 100 devices, the router manages a few fixed IP addresses (permanent leases) and the remainder by DHCP. Both of the NUCs had fixed IP addresses in the router, so on boot NUC2 was getting it’s IP as 192.168.1.54, but all of the configurations in the restored Home Assistant was expecting the host to be at 192.168.1.57. The solution was to simply reassign the NUC2 fixed IP assignment to 192.168.1.57.
Problem solved.
Home Assistant is running on NUC2 and I can take my time analyzing why NUC1 was crashing.
Thank you to all who offered thoughts toward fixing my issue.
3 Likes