8 ms·

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I w

I just blogged about this yesterday. In short: > The line in the sand for me is: network vs cloud-based systems. I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. If I choose to expose this over the internet, great! It's up to me to make sure it's secure. I don't want anyone making that decision for me. I also want it to be upgradeable, and hackable. I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying!

ksk 10y ago
> I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying! You could pay an amateur electronics hacker to make you such devices.
- CaptSpify 10y ago
  Well, I've been building my own with rpi's and whatnot. But I'd love to save time and just buy an off-the-shelf product that's been thoroughly tested, etc.
  - blacksmith_tb 10y ago
    Agreed, I am following the same route. In many cases, I want my gadgets net-enabled primarily for timekeeping, since a lot of automation for me is really scheduling (and having to manually trigger things remotely is an edge case).
bgentry 10y ago
The network model you describe sounds just like Apple's HomeKit.
- CaptSpify 10y ago
  Is that compatible with non-apple devices? I generally dislike apple philosophically, so I avoid their products.
  - Angostura 10y ago
    Yes, but Homekit enabled boxes need to be licensed and apparently need a custom chip. A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/ http://fortune.com/2015/06/09/ceo-apple-homekit-mess/
    - misterdata 10y ago
      Or you implement a HomeKit bridge in software and use that to make non-HomeKit devices available in HomeKit, e.g. using https://github.com/nfarina/homebridge https://github.com/nfarina/homebridge
    - bgentry 10y ago
      I don't believe you need a custom chip, but HomeKit does require some advanced crypto that many low-end embedded devices probably can't support. See the dependency list for this open source Go implementation of the HomeKit Accessory Protocol: https://github.com/brutella/hc#dependencies https://github.com/brutella/hc#dependencies Edit: Missed this line in the original article: The issue, according to Lombard, is that Apple HomeKit certification requires a co-processor to handle device authentication. That co-processor is where the device’s encryption key is stored and handles the computing associated with encryption. Looks like (for security purposes) Apple wants a dedicated crypto co-processor. Probably a tamper-proof chip that stores a private key, similar in concept to Apple's Secure Enclave.
  - joeblau 10y ago
    > Is that compatible with non-apple devices? Yeah, here is a list of a few products: https://support.apple.com/en-us/HT204903 https://support.apple.com/en-us/HT204903
  - bgentry 10y ago
    HomeKit works with non-Apple connected devices like lights, switches, cameras, locks, etc. Apple doesn't actually make any such devices themselves. But as far as I know, you need an iOS or tvOS device to actually run the HomeKit framework and connect the devices together.
  - 10y ago
