[FIXED] Setup Fails when using Web version of hubiVue for New Account

Saw Hubivue mentioned in the Hubitat forums and thought I’d give it a go.

Hub already has Maker API enabled for Remote & Local.
Added https://api.hubivue.com to the Allowed Hosts list.
Hub Login Security is not enabled.

Sign into hubiVue
Choose Hubitat - Via Maker API
Add my local hub IP
Detect Settings shows Maker API not found
Enter the App ID, Access Token & Cloud Token Manually

Get Local Connection Failed / Cloud Connection Failed.

Any ideas?

What platform/device is this running on?

Attempting to add it from a chrome browser via hubiVue on Windows 10. Windows 11 gave the same result.

Hi Mark,

You cannot setup hubiVue from the web browser - that’s a bug in my app that I need to display a warning message in the browser version saying this.

My app shares all the same code regardless of platform, and I missed adding some logic to detect the web browser during first time setup to stop that from trying to run on that platform.

If you install hubiVue on your phone, tablet or download the Windows versions (and allow them to install/run) it will work.


No problem. Installed the Windows application and setup completed successfully.

FWIW, even after doing so the web app doesn’t connect and continuously shows offline.
Windows app shows the dashboard fine.

That’s usually due to missing CORS entry or incorrect setup - have a read of this guide and double check everything

Double checked my setup. The CORS entry isn’t missing and points to https://api.hubivue.com.

The browser log agrees that it’s a CORS error though:

Access to XMLHttpRequest at ‘https://cloud.hubitat.com/api/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/apps/618/devices?access_token=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX’ from origin ‘https://app.hubivue.com’ has been blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.

Have you confirmed hubiVue all works on your mobile or tablet via the cloud? Those apps (non-browser) don’t require CORS and confirms the rest of the MakerAPI setup is correct.

If web doesn’t work, the only reason is that missing or incorrect CORS entry - as this configuration works everywhere else. So maybe the hub or MakerAPI on your hub is buggy or broken?

This is getting near to being a problem that only the Hubitat team can resolve given it’s mostly now all their tools and components. HubiVue just uses their API for remote access to the hub.

Not sure I can troubleshoot much further?

On a whim, I added the full web app URL into the Allowed Hosts and that did the trick.

What browser is that?

What browser is what?

The additional URL was added in the Maker API config of Hubitat.

All browsers failed prior to that change. They all worked after making the change.

You seem to have found a slightly different behaviour in a browser than what I’ve tested against (which is only the latest Chrome App on macOS Version 106.0.5249.119 (Official Build) (arm64)) when running hubiVue web app.

So I’m curious to know what specific browser software and version you are using that requires that change - it simply isn’t required on any of the hubs and browsers I’m testing with… so would be good to figure out what you are using specifically so that either I can capture that issues and add to the help notes, or determine a bug/fix if possible.

e.g here is my hub Allowed Hosts (for CORS) settings that don’t require anything special other than what I’ve mentioned in the help notes…

…and as you can see the web app works perfectly fine.


You mention casually that it is chrome on Windows 10 and Windows 11, so I’m assuming it is the very latest version of chrome for those platforms?? Correct?

I tried it on Chrome, Brave, Edge and Firefox. I didn’t check specific versions as all failed without that additional URL.

Current Platform Version of my Hub:

Definitely works as I’ve outlined and demonstrated. So can’t say why you’re not having the same luck - maybe Hubitat hub MakerAPI settings are flaky ?? Have you tried removing the CORS entry entirely and re-adding it to confirm that indeed it requires both, as that’s not how CORS works anyway, and it isn’t how it should work based on testing and other user reports