今日已更新 80 条资讯 | 累计 20052 条内容
关于我们

标签:#IoT

找到 83 篇相关文章

AI 资讯

Road To KiwiEngine #12: Why I Want To Build Hardware Again

Somewhere along the way, computing became disposable. Devices became sealed. Systems became rented. Ownership became licensing. Repairability disappeared. Infrastructure moved away from the user and into distant cloud platforms. And I think we lost something important because of it. Lately, I’ve found myself becoming increasingly interested in hardware again. Not just software. Not just cloud systems. But actual computing devices. Servers. Home infrastructure. Repairable machines. Set-top systems. Local AI appliances. Sovereign computing. Because I believe the next era of computing will belong to people who own their infrastructure again. The Provider Box Realization One thing that kept sticking in my head was this: Almost every home in America already has a provider box. A Comcast box. An AT&T gateway. A router. A modem. A streaming box. People are already comfortable with the idea of a dedicated computing appliance sitting in their home quietly powering their digital life. That realization changed how I thought about computing infrastructure. What if those boxes worked for the user instead of the provider? What if they: hosted local AI, managed home storage, coordinated smart devices, powered media systems, handled automation, protected privacy, synchronized intelligently, and operated as sovereign infrastructure? That idea became part of the thinking behind KiwiHome. The Return Of Home Infrastructure For a long time, the industry moved toward centralization. Everything shifted toward: SaaS, subscriptions, streaming, cloud storage, cloud intelligence, and rented operational environments. Convenient? Absolutely. But also fragile. If: pricing changes, services disappear, companies shut down, APIs get revoked, or platforms change policies, entire workflows collapse overnight. I think people are starting to feel that tension. Especially creators. Especially businesses. Especially technical users. That’s why I believe we’re going to see a major resurgence in: home serv

2026-06-08 原文 →
AI 资讯

Why Arduino Is Named After a Bar in Italy

Ask a roomful of engineers where the name "Arduino" comes from and you will get confident answers about acronyms, Italian for "bold friend," or some clever electronics pun. Almost all of them are wrong. The most influential open-source microcontroller board in history — the one that introduced millions of students, artists, and tinkerers to embedded development — is named after a bar. The pub in Ivrea The story begins in Ivrea, a small town in northern Italy straddling the Dora Baltea river. In the early 2000s it was home to the Interaction Design Institute Ivrea, where a team led by Massimo Banzi was looking for a cheap, approachable way to teach design students how to make things that sense and respond to the world. The tools available at the time were either too expensive or too intimidating for people who were not electrical engineers. So, in 2005, the team built their own board and released the design as open hardware. They needed a name. Banzi and his collaborators were regulars at a local pub called Bar di Re Arduino — "the Bar of King Arduino." When it came time to christen the project, the bar's name stuck. There was no acronym, no marketing committee, no focus group. The board was named after the place where the people who made it spent their evenings talking through ideas. The medieval king behind the bar The bar itself carries a much older name. Arduin of Ivrea — Arduino in Italian — was a real historical figure, an Italian nobleman who became King of Italy in 1002 and held the crown until 1014. He is one of Ivrea's famous "underdog kings," remembered locally long after his short reign ended. So the chain runs a thousand years deep: a development board used in connected sensors and robots today is named after a pub, which was named after an early-medieval king who ruled around the year 1000. It is the kind of detail that sounds like trivia, but it points at something real about how durable technology actually comes together. Why the origin story matters

2026-06-07 原文 →
AI 资讯

MQTT, CoAP, or HTTP: Which IoT Protocol Fits Your Product?

There are more IoT protocols out there than most teams will ever need. That sounds overwhelming until you realize most connected products only use two or three; one for local communication, one for cloud connectivity, and sometimes one for device management. The problem is not the number of options. The problem is that the protocol you pick at the design stage gets baked into your firmware, your cloud pipeline, and your data model. Change it later and you are rewriting half of your stack. Here is a practical breakdown of the protocols that matter for most developers building connected products today. The Three Layers You Are Choosing Across IoT protocols sit in three distinct layers, and you typically pick one from each: Application Layer → MQTT, CoAP, HTTP, AMQP (how data reaches your cloud) Network Layer → LoRaWAN, NB-IoT, LTE-M, Wi-Fi, BLE (how data travels physically) Industrial Layer → Modbus, OPC UA, Profinet (machine-to-machine on the factory floor) A soil moisture sensor on a farm might use LoRaWAN at the network layer to push data 10 kilometers to a gateway and MQTT at the application layer to deliver that data to a cloud dashboard. Two protocols, two layers, one product. The Big Three for Cloud Connectivity MQTT - The Default for a Reason Publish-subscribe model. Lightweight. Three QoS levels for delivery guarantees. Run over TCP with TLS encryption. Roughly 70% of cloud-connected IoT deployments use MQTT today. A basic publish looks like this: import paho.mqtt.client as mqtt client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2) client.tls_set() client.connect("broker.example.com", 8883) client.publish("sensors/temperature", '{"value": 23.5, "unit": "C"}') Use when: You need real-time telemetry, bidirectional device control, or guaranteed message delivery across unreliable networks. HTTP - Not for Telemetry, But Still Essential Too heavy for continuous sensor data. But it is the standard for OTA firmware updates, cloud API integrations, and management das

