Blog post author here (thank you for sharing). I agree, unskippable ads are one of the not-so-nice uses of this API, and considered a dark pattern by most people. That's something that became apparent to me while I was working on the docs and this blog post - of course this API would be used for this purpose.
Personally, I think it's my role to discourage dark patterns in docs and examples and promote user agency and responsible development where I can. In this case, I'm highlighting the sustainability potential by making systems more efficient when resources are not needed. There's a section on 'patterns to avoid' in the post which talks about user control, so 'opting-in' to use of this API sounds like the better approach whether that's through in-app preferences or browser settings while there is no permission policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Permission...
It's a known issue for a portion of our visitors, which we are working on. For the time being, you can use the direct link to the form: https://tally.so/r/mJ11E7
Someone put it like this recently: the audience for specs is browser vendors, and the audience for MDN is web developers; ideally, you shouldn't have to go to the specs if MDN describes the features well enough to get your application running or your problem solved. MDN docs consider the practical aspect of how application developers will use features or why they should care, so there is a need to keep the content accessible in as many ways as possible.
I presume you're looking to add a .md file and have editor / docs support, but there is this in case anyone is looking to write a limited subset of markdown in a Google doc:
I've been interested in trying out different air sensors for a while. I tested out some of the super cheap ones ("MQ-7" etc.) for DIY cellular iot devices. I wasn't impressed at all with the accuracy, it was more like a random number generator. I recall that pre-heating was something you needed to do with it but I've since realized it's required once for 48 hours before general use, not a two-minute warmup each time a device is powered up. Anyway the general consensus seemed to be that anything under 50EUR was a waste of money. Did anyone else have success with the cheaper sensors?
This post got me interested again in trying out something a bit more robust. I've put through an order for the kit linked in the article. Looking forward to trying it out.
The cheaper sensors detect volatile organic compounds, and assume that CO2 level correlates with that. This isn't necessarily true. BigClive tested one, and called it a party detector[0], because it was great at picking up alcohol, but not so good at detecting when a literal stream of CO2 was blasted at it.
I come from a remote environmental instrumentation background and it's pretty amazing where the technology has gone. I've built two of the airgradient kits, tested various relatively inexpensive sensors and compared them to professional grade sensors. While this stuff is not even close to research grade it's a fraction of the cost, $35 for NDIR CO2? Crazy to me. You could setup a few of these sensors inexpensively, do an in-situ calibration (your house, backyard, whatever), model the response and apply a correction factor to give you some pretty good results.
For homes good enough is fine so it's really cool to see these devices become more available. You'll have fun with the kit, it's super easy to use and really easy to integrate.
Thanks for ordering our air quality monitoring kit!
We use the same industry grade sensor modules that are normally in much more expensive commercial monitors. So the kit will give you very good accuracy.
PSA if you're thinking of repairing appliances that run on mains power supply:
A lot of you might be comfortable tinkering with breadboards or Arduinos and hobbyist electronics, but mains electricity can be lethal. Please consider hiring a professional electrician before you start replacing failing components or power cables if you're unsure about what you're doing.
I did not listen to them, with the caveat that this anecdote is from 8 years ago, but it would have helped me if I had the capacity to accept their insights at the time.
In the United States (and other countries, but is it every country?) we can freely go into a supply store and purchase electrical components with no licensing or any other approvals. Simply go in, get what you think you need, and leave.
So when we were wrapping up the installation of our new kitchen some decade ago, I had recently completed a college Physics course, which I believe I had about a C- average in, and was very confident that I knew enough to wire the electrical connection on our steel range vent, with steel fume collection hood.
A year in, the little light bulbs that illuminate the range beneath had burned out from extreme heat. The metal base was still in the socket, but the glass was gone. "No problem, I'll turn the power off at the circuit and use a potato cut in half as a handle to force the base out".
Of course, a combination of shared neutral wiring, and my own errors, including that ground and neutral were 'the same' and I had tied the neutral into the hood, left me blown across the kitchen when I finally used the oven door handle with my other hand for leverage.
The headache lasted about a week. My chest felt like a couch full of old pennies. The first thing I remember was my wife sobbing, and the second thing I remember was that I am dumb and lucky. The third thing I remember was guilt for making my wife cry, and that's the one that finally registered within me that I should not be touching wires.
10 years later, I touch wires. I'm still not certified to do it, but there haven't been any more accidents. I will do only what I can convince myself I fully understand. Operations performed here are either very simple, or outsourced to professionals.
I really like Mosquitto, I'd recommend it for quickly getting started hacking together IoT projects on the hobby / side project scale. One of our community (QuestDB) contributors put together a docker compose example that I thought was pretty nice for quick prototyping, could be convenient for someone here:
There's another discussion here about this API where a reader believes it should be behind a permission flag: https://news.ycombinator.com/item?id=33965677#33994536
Personally, I think it's my role to discourage dark patterns in docs and examples and promote user agency and responsible development where I can. In this case, I'm highlighting the sustainability potential by making systems more efficient when resources are not needed. There's a section on 'patterns to avoid' in the post which talks about user control, so 'opting-in' to use of this API sounds like the better approach whether that's through in-app preferences or browser settings while there is no permission policy: https://developer.mozilla.org/en-US/docs/Web/HTTP/Permission...