5 ms·

Open standards are a real issues in the industry. I find it ridiculous that you often have to pay thousands of dollars for software that simply understands thos

by romaniv 12y ago

Open standards are a real issues in the industry. I find it ridiculous that you often have to pay thousands of dollars for software that simply understands those protocols. Not only that, it requires you to jump through ridiculous hoops to do stuff that you could easily do with a reasonably simple Python script. (Look up Niagara AX as an example.) Another problem is APIs and connectivity. Tuning a light on or off should be doable with a simple POST call to a RESTful service somewhere. Instead, we are sold dubious phone apps for everything.

fixermark 12y ago
I had some luck awhile ago with an INSTEON setup using their SmartLinc central controller---but only because the SmartLinc itself had a sniffable HTTP protocol for its "phone control." So basically it was ideal for me, as long as I completely bypassed all the crap software that came with it (I ended up writing a small server app that read my Google Calendar for "light on / light off" commands and sent the appropriate HTTP commands to the SmartLinc to fool it into doing the actions). Unfortunately, the setup stopped working and I don't have useful tools to debug it; no way to know why an INSTEON controller can't see another component, only that it can't. Plus, I'd like to move away from systems that want to use the house wiring at all (INSTEON is hybrid x10 / radio) because I don't want an errant power surge blowing my $100+ of equipment.
FrozenCow 12y ago
This is what I do as well. One raspberry pi with all the required connections (Z-Wave USB controller, IR emitter and a wire to my PC) with an extremely simple node application that serves urls like /lights/on, /curtains/open and /computer/power. My phone running Tasker to trigger the various appliances. Add some buttons to the homescreen for direct control over everything. The real added value comes from a trigger from the wakeup-alarm app that runs a Tasker script, turning on the lights, waiting 5 minutes and opening the curtains. I haven't found an all-in-one solution to do all this. Then again, I haven't looked for anything else once I got my curtains going through Tasker. An open standard would've made the process much simpler though.
- dnr 12y ago
  Hah, I ended up with a very similar system: raspberry pi plus a razberry z-wave controller[1], IR receiver and cheap universal remote, and a node app that exposes a simple API as well as a simple UI. stunnel plus port forwarding on my router so I can access it securely from anywhere. Trigger on my phone for geo-fencing to turn off lights when I leave and turn them on when I get home (only if it's dark out). (Cheap PIR sensors are the next project.) Overall I've found that z-wave is quite reliable. It never loses commands and latency is good enough. The protocol supports just about any kind of device or signaling you might want, in theory, though it can't really do high-bandwidth things. The problem is that devices are relatively expensive (compared to the cost of the components) because the protocol is quasi-proprietary. Zigbee is "open" and extremely flexible, but as a result, zigbee devices from different vendors often can't talk to each other. I'll take the more limited but working thing, thanks. (The Trigger app's geofencing is pretty unreliable, though. Has anyone found an android app that can reliably do http requests when crossing a geofence?) [1] http://razberry.z-wave.me/ http://razberry.z-wave.me/
bjt2n3904 12y ago
Right, open standards. I think there's an XKCD comic about this... There's no "open standard for wireless control of a light", because there's not one standard way to do it. For a dollar in parts, I can build a wireless light switch that uses 433 MHz, just like your wireless doorbell. Oh, you wanted a network of addressable lights? Well now it's a dollar fifty. We'll move to 900 MHz and switch to a ZigBee radio. Oh, you wanted to address them through WiFi? Well, here's the problem. Light bulb's don't have keyboards to enter your AP+Key. You could try and use WPS with a fixed pin code, but there's another issue. Putting an embedded Linux device that handles POST requests in a lightbulb is rather silly. We'll keep the ZigBee radios, and build a crossover "base station" that has a RESTful XML based JSON buzzword complaint interface. Did I mention my ZigBee radio only talks with my brand of ZigBee radios? The problem in making a standard comes down to the radios in the lightbulb. That interface will likely always be proprietary. Even if you get a standardized web interface, no one will be able to make a universal base station for all "smart" electronics. Wink is trying to do that, best of luck to them. I don't see it happening. http://thegadgetflow.com/blog/wink-wants-new-standard-smart-home-devices/ http://thegadgetflow.com/blog/wink-wants-new-standard-smart-...
- romaniv 12y ago
  You would be surprised, but there are already standards for automation of almost anything you can think of. The problem is not with the lack of standards or network-enabled devices. The problem is with them being proprietary and tied to software that costs thousands or even tens of thousands of dollars. Some of that software is licensed in such a way that you cannot even install it without being an "authorized" vendor with an established relationship with the manufacturer/provider.

