Ezlo HTTP Access no longer working on my hub

I’ve had to factory reset my Elzo Plus, and HTTP access no longer works.

After reset, I used the API tool to enable anonymous_access.enabled and insecure_access.enabled via the following JSON:

"method": "hub.offline.anonymous_access.enabled.set",
"id": "12345",
"params": { "enabled": true }


"method": "hub.offline.insecure_access.enabled.set",
"id": "12345",
"params": { "enabled": true }

I verified that access was enabled via a hub.info.get command. My response was:

offlineAnonymousAccess: true

offlineInsecureAccess: true

However, when I attempt to issue an HTTP command such as:

I get a connection refused error.

Note: I have two hubs, this command works find on one hub, just not the newly reset one. (It worked previously, so I may have missed something).

I’ve tired both wired and wireless connections.

I’ve also review the “Idiots guide”. No Luck.

I’ve tried both ports: 17000 and 17001. (Why does port 17001 work on my other hub?)


It also appears that port 17000 is closed (I’m on a wired connection right now).

% nmap -p 17000
Starting Nmap 7.94 ( https://nmap.org ) at 2024-01-27 09:35 PST
Nmap scan report for HUB90004084.lan (
Host is up (0.0087s latency).

17000/tcp closed unknown

Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds

How do I open it?


Update: I am at a complete loss… I left the hub overnight - didn’t touch it. Now, 24 hours later, the port is now open. Can you shed any light on why it took 24 hours for the hub to open the port?

Also, why is it responding to port 17000 while my other hub is responding to 17001? (Where is this configured?) It looks like both 17000 and 17001 work?


Hi @robotman,
thanks for adding details.
We are checking this case now and will back with response.

Hello, @robotman

17000 is a local mode server secure port. The https requests go there.
If insecure access is allowed, HTTP requests go there, also.

17001 is a local mode server limited insecure port. The HTTP requests (without TLS) can be handled there. It is used for HTTP links web-server, which allows plugins to create insecure HTTP endpoints for clients that can’t make HTTPS requests. The virtual host on this port is limited. It allows HTTP://hostname:port/v1/links/pligins/{plugin}/{linkId} endpoints to communicate with HTTP endpoints created by plugins.

Docs: HTTP-Server - Ezlo API Documentation

Both these ports should be up when a hub has local mode server certificates updated.

When you turn on “insecureAccess”, - the HTTP (not https) access on the secure port is started.

When you turn on the “anonymousAccess”, both these virtual hosts stop checking for the authorization header. Access without the password becomes available, I’d suggest you never to do that.

If you factory reset your hub, you can have a very old version after that. So, it depends on which version is in metal on your device. If it’s some firmware from 2019/2020, not all features were implemented compared with what hubs have now.

So, first, check the firmware version, hub type, and hub serial number.
If you see something like 2.0.1600.x - HTTP access can be unavailable on the firmware version.

If your hub received auto-update since then (24 hours ago), now you can have the latest production version, and all this started working on the hub again after that.

1 Like

Thank you. Very helpful. I have version 2.0.44….

So, when the hub is reset, it must load a local firmware version, rather than the latest over the network (that comes later)? Is there any way to “force” a hub to load the latest?

Thank you.

It seems the hub stayed on the same version after the factory reset. There was no downgrade in the version. Can’t explain this.

However, it seems that certificates that were present on the hub prevented it from setting up the local mode server. So, the virtual host serving the 17000 port wasn’t up all that time till 2024-01-28 around 4 pm.

After that date, the local mode server was finally set up.
Will investigate it more.

No, from UI there is no such way. It should be done automatically for hubs that have auto-update settings. The majority of hubs have it.