Shelly ThreadLink: Blir Thread det lokala IP-nätverket för smarta hem?

Shelly ThreadLink gör inte Thread till ett IP-nätverk—Thread har byggts på IPv6 från början. Det som förändras är hur Shelly planerar att använda nätverket. I stället för att främst reservera Thread för Matter och behålla leverantörens API:er, molnanslutning och avancerade funktioner på Wi‑Fi är ThreadLink utformat för att överföra flera av dessa vägar över samma energieffektiva mesh-nätverk.

Det gör ThreadLink mer intressant än ännu ett tillkännagivande om Matter-kompatibilitet. Om metoden fungerar som utlovat kan Thread bli det energieffektiva IP-gränsskiktet i ett smart hem: reläer, brytare, sensorer och styrenheter kommunicerar över Thread, medan Home Assistant, servrar, Wi‑Fi-enheter och Ethernet-system fortsätter att ingå i det bredare lokala nätverket. Firmwaren är dock inte tillgänglig ännu—Shelly planerar för närvarande uppdateringen som användaren själv väljer att aktivera till ungefär tre månader efter annonseringen den 3 september.

Vad är Shelly ThreadLink?

ThreadLink är en kommande alternativ firmware för berättigade Shelly Gen4-enheter som använder deras Thread-kompatibla radio som en bredare IP-anslutning i stället för att huvudsakligen begränsa den till en enda användningsväg.

I sitt officiella ThreadLink-tillkännagivande uppger Shelly att firmwaren kommer att köra IPv6-nätverk över Thread samtidigt som TCP samt RPC/UDP-kommunikation stöds. Samma energieffektiva radio är avsedd att överföra:

• Matter-anslutning,
• Shelly Cloud-trafik,
• Shelly RPC- och API-kommunikation,
• direkt enhet-till-enhet-styrning,
• konfiguration och diagnostik,
• och djupare Home Assistant-integration.

Den viktigaste arkitektoniska förändringen ser ut så här:

VANLIG NUVARANDE MODELL

                    Matter
                      |
                    Thread

Shelly-enhet ───── Wi‑Fi ───── Shelly API
       |
       └─────────── Wi‑Fi ───── Moln


THREADLINK-RIKTNING

                    Matter
                      |
Shelly API ─────── Thread ───── Molnväg
                      |
                  Lokal P2P

I stället för att kräva Wi‑Fi för enhetens leverantörsspecifika sida medan Thread transporterar Matter, vill Shelly att Thread självt ska tillhandahålla IP-transport för flera användningsområden samtidigt.

Den skillnaden är viktig eftersom Matter och Thread inte är samma nätverkslager.

Är Shelly ThreadLink tillgängligt nu?

Nej. ThreadLink har annonserats, men produktionsfirmwaren är ännu inte allmänt tillgänglig.

Shelly uppger att det kommer att levereras som separat, kostnadsfri firmware som användaren väljer att aktivera för berättigade Gen4-enheter cirka tre månader efter annonseringen den 3 september 2026.

Användare väljer per enhet om den ska köra den vanliga Wi‑Fi-inriktade firmwaren eller ThreadLink.

Detta innebär att ThreadLink för närvarande bör betraktas som en annonserad arkitektur snarare än en funktion som alla Gen4-ägare kan aktivera redan idag.

Det innebär också att det är för tidigt att hävda att varje Gen4-modell kommer att få den fasta programvaran. Shelly säger specifikt berättigade Gen4-enheter, så den slutliga kompatibilitetslistan är viktig.

Var inte Thread redan ett IP-nätverk?

Ja. Detta är den viktigaste missuppfattningen att reda ut.

Thread utformades som ett IPv6-baserat mesh-nätverk som använder 6LoWPAN över IEEE 802.15.4-radio. Thread Groups förklaring av Threads IPv6-grund daterar denna designprincip till flera år innan Matter existerade.

Nätverksstacken kan förenklas så här:

APPLIKATIONER

Matter
Leverantörsprotokoll
Andra IP-tjänster
       |
       v
TRANSPORT

UDP / TCP
       |
       v
NÄTVERK

IPv6
       |
       v
ANPASSNING

6LoWPAN
       |
       v
RADIO

IEEE 802.15.4

Thread är därför inte ett Matter-specifikt radioprotokoll på samma sätt som många slentrianmässigt beskriver det.

