Reviewed a number of postings on setting up Hubitat C7 on a subnet. Most indicated a 'router' is a necessity for success. Thus the question of setup without a router.
Using a desktop Win 10 computer (running Blue Iris camera software) with a dual NIC setup. NIC-2 IPv4 is configured to obtain IP address (192.168.1.120) automatically on the Blue Iris computer along with the DNS server address. This works with three computers on a LAN for internet access.
NIC-1 IPv4 uses the following IP address (192.168.55.10) with no default gateway and no DNS server addresses. This isolates the two networks keeping the cameras isolated from the internet. NIC-1 is connected to a 24 port POE unmanaged switch which connects to a dozen IP cameras. No router is used.
The issue is how to setup Hubitat so that it can assess the cameras at 192.168.55.12 and above. Tried the static address process, but without a router on the camera side Hubitat can not find its IP address. Used 192.168.55.100 for Hubitat without success.
Hubitat would not change even after reset, reboot and power off attempts. Red, green and blue lights to boot! It stayed on (192.168.1.27)
As a test, used IE 11 on the Blue Iris computer and it can access the camera interface for each camera by using the assigned individual camera IP addresses. Also GET API HTTP commands can be sent to a specific camera to change setting by pasting the statement in the URL bar.
It it possible to setup Hubitat to access the .55 subnet? If yes, please share the process.
Note: It is not necessary to have Hubitat accessible from the LAN internet side (192.168.1.xx) only from (192.168.55.xx). The LAN side does not require the use of any Hubitat features.
You would want to use a router. Setting a /16 network would give every adress access to every subnet in your other subnet's.
So use a router, and if possible vLAN's.
As @fanmanrules points out you can use a /16 subnet (255.255.0.0) but you would have to use that subnet on all your devices which would give you a bit over 65k addresses vs the 254 addresses available on a /24 subnet (255.255.255.0). This would be impractical for segregating networks because really, you're combining them. You need to set up vlan's. This can be done with a router that has the capability or an intelligent switch that has the capability to do vlan's. The reason is that a device on one network that needs to be able to talk to another network needs to be able to have it's packets routed to the other network then the other network needs to be able to respond. Now since you have a dual nic PC you can build a routing table from the hubitat side of the network to the blue iris side by using the ROUTE command in windows . (Make sure you add -p at the end of your route to make it persistent through reboots). So lets say you have an isolated network on 10.128.40.x/24 and the cameras are on 10.128.50.x/24. If your one nic is set as 10.128.40.250 and the other nic is 10.128.40.250 you would default route everything from 40 to 50 which should allow you to have it talk to the other nat. This is very clumsy though and using vlans with restriction rules is much easier. This way you can even keep hubitat attached to the internet for updates.
Sure this can be done, but that is a very dirty option:
PC would nee to be always on
Only the PC would be able to route
Hack the PC, and you have compromised all subnets
Using a /16 subnet on all davices is possible, but think of the overhead in broadcast in your network
I use a /22 subnet (255.255.252.0) that gives me four class C networks. Seperated the IOT, PC, Portable, and misc networks. In every network I use vLAN's to grant connectivity between devices. Traffic between vLAN's is inspected and reports to my SIEM solution. So every unusual traffic is reported, and can be acted upon.
Thank you all for the suggestions. They are all most appreciated.
In reviewing, it would appear that Hubitat was not designed for use on a subnet without a router. The IP cameras can be set to any IP address without issue. That same thought process was ported over to Hubitat. However, your discussion indicates that it could be done but with difficulties and compromises.
At this point, it is best to put this issue to rest.
As a point of interest, the goal is to use Hubitat to change camera day/night operations based on LUX. Have used Hubitat to make camera changes via local sunrise and sunset which does not take into account sunny vs cloudy days. However, those operations were using a NVR (network video digital recorder) all on the same network.
There is a Windows 10 utility that will switch the cameras from day/night based on sunset/sunrise. It does work well and is presently in use. Perhaps that utility can be modified to accept a trigger from the hub to initiate either a day to night or night to day settings change. If it will, then there will be no need to deal with different networks.
I am not sure that this is accurate or what was described in this thread.
If I understand the original post correctly, What you described is having 2 separate networks, with no network connectivity (i.e. routing) between them, and wanting Hubitat on one network to communicate with cameras on the other network.
To allow Hubitat to communicate with the cameras, you either need to have a router (which perhaps could be the PC) and network routes on the devices that allows routing traffic between these networks/devices, or you need to put them all on the same LAN segment (and within the same IP subnet) so they can talk directly to each other without a router.
If your PC (or some other network device) is providing DHCP on the 192.168.55 subnet, it maybe as simple as plugging the Hubitat hub into the 24 port switch you have for that network (assuming you don't need/want internet connectivity for the Hub).
If it is not accurate then that would be good if an IP address can be setup in Hubitat without the use of a router which would be a plus for my application.
Agree, that the two networks can not talk to each other. That is on purpose to provide isolation from the camera network to the internet network on the dual NIC Windows computer.
Did not include it in the text, but did try a connection directly to the 24 port POE switch on 192.168.55.xx subnet as that is the only way there could be a connection to Hubitat. The downside, would be that FW updates would no longer be accessible as the .55 subnet has zero internet connectivity. However, periodically Hubitat could be updated by once again changing its IP address to one with internet connectivity, etc.
Also tried to setup a static IP at 192.168.55.100 for Hubitat, but Hubitat would not accept the change and remained at 192.168.1.27. Perhaps I did not implement the procedure correctly.
That's odd that you couldn't get the status IP to stick.
Either way, if your only use-case is getting a trigger from Hubitat to the PC and having the PC do something, you could most likely use EventGhost do that.
That's already the case with his setup since that particular PC already has access to both subnets. Adding in the routing just opens up the possibility for a different machine on the 192.168.1.X network to access something on the 192.168.55.X network. Static routing from just the IP of the HE to the cameras would only allow that scenario if the HE is compromised.
As said if you want hubitat on one network/sn to talk to the cameras on another network/sn yes, you will need to implement routing within your dual nic windows PC. Otherwise you will need to move hubitat to the other network physically and assign it an address on the same network/sn as the cameras. This isn't a hubitat thing, this is a TCP/IP thing. It is the nature of the best. A packet has to be told where to go and it has to be formed in such a way as to comply with tcp/ip. If it didn't do this, it would not work. So basically on the windows PC you just use ROUTE ip to tell NIC-1 to route any traffic destined for the NIC-2 segment goes through the nic 2 ip. By having no gateway on nic 1 there is no way for the traffic to go anywhere and will be stuck on that network/sn. I still say the cleaner way to do this is to get a router or switch that supports vlan then you could build rules on what's allowed where and when.
Technically you can have a wireless and a wired connection into the hub at the same time (I’ve done this for several months now to test some ideas). So in theory the hub could reside on both networks if you need it to….
How are you doing this when the hub can only handle either a hard line, or wireless dongle? I've always assumed the platform can only assign a single IP address to what ever NIC is being used (either cabled, or wifi dongle, not both at the same time)
Found out accidently (and then confirmed) that the wireless dongle doesn’t deactivate the ethernet connection. The hub will only report back one or the other (and sometimes jumps between in its reporting) but will respond to both.
Suggestions for moving the network from 192.168.1.27 to 192.168.55.100 are appreciated. What is interesting is that changing the IP address for the IP cameras does not initiate an alarm message.
When changing the camera IP address it just becomes unavailable on its old network at 192.168.1.108. When changed to say 192.168.55.22 the camera is accessible on the new network.
That is what one would expect would happen with the C7 hub when moving to a different network. The plan is how can one trick the hub into moving from one network to another? Or the other side of the coin, is that the C7 hub was never designed for this type of operation or there is an error in the TCP setup.
That's the problem, no gateway. 192.168.55.x has no where to go so the only thing it's going to ever see is stuff on the 192.168.55.x network because there is no return route back to the querying network. In order to see the other side you need to set routing using ROUTE. Once again, this isn't because of the device(s) this is because of the design of TCP/IP...If you are able to see the camera on the new network that is because it's now on the same physical segment it was. If you move that camera physically to the .55 side of the nic then you will not see it from the .1 side without there being a default gateway. A lot of what I'm saying is being oversimplified but trust me when I say, the way you're trying to set things up isn't going to work the way you want to.