kbenson 10y ago
Well, there's no point in waiting around for a company to make a local service their device connects to for us, since the incentive is not to deliver what we would really get the most use out of, but to deliver something that maximizes their revenue, likely though only accepting other devices of the same company, or those that have licensed access in some way. If we make a system that can be interacted with, we'll get some cheap cheap manufacturers that use it because they'll try anything, and if it catches, either we'll have a good system, or more likely, manufacturers will band together to create their own standard that's technically not as good but more likely to be supported widely. I imagine something like the following would be good: - Each component runs in it's own chroot/container/virt so the manufacturer can provide whatever they want, and the user can throttle it if it's poorly engineered. - Discovery service that allows installed network server components to register with it for discovery. (Sun's RPC service, anyone?) - Possibly also to proxy all traffic through discovery service, so network components have to specifically register for direct network access with very specific access limits if they want to use an internet service or talk to a company server. - Separate file systems exposed for the application and stored data for each app, so a memory card card can be used for the data portion, and replacing hardware is fairly simple (after base software is installed, each application will discover it's configuration and stored data from the provided memory card). Possibly even a separation between data and config as well. IP cameras can spool all their recorded video to the data partition, which might be a large attached disk, but their config can be on a separate, easily swapped memory card, for maximum choice when upgrading. - Let the manufacturers work out standardizing protocols for their industry, or not, and integrating with other apps, but let apps see the list of available apps, and request access to other ones, so devices from the same manufacturer or ones with a partnership can leverage each other. - Lots of other stuff people will come up with along the way. I imagine you could get any relatively cheap box, install the base software (linux distro of choice plus framework, or distro dedicated to this), and have it mostly work. Something like FreeNAS and similar projects. Does anyone know of any groups out there working on something like this? Maybe some docker oriented distro that aims to be super simple comes closest? Edit: Added another point or two.
chdir 10y ago
> If I choose to expose this over the internet, great! And I can't even control which of my apps should not connect to the network. There are lots of fun apps e.g. games, photo editing etc. where internet connectivity is solely needed for ads. I'm OK with that. However I don't want them uploading any personal information to their servers. I wish I could stop that.
nbadg 10y ago
Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go. I realize this isn't the whole device you want, but is that a starting point you'd be interested in?
- CaptSpify 10y ago
  That absolutely sounds like a good starting point. Any more info?
  - nbadg 10y ago
    Definitely. First a disclaimer: I've held off on creating a dedicated post for this until the code is stable (as in not crashing) enough for other people to play with the demo. That will hopefully happen tomorrow, or possibly Friday. At that point I'll be posting here on HN as well as several subreddits. Until then, I'd request it not be posted on social media, so I can maximize the impact of the potential exposure. + Golix is the name of the protocol: https://github.com/Muterra/doc-golix https://github.com/Muterra/doc-golix + Hypergolix is the background service I've written to implement it, which is backed by a PaaS on AWS: https://www.hypergolix.com https://www.hypergolix.com + This is a demo of Hypergolix: https://github.com/Muterra/py_hypergolix_demos/tree/master/echo-101 https://github.com/Muterra/py_hypergolix_demos/tree/master/e... Cheers, and thanks for the feedback!
- deleted 10y ago
  [deleted]
- DougN7 10y ago
  I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...
beamatronic 10y ago
I want a simple device like this: 1. It plugs into the wall 2. You can plug an appliance of some sort into it 3. The device has a USB interface 4. The device has a WiFi interface 5. When I plug in the device with the USB interface, it looks like a serial device 6. The device has a very simple protocol that you can use to set it up, over the serial interface 7. You can optionally have the device join a WiFi network, and you can choose to enable a simple REST web service 8. Whether you choose USB or Wifi, the device only does 3 things: a. Tell you whether it is supplying power to the appliance b. Supply power to the appliance, if not already doing so c. Stop supplying power to the appliance, if not already doing so edit:formatting
- avn2109 10y ago
  Will there be soft start, and if so do you count that as another feature?
  - matt-attack 10y ago
    Curious what you mean by "soft start"?
    - avn2109 10y ago
      E.g. water pumps or air conditioners might be sensitive to the characteristics of the current/voltage waveforms when they first turn on.
- tzs 10y ago
  If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety). The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things. Various vendors sell small modules that couple an ESP8266 with some flash memory to hold your code. These often come with built in firmware that provides a serial interface similar to the old modem "AT" interface, but with commands for WiFi. There is a free SDK available for programming the thing in C/C++. There are several firmware replacements available. There is one that brings the Arduino environment to the ESP8266. There is one that offers MicroPython. There is one that offers Lua. A solid state relay is a four terminal device. Two terminals are the control terminals, and two are the load terminals. Put a specified voltage across the control terminals, and the devices acts like a closed switch between the load terminals. If the control voltage is below the specified level, the device acts like an open switch between the load terminals. A typical SSR can handle AC voltage on the load terminals of well over what any standard household or office uses. The control voltage is typically around 3-30 V to close the virtual switch, which a logic one in a 3.3 V system (like the ESP8266) falls within, so you may be able to control the SSR directly from an ESP8266 I/O pin. (But you'd need to check the specs for the relay and make sure it doesn't require more current than the pin provides. If it does you might have to toss in a transistor to drive the relay). This would be a good first project to get started in micro controllers or IoT or home automation or home sensing.
awesomerobot 10y ago
It's absurd that an IoT device contacts a server hundreds of miles away when I'm inside my house turning on my lights via wifi.
- Domenic_S 10y ago
  Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.
  - api 10y ago
    We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4. "Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken. Here are some of the characteristics that would label a network as endpoint hostile: - "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere. - Symmetric NAT - Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config. - Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.) - Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.) - IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT). - Lack of support for local multicast or broadcast - Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL. - Badly implemented NAT ALGs for things like FTP and SIP that break other traffic. - Lack of uPnP or NAT-PMP support. - Mandatory proxy configuration. - Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc. Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons. I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.