Det är ett energisnålt IP-nätverk som kan bära applikationsprotokoll ovanpå sig.

Matter är för närvarande dess mest synliga konsumentinriktade tillämpning för smarta hem, men Thread är i sig utformat för att vara applikationslageragnostiskt.

ThreadLink gör inte Thread till ett IP-nätverk. Det använder Thread mer som det IP-nätverk det redan är.

Vad är egentligen nytt med ThreadLink?

Det nya är inte IPv6 i sig. Det är beslutet att låta en enda konsument-IoT-enhet använda Thread för flera applikationsvägar som fortfarande ofta är beroende av Wi-Fi.

THREAD SOM MATTER-TRANSPORT

Matter
  |
Thread


             ↓


THREAD SOM NÄTVERK

Matter ─────────┐
                |
Shelly RPC ─────┤
                |
Lokalt API ──────┼── IPv6 / Thread
                |
P2P-logik ──────┤
                |
Molnsökväg ─────┘

Detta förändrar radions roll.

Thread är inte längre användbart enbart därför att ett annat ekosystem kan styra ett relä via Matter. Det kan också bära Shellys egen applikationstrafik, lokala logik, konfiguration, diagnostik och potentiellt programvaruuppdateringar.

Shelly beskriver ThreadLink som stöd för UDP för snabb lokal kommunikation och fullt TCP-stöd för större eller tillförlitlighetskänsliga överföringar, till exempel konfigurationsdata och diagnostik.

Det är en betydligt bredare tolkning av vad en Thread-ansluten konsumentenhet kan göra.

Varför exponerar Matter inte alla Shelly-funktioner?

Eftersom interoperabilitet och leverantörsdifferentiering löser olika problem.

Matter ger tillverkare och plattformar för smarta hem en standardiserad enhetsmodell. Ett Matter-kompatibelt relä kan exponera kända funktioner på ett sätt som Apple Home, Google Home, Amazon Alexa, SmartThings eller Home Assistant kan förstå, utan att varje plattform behöver implementera ett helt annat proprietärt protokoll.

Den standardiseringen är värdefull.

Men en leverantör kan fortfarande exponera funktioner utöver den standardiserade Matter-modellen, till exempel:

• djupare energimätningar,
• diagnostikinformation,
• speciellt reläbeteende,
• enhetsspecifik konfiguration,
• skript- eller automationsfunktioner,
• avancerad statusinformation,
• och leverantörens hanteringsfunktioner.

Det skapar ofta två parallella vägar i dag:

ENHET
  |
  +-- Matter
  |      |
  |      v
  |  Standardfunktioner
  |  Apple / Google / HA
  |
  +-- Leverantörs-API
         |
         v
     Avancerade funktioner
     Diagnostik
     Konfiguration

ThreadLink försöker behålla dessa två vägar utan att kräva två olika nätverkstransporter:

          Matter
            \
             \
              Thread
             /
            /
       Shelly RPC

Shelly säger att en särskild Home Assistant-modul kommer att exponera den bredare Shelly-funktionsuppsättningen utöver vad Matters datamodell tillhandahåller.

ThreadLink är därför viktigt eftersom Matter kan fortsätta vara en applikation på Thread utan att behöva vara den enda applikationen på Thread.

Kan Shelly-enheter styra varandra utan Wi-Fi?

Enligt Shellys ThreadLink-design, ja.

Shelly säger att ThreadLink-enheter kan kommunicera direkt via Thread-meshnätverket med hjälp av dess API, vilket gör att scener, spärrar och automationer kan köras peer-to-peer.

Det viktiga är vad som händer vid ett fel.

Shelly säger att dessa relationer mellan enheter kan fortsätta även om:

• internetanslutningen bryts,
• Shelly Cloud är inte nåbart,
• eller hemmets Wi-Fi-nätverk slutar fungera.

En enkel relation skulle därför kunna se ut så här:

Väggbrytare
     |
   Thread
     |
     v
    Relä

i stället för att alltid kräva:

Väggbrytare
     |
     v
Wi-Fi-/router
     |
     v
Hemmserver
     |
     v
Wi-Fi-/router
     |
     v
Relä

Det gör inte serversökvägen fel.

Det innebär att inte varje lokal åtgärd måste använda det.