2026-06-05 原文 →
AI 资讯

Are AI chatbots making us lose control of our brains?

This week I’ve been at SXSW London. There’s been music, film, and a lot—and I mean a lot—of talk about AI. I also had the opportunity to sit down with Gloria Mark, a psychologist at the University of California, Irvine, who has spent the last 30 years studying how people interact with digital technologies. Early…

2026-06-05 原文 →
AI 资讯

I Made a Battery Admit It Was Only 73% Healthy — On-Device, End to End

Voltage lies. Put a battery under load and its terminal voltage sags. Let it rest and the voltage springs back. A naive fuel gauge watching only voltage will happily tell you a worn-out cell is "fine" right up until it falls off a cliff. The number you actually care about — is this battery still good, or is it time to replace it? — isn't in the instantaneous voltage at all. It's in the capacity : how much charge the cell can still deliver between full and empty. That quantity fades as a cell ages. Tracking it is called State of Health (SoH) , and it's the difference between "the device says 80%" and "the device has 80% of the runtime it had when it was new." I wanted my open-source battery SDK ( ibattery-sdk , Apache-2.0) to learn SoH on the device itself — no cloud model, no floating-point, on MCUs with kilobytes of RAM. This post is the story of getting that working end to end: from a coulomb integral in firmware to a faded value showing up live on a Grafana dashboard. The idea: learn capacity from one full→empty trip You don't need a PhD-grade model to estimate usable capacity. You need two anchors and an ammeter. Full anchor — when the cell is at its full-voltage plateau, declare "this is full" and set the coulomb counter to the rated capacity. Discharge — integrate current over time (coulomb counting). Every milliamp-hour that leaves the cell ticks the counter down. Empty anchor — when the cell hits its empty-voltage threshold, look at how much charge actually flowed. A healthy cell delivers close to its rated capacity before going empty. An aged cell hits empty early — it simply has less to give. From the charge measured between those two anchors, you get the cell's real usable capacity, and SoH = measured / rated . The SDK runs it through an integer EMA (so one noisy excursion doesn't whip the estimate around) and a plausibility guard (reject anything outside 30–120% of rated — that's almost certainly a glitch, not a real measurement). The whole thing is inte

2026-06-05 原文 →
AI 资讯

Smart Lighting Protocol Showdown: Zigbee vs Matter vs BLE Mesh (2026)

Smart Lighting Protocol Showdown: Zigbee vs Matter vs BLE Mesh (2026) After deploying thousands of Zigbee smart lights through our manufacturing line at nexLAMP, and watching countless customers struggle with protocol selection, I decided to write this practical comparison. The Real Problem "My smart lights keep disconnecting! I think I chose the wrong protocol..." This is the #1 complaint I see on Reddit, Xiaohongshu, and Zhihu. The fix isn't a better router — it's choosing the right protocol from day one. Protocol Deep Dive Zigbee — The Workhorse Frequency : 2.4 GHz (separate from WiFi) Topology : Star + Mesh hybrid Max devices : 200+ per coordinator Latency : 50-200ms Cost/unit : ~$3.5-5.0 (Tuya Zigbee drivers) Why it wins for lighting: Each node is a repeater → self-healing mesh Ultra-low power → years on coin cell for sensors Mature ecosystem → Tuya, Hue, Aqara, Xiaomi all ship Zigbee The catch: You need a Zigbee gateway (~$15-20). This is the only upfront cost. BLE Mesh — The Budget Option Frequency : 2.4 GHz (shared with WiFi/BLE) Topology : Managed flood mesh Max devices : ~50 (practical limit ~30) Latency : 100-500ms (increases with node count) Cost/unit : ~$2.0-3.5 The flooding problem: Every command is broadcast to every node. With N nodes, you get O(N²) message propagation. Past 30 devices, you'll notice visible lag. Good for: Small apartments (≤ 6 lights), budget projects. Matter — The Future Transport : Thread (preferred) or WiFi Topology : Thread mesh (similar to Zigbee) Max devices : 250+ (theoretical) Latency : 30-150ms (Thread), variable (WiFi) Cost/unit : ~$7.0-11.0 (currently higher) Matter's promise is genuine cross-platform control. But in 2026: Pros: Native HomeKit, Alexa, Google Home support Thread mesh is excellent (when it works) IP-based → easier cloud integration Cons: Thread Border Routers aren't ubiquitous yet Advanced lighting features still evolving Premium pricing for early adoption Cost Analysis (20-Fixture Deployment) Protocol Driv

2026-06-03 原文 →
开发者

Java on Raspberry Pi: Rediscovering Java Beyond the Enterprise

When most people think about Java, they immediately picture enterprise applications, banking systems, massive backend services, or decades-old corporate software. While Java has earned its reputation in the enterprise world, that is only part of the story. Today, Java can run on devices as small as a Raspberry Pi, opening the door to hardware projects, edge computing, home automation, education, and hands-on learning experiences. Combining Java with Raspberry Pi creates a powerful platform for experimentation, learning, and building real-world solutions that go far beyond traditional enterprise development. Raspberry Pi teaches us about hardware. Java allows us to apply professional software engineering practices to that hardware. Together, they create a powerful platform for learning, prototyping, and building real-world IoT and edge computing solutions. Java Is More Than Enterprise Software Java's enterprise success has sometimes created the misconception that it only belongs in large organizations. In reality, modern Java offers: Excellent support for Linux and ARM architectures. High performance and low resource consumption. Modern frameworks such as Spring Boot, Quarkus, and Micronaut. Strong support for IoT and edge computing. Access to hardware through mature libraries. One of the largest developer ecosystems in the world. The Raspberry Pi highlights a different side of Java—one focused on creativity, experimentation, and direct interaction with the physical world. Instead of building another web application, you can build systems that sense, react, and interact with their environment. Java at the Edge One of the most exciting technology trends today is Edge Computing. Traditionally, devices send data to cloud services where processing and decision-making occur. Edge computing shifts part of that processing closer to where the data is generated. A Raspberry Pi running Java can: Process sensor data locally. Apply business rules before sending information to th

2026-06-02 原文 →
AI 资讯

The deadly Ebola outbreak is proving difficult to control

The alert was raised on May 5. Four health-care workers in the Ituri Province of the Democratic Republic of the Congo had died from an unknown illness within four days. Rapid response teams were sent to investigate, and tests at a research center in Kinshasa revealed the culprit: the Bundibugyo virus, one of the viruses…

2026-05-29 原文 →
AI 资讯

Sniffing Modbus Traffic with 5 Lines of Python (And Why It Should Scare Your OT Team)

⚠️ For defensive/educational purposes only. Sniff only networks you own or are explicitly authorized to test. Unauthorized network monitoring is illegal in most jurisdictions. The uncomfortable truth about your factory floor If your plant uses Modbus TCP — and statistically, it probably does — every register read, every coil write, every sensor value is flying across your network in plaintext . No encryption. No authentication. No signature. Nothing. Modbus was designed in 1979 by Modicon for serial communication between a PLC and a few field devices on a dedicated cable. The threat model was "someone might physically tap the wire." The solution was "don't let strangers into the control room." Forty-five years later, that same protocol is running over your corporate VLAN, talking to cloud historians, and occasionally — if your IT/OT segmentation has gaps — reachable from the internet. Let me show you what that looks like from the wire. The 5-line sniffer This is a defensive monitoring tool. Same code your blue team would use to baseline normal traffic and detect anomalies. Requires scapy : pip install scapy from scapy.all import sniff , TCP , Raw def show_modbus ( pkt ): if TCP in pkt and pkt [ TCP ]. dport == 502 and Raw in pkt : payload = pkt [ Raw ]. load print ( f " { pkt [ ' IP ' ]. src } → { pkt [ ' IP ' ]. dst } : { payload . hex () } " ) sniff ( filter = " tcp port 502 " , prn = show_modbus , store = False ) Run it on a span port, a TAP, or a mirror VLAN, and within seconds you'll see something like this: 192.168.1.50 → 192.168.1.10: 0001000000060103006400 02 192.168.1.10 → 192.168.1.50: 00010000000701030441f00000 192.168.1.50 → 192.168.1.10: 00020000000601100065000102 Every byte tells a story. Let's decode the first packet. Decoding what you just captured The Modbus TCP frame format is documented in the spec (it's public — that's part of the problem): Bytes 0-1: Transaction ID Bytes 2-3: Protocol ID (always 0x0000 for Modbus) Bytes 4-5: Length Byte 6: Unit

2026-05-28 原文 →
AI 资讯

TechCrunch Disrupt 2026 Early Bird ticket savings end in 3 days

There are only 3 days left to save up to $410 on your ticket to TechCrunch Disrupt 2026. Early Bird pricing ends May 29 at 11:59 p.m. PT, and once the deadline passes, ticket prices increase. If you plan to attend one of the most influential gatherings in tech this year, now is the time to lock in your pass before rates go up again.

2026-05-27 原文 →
AI 资讯

The Enhanced Games fit right in with the rest of 2026’s longevity vibes

This Sunday, a group of 42 athletes will gather in Las Vegas to compete in a somewhat unusual sporting competition. Participants in the inaugural Enhanced Games are being encouraged to take performance-enhancing drugs. The goal is to “push the boundaries of human performance.” The games’ organizers have said that competitors will only be taking substances that…

2026-05-22 原文 →
AI 资讯

Alleged Kimwolf Botmaster ‘Dort’ Arrested, Charged in U.S. and Canada

Canadian authorities on Wednesday arrested a 23-year-old Ottawa man on suspicion of building and operating Kimwolf, a fast spreading Internet-of-Things botnet that enslaved millions of devices for use in a series of massive distributed denial-of-service (DDoS) attacks over the past six months. KrebsOnSecurity publicly named the suspect in February 2026 after the accused launched a volley of DDoS, doxing and swatting campaigns against this author and a security researcher. He now faces criminal hacking charges in both Canada and the United States.

2026-05-22 原文 →