antoniuschan99 10y ago
What do you think of this. I'm producing it: https://www.facebook.com/kokonautweathersensors/ https://www.facebook.com/kokonautweathersensors/ It's not using my network, but it's hackable enough that you can use it on your own network if you know how to flash it yourself.
- CaptSpify 10y ago
  Is it open source? that looks pretty rad. Are they available to purchase? Any plans for other devices?
  - antoniuschan99 10y ago
    What would you use this device for? I haven't released the code for it yet, but there are plenty of tutorials online. It's using NodeMCU and a DHT11. If there's more interest in hacking the device, I can provide some blogposts or tutorial videos. There are 5 available and 15-25 more are on the way. Please contact me if you're interested. I'm planning on selling it for around $35 and for the first few batches at $30 (as an early adopter discount). Email: antoniuschan99@gmail.com For personal uses, I have a waterproof temperature sensor coming in, and plan to use that for my aquarium, so maybe I will produce that version. Also I am tinkering with electrical outlets that can be remotely triggered. So you can set the weather alarm to trigger appliances.
    - CaptSpify 10y ago
      A few things: Monitor the temperature in my office (I run a few servers) Check the temperature outside. I'm close enough to a major city that everything uses that location, but often it's different from where I'm actually at. My garage. Sometimes I have paints/stains/beer/etc that shouldn't be above/below a certain temperature. I'll look at it more then email you
      - antoniuschan99 10y ago
        Cool, thanks!
roel_v 10y ago
I have that, based on zwave devices. Can be bought off the shelf, requires some tinkering to set up usually when you want to do something that's not trivial, but is as flexible as you want it to be. Can run on raspi, there are diy sets for it etc. Ppl bitch about zwave being 'proprietary' but it's open/documented enough to be hackable to your heart's content.
- CaptSpify 10y ago
  Personally, I don't want to invest into a closed platform. Hackable solutions are nice, but I've purposefully avoided zwave because they aren't open source. Maybe I'm naive, but I'm holding out for something that actually is open-source, not seems to be open source. Having never used zwave though, it sounds like your point is valid.