Behöver lokal styrning fortfarande Home Assistant?

För enkla enhetsrelationer, inte alltid. För bredare orkestrering har Home Assistant fortfarande en helt annan uppgift.

Att en lokal väggbrytare slår på ett relä är fundamentalt annorlunda än en automation som kombinerar flera system.

Logik på enhetsnivå kan hantera:

• enkla relationer mellan brytare och relä,
• spärrar,
• enkla scener,
• och omedelbart reservbeteende.

En hemautomationsserver passar bättre för logik som:

OM

solelexport > 3000 W

OCH

batteriets laddningsnivå > 80 %

OCH

rummet är bemannat

OCH

elpriset är lågt

SEDAN

aktivera HVAC-/apparatbelastning

Det arbetsflödet omfattar energi, närvaro, priser, scheman och potentiellt flera protokoll.

Det hör hemma på ett högre orkestreringslager. Den bredare övergången till lokal bearbetning i Home Assistant följer samma princip: behåll lämpliga beslut nära hemmet och reservera molnberoenden för arbetsbelastningar som faktiskt behöver dem.

LOKAL STYRNING PÅ ENHETSNIVÅ

Brytare
   |
 Thread P2P
   |
Relä


LOKAL STYRNING PÅ SERVERNIVÅ

Solenergi ───────┐
Energimätare ┤
Närvaro ────┼── Home Assistant ── HVAC
Schemaläggning ────┤
Övriga IoT ───┘

Lokalt först betyder inte alltid server först.

Ett robust smart hem kan använda lokala enhetsrelationer för enkla åtgärder och låta hemmaservern fokusera på systemöverskridande logik, historik, policyer, instrumentpaneler och tillstånd.

Hur kan ThreadLink nå molnet utan Wi-Fi?

Ett av ThreadLinks mer ovanliga löften är att slutpunkten kan fortsätta vara en Thread-enhet och samtidigt få åtkomst till Shelly Cloud.

Själva enheten behöver inte Wi-Fi-uppgifter för den vägen.

Shelly beskriver arkitekturen så här:

Shelly ThreadLink-enhet
          |
          v
     IPv6 / Thread
          |
          v
 Thread-gränsruter
          |
          v
        NAT64
          |
          v
   IPv4-internettjänst
          |
          v
      Shelly Cloud

Idén passar in i den bredare utvecklingen av Thread. Thread 1.4 formaliserade ytterligare arbete kring en standardiserad väg från Thread-nätverk till internettjänster, inklusive IPv6-till-IPv4-anslutning vid nätverkskanten.

Den viktiga konceptuella förändringen är:

Molnanslutning behöver inte längre innebära Wi-Fi-anslutning på slutpunkten.

En strömsnål enhet kan använda Thread lokalt, medan IP-routing längre upp i nätverket hanterar åtkomst till externa tjänster.

Det innebär inte att ThreadLink endast fungerar lokalt.

Det visar motsatsen: lokal enhetskommunikation och valfri molnanslutning kan dela samma IP-arkitektur.

Vad gör en Thread Border Router egentligen?

En Thread Border Router ansluter Thread-meshen till det bredare IP-nätverket. Den är i grunden en router, inte en protokollöversättare för varje kommando i det smarta hemmet.

Thread Groups förklaring av Thread Border Routers roll gör denna skillnad tydlig.

Traditionella arkitekturer för smarta hem ser ofta ut så här:

Zigbee-enhet
     |
     v
Zigbee-nätverk
     |
     v
Leverantörshubb
     |
protokollöversättning
     |
     v
IP-nätverk

Thread använder i stället IP i själva enhetsnätverket:

Thread-enhet
     |
 IPv6 / Thread
     |
     v
Gränsrouter
     |
 IP-routing
     |
     v
Hemnätverk

Border Routern vidarebefordrar paket mellan fysiska nätverkssegment.

Den behöver inte översätta varje applikationskommando från Thread till ett proprietärt LAN-protokoll.

Det innebär att Home Assistant kan finnas någon annanstans i det lokala nätverket:

Thread-enhet
     |
Thread-mesh
     |
Gränsrouter
     |
Ethernet-/Wi-Fi-LAN
     |
     +-- Home Assistant
     +-- Hemmaserver
     +-- Andra IP-tjänster

