MSR UI on a mobile browser

[gwp1]

@mikereadington I could be reading that wrong, but it looks like it's unhappy with the token. Have you tried recreating the token on the second Hubitat?

I'm using two Hubitats on one MSR and it works without a hitch. I did do the original recommendation of a second Maker API instance but @toggledbits advised that's no longer really necessary.

What does your configuration look like in reactor.yaml?

[toggledbits]

Url should not be https

[gwp1]

@toggledbits Totally missed that.

[MikeReadington]

@toggledbits I get that, but I don't have HTTPS populated in the config. It looks like it checks HTTP, fails, then tries HTTPS.

Here is my config.

  - id: hubitat
    enabled: true
    implementation: HubitatController
    name: A Hubitat Elevation system
    config:
      # Copy the entire URL from the Maker API app page on your Hubitat UI. A quick, easy way is to
      # right-click the "Get All Devices" link and choose "Copy link location", the paste it below.
      source: "http://10.10.10.85/apps/api/3/devices?access_token=1afd6778-a2ed-4323-9e81-f4e570d20082"
      #
      # dump_all_devices - This is for troubleshooting. Do not enable unless asked.
      dump_all_devices: false
      
  - id: hubitatshop
    enabled: true
    implementation: HubitatController
    name: Hubitat Elevation system
    config:
      # Copy the entire URL from the Maker API app page on your Hubitat UI. A quick, easy way is to
      # right-click the "Get All Devices" link and choose "Copy link location", the paste it below.
      source: "http://10.10.10.86/apps/api/1/devices?access_token=798a073c-4021-43e3-9da7-c5c4ac4f141a"
      #
      # dump_all_devices - This is for troubleshooting. Do not enable unless asked.
      dump_all_devices: false

[toggledbits]

None of this is adding up for me. You log previously shows that an attempt to connect on HTTPS is being made, and at that to the very unusual port 5001, yet your config (at least, what you've shown, which is only partial -- the error is for the controller config you have not shown us), shows HTTP and no port number. HubitatController handles the source URL very simply, and it contains no insertion of a port number (and 5001 specifically) anywhere in the code. Nor does HubitatController attempt both HTTP and HTTPS; it uses what you give it (and it expects HTTP only). So unless this is coming from hidden config, I have no idea where it's coming from. There's something more to your environment that you've disclosed here; I don't have enough information to provide you any further guidance, but based on what you've shown, in a normal (LAN, everything directly connected on the same network segment) environment this should just work as presented. But again, this isn't a complete picture, as the most vital information (config for the hub that actually is causing the error message you posted) isn't here.

EDIT: Apologies! I could not see the scroll bar on the config (off screen) on the device I'm using. I see the config for that second unit. Still, no port number. No idea where https or 5001 is coming from; these are not things HubitatController does. This isn't adding up. Hmm... is the hub redirecting? Do you have some app or setting that is forcing a redirect to HTTPS?

[MikeReadington]

Thanks Patrick,

Apologies are never necessary with me. You're on vaca, and this stuff isn't exactly running a nuclear power plant.

The MSR installation is about as vanilla as it could be. Docker on Synology, latest version, standard ports, with nothing optional added to it. The config file contains 3 Vera units (2 production, 1 test), 1 Hubitat (hopefully 2 at some point), and a weather subscription.

The network topology is also straightforward. MSR and this Hubitat are connected to the same physical switch with no VLANs in this segment. The range of 10.10.10.8X is what I use for automation devices, all devices are "on device" statically assigned, and those IPs are not within the range of the DHCP server. (I did also verify there is no duplication of IPs)

The first Hubitat (2.3.0.124) works with no issues. That unit is in service with devices and whatnot. (the Hub Information driver/device is installed)

The second Hubitat was taken out of the box, updated to 2.3.0.124, and I installed the Hub Information driver/device and the Maker API. I changed the MSR config to reflect the second unit as posted above, and here we are. I changed nothing else in this unit from out of the box, and I am 100% sure the token is accurate. When I browse to the hub over HTTP, it does not redirect to HTTPS. These two units are NOT meshed together, and if you remember back, I was the guy who had my Vera units bridged, which caused me some unexpected issues in the beginnings of MSR.

Anything I can think of that would affect the second hub should also affect the first hub, and I can't see why anything anywhere would redirect a request to HTTPS let alone an alternative port. I thought that might have been a failure model to retry with a secure connection if a failure occurred.

I know it's not magic, so something somewhere has to be doing this. @gwp1 confirmed he is using two with no issues, so it has to be something unique to me. I have been jammed up today, but I am going to take the first unit .85 out of the config and see if second one connects alone when the first is removed. If it does not, then it has to be something with that unit specifically.

Thanks again for trying to look at this, and thanks again for all you do with MSR.

[toggledbits]

OK, so let's back up to the beginning. Can you a screen shot of the local access URLs from the Maker API on the new hub?

[MikeReadington]

@toggledbits Sure

I really hope I am not missing something stupid here

[toggledbits]

Sigh. I have a suspicion. And this is why I made the posting guidelines (which you didn't follow, and I didn't catch/stop until followed)...

Are you running on a Synology NAS, or at least, you have a Synology NAS in your network?

Edit: And yes, indeed you did say that in a follow-up post (7 posts in, but really need to have the info in the head post, up front), but in any case, there's the answer: your NAS is answering on that IP address. I don't know if that's a duplication of the IP (you said you didn't, but it can happen), or maybe a misconfig of the container somehow, no idea how, but the redirect URL is exactly what/how the NAS would respond if you sent the Maker API query URL to the NAS IP address (I was able to confirm exactly that by doing it to my own Synology NAS). Double-check the configuration of everything. The NAS should not be answering on that IP if that's really your new hub (or maybe, your new hub should not be on that address...?).

[MikeReadington]

Thanks Patrick,

I am sorry I did not include everything in the first post. I know better, and for that I apologize.

There is 1 Synology NAS on site with only 1 connected network interface (10G copper) and that has a static set of IP address of 10.10.10.30. There were some test containers that were deleted from the system, but I don't know if there could still be something that could exist after a container is deleted. When I get in there tomorrow I will dig around and see what I find.

Thanks again

[MikeReadington]

I did not have time to get into this until today, and this is something Synology owners should know.

I had two test containers that were shutdown, and one of them was a test Home Assistant on .86. After deleting the container, the issue persisted. I stopped and restarted the docker service, and it worked after that. I am a little puzzled by this because the contain was in the shutdown state, but for sure that container was the issue.

[toggledbits]

Good sleuthing. That's an interesting resolution. In a way it makes sense, because I could see docker reserving the resource (a network interface and its desired address) whether the container is running or not, but it's not the obvious thing for it to do (IMO), especially given that the side-effect is to let the host OS handle requests when the guest is down. That actually seems like is has potential security implications...