It was just brought to my attention in this post that you can now manually assign IP's to devices per bertabcd1234. If you were not able to manually assign IP's then the Hubitat could only be aware of the /24 that is was on. I also read where the Hubitat still was not able to see devices outside of a specific CIDR.
Before this people had issues with gaining access to devices that were not on the same subnet as the Hubitat. This has nothing to do with the hubitat being a switch or router. It has to do with what the Hubitat can see.
I just received my Hubitat yesterday so I have spent the last few days prior to receiving trying to read up on how to use and implement in my network. I appreciate the effort in responding to me.
There are possibilities and there are limitations. E.g. network devices that are “automatically” discovered (UPnP/ SSDP) have to be on the same subnet.
Hubitat receives it’s subnet from the DHCP server, there is no static IP setting or something similar. People use DHCP reservations to make things “static”. If your DHCP server gives out a /24 subnet than this is what hubitat knows.
There are plenty of “custom” hubitat drivers out there that talk to network devices. Just take a look at HubDuino, a user made software that allows you interact with network based Audrino boards. In these drivers, you specify the IP address of the device that Hubitat should talk to. All that hubitat cares about is that there is an IP connection, your device could be in Timbuktu and Hubitat wouldn’t care. So it also works over VLANs.
I think what most people are looking for when they ask for VLAN support is for a change in the SSDP settings to allow a higher TTL than 1. Right now, Hubitat sets this to 1 which limits it to the subnet that hubitat is in. This is really “only” required if you have something like Sonos players or a Hue bridge in a different VLAN. You network design would also need to support a TTL greater than 1.
I know that this request has been made before. I don’t know where it is from a todo list perspective but I am pretty sure that it is not high on the priority list as it is really an edge case.
There is still the question on why everyone (including me) always “jumps” on the “Why do you need VLAN” support... the reason, at least for me, is the understanding of VLAN support means. VLANs are a layer 2 level function and hubitat is really not a layer 2 level device...
I think saying "VLAN Support" isn't the correct way to say it. Basically the hubitat needs to be able to see IPs beyond the same first 3 octets that it has been assigned for people who put other devices on an IP with a different 3rd octet from the hub, even within the same VLAN.
In my case I have 10.100.0.0/16. With my hubitat on 10.100.20.5, for example, it refuses to even try to look for 10.100.30.5.
Any app I've tried in the past. Built in or third party.
A couple of examples:
Built in Alexa app won't see Alexa unless Alexa has the same first the octets.
Lutron app, won't see the pro hub unless it has the same first three octects.
Tonesto's homebridge won't be seen by the hubitat if it doesn't have the same first 3 octets.
I tried explaining this a year or so ago but it seemed no one cared so I gave up and just gave everything that needs to talk to hubitat the same first 3 octets. I haven't tried since.
Not really. SSDP discovery uses multicast packets. These packets have a TTL field that your router should decrease, and if its value is still greater than zero AND there are multicast forwarding policies configured, forward them accordingly.
But SSDP is used only to find devices with certain capabilities... usually "normal" unicast-based protocols are used afterwards.
IMHO this issue has been fixed since then, haven't tested it yet though...
So in my understanding HE supports environments where VLANs are used, because
the TTL of SSDP discovery messages can be set (and defaults to 2)
the destination IP the driver connects to can be on a different subnet - HE uses its default gw to route through.
The rest is up to the end devices and the DTH.
From an other perspective, HE can have only 1 IP address, so it makes no sense to use VLAN tagging.
Actually I have Samsung speakers on an other "VLAN". Had to modify the driver slightly, but now they can be discovered and used in HE. (I had to set up igmp-proxy in my gateway). I think we can take it as a proof-of-concept...
The switchport HE uses has to be configured to be in access mode and set to your specific (L2) VLAN id, and a DHCP server is also needed on that segment to assign the (L3) address details.
With this config, my HE (192.168.179.9) can discover and use my speakers (10.179.15.223-224). I agree with @dan.t, it's not the platform's fault...
Yeah, so if you read my post you'll see it's a /16. The ports for the hubitat and all devices I tried getting it to see are on the same VLAN. It has nothing to do with the VLAN. It's hubitat refusing to allow the third octet to be different, regardless of VLAN.
Alexa is cloud depended, it will never talk locally to Alexa for the integrated skill.
What do you mean with "won't" see? When I set up my lutron hub, I had to specify the IP address of my Lutron hub. Hubitat establishes a telnet connection to it (pure TCP). There is no lookup of lutron.
Also here, tonesto's app has no discovery.
It almost sounds like you have networking issue..... The "standard" communications are not even working....
Not blaming the user, not my intention, working on something for you right now. Sorry that it was understood that way, I just wanted to provide some background. I'll be back (probably PM) once I cleared one "little" step
I have Hubitat on a IOT dedicated VLAN and Influxdb and grafana on my main one and Hubitat correctly redirects to the default gateway to find the Influx server.
I think anyway that cstory777 issue is not VLAN related, but more to the subnet that as described is always /24 even if the DHCP one is bigger (I haven't test the scenario).
Instead I cannot completely understand mgilbert one, because at the beginning you ask for vlan support but after you say "that dramatically increases the complexity as you must now keep track of every cable and to which switch port it is plugged into" but that's the correct usage of the VLAN, if you are just using different subnets on the same VLAN, that's not VLAN but instead a poor network isolation..
Maybe multiple subnets would have been a better title.
There are times where I do not want a device to be on a different VLAN than other nearby equipment and would want the Hubitat to be able to traverse the subnets. Allowing the Hubitat to traverse the networks simplifies my setup because I am able to create rules in the firewall centrally for block and allow rather than having to create complexity with assigning untagged VLANs to devices that I may not want to be on a different network. For example, I may want my Hubitat to be on a DMZ network rather than on my LAN. There are many scenarios where people may want to segregate their devices. Sometimes it is a mobile app that must be on the same /24 as the device. Being able to have the Hubitat traverse multiple subnets opens up opportunities that more technically inclined people will have. I consider Hubitat to be a device that is for people that are more inclined to be of a higher technical level and requirement. Unlike Amazon Echo or Smartthings (Now).
I am able to create rules in the firewall centrally for block and allow rather than having to create complexity with assigning untagged VLANs to devices that I may not want to be on a different network.
That's the point: if they are all on the same VLAN, then your central firewall can't do anything to prevent that a DMZ hacked device, moved to your LAN subnet, will connect to your LAN devices.
Instead, using VLANs routed with proper rules by a central device, even if hacked it will still be in his isolated DMZ without any access to the LAN.
Sorry you lost me. If I have vlans which is what I want I can then create rules to limit connectivity between the different devices on the vlans/subnets at Layer 7. I can limit connectivity based on port, protocol, Operating system, direction etc. So if a device gets hacked in my DMZ that has access to my LAN it only has access to the devices and ports that the device needs and not the entire range of ports. A simple example is my printers are on the same subnet as my office but all my Networks/wireless networks have the ability to print to the printers IP's but that is it. They cannot manage the printers. Only TCP 9100 for RAW or TCP 515 for LPR.