En Matter-controller och en Thread Border Router har därför olika roller. Border Routern tillhandahåller nätverksåtkomst; Matter tillhandahåller en applikations- och controllerrelation ovanpå det nätverket. Om flera plattformar styr samma Matter-enheter oberoende av varandra introducerar flera Matter-controllers ett separat lager för förtroende och ägarskap som Thread-routing i sig inte löser.

När trafiken lämnar Thread-meshen gäller vanliga IP-regler fortfarande. Home Assistants nätverkstillgänglighet är fortfarande beroende av användbar adressering, routing, policy och en fungerande returväg mellan controllern och slutpunkten.

Betyder ThreadLink att Thread kommer att ersätta Wi-Fi?

Nej. Thread och Wi-Fi är optimerade för olika typer av trafik.

Home Assistants aktuella dokumentation om Thread beskriver Thread som både strömsnålt och bandbreddssnålt, vilket gör det särskilt lämpligt för enheter som utbyter relativt små datamängder.

Ett strömsnålt relä behöver inte Wi-Fi:s bandbredd.

En säkerhetskamera i 4K bör inte tvingas över till Thread bara för att Thread är IP-baserat.

Thread håller inte på att bli det nya Wi-Fi. Det kan bli den strömsnåla IP-kanten av samma hemnätverk.

Är Thread på väg att bli den strömsnåla kanten av hemmets LAN?

Det är här ThreadLink blir mer intressant än det enskilda tillkännagivandet om Shellys firmware.

Ett framtida lokalt nätverk kan komma att likna mindre flera isolerade ekosystem för smarta hem och mer en enda IP-arkitektur fördelad över flera fysiska överföringsmedier:

                     HEMSERVER
                          |
                          |
                    HEMMETS IP-NÄTVERK
                          |
        +-----------------+----------------+
        |                 |                |
     ETHERNET           WI-FI            THREAD
        |                 |                |
       NAS             Kameror          Reläer
     Servrar           Telefoner           Sensorer
   Arbetsstationer          TV-apparater            Brytare
                                       Lås

Slutpunkten behöver inte kräva att varje enhet använder samma radio.

Det viktigaste är att de högre lagren kan kommunicera via standardiserad routing när det är lämpligt.

Detta skiljer sig grundläggande från att försöka få Thread, Wi-Fi och Ethernet att konkurrera om att bli den enda vinnaren.

Det framtida smarta hemmet kanske inte har ett enda trådlöst nätverk. Det kan ha en gemensam IP-arkitektur över flera fysiska nätverk.

Vad förändrar ThreadLink för Home Assistant?

ThreadLink ger potentiellt Home Assistant två användbara vägar till samma fysiska Shelly-enhet.

Den första är standard-Matter:

Shelly-enhet
      |
Matter över Thread
      |
Thread-gränsruter
      |
Matter-controller för Home Assistant
      |
Standardfunktioner för Matter

Den andra är den leverantörsspecifika väg som Shelly planerar:

Shelly-enhet
      |
Shelly RPC över Thread
      |
Thread-gränsruter
      |
Home Assistant
      |
Shelly-specifika funktioner

Den officiella Matter-arkitekturen i Home Assistant tydliggör redan skillnaden mellan nätverk och applikation: Matter är ett kontrollprotokoll på applikationsnivå som kan kommunicera över Wi-Fi, Ethernet eller Thread beroende på enheten.

ThreadLink bygger vidare på den lagerindelade designen.

Matter kan ge interoperabilitet mellan ekosystem, medan Shelly-integrationen kan behålla djupare enhetsspecifik funktionalitet.

Detta är en starkare arkitektur än att tvinga användare att välja mellan interoperabilitet och avancerade leverantörsspecifika funktioner.

Är ett enda Thread-nätverk verkligen möjligt idag?

Inte alltid. Dagens Thread-distributioner kan fortfarande vara mer fragmenterade än vad den idealiska arkitekturen antyder.

Home Assistant beskriver för närvarande sin Thread-integration som under utveckling och håller uttryckligen reda på de olika Thread-nätverk som finns i ett hem.

Ett hushåll kan upptäcka något i stil med:

Apple Thread-nätverk
       |
olika autentiseringsuppgifter


Google Thread-nätverk
       |
olika autentiseringsuppgifter


Home Assistant Thread-nätverk
       |
different credentials

