131–140 of 146 posts
Earlier quoted context omitted.
On that page, there are links to both the API reference and a beta SDK.
To get to the relevant hardware information you have to have an Apple Dev account, unfortunately.
Earlier quoted context omitted.
May I counterpoint? I live in a 1200 sq foot condo, 1 floor, with limited natural light. Automated lighting activation via Bluetooth LE (Tasker on my Android phone) is very handy when I come home late at night, because walking through ~15 feet in the dark to a light switch isn't fun (yes, first world problem). More importantly, my Nest thermostat. Am I lazy for changing the house temp from my bed? Most definitely. Bu…
Or "I'm going to bed early, turn off all the lights". Or, "I'm having a party outdoors, turn on all the exterior lights." Or, "I'm done listening to music, turn off the audio." There are lots of use cases. But, all of this nifty tech does rely on tapping in to home infrastructure (switches and devices that understand the protocol), so it's a long haul. These devices are wired in and have 50-year design lives. The lif…
Dear Apple, please for the love of god and the good of everyone, get together with Google and iron out a common protocol for this stuff. Don't make this one of your competitive technologies designed to fragment the world into Apple and not-Apple. Home automation is just dying to take off and there's a pile of gold for everyone if you just show a tiny bit of cooperation to get it started ... And you can all still sue…
Dear Apple, please for the love of god and the good of everyone, get together with Google and iron out a common protocol for this stuff. Don't make this one of your competitive technologies designed to fragment the world into Apple and not-Apple. Home automation is just dying to take off and there's a pile of gold for everyone if you just show a tiny bit of cooperation to get it started ... And you can all still sue…
When was the last time Google and Apple actually worked together? Serious question.
http://www.bloomberg.com/news/2013-01-11/apple-google-deal-f...
Which is funny because two years before that, Google was absolutely outraged that Apple and Microsoft would band together in a clearly anti-competitive move to deny Google a collection of patents
don't mean to spam, but can the opensource world just do something better? clearly apple is going to use some super apple only thing...and always will I tried a while back, and it looks awfully similar to what apple is doing... I use it all the time, manages my lights, my server, my IR electronics, through the UI or on a schedule. Has macros, etc. doesn't have the fancy detection features although at the time those w…
The reason people wait for commercial alternatives is obviously ease of installation, support, etc., but there are also some features the big guys can offer that open source just can't compete with. Voice recognition is one, what if you want to talk to your TV or set your alarm while you're lying in bed? Open source speech recognition is passable, but there is no open source package that lets you do a hands-free "OK Google" trigger word type of thing. You'd have to pay thousands for that, in which case maybe you'll just wait for Google or Apple to integrate it into their home automation products.
Dear Apple, please for the love of god and the good of everyone, get together with Google and iron out a common protocol for this stuff. Don't make this one of your competitive technologies designed to fragment the world into Apple and not-Apple. Home automation is just dying to take off and there's a pile of gold for everyone if you just show a tiny bit of cooperation to get it started ... And you can all still sue…
But... They won't. Please, if you're developing on iOS don't do this. Apple is hungry and looking for another market segment to lock out the slow, but good, innovation taking place. Today I happily control 70% of my house with full access to scene programming and enjoy no vendor lock-in other than the protocols my choice of controller supports. The biggest things here is I have access to a local API, I don't need to…
Shrug. Maybe I'm stuck in the past, but am I the only one not really excited for this kind of thing? Turning lights, air conditioning on and off isn't exactly a huge problem in my life.
Earlier quoted context omitted.
> They continued to use XMPP so long because it was still profitable for them to More like, they continued to use XMPP for 8 years at enormous loss, watching while it acted as a massive sink hole of users to their competitors who exploited it ruthlessly ... I too wish they hadn't ended federation, but do note that to this day XMPP clients continue to work just fine. They did not abandon XMPP as everyone loves to impl…
- XMPP is deprecated as far as Google is concerned. - Google Hangouts (non-XMPP) replaces Google Talk (XMPP) on Android. - Apparently I always appear online in Google Hangouts even when I'm signed out of Google Talk leading to people messaging me and being confused that I don't respond, or never got the message (apparently it just goes into the aether, or maybe only shows up if I switch over the Google Hangouts). Say…
As someone that remembers the constant battle between AOL and third-party IM clients, I'll note that Google's handling of XMPP feels similar to AOL transitioning from TOC to OSCAR[1]. The parallels are there. They provide a way for third-party clients to connect to their service, but make sure it's never as fully-featured as the 'official' client which uses an entirely different protocol.
[1] The OSCAR protocol was more fully functional than the TOC protocol (e.g. 'buddy icons' didn't exist in TOC, nor the ability to directly connect and send images to a buddy), but AOL pointed to the TOC protocol when third-party IM clients wanted to connect to AOL's IM service. At one point, the OSCAR protocol would start doing things like requesting random binary chunks AOL's official IM client to assert that a third-party wasn't connecting to the service (i.e. working around this would mean distributing a copy of AOL's IM client, which allows AOL to sue).
Earlier quoted context omitted.
Indeed, BACnet's been around for so long now (and has such poor takeup in the consumer space) that one might wonder whether a newer protocol is necessary. Or one could consider that only very recently technology has become cheap enough to be a viable option. In fact, I'm still not convinced it's cheap enough to interest the average consumer. Tho Apple's team probably disagree. What do you mean by not plug-and-play? A…
Security is incredibly important. If I give someone my WiFi password, I'd really rather they didn't have the ability to open/close my windows, turn off my heating, turn on my lights etc. Introducing such a system to the consumer domain would be the most socially irresponsible thing Apple could do. Now when your kid downloads dodgy porn and gets a virus, you don't just get a slower computer demanding your cash, your c…
And no, by adding new stuff I don't mean a new standard.
It's called an addendum. Which, I'm surprised I overlooked, some were made especially to address the security issues: http://www.bacnet.org/Addenda/
If security really is a big issue, the LAST thing I want is give access to the secured network to my PHONE. Is your phone secure? Would you store your bitcoins on it?
The reason that home users have ethernet and IP is because of the hourglass model. The reason that most services just work is that they talk TCP/UDP - anything below that they can ignore - so if we use a new hardware layer, if we use FDDI etc we can still use TCP because everything talks in IP. BACnet kinda breaks that - you mentioned ZigBee adding BACnet support - ZigBee has supported IP for ages - had BACnet followed the hourglass model (as literally every other internet service I have ever seen has done) then support for BACnet would have been immediate and unnecessary to trumpet.
And by supporting IP, it was also (indirectly) supporting BACnet. You just explained how services using TCP/UDP could ignore everything below... I don't understand why you don't understand it's the same thing for BACnet. Those 'official' transport layers offer you alternatives. But guess what, by supporting Ethernet and IP, BACnet can already use pretty much all the network architecture around..
BACnet doesn't quite fit into that, mostly because it replaces IP for (as I understand it) no particularly good reason. Ok, this might be the source of the confusion. Yes, the BACnet network layer needed to be defined, because at the time IP wasn't everywhere like it is today. BUT, you can easily embed this into other protocols. That's exactly how you talk about your hourglass model: BACnet devices don't care if they are connected by MS/TP, Ethernet, IP, Arcnet... They just look at the BACnet level. Just like many services look at the TCP level, not at the IP or Ethernet level.
About IPv6 for new networks, if they become required, I see no real obstacle into extending the standard for IPv6. IPv6 is itself an example of a standard changing with time. Would you prefer to throw away IP a start from scratch because IPv4 devices might not be able to communicate with IPv6?
You want standards when you have a mature market and you want to prevent lockin. Standards in an emerging market can lead to stagnation and reduced innovation(...)
But why do you consider the consumer domain to be an emerging market? For all intended purposes, you still have lighting, HVAC, access... those all already exist in bigger organizations!
There's nothing new here!
Dear Apple, please for the love of god and the good of everyone, get together with Google and iron out a common protocol for this stuff. Don't make this one of your competitive technologies designed to fragment the world into Apple and not-Apple. Home automation is just dying to take off and there's a pile of gold for everyone if you just show a tiny bit of cooperation to get it started ... And you can all still sue…
There's already a common protocol... https://news.ycombinator.com/item?id=7836739