> There were two strings printed with labels “SSID” and “Pwd”. I froze in horror. They wouldn’t dare. It is literally 3 meter distance. These are embedded devices, they do not need this complexity…
Not surprising at all. I would expect that a lot of these are bought as retrofits, and not as a part of new construction. Running wires through existing walls can be annoying, and they don't want to put that barrier to sale in front of them. And you can get a good-enough WiFi chipset for a few bucks these days.
> I need a 3A fuse [...] After installation, I checked the temperature of the fuse multiple times during the day to get at least some indication that things are not going to get worse. It worked fine for a more than a week now, but I still do not recommend experiments like this to anyone.
Probably don't need to be so worried here. If it's a 3A fuse, the entirety of your apartment's mains power is not running through it. A 3A fuse would burn out in a fraction of a second if you tried to do that.
Also, oh, man, Jazelle. I'd forgotten about that. Hardware support for Java bytecode... that did not pan out well.
> A 3A fuse would burn out in a fraction of a second if you tried to do that.
he bought it on Amazon. He has every reason to be worried that it won't burn out. Louis Rossman did a video[0] where he put 8 amps through a 2 amp fuse and left the room for quite a long time, I think it was several minutes with 8a going through a 2a fuse.
In general, people have the wrong idea about how fuses work. They're not supposed to blow at their rated current, they're supposed to withstand it indefinitely, and only blow at much higher currents. Look up any datasheet from a well established manufacturer and see for yourself (like this one from littelfuse: https://littelfuse.com/products/fuses/cartridge-fuses/5x20mm... )
Indeed. There is a slight temperature dependent de-rating, but in general that is correct. To add, Littelfuse is in fact the inventor of the standard automotive blade fuses - they know their fuses if anyone does. I archived a datasheet of some of their blade fuses here [0] - you can see that a 1-amp fuse will run at 1A indefinitely, 2A for 300ms, 3A ~100ms, 4A ~60ms, 5A ~40ms etc. The same datasheet will tell you the temperature derating for their blade fuses is less than 25% at any temperatures you want your electronics to live at.
Another fun fact that is obvious from applying Ohm's Law - you can calculate the current flowing through a fuse by measuring the voltage drop. You can do the math yourself, or there are handy "fuse voltage drop charts" so you don't even have to use a calculator. Yes, this means that with a simple oscilloscope you now have a portable energy meter that requires zero rewiring. Ha, I accidentally brought us full circle :)
Just be careful with that, measuring mains is a bad idea with most oscilloscopes. The ground pin is usually connected to mains earth, so if you're not careful, you might create a short and blow up your scope. If you have one of these battery powered ones, it'll be fine, but the mains powedered ones are usually a no-no.
Ah, I was referring to automotive blade fuses (which have lovely little contacts on top for measuring.) They are only rated to 32VDC so if you are running mains through that you have other issues. Indeed I'd just use my battery-powered oscilloscope to measure mains but if I wanted to use a benchtop scope I'd use an isolation transformer.
People also have a wrong idea about how buying electronic components on Amazon/Aliexpress/eBay/etc. works. You buy a few of the same, test them, then use them if they work. Otherwise ask for refund.
Otherwise you're up for a big surprise that all your TL081's are LM356 instead, or that mosfet you bought has 3x the Rds(on) than expected, or that your fuse doesn't work.
Amazon had one of their buildings in California shut down a few months ago by the fire department when a generator started smoking. It was probably due to a bad fuse they bought off Amazon. https://signalscv.com/2023/07/fire-breaks-out-at-amazon/ That's how blinded by their avarice Amazon has become; they can't even protect their own house. Notice how the Nilight fuses (https://amzn.to/3S06G2n) are still listed, even after a YouTube video with 300,000 views demonstrated that their 2 ampere fuse takes 10 amps to blow. I even had an electrical fire in my house recently, due to components that I purchased off Amazon. I know Amazon monitors Hacker News PR closely, since they took down those ChatGPT generated listings within minutes of us posting them here. Yet they do nothing about product listings that put our lives, and their own lives, in critical danger.
> I know Amazon monitors Hacker News PR closely, since they took down those ChatGPT generated listings within minutes of us posting them here.
Like other engineers at Big Tech, Amazon Engineers also read HN and the post in question happened to be on the HN front page around the lunch break of a work day, IIRC.
It’s easy to imagine one or more Amazon engineers internally pinging the team responsible for Amazon listings hence the appearance that Amazon was able to take down/hide those ChatGPT generated listings in less than an hour of it landing here.
I'm not going to watch the whole video but it doesn't seem like it supports the point you're trying to make.
> How long does it take for your 400mA multimeter fuse to blow at 600mA?
> The amazing unpredictability of fusing current ratings at low overloads.
It makes a point of saying that fuses are imprecise, i.e. that a fuse likely won't blow when 600mA of current passes through a 400mA fuse for a few seconds.
What Rossmann discovered was that fuses from Amazon took 4x the rated current for minutes. That's many orders of magnitude out of spec.
The relationship between the amount of overload and how fast the fuse is supposed to blow is quadratic, not linear. As an example with somewhat made-up numbers, at 1x it might take hours to blow, at 2x it might take a minute or two, at 3x it shouldn't take more than a second and at 4x it should be nearly instant.
If it's supposed to blow in 0.1 seconds when overloaded by 4x, then taking 10 minutes is many orders of magnitude in my book. While that fuse is taking its sweet time, wiring or other components are being heated out of spec (16x more heat at 4x the current), potentially posing a fire hazard or damaging the device it's supposed to be protecting.
Sorry, I misread you, didn't catch you meant the time. Also good point about the possible power damage being quadratic on the current.
Thanks for the polite clarification.
Seriously, I think they would refund the fuse since you are not satisfied.
I think the only way for Amazon to stop organizing countraband would be if dozens of people die in each country and it makes a big media mess and public prosecutors finally rule that Amazon is responsible for mingling and smuggling the products in-country.
Which will impact all
marketplaces, requiring Craigslist/Leboncoin/Gumtree to asses the liability of the sellers on the marketplace.
Well yeah, there's that. My assumption about the worry the author expressed was that it was just an "I'm a little uncomfortable with mains power" type worry, not "did I buy a crappy part that's going to explode" type worry. If it was the latter, that's, well... entirely avoidable.
Also, too: Wifi has inherent galvanic isolation with a wide gap.
It isn't strictly necessary, as anyone here obviously knows, but it can be a cost-effective way to isolate the [electrical] pokey-bits from the [meat-based] pokey-bits, and to avoid loops when things go wrong.
> Also, oh, man, Jazelle. I'd forgotten about that. Hardware support for Java bytecode... that did not pan out well.
As someone who was too young to be paying any attention during this time, what were some of the reasons this didn’t pan out? Java seems so dominant looking back that I’m surprised something like this wouldn’t have been a success.
The Lisp machine failed because Lisp compiler technology got better and better at targeting generic 32-bit CPU hardware, which was becoming increasingly cheap and plentiful. So the benefits of having all this custom hardware to specially execute Lisp code were nullified -- leaving only the costs.
The same thing happened to Java in hardware. It seemed like a good idea at the time because it allowed developers to target a language they were already familiar with, and present an alternative to Wintel -- especially when you realize that Java was all the rage as a sort of universal programming environment, and in particular J2ME was a big deal for proto-"smart" phones before the iPhone came along. But embedded Java didn't really pan out, memory and CPU time got cheaper, and compiler and JIT tech improved to the point where there was just no benefit to adding the hardware it took to decode Java instructions. So Jazelle was deprecated and replaced with something called ThumbEE, which was a more generic framework based on ARM's Thumb instruction set for running code for an abstract machine, providing features like automatic null-pointer checking and that. Like you could set up a ThumbEE environment for running Python or .NET code in addition to Java. Nowadays even ThumbEE is deprecated. Neither feature appears in ARMv8 processors, for instance.
I have also wondered this for years, and always was told "because JITs work better", but that felt a bit handwavy. Luckily for both of us David Chisnall just published an article on ACM about designing ISAs that properly explains the reasoning behind Jazelle and why it did not work in the long run:
> Small code is also important [for a simple single-issue in-order core]. A small microcontroller core may be as small as 10KB of SRAM (static random access memory). A small decrease in encoding efficiency can dwarf everything when considering the total area cost: If you need 20 percent more SRAM for your code, then that can be equivalent to doubling the core area. Unfortunately, this constraint almost directly contradicts the previous one [about decoder complexity]. This is why Thumb-2 and RISC-V focused on a variable length encoding that is simple to decode: They save code size without significantly increasing decoder complexity.
> This is a complex tradeoff that is made even more complicated when considering multiple languages. For example, Arm briefly supported Jazelle DBX (direct bytecode execution) on some of its mobile cores. This involved decoding Java bytecode directly, with Java VM (virtual machine) state mapped into specific registers. A Java add instruction, implemented in a software interpreter, requires at least one load to read the instruction, a conditional branch to find the right handler, and then another to perform the add. With Jazelle, the load happens via instruction fetch, and the add would add the two registers that represented the top of the Java stack. This was far more efficient than an interpreter but did not perform as well as a JIT (just-in-time) compiler, which could do a bit more analysis between Java bytecodes.
> Jazelle DBX is an interesting case study because it made sense only in the context of a specific set of source languages and microarchitectures. It provided no benefits for languages that didn't run in a Java VM. By the time devices had more than about 4MB of RAM, Jazelle was outperformed by a JIT. Within that envelope, however, it was a good design choice.
> Jazelle DBX should serve as a reminder that optimizations for one size of core can be incredibly bad choices for other cores
So: a decent JIT works better if you can afford the overhead of the JIT. Jazelle was only a good idea in a very brief period of time when this wasn't true, and even then only if you insist on running a Java VM.
>> To be honest, the whole thing was a bit scary, since I was very close to the mains
I laughed at this. Changing a fuse is… a bit scary? They literally teach this in elementary school in the U.K. - or they did. As you say, no need to fretfully check the fuse - either it blows or it doesn’t, and you’ll know when it does. At least he didn’t find the receptacle holding a dead fuse, carefully wrapped in the ceremonial aluminium shroud of eternal life and certain death, which is a crime I may have committed in my younger, more fire-prone years.
I find it interesting how uncomfortable some people are outside of their comfort zones - but then I am a person who spends his life sticking his nose in stuff he has no business with.
I don't know how old the author is, but I'm not surprised when people even 10-15 years younger than I am (I'm in my 40s) shy away from digging into the guts of how things work.
I feel like I was at the tail end of when it was ok to experiment with technology as a kid and teen. The early '00s brought much more in the way of disposable, locked-down devices. Kids growing up today (despite the educational push of orgs like the Raspberry Pi Foundation) are presented with hermetically-sealed devices that present a sanitized interface. Manufacturers explicitly don't want their customers taking things apart, discovering how they work, or tinkering with them in any way... and often even try to put legal barriers in place to keep people from doing stuff like this.
This is a far cry from when I was very young (and before I was born) when computers and kits would come with full schematics and datasheets!
> Running wires through existing walls can be annoying, and they don't want to put that barrier to sale in front of them.
It also makes it more convenient to compromise the device from across the street (or across town with a directional antenna). Though of course that's not a problem if your security is up to par and the device continues to receive regular security updates, and we can only surmise that the author has discovered a rare outlier in this space where that is not the case.
> we can only surmise that the author has discovered a rare outlier in this space where that is not the case.
Exactly what I was thinking! What luck that the author found the single IoT device out there that's a cobbled together piece of bodged electronics designed by a graduate from a webdev bootcamp with a Corel Draw focus. A device that, while only ~15 years old is not only hopelessly useless, but also obsolete and insecure.
It's a good thing all other consumer IoT device manufacturers think about and prioritize security, longevity! Also, that customers nowadays are more focused on installing something fit-for-purpose and sustainable once than buying the cheapest shit possible with the blinkiest LEDs.
I shudder to think about how long they tried to get the string-and-cups based telephone to work in my building until the 1930's when they installed the copper still used today for DSL. Or how terrible the paper-straw based water system must have been up to the 1890's when they realized investing in metal pipes has advantages. So glad the days of short-term thinking are behind us.
I’m passionate about the problem of software maintenance:
- Can we solve this with some companies dedicated to maintaining simple code (1 probe, 2 charts for each IoT, or more if the IoT subscribed for more) multiplied by 10k different IoT objects over 30 years?
- How would upgrading all of them look like? Can we batch the upgrade of NPM’s package.json? Can we define a minimum toolset, say NPM+Next+React, for long-term support?
- How can we keep software engineers passionate for that software over dozens of years? Can the challenge of upgrading and migrating to newer frameworks and applying security upgrade be ever a trove of genius and a competiton of the best hacks?
For the moment, when it’s done, it’s all GitHub Actions. Released in 2018. Well, not a good start. Plus everyone has a different pile of … in their actions, it’s all custom code, nothing is standardized, and each new IoT requires a new guy writing new ones.
- Is this already done in some part of OSS (openWrt?) and how do they deal with the boredom of engineers?
Sure, but manufacturers -- as we should well know by now -- don't particularly care about that.
And for a device like this -- a rare one where it seems they sold it without any kind of online subscription service -- their goal is to sell units, and telling people they'll have to cut holes in their walls and run wires (for most people this probably means hiring someone) is certainly going to sell fewer units.
device continues to receive regular security updates
Have to reply to this, and my response was covered a bit by your statement of "security up to par".
Nothing should be considered secure. All those bug bounties are to entice black hats, into giving up juicy pre-0day vulnerabilities.
So just because a device is up to date with security updates, we all must understand, there are countless bugs unknown, needing to be patched, and often, being discovered by those that will never tell, never disclose, never report, and only use them for nefarious purposes.
This is why security is nothing without monitoring.
And why nothing is ever "safe", only likely "more safe" due to a security update.
Consider everything that is network connected as compromised. Everything.
> Consider everything that is network connected as compromised. Everything.
This doesn't seem like useful advice.
If you know something is compromised, you're going to want to stop using it and build a clean system etc. You can't just do that continuously the instant you've built the new system.
Likewise, how does monitoring even work? Every device and app wants to phone home to some random server. The connection will be encrypted and even if it wasn't it could be some arbitrary custom protocol you'd have to spend several hours to reverse engineer. You could just block them all but that will cause massive breakage and possibly impair security when the thing you're blocking is whatever thing's security update mechanism.
I agree with your first part, but not with your second. It really depends what you use, you can easily build up a while home automation system that doesn't phone home or require internet at all
Same thing as the security of the lock on our doors. We know that if somebody really want to get into our homes they will. In the case of IoT and computers add to it the automation of the attack.
What do we do with our homes? Tradeoffs.
We put some valuables in banks, we keep some at home. We insure precious items, if we do have them. We curse when burglars steal from us.
We also install curtains so people outside cannot look at us and at what we are doing at home. There are several level of protections to do the same thing for networks and devices. Of course vulnerabilities mean that they are not perfect. Curtains are not perfect too. Add to that imaging through walls with WiFi or mobile network signals, but that's still fringe at best even if you should read https://news.ycombinator.com/item?id=37469920
I think this discussion mostly comes down to how we interpret the word “secure”. Do we mean “zero risk”, “nothing can go bad”, “no potential attack, ever”?
Or do we mean “low enough risk for this thing , here, now”? I prefer the latter, even if that implies that statements like “this thing is secure” are somewhat useless due to the subjectivity.
> Probably don't need to be so worried here. If it's a 3A fuse, the entirety of your apartment's mains power is not running through it.
If it's a "3A fuse" that doesn't blow at 6A or worse, then it will get very hot (fire hazard) if/when there's a short regardless of the distance to the mains power.
If it truly is a 3A fuse, then great. If it's bought from Amazon then I doubt it's truly a 3A fuse.
Louis Rossman over at YouTube has been going over this fuses thing from Amazon. All the fuses he tried from top-results didn't blow until he put 4x or 5x the current rating through them.
Probably not. But precision is expensive. A 3A +- 0.1A fuse will be more expensive to make them a 3A +- 6A fuse. And of course a customer will be upset with a 3A - 2A = 1A fuse so they really make a 9A +- 6A fuse and sell it as 3A.
So if you are "lucky" you can pass 12A though it no problem.
1) a dead short in the circuit. Fuse will blow pretty much instantly.
2) an overload on the circuit. Fuse will blow sooner or later depending on how great the load excess is. If the fuse is rated at 3A, it's not going to be fine at 2.9A and then instantly blow at 3.1A. You'd need actual current monitoring to do that.
And some fuses are "delayed" to allow an overload for a few moments, such as when starting a motor.
None of this disputes that Amazon is well known to sell garbage, and not just limited to fuses. That's why I don't buy anything there.
> Also, oh, man, Jazelle. I'd forgotten about that. Hardware support for Java bytecode... that did not pan out well.
I'd love someday to learn more about why Jazelle failed.
The first SoC I worked on almost 20 years ago was built around an ARM926EJ-S, just like in the story. It was built for Nokia, who used Symbian OS [1], and supported user-installable apps written against Java Micro Edition [2].
The utter mess of Symbian's app discovery and installation, I suspect, was a prime reason Apple created their App Store for the iPhone.
Nevertheless, the fundamental concept of HW-accelerated Java apps doesn't sound crazy. What happened? Were they just stuck with a sinking ship, Symbian?
Not surprising at all. I would expect that a lot of these are bought as retrofits, and not as a part of new construction. Running wires through existing walls can be annoying, and they don't want to put that barrier to sale in front of them. And you can get a good-enough WiFi chipset for a few bucks these days.
> I need a 3A fuse [...] After installation, I checked the temperature of the fuse multiple times during the day to get at least some indication that things are not going to get worse. It worked fine for a more than a week now, but I still do not recommend experiments like this to anyone.
Probably don't need to be so worried here. If it's a 3A fuse, the entirety of your apartment's mains power is not running through it. A 3A fuse would burn out in a fraction of a second if you tried to do that.
Also, oh, man, Jazelle. I'd forgotten about that. Hardware support for Java bytecode... that did not pan out well.