Enheter i separata Thread-nätverk blir inte automatiskt ett enda stort mesh-nätverk bara för att de alla använder Thread.

Home Assistant kan hjälpa användare att inspektera befintliga nätverk och, i de fall det stöds, ansluta en Home Assistant-gränsruter till ett föredraget befintligt nätverk. Men konsumentekosystemet motsvarar ännu inte ett perfekt enhetligt Thread-mesh-nätverk i alla hem.

Detta är en viktig verklighetskontroll för ThreadLink.

Även en tekniskt elegant IP-arkitektur är fortfarande beroende av kompatibilitet mellan gränsroutrar, gemensamma autentiseringsuppgifter, nätverkstopologi och faktiskt stöd i implementeringen.

Hur förändrar Thread 1.4 bilden?

Thread 1.4 för ekosystemet närmare idén om ett enhetligt nätverk.

Thread Group beskriver en av de viktigaste förbättringarna som ett enda mesh-nätverk som blir enklare att skapa.

Målet är att uppdaterade enheter och gränsroutrar från olika ekosystem ska känna igen och ansluta till ett befintligt Thread-nätverk i stället för att skapa ytterligare ett mesh-nätverk i onödan.

Thread 1.4 lägger också till eller förbättrar:

• en standardiserad väg till molnanslutning
• Thread över infrastruktur
• insyn i nätverksdiagnostik och felsökning
• konvergens mellan ekosystemens nätverk
• och förbättringar av driftsättningen.

Detta ger ThreadLink ett bredare sammanhang.

TIDIGARE THREAD

IPv6-mesh med låg energiförbrukning
      |
Matter blir dominerande
konsumentapplikation


THREAD 1.4

Bättre nätverkskonvergens
Bättre infrastruktur för gränsroutrar
Molnväg
Diagnostik
      |
      v


THREADLINK-IDÉ

Matter
Leverantörs-API
Moln
P2P
      |
samma IP-transport med låg energiförbrukning

ThreadLink är därför inget bevis på att alla leverantörer kommer att välja samma angreppssätt.

Men det är ett konkret exempel på den typ av mångfald av tillämpningar som Threads nätverksarkitektur alltid har möjliggjort.

Måste all automatisering i det smarta hemmet gå via hemservern?

Nej. Ett motståndskraftigt system kan fördela logiken utifrån hur komplex och viktig åtgärden är.

En enkel förregling behöver inte nödvändigtvis en tur och retur till servern.

En energi­automatisering för hela hemmet gör det förmodligen.

Denna uppdelning kan göra nätverket mer motståndskraftigt, eftersom ett fel i ett lager inte automatiskt tar bort all lokal funktionalitet. Den förklarar också varför den verkliga prestandavägen för Home Assistant omfattar radioenheter, nätverk, mäklare, målenheter och lagring, inte bara processorn som kör Home Assistant.

Gör ThreadLink en hemserver mindre viktig?

Det kan göra hemservern mindre viktig som protokollgateway, men tydligare definiera den som ett orkestreringslager.

Traditionella smarta hem samlade på sig bryggor eftersom många enhetsnätverk inte kunde delta direkt i hemmets IP-nätverk.

GAMLA MODELLEN

Zigbee-enheter ── Leverantörshubb ──┐
                               |
Andra enheter ─── Gateway ─────┼── Hemserver
                               |
Wi‑Fi-enheter ─────────────────┘

En mer IP-orienterad arkitektur kan se annorlunda ut:

ENHETSLAGER

Thread-enheter
Wi‑Fi-enheter
Ethernet-enheter
       |
       v

IP-NÄTVERKSLAGER
       |
       v

KONTROLLAGER

Home Assistant
       |
       +-- Automatiseringar
       +-- Tillstånd
       +-- Historik
       +-- Policyer
       +-- Instrumentpaneler
       +-- Logik över protokollgränser
       |
       v

DATALAGER

Säkerhetskopior
NAS
Beständig lagring

Servern behöver inte längre hantera varje paket för att motivera sin existens.

Dess värde kommer i allt högre grad från att bevara helhetsbilden:

• vilka enheter som finns,
• vilket tillstånd de befinner sig i,
• hur orelaterade system samverkar,
• vad som hände i går,
• vilka automatiseringar som ska köras,
• vad som ska hända när en tjänst slutar fungera,
• och hur konfiguration och historik skyddas.

