Request for devs - supporting devices NOT on local subnet


#1

Just a request for those that make apps/drivers for devices. If possible, can you add the capability to discover/connect to devices that are NOT on the local network? I know it's not possible in all cases, especially if you rely on UPnP for discovery.

My home network is split up into multiple VLANs and the Hubitat is isolated from many of my other devices.

I'm building stuff also, and I'm going to make sure I always take this into account when writing stuff.


#2

But that means that you would discover devices all over the internet making your hub very vulnerable. How are your vlans connected?


#3

No it would just mean you would have to ask what other subnets to search. Or at minimum provide a way to enter an ip address statically for a device on a different subnet.

I do the same at my house but realized that many things just aren't that smart to handle it. So I have a HA subnet where all of it lives include the google homes.


#4

Why? I don't understand the reason you would do that in your home network. I have network isolation for my guest network. Nothing except acceptable devices are allowed on my network so why would you have two of them?


#5

multiple vlans


#6

I have a work network, home network, guest, voip, and one that contains HA stuff and surveillance cams. I have some other ones that I don't currently use... Public dmz, DB, etc.

Lifx bulbs, Google home, plex, Alexa, and Sonos are on the home network because of discovery issues when putting them elsewhere.

I work in IT security, and what I have done follows best practices for segmentation and overall security architecture.


#7

Yeah...but it doesn't provide full usability of all of your devices. So, why bother having them? You really need to have everything that segmented on your home network?


#8

A related topic: Set TTL of SSDP discovery

No reply from HE though... :frowning:

As I mentioned in that thread, HE uses TTL=1 in its SSDP discovery messages, and this (nonstandard) behavior prevents using it in multi-VLAN environments (without some network magic of course). The first step would be to support other TTL values, then the drivers should be adapted to support these scenarios as well.
E.g. @djgutheinz's awesome [Release] Samsung WiFi Audio driver works fine on local subnet, but it uses the MAC address for device ID (which is null when routing is involved), so it cannot be used in multi-VLAN networks. (I'll create a pull request for him as soon as I have some free time) These kind of issues may arise in other drivers as well...


#9

My network is setup with VLANs as well. I have an IoT VLAN where all automation devices live. I use WiFi Presence on my sons smart watch and wife’s phone they are on a different VLAN I had to configure a LAN in firewall rule to allow HE to see their status. Oh also my harmonies are in that rule. I was having too much trouble using the harmony app when they were on the IoT VLAN I decided to leave them on my users VLAN.


#10

One possible solution is to get a 2nd hub and use something like HubConnect.. I know it's completely impractical for multiple vlans but just one might be doable if you have enough devices to make it worthwhile.


#11

Like @signal15, I have multiple VLANs running here:

  • Work (I work from home, so I keep all my work stuff separated from my personal stuff)
  • Home IoT
  • Home Media (Dedicated VLAN for media devices)
  • Home Phones/Laptops/Watches
  • Home Servers (RPis, PiHole, Plex, etc)
  • Printers (Because they are nothing but security risks)
  • Guest network

For security. IoT devices and printers are some of the most insecure devices available today. If someone were to hack my home IoT network, the worst they could do is mess with my lights/devices. They can't traverse to other VLANs nor can they get to things like my file server or main desktop. To further mitigate that risk, my home IoT VLAN is buried in my network behind various firewalls.

Anyone who's been in enterprise IT is most likely running a complex network setup at home.


#12

I also work in cybersecurity for a Fortune 20 company, not that any of us are here to compare credentials...

Segregation is good - up to the point that it is more burden than it is worth. And the "more than it is worth" is subjective based on the criticality and installation location. For example, a financial institution will have a different view of criticality than a home user.

In my home I have 3 VLANs - trusted (PC devices operated by humans), untrusted (IoT, printer, etc), and Guest.

I used to have it much more segregated, but I saw zero value (and a lot of time/overhead) in making it any more granular than that.

But there is no right/wrong here. If more segregation isn't too much of a burden / you are willing to work around the issues it sometimes causes - great!


#13

Show off :wink: (I kid). I do sysadmin/network administration/development for a hated county government.

I totally agree. I have my home network setup to run itself (mostly). On paper, it's a lot more complex than it really is and I have scripts and services galore to manage it for me. I know that I could get hit by a bus tomorrow and my wife would be just fine with how our network here operates itself.


#14

Nice! While my wife is a degreed Engineer, she has zero interest in understanding how anything on our home network works.

Similar to you, it is pretty hands off, so would/does carry on without me... But if it broke she wouldn't know where to start (unfortunately!).


#15

Exactly my point. The segmentation in the OPs post prevents his system from working the way he wants. So, in my mind, that would be fixed by modifying the way his network is configured rather than having Hubitat bend over backwards or modify how it works.

If the way the network is set up is preventing full function than that is what needs to be modified.


#16

It's not even a subnet/vlan thing. It won't find devices that don't share the first 3 octets. For instance I have a /16 VLAN here, 10.100.X.X. My HE hubs are on 10.100.100.X and wouldn't see my HUE and Lutron hubs on 10.100.200.X. All devices were in the same 255.255.0.0 subnet.


#17

Now THAT is a little annoying. Good thing I use /24s. :smile:


#18

How are you routing mDNS between your subnets? That's usually the issue with Hue/Lutron hubs on different VLANs.

Granted, Hue has the https://discovery.meethue.com/ url that makes discovery super simple. I don't know if Lutron supports something similar or not.

I do all my VLANs as /24 for simplicity.


#19

Between 10.100.100.x and 10.100.200.x on a /16 isn't "between subnets". It's the same subnet, same VLAN. No special routing required.


#20

Duh. You're 100% correct. I need more coffee.