Manual configuration of a static IP can't be done from inside Hubitat C8? I read the following in documentation and figured it must be a mistake...who would remove a feature many network admins would be looking for: "Alternatively, you may specify a static IP address using Settings > Networking. This is available on model C-5 and C-7 hubs only."
How dependent is the C8 system on the cloud? Coming from HA, my intended setup is on a isolated network and using Maker API to send important messages through my own proxy out to my remote listeners instead of trusting Hubitat cloud to not have a vulnerability I can't scan for. Security just never seems to scale with company growth. I also prefer a tighter setup because the standard setup will require more frequent HE updates to stay secure. Updates themselves are often a point of instability and lost-time/headaches that I don't have to deal with when using offline first setups (or they are limited to firewall/switch update headaches). I don't intend on using Hubitat iOS or Android apps. They look good but my use case is a lot more security focused than a lot of systems so a lot more testing will need to be done since the barrier to entry for hacking systems is rapidly falling.
Is Hubitat company okay with users pen-testing their cloud servers looking for holes?
Does the dev team ever plan to operate off the concept of LTS (Long Term Support) releases? Based on the forum there have been a lot of updates (20+) this year. They look to be a mix of bug fixes and feature additions. Updates are good. New features are awesome. Yet some of us just want to stay on top of security and are happy with the features we had when the system was purchased as long as they are stable. LTS has it's drawbacks but it would be nice if users could look forward to LTS releases so that the bleeding edge users could update their systems all the time and the ones focused on security and stability can get what they need.
HE on the surface looks like a huge step forward over HA for the heart of these issues. I'm looking further than that though. I'm trying to find a path I can support as well as recommend to others for security. Right now building isolated systems on top of solutions like isolated HE installations seems like the most practical choice.
This is sort of a mistake, text written before the release of the C-8 and not caught since; it has now been fixed (thanks!). Model C-8 absolutely supports this.
You need Internet access to download hub updates (really the same way most HASS OS users get them, even though other installation methods allow for different options). You also can use Internet access for NTP (the default, but you can configure your own if you have one) and, of course, cloud features like remote Dashboard access or the use of presence and notifications through the mobile app.
Can't speak for anyone on the last two, but I suspect you won't see LTS releases given their development pattern. But you don't ever have to update, or if you do, you can certainly wait a week or few before updating to see what others report or avoid the flurry of hotfixes that often follows an initial public release). So, again similar to HASS.
The number of releases you're seeing recently is a bit skewed from normal because there was also a new hardware release, model C-8, and lots of updated builds released targeted towards some initial troubles some had with that, many related to Zigbee. This normally slows down once they begin work on the next release, which has likely happened for 2.3.5 at this point (though we don't know anything until it happens ).
It is not. What the cloud will give you is remote dashboards and platform updates. You can completely isolate Hubitat on your network and use VPN to access dashboards and configuration. Devices attached to Hubitat that use the cloud will be dependent on the cloud. For instance if you use Google Home, that will need access. I will note that backing up the hub locally does not back up either the zigbee or z-wave radio. For that you need a Hub Protect subscription which does backup to the cloud.
It is always recommended to use the latest public release as that will have bug fixes...
They've been around a long time. I don't expect them to go anywhere.
Yep and we love everyone of them. Feel free to read the change logs. The other great thing is how easy it is to roll back to a previous version. Most don't have an issue though. And on the rare instance an update has to be pulled, the fix is release within a day. Again incredibly easy to roll back.
Thanks for the info everyone. Good info @rlithgow1 on "note that backing up the hub locally does not back up either the zigbee or z-wave radio..." i missed that in the documentation notes.
Pre-C8: Z-Wave radio & Z-Wave devices are fully restored. Zigbee devices are not restored (licensing issue on the Zigbee chip in the pre-C8 models) so Zigbee devices would need to be reset/re-paired to the hub. Zigbee devices fall right back into their previous slots/automations as they are re-paired, so relatively straightforward process to get up and running.
C8: Both Z-Wave and Zigbee radio/devices are fully restored, so you're up and running w/all your devices and automations after a restore.
Cloud connection is required to create and restore cloud backups, you can't download and save a cloud backup for offline use later.
I am an IT Security consultant by trade and there is no circumstance in which I would risk doing pen tests against someone else's system without an authorizing contract in place, even if the vendor is friendly toward them. My advice for anyone thinking about it is to never pen test someone else's system without written authorization signed by someone qualified to bind the company in question.
If there's an outage with significant monetary impact, it isn't necessarily the vendor you need to worry about but rather the insurer who pays out on the claim and wants to recover their losses. They are never friendly. But that's just the civil side. The insurer's case is easier if the pen tester is criminally convicted first so many insurers won't pay unless the insured files a criminal complaint.
Unauthorized pen testing violates several federal felony laws as well as state laws. The anti-circumvention clause of the DMCA is so broad it is almost impossible to defend against, which makes filing in federal court attractive.
The worst case, for the casual or hobbyist pen tester, is to stumble across any type of regulated data (or to have the extremely bad luck to be active at the same time as an actual hacker who is siphoning off such data). Even if it is accidental, accessing regulated data raises the stakes an order of magnitude, both federally and at the state level. Keep in mind that the state violations are based not on where the company is located but where the user whose data is accessed lives. That means even a small breach can violate the privacy laws of, and opening the hacker up to charges in, dozens of states.
Fighting a suit, a criminal complaint, or (shudder) both, is nightmare that eats up a defendant's life and drains their bank account. Even if the case is won, the person loses by just having to fight. Best case is to never be in a position to defend against a charge or suit.
This is all just my opinion, of course. Plenty of casual/hobby pen testers are active and few are ever charged. My advice is to not conflate the fairly low probability of being charged with the incredibly disproportionate impact if charged.
@tdotrob good information. I didn't intend on proceeding without official word from hubitat and their silence was enough. I choose not to purchase hubitat and started building out my own system. I get the impression from all the options I've looked at that security/privacy isn't a higher priority than convenience; even for security products. That's fine for most people who don't care about all the data breaches, or don't have any security training, or aren't looking at sketchy traffic coming from the new security device they just brought into their home. Not cool to me. I'd rather take my chances in a hole away from the crowd/big-targets.
@marktheknife while AWS might have some input, I haven't heard of them (or google, digital ocean, linode, etc) having a problem with people pen testing or hiring other companies to pen test apps hosted on instances they are paying for.
As far as I know, they only have a problem if you're trying to hack AWS itself and not some user point you are paying for inside it. They'll likely not get involved unless you are trying to hack into a shared server. I get your point from the perspective that proving your intentions might be difficult if your actions look like you are targeting the AWS service and not your app inside it.
).