Dessa ansvarsområden har olika krav på lagring och återställning. Genom att separera beständiga Home Assistant-data från tillfälligt körningstillstånd blir det mycket enklare att skydda datalagret i den här arkitekturen.

Thread minskar behovet av protokollöversättning, inte behovet av programvara för hemautomatisering.

Det betyder inte heller att Home Assistant plötsligt behöver kraftfull maskinvara. De aktuella kraven på maskinvara för Home Assistant-servern är fortfarande måttliga för vanlig automatisering; det är kameror, lång historik, lokal röststyrning, databaser och ytterligare tjänster som vanligtvis skapar en större serverbelastning.

Om flera av dessa tjänster förväntas köras tillsammans bör dimensioneringen av smart hem-servern baseras på hela tjänstestacken snarare än antalet Thread-enheter.

Bör Shelly Gen4-ägare byta från Wi-Fi till ThreadLink?

Det är för tidigt att rekommendera det.

Den fasta programvaran har ännu inte nått allmän tillgänglighet, den slutliga listan över kvalificerade enheter är viktig, och verklig interoperabilitet med befintliga Thread-nätverk och Border Routers behöver fortfarande testas utanför demonstrationer.

När ThreadLink blir tillgängligt bör Gen4-ägare utvärdera:

• om deras exakta Shelly-enhet är kvalificerad,
• om en lämplig Thread Border Router redan finns,
• om hemmets Thread-nätverk är enhetliga eller fragmenterade,
• om de nödvändiga Shelly-funktionerna fungerar via den nya Home Assistant-modulen,
• om åtkomst till molnet behövs,
• om direkt enhet-till-enhet-logik är användbar,
• och om den befintliga Wi-Fi-installationen redan fungerar tillförlitligt.

Den korrekta hållningen 2026 är därför att följa implementeringen i stället för att migrera en fungerande installation enbart utifrån tillkännagivandet.

Blir Thread det lokala IP-nätverket för smarta hem?

Thread kommer sannolikt inte att bli det enda lokala nätverket i ett smart hem. Det har större chans att bli det energieffektiva IP-baserade kantenätverket i det nätverket.

Ethernet förblir den naturliga överföringstekniken för servrar, NAS-enheter och fasta system med hög bandbredd.

Wi-Fi förblir det naturliga trådlösa nätverket för telefoner, bärbara datorer, kameror, skärmar och enheter som behöver betydligt högre bandbredd.

Thread passar för energieffektiva kantenheter:

• sensorer,
• reläer,
• strömbrytare,
• lås,
• styrningar,
• och andra enheter som utbyter relativt små datamängder.

Shelly ThreadLink är intressant eftersom det slutar behandla den kanten som en silo för en enda applikation.

Matter kan tillhandahålla standardiserad styrning av ekosystemet.

Shelly RPC kan tillhandahålla mer omfattande leverantörsfunktioner.

Direktkommunikation mellan enheter kan hålla enkla åtgärder lokala.

En Border Router kan ansluta mesh-nätverket till det större lokala nätverket.

Home Assistant kan orkestrera över flera protokoll.

Och molnanslutning kan förbli valfri i stället för att kräva att själva ändpunkten ansluter till Wi-Fi.

För användare som vill ha det orkestreringslagret på ett dedikerat lokalt system är ZimaBoard 2 för smarta hem ett exempel på hur styrenheten kan köras på en utbyggbar, alltid påslagen server medan Thread Border Routers och ändpunktsradioenheter förblir separata delar av nätverket.

Det framtida smarta hemmet kan därför handla mindre om att välja mellan Thread, Wi-Fi och Ethernet och mer om att ge varje teknik en roll inom samma IP-arkitektur.

Det är den större idén bakom ThreadLink.

Thread har alltid varit ett IP-nätverk.

Shelly börjar helt enkelt använda det som ett sådant.

Vanliga frågor: Shelly ThreadLink och Thread-nätverk för smarta hem

Vad är Shelly ThreadLink?

ThreadLink är en tillkännagiven valfri uppdatering av den fasta programvaran för berättigade Shelly Gen4-enheter. Shelly uppger att enheternas Thread-radio ska användas för att överföra Matter, Shellys RPC/API-trafik, molnanslutning och direktkommunikation mellan enheter över samma energieffektiva IP-meshnätverk.