by romaniv 12y ago

fixermark 12y ago

I had some luck awhile ago with an INSTEON setup using their SmartLinc central controller---but only because the SmartLinc itself had a sniffable HTTP protocol for its "phone control." So basically it was ideal for me, as long as I completely bypassed all the crap software that came with it (I ended up writing a small server app that read my Google Calendar for "light on / light off" commands and sent the appropriate HTTP commands to the SmartLinc to fool it into doing the actions). Unfortunately, the setup stopped working and I don't have useful tools to debug it; no way to know why an INSTEON controller can't see another component, only that it can't. Plus, I'd like to move away from systems that want to use the house wiring at all (INSTEON is hybrid x10 / radio) because I don't want an errant power surge blowing my $100+ of equipment.

FrozenCow 12y ago

This is what I do as well. One raspberry pi with all the required connections (Z-Wave USB controller, IR emitter and a wire to my PC) with an extremely simple node application that serves urls like /lights/on, /curtains/open and /computer/power. My phone running Tasker to trigger the various appliances. Add some buttons to the homescreen for direct control over everything. The real added value comes from a trigger from the wakeup-alarm app that runs a Tasker script, turning on the lights, waiting 5 minutes and opening the curtains. I haven't found an all-in-one solution to do all this. Then again, I haven't looked for anything else once I got my curtains going through Tasker. An open standard would've made the process much simpler though.

dnr 12y ago
Hah, I ended up with a very similar system: raspberry pi plus a razberry z-wave controller[1], IR receiver and cheap universal remote, and a node app that exposes a simple API as well as a simple UI. stunnel plus port forwarding on my router so I can access it securely from anywhere. Trigger on my phone for geo-fencing to turn off lights when I leave and turn them on when I get home (only if it's dark out). (Cheap PIR sensors are the next project.) Overall I've found that z-wave is quite reliable. It never loses commands and latency is good enough. The protocol supports just about any kind of device or signaling you might want, in theory, though it can't really do high-bandwidth things. The problem is that devices are relatively expensive (compared to the cost of the components) because the protocol is quasi-proprietary. Zigbee is "open" and extremely flexible, but as a result, zigbee devices from different vendors often can't talk to each other. I'll take the more limited but working thing, thanks. (The Trigger app's geofencing is pretty unreliable, though. Has anyone found an android app that can reliably do http requests when crossing a geofence?) [1] http://razberry.z-wave.me/ http://razberry.z-wave.me/

bjt2n3904 12y ago

Right, open standards. I think there's an XKCD comic about this... There's no "open standard for wireless control of a light", because there's not one standard way to do it. For a dollar in parts, I can build a wireless light switch that uses 433 MHz, just like your wireless doorbell. Oh, you wanted a network of addressable lights? Well now it's a dollar fifty. We'll move to 900 MHz and switch to a ZigBee radio. Oh, you wanted to address them through WiFi? Well, here's the problem. Light bulb's don't have keyboards to enter your AP+Key. You could try and use WPS with a fixed pin code, but there's another issue. Putting an embedded Linux device that handles POST requests in a lightbulb is rather silly. We'll keep the ZigBee radios, and build a crossover "base station" that has a RESTful XML based JSON buzzword complaint interface. Did I mention my ZigBee radio only talks with my brand of ZigBee radios? The problem in making a standard comes down to the radios in the lightbulb. That interface will likely always be proprietary. Even if you get a standardized web interface, no one will be able to make a universal base station for all "smart" electronics. Wink is trying to do that, best of luck to them. I don't see it happening. http://thegadgetflow.com/blog/wink-wants-new-standard-smart-home-devices/ http://thegadgetflow.com/blog/wink-wants-new-standard-smart-...

romaniv 12y ago
You would be surprised, but there are already standards for automation of almost anything you can think of. The problem is not with the lack of standards or network-enabled devices. The problem is with them being proprietary and tied to software that costs thousands or even tens of thousands of dollars. Some of that software is licensed in such a way that you cannot even install it without being an "authorized" vendor with an established relationship with the manufacturer/provider.