Would be great if there was a road map of up and coming features.
Is there a plan to support vlan's? I am hoping there is as this is critical to being able to use Hubitat across my entire network.
The principals have been very clear that they don't discuss road maps. That has been discussed a lot in this forums.
What would VLAN support give you?
Support for IP devices across all my subnets.
I have 4+ subnets to isolate and secure access to resources. From reading other posts the Hubitat only supports the /24 that it has an IP on. Being able to tell the Hubitat to be aware of other subnets to scan would be great. Or at least the ability to define manually IP addresses of other devices.
More and more home networking is becoming more complex and the equipment that was usually used only in business and enterprise that used to cost more is now at consumer/prosumer pricing. I would not consider Hubitat a device for the average non-technical user. It is more geared to the prosumer and more technical user. Supporting Vlans only opens up more opportunities and can actually enhance the security of the solution.
Staff have commented a few times in the past that long-term public roadmaps are a no-go. However, they will often hint at new features they are exploring (search any of Bruce's post for the string "roadmap" and you'll find dozens of examples), though with no guarantee as to timing or feasibility. They do often announce major new features shortly before release, as they just did with Rule Machine 4.0 (and with 3.0 before it). They do listen to community feedback, so if you think something is missing, search the forum to see where someone else already asked about it and what the response was, or post if you feel it hasn't already been addressed. 
I thought that was addressed in a previous firmware release, but maybe it was just this specific issue. In any case, most LAN devices in Hubitat work via you manually entering their IP address rather than by discovery, so if you allow the right kind of traffic for the devices between your vLANs and the device is set up this way, shouldn't this already work?
1 Like
Basically any of the LAN devices. My office is at home but on its own vlan/subnet. Yes technically I could assign the ports that these devices are on to the same subnet as the Hubitat but that dramatically increases the complexity as you must now keep track of every cable and to which switchoort it is plugged into.
I actually just received my device. Since there is no documentation detailing functionality I have been going through many forum posts looking for details. My question was based on forum posts discussing these issues.
I don’t see how Hubitat has anything to do with VLANs. Yes, hubitat does do some discovery especially if it is SSDP, however, SSDP won’t get to any other VLAN unless your default gateway / firewall / router is configured properly. The whole purpose of VLANs is to segregate / isolate networks. So I am not sure what you are exactly looking for. Hubitat is an end device and not a switch / router, so even if you would “tag” the other VLANs on that port that hubitat is connected to it wouldn’t see anything. I think you are trying to overlap the usage of routers / firewalls with Hubitat. IMHO, that is a bad network design.
3 Likes
Any properly configured router or firewall should be aware of the other networks and be able to route the traffic. This should be a given for anyone who is using vlans. There is also inter-vlan routing that is possible on certain switches (Layer 3). The point is it gives the ability to restrict devices on certain subnets/vlans from accessing certain other devices. For example a DMZ for public facing resources. I am unable to restrict devices from each other on the same subnet using layer 2 switches. The firewall/gateway has to do that as it generally acts as the gateway for all the vlans in a simple setup.
I agree with that statement 100%! However, Hubitat is not a switch or a router, it is an end device. That is why I don’t understand your request of VLAN support. What is it that you want to do on Hubitat with VLAN support?
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.
Ok, I see.
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...
1 Like
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.
In regard to "trying to look", which App are you referring to that does the discovery? It might be App related and not platform related.
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.
again, you're not reading... 10.100.20.5 and 10.100.30.5 are in the same 10.100.0.0/16 VLAN, no routing or proxy required.
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....
Sure, blame the user. Once again, I give up.