Är Shelly ThreadLink tillgängligt nu?

Nej. Shelly tillkännagav ThreadLink den 3 september 2026 och planerar för närvarande att släppa den kostnadsfria, valfria fasta programvaran ungefär tre månader senare för berättigade Gen4-enheter.

Kommer alla Shelly Gen4-enheter att stödja ThreadLink?

Shelly har endast lovat uppdateringen för berättigade Gen4-enheter. En fullständig slutgiltig kompatibilitetslista bör kontrolleras när den fasta programvaran blir tillgänglig.

Gör ThreadLink Thread till ett IP-nätverk?

Nej. Thread har alltid varit baserat på IPv6, 6LoWPAN och IEEE 802.15.4. ThreadLink förändrar hur Shelly avser att använda det befintliga IP-nätverket genom att köra mer än bara Matter över det.

Är Matter samma sak som Thread?

Nej. Matter är en standard för smarthemsstyrning på applikationsnivå. Thread är ett energisnålt IPv6-meshnätverk som kan bära Matter eller andra kompatibla applikationsprotokoll.

Kan Thread fungera utan Matter?

Ja. Thread är agnostiskt när det gäller applikationslagret. Konsumentprodukter med Thread är i dag starkt förknippade med Matter, men Thread kan i sig bära andra IP-baserade applikationsprotokoll.

Kan ThreadLink-enheter fungera utan Wi‑Fi?

Shelly uppger att ThreadLink-enheter kan använda Thread för Matter, lokal API-kommunikation, automatisering mellan enheter och molnanslutning via en Thread Border Router, utan att själva slutpunkten ansluter till Wi‑Fi.

Kan ThreadLink fungera utan internet?

Shelly uppger att direkta scener mellan enheter, förreglingar och automatiseringar kan köras lokalt i Thread-meshnätverket, även om internetanslutningen eller Wi‑Fi-nätverket slutar fungera.

Kräver ThreadLink en Thread Border Router?

En Border Router krävs när ThreadLink-enheter behöver kommunicera med hemmets bredare LAN, appar, Home Assistant eller molntjänster. Shelly uppger att scener mellan enheter kan köras i själva Thread-meshnätverket.

Ersätter ThreadLink Home Assistant?

Nej. Direkt logik för kommunikation mellan enheter kan undanröja behovet av en server i enkla enhetsrelationer, medan Home Assistant fortfarande är användbart för automatisering mellan protokoll, historik, instrumentpaneler, policyer, scheman och orkestrering av hela hemmet.

Kommer Thread att ersätta Wi‑Fi?

Förmodligen inte. Thread är utformat för IoT-enheter med låg energiförbrukning och relativt låg bandbredd. Wi‑Fi är fortfarande bättre lämpat för produkter med högre bandbreddskrav, som kameror, skärmar, telefoner och datorer.

Vad är skillnaden mellan en Thread Border Router och en smarthemshubb?

En Thread Border Router vidarebefordrar främst IPv6-trafik mellan Thread-meshnätverket och det större IP-nätverket. En traditionell hubb eller brygga översätter ofta mellan ett icke-IP-baserat enhetsnätverk och ett IP-baserat LAN eller en applikation.

Kan ett hem ha mer än ett Thread-nätverk?

Ja. Dagens hem kan innehålla separata Thread-nätverk från Apple, Google, Home Assistant eller andra aktörer, med olika autentiseringsuppgifter. Thread 1.4 är avsett att göra det enklare att samordna dem i ett befintligt mesh, men implementeringar i praktiken beror fortfarande på stöd från enheter och ekosystem.

Vad förändrar Thread 1.4?

Thread 1.4 förbättrar nätverksanslutning mellan olika ekosystem, Border Router-infrastruktur, molnanslutning, diagnostik, konfigurering, tillförlitlighet och möjligheten att upprätthålla ett större enhetligt Thread-meshnätverk.

Varför är ThreadLink viktigt för hemmaservrar?

Det innebär att hemmaservern kan fokusera mindre på att översätta proprietära enhetsnätverk och mer på orkestrering, tillstånd, historik, policyer, automatisering mellan system och beständiga data, medan Thread, Wi‑Fi och Ethernet hanterar den underliggande IP-transporten.