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

标签:#art

找到 1970 篇相关文章

AI 资讯

Shelly in Home Assistant: Local Switching & Energy Metering

I didn't put Shelly Plus 1PM and 2PM behind my wall switches for the app or the cloud. I put them there because each one quietly does two jobs at once: it switches a circuit locally, and it measures exactly what that circuit draws. The moment I had them wired in, every light group and every roller shutter in the flat became both controllable AND measurable in Home Assistant — with no separate energy meter and, deliberately, no cloud in the loop. This is the part most Shelly write-ups skip: the metering isn't a bonus, it's the reason to use them. This is how I set them up, kept them fully local, wired the physical switches so they still work like switches, and pulled per-channel energy into the HA Energy Dashboard. Why the Plus series for in-wall use The Plus 1PM and 2PM are Gen2 devices. That matters: they speak a local RPC API over HTTP and WebSocket, they're supported by the native Home Assistant Shelly integration out of the box, and nothing about them needs the internet once they're on your Wi-Fi. The 1PM is a single relay with power metering — I use it behind light circuits. The 2PM has two relays with metering and a dedicated cover/roller-shutter mode — that's what sits behind my shutters. The catch you plan for up front: both need a neutral wire in the switch box. Older installations often don't have one at the switch, so check before you order. If the neutral is there, the rest is easy. The first thing I change: kill the cloud, pin the IP Straight out of the box I do two things in the Shelly web UI (just browse to the device's IP). First, I disable Bluetooth and Cloud under Settings — I don't want the device reaching out to anything, and Home Assistant talks to it directly on the LAN. Second, I give it a fixed address via a DHCP reservation on my router, so the native integration never loses it after a reboot. That's the whole hardening story. No firmware flashing, no third-party firmware — stock Shelly firmware with the cloud switched off is already a fully

2026-08-05 原文 →
AI 资讯

Why Does This Download End in .tar.zst?

You download a backup, software package, or dataset and find a file with an unusually long extension: something.tar.zst It looks like two file formats have somehow been glued together. That is essentially what happened — but each part has a different job. The .tar part bundles files and folders together. The .zst part compresses that bundle. Understanding the difference also explains why these files can be awkward to open on a Mac. Two formats, two jobs ZIP is both an archive format and a compression format. It can collect multiple files and folders while also reducing their size. Zstandard works differently. Zstandard is primarily a compression format. It can compress a file very quickly and efficiently, but it does not by itself turn a folder containing many files into a conventional archive. That is where TAR comes in. TAR collects files, folders, filenames, permissions, and directory structures into one .tar file. Despite its common association with compressed downloads, TAR does not necessarily compress that data. The result can be large, but it contains everything in one structured file. Zstandard then compresses that TAR file: folder with files ↓ something.tar ↓ something.tar.zst This produces the double extension. tar tells you what is inside the compressed data. zst tells you how that data was compressed. Why not just use ZIP? ZIP remains convenient because nearly every operating system can open it without additional software. But convenience is not its only consideration. Zstandard was designed for fast, lossless compression. It can provide a useful combination of compression ratio and decompression speed, especially for large backups, software packages, logs, databases, and datasets. That makes .tar.zst attractive for systems that regularly process large amounts of data. The sender gets a compact archive that can be created and extracted quickly. The problem only becomes visible when that file reaches an operating system without native Zstandard support.

2026-08-04 原文 →
AI 资讯

How I Made Features in a Large Flutter App Actually Removable

"Just delete the features you don't need" is the easiest thing in the world to write in a README, and the hardest to make true. I hit this building a Flutter app with six verticals in one codebase — marketplace, ride-hailing, car rentals, social feed, chat, wallet. Deleting one should have been simple. It wasn't, because every feature had tendrils: a route in the central route table a tab hardcoded in the app shell a button on the home screen a service registered in main() Remove the feature folder and you get a wall of compile errors from files that have nothing to do with it. Here's what actually worked. Make three things data instead of code 1. Routes Each feature exposes its own routes from its own folder: class WalletModule extends AppModule { const WalletModule (); @override String get id = > 'wallet' ; @override List < GetPage > get pages = > [ GetPage ( name: AppRoutes . wallet , page: () = > const WalletScreen ()), ]; } The app's route table becomes a composition: static final routes = < GetPage >[ .. . _centralRoutes , .. . ModuleRegistry . pages , ]; Adding or removing a feature stops being an edit to a shared file. It's one line in a registry. 2. Bottom-navigation tabs This one surprised me. My app shell imported the feed widget directly: // before — the always-present shell depends on an optional feature import '../feed/feed_tab.dart' ; The shell ships in every build. That import meant the social feature could never be removed. So a tab became a small data class that a feature contributes: class ShellTab { final String id ; final int order ; // core tabs use 10/30/40 final IconData icon ; final String labelKey ; final Widget Function () builder ; } Social contributes its tab at order 20, slotting between home and alerts without the shell knowing it exists. The shell merges its own tabs with ModuleRegistry.shellTabs and sorts. 3. Entry points Home screens linked to feature screens with Get.toNamed(...) . Named routes are already decoupled — no import nee

2026-08-04 原文 →