For those unfamiliar with CoAP, it's a REST based protocol for machine-to-machine communication targeted at IoT (Internet of Things) scenarios particularly in Home Automation.
NB: Unlike REST though, URLS begin COAP:// instead of HTTP:// or HTTPS://.
I particularly like the introduction, which succinctly explains the value in realizing a subset of REST common with HTTP, while not just blindly trying to make a compressed version of HTTP. The end result is a protocol which is quite easy to map to each other, not just in terms of implementation but also in terms of mindset. Being familiar with HTTP means you won't feel completely lost in trying to learn CoAP, which is pretty cool.
This is great. Thanks for the link!
Its well written and shows great clarity of thought. The practical considerations are always mentioned, and they thought of everything, even ddos amplification attacks. A thing of beauty.
There was a firmware change in 2016 that blocked 3rd party bulbs but it didn't take long for the public pressure to influence them enough to revert it.
Philips Hue hubs do work with 3rd party ZLL endpoints. However, the likely reason they disabled 3rd party device support was because all Zigbee products have compatibility issues; nothing works as well as staying with one brand.
You can't always control all features and can't update firmware of all 3rd party devices from any hub. Sometimes you just need to manually configure the drivers (in code).
According to Phillips [1] it is IKEA not implementing the standard as they expect it to be implemented. That said, it's hard to say who is right here. Either way, consumers are losing out.
As a side note, IKEA's brightest bulb is 1000lm which is much brighter than the brightest Hue bulb, and it's cheaper :) I can perhaps see why Phillips would not go out their way to resolve this issue.
The Hue Bridge connects an IP network to a ZigBee network. That component emulates the IP side: it accepts IP commands for lights and translates them to Home Assistant devices. That's handy if you have something like an Amazon Echo that knows how to communicate via Hue's IP protocol.
What I believe you are describing would require a ZigBee radio and support for the ZigBee Light Link protocol (or maybe ZigBee Home Automation?). Luckily, there's a PR being worked on to support that in Home Assistant: https://github.com/home-assistant/home-assistant/pull/6263
Second article in a short while that praises Ikea's implementation. In the face of the security disaster that IoT devices usually represent, I'm somewhat dumbfounded by the idea that it would be Ikea, of all companies, to break the mould.
Ikea, as far as I can tell, does a very good job of providing good value and products that are well-designed. From the electronics perspective, I have had a peek inside some of their LED fixtures and USB chargers and the designs inside are textbook and well-executed. I'm not at all surprised that an IoT implementation would be equally well-designed.
I bought some random Ashley Furniture coffee table from Fred Meyer for my house, not two days after I brought it home my 3-at-the-time year old 40lb daughter sat on it and broke the cheap as crap legs on the $50 table.
Meanwhile, my aunt has an Ikea Lack coffee table sitting in the basement of her shop holding up a 50lb Dell PowerEdge 1950 and it will still let me drop more on it without complaint.
Ikea products may be cheaper than others in certain situations, but quite honestly I trust them a whole lot more.
Ikea gets grief for being flat
pack and using MDF, but in no way are those novel concepts. Ikea however, has executed on that better than their completion. I was shocked at how bad some flat packed MDF furniture from Target and Walmart was; they barely survived being put together!
Fwiw 40lbs in motion produces more force than at rest. The area it is applied to (among other things) also changes how the beam handles the load. Lack tables have such simple construction that they may handle higher than usual loads without deformation; four large posts supporting a single beam pinned at the ends can handle a decent load, if the beam and posts are big enough. They might also use cheap hacks, like strengthening the bottom of the beam to account for increased tension.
Walmart has some pretty decent mdf tables for about the same price as similar ikea tables. Sometimes their construction is really good, too, such as this table[1]. It brings the posts in closer to center which distributes load better and increases load rating for the beam, and the post supports both the beam and the strut, and the strut helps reinforce the beam. Everything is brought in farther from the edge to make the effective load-bearing part of the beam smaller, which makes it stronger.
Their dressers are total shit, though, unless you pay a pretty penny for real wood.
I'm not a structural engineer, but I've sawn off the legs of a Lack table a few months ago, and they are hollow (I think fibre board) with wood blocks inside at both ends. Seems like a sturdy construction.
Yep. It has the effect of making the top layer in compression, the top of the webbing in compression, the bottom of the webbing in tension, and the bottom layer in tension. The webbing distributes force as shear along a large area (and along the entire beam), so it can handle a great force with a pretty thin member. It's like building a really wide, really short I-beam. But better.
Because the top skin only has to resist compression and the bottom only tension, you can choose materials that will perform each of these best. The top can be really thin, while the bottom can be thicker, and the result will be a slightly stronger table than if both skins were a thickness in between. The length of the web will also directly affect the strength (part of why those table tops are so thick... to have longer webs)
In fact, you can build "torsion beams" that work like long torsion boxes, but instead as beams. A 6-foot long beam might weigh only 20lbs. Sit them on sawhorses and you now have a stowable assembly table. Another benefit to torsion beams is they are easier to construct straight because finding small members that are straight is easier than finding big thick straight members. (Uh.... let's ignore the obvious jokes here)
The downside to all this strength-hackery is, if one of the webs fail, structural integrity is gone. So don't land anything too heavy on a single spot.
When you're focusing on customer satisfaction and cost control I suspect any idea of an 'Cloud Light Control Panel' or some other such nonsense was axed rather quickly.
They'll be making plenty of money on the margins on the lamps and gateways as is.
Refreshing isn't it? Not familiar with IKEA's track record in electronics though. I've had mostly good experiences with the furniture (though price influences quality a lot). Bad experiences with their cheap wok pans. But generally my IKEA stuff works well.
Nice to seem them align with standards though, because they seem to have their own standards for curtains. Very upsetting :)
They do have a well-proven track record of providing very good value for money, and I get the impression that they achieve the prices they do through ruthless optimisation of their processes. I'm curious to see how that culture extends to software engineering (Provided they do it in-house).
Certainly ruthless optimisation of their corporate structure with respect to tax helps contribute to their low prices: http://www.economist.com/node/6919139.
But it's nice to think that it could also be due to genuine technical ability.
Yeah, IKEA isn't really a saint, few corporations are. But they've done a lot of technical optimisation as well that should contribute to their low pricing. Flatpacks, big production runs, design stuff to be cheap to produce. A whole bunch of things.
And while I doubt their morals (corporations rarely have any) I generally have faith in their quality-to-price ratio. Not a resounding endorsement, just have had few problems.
And honestly if a company is going to evade or limit their taxes passing on part of the savings to consumers if fairly benevolent (if the tax avoidance contributes to the price as GP claims).
Only if the product is something which is generally useful and affordable for the entire population. Evading taxes on, say, megayachts and passing the savings on to the consumer doesn't seem particularly benevolent.
Yeah, I can imagine that if these things shake out well and I figure they should sell fine, IKEA will slowly add more and more software-driven stuff to their line-up.
No idea if that means in-house software engineering, I imagine it wouldn't as they want to keep prices low. Just heavy QA? Or they might eat the cost for local development since the software cost is pretty small and doesn't scale up with the number of units produced.
They do have a set of cheap table serrated-edge steak knives (SNITTA - set of 4 for $5) that are actually quite nice when you look at them closely; stainless steel with a tang that goes completely down the handle.
Not sure what the handle is made out of, but its solidly attached, and the set my wife and I bought has lasted almost a decade going thru the dishwasher and such, and still look nearly brand new. They say they can be used as a utility knife; they'd probably cut cardboard well, maybe other stuff, but I prefer other tools for that kind of thing.
I actually like them better than a set I have that are identical to the large steak knives they put out (or did at one time) at the Outback Steakhouse restaurant (not saying anything about the food - I just liked the knives).
Some day I'm going to pick up a set of Knork knives (I already love their namesake utensils), but I bet I still might like the Ikea set better.
I have a dream that they'll sell something like (or maybe the same product) the Oxfam OX flatpack truck to consumers.
I want one of those so bad, to the point where I've considered building one from scratch. I doubt we'll ever see one of them stateside, though, because they look like a deathtrap in an accident.
Though I wonder if, as a "kit car" put together by the owner and not sold as a complete vehicle, they couldn't be legally registered and driven as an "experimental" vehicle (which is what I would have to get if I self-built one)?
Indeed, they might even have exaggerated it. The computations are expensive and can take several seconds even on powerful MCUs. There are HomeKit chips that can accelerate this, but good luck getting your hands on one (or its manual).
You mean that HomeKit-compatible products all need to include some kind of HomeKit-chip with a pre-shared key or something? I'm completely unfamiliar and a quick search on homekit and pre-shared key didn't make me wiser :)
You don't even get to know what's inside HomeKit until you're an MFI-certified developer with Apple. And yes, there's a chip involved (again, which you can't even touch until you're an MFI licensee). The chip handles all the security protocols involved.
Well, it's pretty simple. If you want into Apple's ecosystem, you follow their rules. They've hardware-locked many other external things (dongles, charging cables, etc).
Cynics will say it's a money grab, proponents will say it greatly reduces or eliminates the risk of buying something that will not work right. Apple sells itself on the ability of their things working right out of the box.
> proponents will say it greatly reduces or eliminates the risk of buying something that will not work right.
IIRC, it's been shown that a massive percentage of the Apple chargers for sale on Amazon are difficult to spot counterfeits. Some of those use dangerous electronic designs.
Yeah, unfortunately Apple can't stop everyone from making bad 5VDC bricks with USB sockets. Perhaps the "approved" cables have some kind of overvoltage protection in them, but otherwise that's always been a weak point.
actually, i'd be surprised if apple had better ideas here than ikea. ikea is a home and furniture company and always has been. apple is neither, it's a luxury goods company at this point.
apple can definitely execute, though. it just has to execute the right thing.
That's the real problem with most of the "Internet of Things" products - they really shouldn't have skipped the "Network of Things" step. So many of the problems with these products could have been reasonably and properly shaken down and out... but instead all of the companies decided to unnecessarily bridge their products with the cloud and hastily rush to the market.
Security aspects aside, that's fine - what isn't is the inability to run that external server yourself.
Imagine if instead of using "proprietary cloud xyz" for a particular IoT product, you could spin up a cloud server or container up somewhere and install it yourself - and as long as you pay for the server, you have access.
Let the consumer decide based on their "expertise" level what option they want to use - but the option should be there, and included in some form with the product itself (maybe on an sd card or something), so that they could at least transition to that should the company go out of business. Ideally, the system would be open source as well, so it could be expanded.
Fair enough. At least it doesn't run through some cloud solution that will leave it bricked when it stops running. Glad they've chosen an interoperable approach even though they don't explicitly encourage interop.
I bought some of these this weekend. The big perk? You don't need to use them as IoT devices at all. Hold one button to pair with a remote and you are done.
Unlike say the very expensive power mattress base (bad Ergotron) I bought which has sleep tracking that will only work if I reveal all my health data on my phone to their app. This includes data not collected by the mattress. It also requires you give your wifi password. They explicitly tell you they are going to sync it all to their cloud.
They basically demand the keys to the kingdom when all they should need is some basic bluetooth syncing to my phone. Obviously I did not move forward with the sleep tracking functionality.
I use CoAP in my small DIY projects (ESP8266 mostly for now)… but sometimes I wish I used MQTT, because with the broker model you can put your device in deep sleep and only wake up occasionally, saving power. On the other hand the REST server model lets me adjust polling frequency on the client side, without storing any config in the device…
It is a good example of marketing dollars influencing protocol adoption. I've met a remarkable number of people that work in IoT that know nothing of CoAP.
With Mosquitto, I can run a very tiny broker. And things as small as "Arduino with ethernet chip" can serve as a MQTT client. I'd consider something that can run in 16MHz with 2k ram and 32k storage to not be something "consultant-driven over-engineering and under delivery par excellence."
Indeed. If you're going with an Arduino/ethernet you are not going to get SSL layer between client/broker. Then again, you do get the security of being on a wired network, and little to no RF emissions.
If you "upgrade" to an ESP class microprocessor, you do get MQTT, CoAP, and SSL support. And frankly the more protocols, the better. Some do tend to be better than others in different situations. I know I greatly prefer MQTT, for its clean and basic protocol. It gets out of the way for me to do what I want, basic Pub/Sub and storing relevant data into a MongoDB for timeseries.
I know at work, we're using RabbitMQ (AMQP). It has its own positives and negatives. My biggest concern is it serves as a forward-and-store datastore - another place where backups need to be made, let we lose essential data. I'm against complex moving parts, where simpler moving parts would suffice.
It's to prevent a proliferation of things like /favicon.ico, /robots.txt, etc. each of which may actually be dynamically generated (e.g. think of subdomains like someguy.tumblr.com ), and therefore requires separate handling in firewalls, routing, etc. Basically many of the same problems you might encounter with librarys whose API is a bunch of globals; or a shell script which takes in options from hardcoded file paths rather than commandline flags or env vars.
The ".well-known" path makes this easier to manage going forward, since you can single it out for special handling once, and implement the contents however you like (statically, dynamically, whatever).
NB: Unlike REST though, URLS begin COAP:// instead of HTTP:// or HTTPS://.
This site gives a good overview: https://www.slideshare.net/jvermillard/co-ap Whilst this gives a lot more info: http://coap.technology/