logicallee 10y ago
This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you bought it. (Otherwise it's not an upgrade.) So. You want to be able to enjoy upgrades. Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right? You don't want devices to stay on the latest version pushed by their companies, by default? (By default). I want to be super-clear about your thinking on this. It's a binary line in the sand. Either devices do, or they don't, upgrade by default whenever the company decides to push a version. I don't update my version of Chrome - Google does, whenever they want. I didn't set it that way. I agree it's best practice. Do you want to deny this benefit to all purchasers of all IOT devices? (Genuine question.) The conclusion I've come to is the opposite one that you've come to. I've come to the conclusion: -> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest. If the user does not disable that option: -> By default devices should ping to see if their company wants to push an update. -> If there's nothing to ping because their companies have gone out of business or the product is no longer supported, then they should stay on their current version and NOT stop working or be bricked. A Nest-like debacle shouldn't happen. Devices shouldn't be bricked by an end to support. -> If the device has its ping answered it should download the update and check that it is signed with a key in its list of accepted keys, however, only if it successfully reaches a revocation server and the revocation server does not say the key is revoked. It should have a set of possible keys, and if they have all been revoked then it should never apply another automatic update. If it can't reach the revocation server it should never apply an update. -> Since you're a hacker you can just add a file to the filesystem into the list of keys. This is fine because anyone who can read your device's filesystem in person can already do anything, such as replace the contents of the file after it has been checked, verified, and decrypted, but before being run. So this is not a vector that concerns us. This means that code-signing doesn't destroy anything of your own control over your own device, nor place an inordinate burden on you. -> Once a signed update has been received it will just be run as root regardless of its contents. In practice what the scripts should do is copy the current filesystem to an Updated filesystem, then use the scripts to modify the Updated filesystem. It should then issue a reboot command and the device firmware should attempt to reboot into the Updated filesystem. If successful and tests pass then the Updated filesystem becomes Current. If it fails then after a while the firmware will reboot to the old version. The device in this case (via scripts) reports to the server, by encrypting with the non-revoked key, that its update failed. It will then go back to pinging for updates as normal. The server can choose whether and when to push another update, or what other update to push. So if devices in the field are failing to update then the server operator can turn off the push of the updates and fix the problem. That's it. This is the architecture that I envision. What do you think? It's the exact OPPOSITE conclusion from the one you've reached. It is far, far beyond the line in the sand that you've drawn. But your line in the sand means you want the benefits of upgrades, but you want your non-technical dad (or mom), grandparent, non-technical boyfriend or girlfriend, cousin, all the people buying the device and driving the price down for you, not to enjoy upgrade benefits. Are you sure this is what you want? Positive?
deleted 10y ago
[deleted]
ultramancool 10y ago
I'd argue that these guys are actually supplying. Just firewall it out to a specific network segment for these devices, have one box that interacts with it and modify it to your own liking, you have root on it afterall. They're dirt cheap, they work, and you get root so it's completely upgradable and hackable. Can't beat that really if you have decent security practices outside of the device. It's definitely an investment in terms of time to beat it into shape, but it sounds like a fun weekend project to me.
- CaptSpify 10y ago
  heh, that's actually what I kind of do now with a couple of devices. Then I ban that vlan from the internet. I'm speaking more in general though: Too many IoT devices require cloud access to work properly. I don't want to put a hacky solution together, I'd rather things would out of the box. I don't like the idea of having to be defensive against my own equipment.
  - TeMPOraL 10y ago
    That's the part of the business model. IoT isn't about giving you some value - it's an extension of SaaS, but with the twist that it has to convince you to give service provider some value that they can then sell back to you. Personally, I consider most of IoT products to be a waste of resources used to create them. It's a blatant promotion of shitty engineering in an attempt to get some money out of people.
api 10y ago
We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/ https://www.zerotier.com/ ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.
- CaptSpify 10y ago
  Interesting. So this would be something you set up on an existing device?
  - api 10y ago
    You could install it on a device and then remotely access it. The software handles a lot of complexity for you. We're working with several vendors about incorporating it as a network layer and then using our (to be released soon) SDK to allow iOS/Android apps to directly access things.
npsimons 10y ago
So totally this. I refused to buy a Nest for exactly this reason. In the words of the Cluetrain manifesto: 'We are not seats or eyeballs or end users or consumers. We are human beings - and our reach exceeds your grasp. Deal with it.' I'm not here to be monetized by being glued to the hip to your infrastructure that may go away for any number of reasons (technical or non) and make my property suddenly stop working.
shrugger 10y ago
Sounds like you want better hardware. Which is what we ALL want.
StillBored 10y ago
I'm in the same boat... Spent a couple years looking for a wifi thermostat that didn't require a cloud service. Actually I purchased a couple and hacked on them, but never hooked any of them up to my AC unit. Granted I had some pretty specific requirements (long list having to do with multiple zones/etc). Not to long ago I settled for a couple of the venstar T7900's. They aren't perfect by any means, but they are light years ahead of anything else I could find. In fact they have a whole bunch of options that harken back to some of the early programmable thermostats. For example, out of the box you can control the max cycles/hour, or the number of degrees of variance from the setpoints. Buried in the menus are a wealth of options, including a few for limiting features available to "unprivileged" users. Funny enough, they can be subscribed to the power companies remote kill features, but the user is still in control and can disable the feature, which is probably why they are excluded from my power companies list of "smart" thermostats that qualify for rebates. So, the cloud service can do a lot of things that aren't available from the published API, but running a local deamon and polling runtimes, setpoints, etc is all very straightforward, as is forcing a thermostat on/off from a server on the local network. Anyway, that is my .02 for a thermostat that isn't owned by $megacorp/etc and can be disabled at the wim of a company that decides paying for a bunch of cloud servers is no longer in their interest.

ksk 10y ago

> I'm willing to pay a lot of money for standalone quality devices, but nobody is supplying! You could pay an amateur electronics hacker to make you such devices.

CaptSpify 10y ago
Well, I've been building my own with rpi's and whatnot. But I'd love to save time and just buy an off-the-shelf product that's been thoroughly tested, etc.
- blacksmith_tb 10y ago
  Agreed, I am following the same route. In many cases, I want my gadgets net-enabled primarily for timekeeping, since a lot of automation for me is really scheduling (and having to manually trigger things remotely is an edge case).

bgentry 10y ago

The network model you describe sounds just like Apple's HomeKit.

CaptSpify 10y ago
Is that compatible with non-apple devices? I generally dislike apple philosophically, so I avoid their products.
- Angostura 10y ago
  Yes, but Homekit enabled boxes need to be licensed and apparently need a custom chip. A look at the practicalities here: http://fortune.com/2015/06/09/ceo-apple-homekit-mess/ http://fortune.com/2015/06/09/ceo-apple-homekit-mess/
  - misterdata 10y ago
    Or you implement a HomeKit bridge in software and use that to make non-HomeKit devices available in HomeKit, e.g. using https://github.com/nfarina/homebridge https://github.com/nfarina/homebridge
  - bgentry 10y ago
    I don't believe you need a custom chip, but HomeKit does require some advanced crypto that many low-end embedded devices probably can't support. See the dependency list for this open source Go implementation of the HomeKit Accessory Protocol: https://github.com/brutella/hc#dependencies https://github.com/brutella/hc#dependencies Edit: Missed this line in the original article: The issue, according to Lombard, is that Apple HomeKit certification requires a co-processor to handle device authentication. That co-processor is where the device’s encryption key is stored and handles the computing associated with encryption. Looks like (for security purposes) Apple wants a dedicated crypto co-processor. Probably a tamper-proof chip that stores a private key, similar in concept to Apple's Secure Enclave.
- joeblau 10y ago
  > Is that compatible with non-apple devices? Yeah, here is a list of a few products: https://support.apple.com/en-us/HT204903 https://support.apple.com/en-us/HT204903
- bgentry 10y ago
  HomeKit works with non-Apple connected devices like lights, switches, cameras, locks, etc. Apple doesn't actually make any such devices themselves. But as far as I know, you need an iOS or tvOS device to actually run the HomeKit framework and connect the devices together.
- 10y ago

kbenson 10y ago

Well, there's no point in waiting around for a company to make a local service their device connects to for us, since the incentive is not to deliver what we would really get the most use out of, but to deliver something that maximizes their revenue, likely though only accepting other devices of the same company, or those that have licensed access in some way. If we make a system that can be interacted with, we'll get some cheap cheap manufacturers that use it because they'll try anything, and if it catches, either we'll have a good system, or more likely, manufacturers will band together to create their own standard that's technically not as good but more likely to be supported widely. I imagine something like the following would be good: - Each component runs in it's own chroot/container/virt so the manufacturer can provide whatever they want, and the user can throttle it if it's poorly engineered. - Discovery service that allows installed network server components to register with it for discovery. (Sun's RPC service, anyone?) - Possibly also to proxy all traffic through discovery service, so network components have to specifically register for direct network access with very specific access limits if they want to use an internet service or talk to a company server. - Separate file systems exposed for the application and stored data for each app, so a memory card card can be used for the data portion, and replacing hardware is fairly simple (after base software is installed, each application will discover it's configuration and stored data from the provided memory card). Possibly even a separation between data and config as well. IP cameras can spool all their recorded video to the data partition, which might be a large attached disk, but their config can be on a separate, easily swapped memory card, for maximum choice when upgrading. - Let the manufacturers work out standardizing protocols for their industry, or not, and integrating with other apps, but let apps see the list of available apps, and request access to other ones, so devices from the same manufacturer or ones with a partnership can leverage each other. - Lots of other stuff people will come up with along the way. I imagine you could get any relatively cheap box, install the base software (linux distro of choice plus framework, or distro dedicated to this), and have it mostly work. Something like FreeNAS and similar projects. Does anyone know of any groups out there working on something like this? Maybe some docker oriented distro that aims to be super simple comes closest? Edit: Added another point or two.

chdir 10y ago

> If I choose to expose this over the internet, great! And I can't even control which of my apps should not connect to the network. There are lots of fun apps e.g. games, photo editing etc. where internet connectivity is solely needed for ads. I'm OK with that. However I don't want them uploading any personal information to their servers. I wish I could stop that.

nbadg 10y ago

Would you feel comfortable with end-to-end encryption via an open, documented, free protocol? This is literally my raison d'être as a company, so I'd be interested to hear your comfort level. What I've got is a platform that 1.) makes it substantially easier for IoT developers to get their devices to market and 2.} enforces end-to-end encryption and affirmative consensual sharing. It works by running as a background service on both the IoT device and on any connecting computers. In a similar vein to IPFS, the service magically switches between local and nonlocal networks dynamically, so it doesn't matter if your interent connection goes out; as long as you have power (and a local server set up, but I'd like to add P2P capability over LAN in the near future) you're good to go. I realize this isn't the whole device you want, but is that a starting point you'd be interested in?

CaptSpify 10y ago
That absolutely sounds like a good starting point. Any more info?
- nbadg 10y ago
  Definitely. First a disclaimer: I've held off on creating a dedicated post for this until the code is stable (as in not crashing) enough for other people to play with the demo. That will hopefully happen tomorrow, or possibly Friday. At that point I'll be posting here on HN as well as several subreddits. Until then, I'd request it not be posted on social media, so I can maximize the impact of the potential exposure. + Golix is the name of the protocol: https://github.com/Muterra/doc-golix https://github.com/Muterra/doc-golix + Hypergolix is the background service I've written to implement it, which is backed by a PaaS on AWS: https://www.hypergolix.com https://www.hypergolix.com + This is a demo of Hypergolix: https://github.com/Muterra/py_hypergolix_demos/tree/master/echo-101 https://github.com/Muterra/py_hypergolix_demos/tree/master/e... Cheers, and thanks for the feedback!
deleted 10y ago
[deleted]
DougN7 10y ago
I've been debating about hooking my garage door opener up using a built-in feature so I could open the door from my iPhone. I don't trust that whatever central site I'll be connected to is safe. If I _knew_ the vendor had implemented your protocol/software well, and I _knew_ your software was safe, yeah, I'd use it. But I don't know those two things, so no way am I hooking my home's door up to the Internet...

beamatronic 10y ago

I want a simple device like this: 1. It plugs into the wall 2. You can plug an appliance of some sort into it 3. The device has a USB interface 4. The device has a WiFi interface 5. When I plug in the device with the USB interface, it looks like a serial device 6. The device has a very simple protocol that you can use to set it up, over the serial interface 7. You can optionally have the device join a WiFi network, and you can choose to enable a simple REST web service 8. Whether you choose USB or Wifi, the device only does 3 things: a. Tell you whether it is supplying power to the appliance b. Supply power to the appliance, if not already doing so c. Stop supplying power to the appliance, if not already doing so edit:formatting

avn2109 10y ago
Will there be soft start, and if so do you count that as another feature?
- matt-attack 10y ago
  Curious what you mean by "soft start"?
  - avn2109 10y ago
    E.g. water pumps or air conditioners might be sensitive to the characteristics of the current/voltage waveforms when they first turn on.
tzs 10y ago
If you are OK with building it yourself, you could do this with an ESP8266, a USB to serial cable, a solid state relay, a power brick, and some miscellaneous things like a power cord and a socket (and ideally some case to put all this in for safety). The ESP8266 is a micro controller with built in WiFi and network stack and a serial interface, and several digital I/O pins you can use to interface to other things. Various vendors sell small modules that couple an ESP8266 with some flash memory to hold your code. These often come with built in firmware that provides a serial interface similar to the old modem "AT" interface, but with commands for WiFi. There is a free SDK available for programming the thing in C/C++. There are several firmware replacements available. There is one that brings the Arduino environment to the ESP8266. There is one that offers MicroPython. There is one that offers Lua. A solid state relay is a four terminal device. Two terminals are the control terminals, and two are the load terminals. Put a specified voltage across the control terminals, and the devices acts like a closed switch between the load terminals. If the control voltage is below the specified level, the device acts like an open switch between the load terminals. A typical SSR can handle AC voltage on the load terminals of well over what any standard household or office uses. The control voltage is typically around 3-30 V to close the virtual switch, which a logic one in a 3.3 V system (like the ESP8266) falls within, so you may be able to control the SSR directly from an ESP8266 I/O pin. (But you'd need to check the specs for the relay and make sure it doesn't require more current than the pin provides. If it does you might have to toss in a transistor to drive the relay). This would be a good first project to get started in micro controllers or IoT or home automation or home sensing.

awesomerobot 10y ago

It's absurd that an IoT device contacts a server hundreds of miles away when I'm inside my house turning on my lights via wifi.

Domenic_S 10y ago
Apparently this is kind of a hard thing to handle. I battle with this and PS4 Remote Play -- about 80% of the time, RP will give up looking on my local network and go out to the internet to find my PS4... which is right here on the same network. If I cancel it and retry a few times it always ends up seeing it but man what a pain.
- api 10y ago
  We've been using the term "endpoint hostile" to describe how networks are typically deployed, especially with IPv4. "Endpoint hostile" networks are designed with a single use case in mind: accessing remote servers, usually via HTTP/HTTPS. Other use cases are prohibited or broken. Here are some of the characteristics that would label a network as endpoint hostile: - "Device isolation," which prohibits local LAN device communication. This is common on some WiFi networks. It's forgivable on a public WiFi but not elsewhere. - Symmetric NAT - Multiple levels of nested NAT e.g. consumer routers plugged into consumer routers. It's important to note that this makes everything flaky due to weird interactions and timeout behaviors. In our experience it's disturbingly common. We talked to one person whose company had at least five levels of this, requiring things like "ServerAliveInterval 10" in ssh_config. - Lack of support for NAT hairpinning. (NAT can't NAT-traverse with itself.) - Short NAT/firewall stateful connection timeout (120s is the RFC recommendation, but 30-60s is common and we've seen 15.) - IPv6 absent (assuming it's available upstream) or deployed in a silly way (e.g. IPv6 NAT). - Lack of support for local multicast or broadcast - Aggressive edge firewall rules that prohibit UDP, non-standard TCP ports, etc. or that DPI traffic and attempt to block anything other than HTTP, SSH, and SSL. - Badly implemented NAT ALGs for things like FTP and SIP that break other traffic. - Lack of uPnP or NAT-PMP support. - Mandatory proxy configuration. - Middle boxes that modify traffic in general. This includes things that bork TCP in a misguided attempt to "optimize" it, things that inject HTTP headers (or worse JavaScript), things that modify DNS to strip A/AAAA records for "private" IPs or strip TXT records, etc. Some of this stuff is just stupidity or brokenness, but much of it is implemented for "security" reasons. I personally consider reliance on network edge controls for security to be a borderline-obsolete cargo cult practice, since the vast majority of today's vulnerabilities and attack vectors are unaffected by it and involve things like cloud services, e-mail, web, app updates, etc. I've worked in netsec/infosec and have seen a number of intrusions, and so far I have yet to see one in the past 10 years that was mitigated in any way by the presence of a firewall. Yet a generation of IT people thinks "firewall equals security" and I'm increasingly thinking this generation will have to just pass along.

antoniuschan99 10y ago

What do you think of this. I'm producing it: https://www.facebook.com/kokonautweathersensors/ https://www.facebook.com/kokonautweathersensors/ It's not using my network, but it's hackable enough that you can use it on your own network if you know how to flash it yourself.

CaptSpify 10y ago
Is it open source? that looks pretty rad. Are they available to purchase? Any plans for other devices?
- antoniuschan99 10y ago
  What would you use this device for? I haven't released the code for it yet, but there are plenty of tutorials online. It's using NodeMCU and a DHT11. If there's more interest in hacking the device, I can provide some blogposts or tutorial videos. There are 5 available and 15-25 more are on the way. Please contact me if you're interested. I'm planning on selling it for around $35 and for the first few batches at $30 (as an early adopter discount). Email: antoniuschan99@gmail.com For personal uses, I have a waterproof temperature sensor coming in, and plan to use that for my aquarium, so maybe I will produce that version. Also I am tinkering with electrical outlets that can be remotely triggered. So you can set the weather alarm to trigger appliances.
  - CaptSpify 10y ago
    A few things: Monitor the temperature in my office (I run a few servers) Check the temperature outside. I'm close enough to a major city that everything uses that location, but often it's different from where I'm actually at. My garage. Sometimes I have paints/stains/beer/etc that shouldn't be above/below a certain temperature. I'll look at it more then email you
    - antoniuschan99 10y ago
      Cool, thanks!

roel_v 10y ago

I have that, based on zwave devices. Can be bought off the shelf, requires some tinkering to set up usually when you want to do something that's not trivial, but is as flexible as you want it to be. Can run on raspi, there are diy sets for it etc. Ppl bitch about zwave being 'proprietary' but it's open/documented enough to be hackable to your heart's content.

CaptSpify 10y ago
Personally, I don't want to invest into a closed platform. Hackable solutions are nice, but I've purposefully avoided zwave because they aren't open source. Maybe I'm naive, but I'm holding out for something that actually is open-source, not seems to be open source. Having never used zwave though, it sounds like your point is valid.

logicallee 10y ago

This is a genuine question, and I think I've come to the opposite conclusion as you. You write: >I want things to be network connected, but I want it for my own network only. I want to be able to control my coffee pot, but only from home. and >I also want it to be upgradeable, So let's be super-super clear. You do want it to be upgradeable. That means you want it to be able to be better in the future than the day you bought it. (Otherwise it's not an upgrade.) So. You want to be able to enjoy upgrades. Meanwhile, are you sure that you 100% definitely want non-technical users who plug in the device and never want to take any further action, to ever enjoy the benefits of any automatic upgrade they don't need to know or touch or think about? You want to monopolize upgrades for hackers, and deny them to 99.999% of world's population, right? You don't want devices to stay on the latest version pushed by their companies, by default? (By default). I want to be super-clear about your thinking on this. It's a binary line in the sand. Either devices do, or they don't, upgrade by default whenever the company decides to push a version. I don't update my version of Chrome - Google does, whenever they want. I didn't set it that way. I agree it's best practice. Do you want to deny this benefit to all purchasers of all IOT devices? (Genuine question.) The conclusion I've come to is the opposite one that you've come to. I've come to the conclusion: -> The default settings should have an option "Stay on latest version. Upgrades will be applied automatically." You as a hacker can turn it off to instead get the behavior you suggest. If the user does not disable that option: -> By default devices should ping to see if their company wants to push an update. -> If there's nothing to ping because their companies have gone out of business or the product is no longer supported, then they should stay on their current version and NOT stop working or be bricked. A Nest-like debacle shouldn't happen. Devices shouldn't be bricked by an end to support. -> If the device has its ping answered it should download the update and check that it is signed with a key in its list of accepted keys, however, only if it successfully reaches a revocation server and the revocation server does not say the key is revoked. It should have a set of possible keys, and if they have all been revoked then it should never apply another automatic update. If it can't reach the revocation server it should never apply an update. -> Since you're a hacker you can just add a file to the filesystem into the list of keys. This is fine because anyone who can read your device's filesystem in person can already do anything, such as replace the contents of the file after it has been checked, verified, and decrypted, but before being run. So this is not a vector that concerns us. This means that code-signing doesn't destroy anything of your own control over your own device, nor place an inordinate burden on you. -> Once a signed update has been received it will just be run as root regardless of its contents. In practice what the scripts should do is copy the current filesystem to an Updated filesystem, then use the scripts to modify the Updated filesystem. It should then issue a reboot command and the device firmware should attempt to reboot into the Updated filesystem. If successful and tests pass then the Updated filesystem becomes Current. If it fails then after a while the firmware will reboot to the old version. The device in this case (via scripts) reports to the server, by encrypting with the non-revoked key, that its update failed. It will then go back to pinging for updates as normal. The server can choose whether and when to push another update, or what other update to push. So if devices in the field are failing to update then the server operator can turn off the push of the updates and fix the problem. That's it. This is the architecture that I envision. What do you think? It's the exact OPPOSITE conclusion from the one you've reached. It is far, far beyond the line in the sand that you've drawn. But your line in the sand means you want the benefits of upgrades, but you want your non-technical dad (or mom), grandparent, non-technical boyfriend or girlfriend, cousin, all the people buying the device and driving the price down for you, not to enjoy upgrade benefits. Are you sure this is what you want? Positive?

deleted 10y ago

[deleted]

ultramancool 10y ago

I'd argue that these guys are actually supplying. Just firewall it out to a specific network segment for these devices, have one box that interacts with it and modify it to your own liking, you have root on it afterall. They're dirt cheap, they work, and you get root so it's completely upgradable and hackable. Can't beat that really if you have decent security practices outside of the device. It's definitely an investment in terms of time to beat it into shape, but it sounds like a fun weekend project to me.

CaptSpify 10y ago
heh, that's actually what I kind of do now with a couple of devices. Then I ban that vlan from the internet. I'm speaking more in general though: Too many IoT devices require cloud access to work properly. I don't want to put a hacky solution together, I'd rather things would out of the box. I don't like the idea of having to be defensive against my own equipment.
- TeMPOraL 10y ago
  That's the part of the business model. IoT isn't about giving you some value - it's an extension of SaaS, but with the twist that it has to convince you to give service provider some value that they can then sell back to you. Personally, I consider most of IoT products to be a waste of resources used to create them. It's a blatant promotion of shitty engineering in an attempt to get some money out of people.

api 10y ago

We're working toward some IoT developer products designed to allow global p2p connectivity for IoT devices over networks the user can control: https://www.zerotier.com/ https://www.zerotier.com/ ZeroTier already runs fine on embedded Linux, which is a large subset of IoT, and we've researched a lightweight port to FreeRTOS.

CaptSpify 10y ago
Interesting. So this would be something you set up on an existing device?
- api 10y ago
  You could install it on a device and then remotely access it. The software handles a lot of complexity for you. We're working with several vendors about incorporating it as a network layer and then using our (to be released soon) SDK to allow iOS/Android apps to directly access things.

npsimons 10y ago

So totally this. I refused to buy a Nest for exactly this reason. In the words of the Cluetrain manifesto: 'We are not seats or eyeballs or end users or consumers. We are human beings - and our reach exceeds your grasp. Deal with it.' I'm not here to be monetized by being glued to the hip to your infrastructure that may go away for any number of reasons (technical or non) and make my property suddenly stop working.

shrugger 10y ago

Sounds like you want better hardware. Which is what we ALL want.

StillBored 10y ago

I'm in the same boat... Spent a couple years looking for a wifi thermostat that didn't require a cloud service. Actually I purchased a couple and hacked on them, but never hooked any of them up to my AC unit. Granted I had some pretty specific requirements (long list having to do with multiple zones/etc). Not to long ago I settled for a couple of the venstar T7900's. They aren't perfect by any means, but they are light years ahead of anything else I could find. In fact they have a whole bunch of options that harken back to some of the early programmable thermostats. For example, out of the box you can control the max cycles/hour, or the number of degrees of variance from the setpoints. Buried in the menus are a wealth of options, including a few for limiting features available to "unprivileged" users. Funny enough, they can be subscribed to the power companies remote kill features, but the user is still in control and can disable the feature, which is probably why they are excluded from my power companies list of "smart" thermostats that qualify for rebates. So, the cloud service can do a lot of things that aren't available from the published API, but running a local deamon and polling runtimes, setpoints, etc is all very straightforward, as is forcing a thermostat on/off from a server on the local network. Anyway, that is my .02 for a thermostat that isn't owned by $megacorp/etc and can be disabled at the wim of a company that decides paying for a bunch of cloud servers is no longer in their interest.