COAP endpoints on IKEA Trådfri
bitsex.net
bitsex.net
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/
Edit: This was a serious question, not sure I deserve multiple downvotes
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.
However Philips appear to be modifying Hue software to prevent it. Cloud lock-in. https://developers.meethue.com/comment/2337#comment-2337
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).
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.
[1] https://developers.meethue.com/comment/2686#comment-2686
Edit: fixed typo of watts vs lumen :)
1000 Lumen. 1000 Watt bulbs exist for grow lights but IKEA doesn't make them that thirsty.
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
Nice to seem them align with standards though, because they seem to have their own standards for curtains. Very upsetting :)
But it's nice to think that it could also be due to genuine technical ability.
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.
It is fascinating though, they take a lot of things to extremes.
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 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)?
apple can definitely execute, though. it just has to execute the right thing.
Has it been generally well received security-wise then?
Not a good solution in general.
Makes me curious about how that homebridge node thing makes it work.
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.
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.
They'll be making plenty of money on the margins on the lamps and gateways as is.
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.
I couldn't find the wood option.
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.
[1] https://www.walmart.com/ip/17767350?wmlspartner=wlpa&adid=22...
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.
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.
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.
Also I'm curious if they're still ZigBee 2 or if they're ZigBee 3.0, which essentially merges those standards together.
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."
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.
I mean you could make it a client, sure, but I think that kinda defeats the point.
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).