Hacker News Reader

Comment by droithomme | Hacker News Reader

> What happens if the company goes out of business, Or the company decides to terminate support?

I agree with you completely. Devices that rely on external servers are not OK. My house's automation uses IoT devices that host their own servers, and/or communicate with those locally that do. I had to build them myself since no company I could find offered anything like this. I'm not a snowflake either, other engineers have done the same.

Currently, IMO, the only reasonable solution to home automation is to do everything yourself, from absolute scratch. Commercial solutions are a combination of insidious spyware and stuff that will become useless when the company becomes acquired, dies, or gets mad at you and shuts down a server.

View on HN

Servers are necessary because many users have a dynamic IP address.

If your product doesn't need to offer remote control, this isn't a problem. But for many products remote control is a significant USP.

I've built my own IoT systems, and this is one of the first problems that has to be solved.

In an IPv4 world, with domestic networks connected through NAT and a dynamic IP, external servers are going to remain a thing, because the problem cannot be solved without an external server.

If IPv6 ever really takes off every device will have its own address, and then all we'll have to worry about is building bullet proof top tier security into an SoC running some version of Linux that was last patched a few years ago.

Just run a dynamic dns server and have the client update that. Then in the client software default to using your dns infrastructure but let the user override, so when you go out of business they could set up their own dyndns and use that.

There is still the security problem of course.

> In an IPv4 world, with domestic networks connected through NAT and a dynamic IP, external servers are going to remain a thing, because the problem cannot be solved without an external server.

It can be solved, but the setup UX might not be great. Wouldn't you just have an "Advanced" UI that allows you to input the public IP address of your home network? The IoT device itself could take it from there and set up the correct firewall and forwarding rules over UPnP, or you can do it yourself. It's a one-time setup. Despite it being dynamic, how often does your ISP-provided IPV4 address actually change?

> how often does your ISP-provided IPV4 address actually change?

About once a week. This also presupposes that every customer of your home automation gets an external IP address with a router they control. What if you don't? What if you only get an internal or private IP address from your building or whatever?

Well, you can set up Dynamic DNS or (my favorite method) set up a persistent reverse SSH tunnel from the NAT-ed client to a world-facing server.

You're welcome to walk my mother through this process.

What would a venn diagram look like between people like your mother and people that want home automation? My mother is still firmly in the "why would I want an automatic garage door?" category.

I think something like an automatic garage door opener is a reasonable thing for someone to want; same with, for example, a smart HVAC system or potentially security cameras.

It obviously drops off sharply when you start getting into the Bill Gates territory where monitors on the walls adjust their artwork to suit the people currently occupying the room, or modifying the light levels, etc. But all the previously mentioned stuff seems like a reasonable thing to want, the same as an automated washing machine or a microwave oven became standard items.

Why do they require a static IP? They should be using DNS. It should be simple for any internet connected device to run dynamic DNS.

Assuming a NAT and restrictive firewall like those included in most consumer routers, DNS gets you the public IP address, but it doesn't get you a port to the client (though one may be better advised to use STUN or ICE). You'd need to punch a hole dynamically with UPnP, require the user to punch the hole manually, or introduce a relay server using something like TURN.

That's assuming you want external access.

Often the user just needs to find the device on their own internal network: in which case a DNS entry of myserialnumber.myIoT.com returning 192.168.1.104 is fine.

Or if you need need to initiate communication from outside the local network: establish a tunnel (in same style as e.g. ngrok).

Between UPnP, ICE [0], and TURN, haven't we figured this out? I'm asking for real since I've never implemented these. Undoubtedly there are some configurations where these methods fail, but I would expect they work fine on almost all consumer networks.

I understand that TURN is where you proxy the connection through a third-party server, having given up on establishing a direct connection. While that does require a third-party server, there's no reason that server necessarily has to be directly owned/operated by the company; they could set up P2P relays in their devices, and/or open-source the server software so that it could be run locally.

[0] https://tools.ietf.org/html/rfc5245

Perhaps there is a gap in the market for an independent rendezvous service that IoT devices and their controllers can connect to each other over.

Rather than baking in a dependency on the vendor of the specific device not going out of business, not stopping support for the device you bought, and not taking a dislike to you, you could depend upon an independent service that all (or at least many) IoT devices use.

Mesh overlay networks are a thing - you could very well build on them, and provide your own bootstrap hosts. The issue is that there's no incentive to learn how to manage and build that complexity into your devices and apps, vs building a simple web API.

You can use Tor Hidden Services to make your home devices accessible from the Internet:

https://github.com/n8fr8/talks/blob/master/onion_things/Inte...

This is what I'm doing also. Anything I want to access externally can be reached via an mqtt server running on an el-cheapo VPS.

No small irony (to me) that what simply the easiest method for me, is also one I can replace or migrate in a heartbeat. It's a shame there's no commercial offerings that do the same - there's not many vendors at all I trust to not sunset their service while I'm still using it.

(even giants that can afford it. I've been through dotmac / mobileme and now icloud on Apple, email has been the only service I've used for 10 years without being discontinued. Buying in to home improvements where I can't expect 10 years, isn't something I'm comfortable with)

Agree that you shoudn't be buying gadgets that rely on someone elses servers. If you are buying a gadget+service, it makes more sense to subscribe to the service and have the gadget on loan. At least when the service provider dies you can just sign up to another, and get a new gadget (e.g. how cable modems used to work).

The problem with the user setting up his own boxes is that I absolutely will not be bothered with updating the machines. So until there is a solution that lets me have internet connected machines at home that require no maintenance no matter how many years they run, then I'm out of luck.

I bought a TurtleBeach Audiotron years ago. It needed to hook up to the TurtleBeach server on powerup. Naturally, TurtleBeach turned that off at one point, bricking the Audiotron.

Fortunately, they did release a patch that bypassed the ping. I continued using it for years, and finally replaced it with a Grace Digital device, which also relies on connecting to Grace Digital on powerup. I know it'll eventually fail when GD moves on.

Also, my 35mm film cameras are now useless :-(

This also requires that you can secure the home network and server, which is something many techies (myself included) would struggle with.

Reply on news.ycombinator.com