Poznámka:
Přístup k této stránce vyžaduje autorizaci. Můžete se zkusit přihlásit nebo změnit adresáře.
Přístup k této stránce vyžaduje autorizaci. Můžete zkusit změnit adresáře.
V IoT Hubu můžete v rámci každé identity zařízení vytvořit až 50 identit modulů. Každá identita modulu implicitně generuje dvojče modulu. Podobně jako dvojčata zařízení jsou dvojčata modulů dokumenty JSON, které ukládají informace o stavu modulu, včetně metadat, konfigurací a podmínek. Azure IoT Hub spravuje dvojče modulu pro každý modul, který připojíte ke službě IoT Hub.
Tento článek předpokládá, že jste si nejprve přečetli Pochopit a používat dvojčata zařízení ve službě IoT Hub.
Na straně zařízení umožňují sady SDK (software development kit) IoT Hubu vytvářet moduly, kde každý z nich otevře nezávislé připojení k IoT Hubu. Tato funkce umožňuje používat samostatné obory názvů pro různé komponenty ve vašem zařízení. Máte například prodejní stroj, který má tři různé senzory. Jednotlivé senzory řídí různá oddělení ve vaší společnosti. Pro každý senzor můžete vytvořit modul, aby oddělení dokázalo odesílat úlohy nebo přímé metody jenom do senzoru, který řídí, a vyhnout se konfliktům a chybám uživatelů.
Identita modulu a dvojče modulu poskytují stejné funkce jako identita zařízení a dvojče zařízení, ale s jemnější granularitou. Tato jemná granularita umožňuje schopným zařízením, jako jsou zařízení založená na operačním systému nebo firmwarová zařízení, která spravují více komponent, izolovat konfiguraci a podmínky pro každou z těchto komponent. Identita modulů a dvojčata modulů poskytují oddělení problémů správy při práci se zařízeními IoT, která mají modulární softwarové komponenty. Snažíme se podporovat všechny funkce dvojčete zařízení na úrovni dvojčete modulu podle obecné dostupnosti dvojčete modulu.
Poznámka:
Funkce popsané v tomto článku jsou k dispozici pouze na úrovni Standard služby IoT Hub. Další informace o úrovních Basic a Standard/Free IoT Hub najdete v tématu Volba správné úrovně a velikosti služby IoT Hub pro vaše řešení.
Tento článek popisuje:
- Struktura dvojčete modulu: značky, požadované a hlášené vlastnosti.
- Operace, které aplikace zařízení a back-end řešení můžou provádět na modulových dvojčatech.
Pokyny k používání ohlášených vlastností, zpráv typu zařízení-cloud nebo nahrávání souborů najdete v doprovodných materiálech ke komunikaci typu zařízení-cloud.
Podívejte se na Pokyny ke komunikaci cloud na zařízení pro používání požadovaných vlastností, přímých metod nebo zpráv typu cloud na zařízení.
Dvojčata modulů
Dvojčata modulů ukládají informace související s modulem, které:
Moduly na zařízení a v IoT Hubu mohou být použity k synchronizaci podmínek a konfigurace modulů.
Back-end řešení může použít k dotazování a cílení dlouhotrvajících operací.
Životní cyklus dvojčete modulu je propojený s odpovídající identitou modulu. Dvojčata modulů se implicitně vytvářejí a odstraňují při vytvoření nebo odstranění identity modulu ve službě IoT Hub.
Dvojče modulu je dokument JSON, který obsahuje:
Značky. Část dokumentu JSON, do kterého můžou back-endové aplikace číst a zapisovat do. Značky nejsou viditelné pro moduly v zařízení. Značky jsou nastavené pro účely dotazování.
Požadované vlastnosti. Používá se společně s ohlášenými vlastnostmi k synchronizaci konfigurace nebo podmínek modulu. Back-endové aplikace můžou nastavit požadované vlastnosti a aplikace modulu je může číst. Aplikace modulu může také přijímat oznámení o změnách požadovaných vlastností.
Ohlášené vlastnosti Používá se společně s požadovanými vlastnostmi k synchronizaci konfigurace nebo podmínek modulu. Aplikace modulu může nastavit ohlášené vlastnosti a back-endové aplikace je mohou číst a dotazovat.
Vlastnosti identity modulu Kořen dokumentu JSON dvojčete modulu obsahuje vlastnosti jen pro čtení z odpovídající identity modulu uložené v registru identit.
Následující příklad ukazuje dokument JSON dvojčete modulu:
{
"deviceId": "devA",
"moduleId": "moduleA",
"etag": "AAAAAAAAAAc=",
"status": "enabled",
"statusReason": "provisioned",
"statusUpdateTime": "0001-01-01T00:00:00",
"connectionState": "connected",
"lastActivityTime": "2015-02-30T16:24:48.789Z",
"cloudToDeviceMessageCount": 0,
"authenticationType": "sas",
"x509Thumbprint": {
"primaryThumbprint": null,
"secondaryThumbprint": null
},
"version": 2,
"tags": {
"deploymentLocation": {
"building": "43",
"floor": "1"
}
},
"properties": {
"desired": {
"telemetryConfig": {
"sendFrequency": "5m"
},
"$metadata" : {...},
"$version": 1
},
"reported": {
"telemetryConfig": {
"sendFrequency": "5m",
"status": "success"
},
"batteryLevel": 55,
"$metadata" : {...},
"$version": 4
}
}
}
Na nejvyšší úrovni objekt dvojčete modulu obsahuje vlastnosti identity modulu a kontejnerové objekty pro tags a pro vlastnosti reported a desired. Kontejner properties obsahuje některé prvky jen pro čtení ($metadata a $version) popsané v metadatech dvojčat modulů a v částech Optimistická souběžnost .
Příklad ohlášené vlastnosti
V předchozím příkladu obsahuje dvojče modulu nahlášenou batteryLevel vlastnost. Tato vlastnost umožňuje dotazovat se na moduly a pracovat s ním na základě poslední hlášené úrovně baterie. Mezi další příklady patří schopnosti modulu aplikace pro generování sestav nebo možnosti připojení.
Poznámka:
Ohlášené vlastnosti zjednodušují scénáře, ve kterých vás zajímá poslední známá hodnota vlastnosti. Použijte zprávy typu zařízení-cloud, pokud chcete zpracovávat telemetrii modulu v sekvencích událostí s časovým razítkem, jako jsou časové řady.
Příklad požadované vlastnosti
V předchozím příkladu se požadované a hlášené vlastnosti dvojčete modulu telemetryConfig používají v back-endových aplikacích a v aplikaci modulu k synchronizaci konfigurace telemetrie pro tento modul. Příklad:
Back-endová aplikace nastaví požadovanou vlastnost s požadovanou hodnotou konfigurace. Tady je část dokumentu s požadovanou vlastností:
... "desired": { "telemetryConfig": { "sendFrequency": "5m" }, ... }, ...Aplikace modulu obdrží oznámení o změně okamžitě, pokud je modul připojený. Pokud není připojený, aplikace modulu se při připojení řídí tokem opětovného připojení modulu. Aplikace modulu pak hlásí aktualizovanou konfiguraci (nebo chybový stav pomocí
statusvlastnosti). Tady je část ohlášených vlastností:"reported": { "telemetryConfig": { "sendFrequency": "5m", "status": "success" } ... }Back-endová aplikace může sledovat výsledky operace konfigurace napříč mnoha moduly pomocí dotazování na dvojčata modulů.
Poznámka:
Předchozí fragmenty kódu jsou příklady, optimalizované pro čitelnost, jedním ze způsobů, jak zakódovat konfiguraci modulu a její stav. IoT Hub neukládá konkrétní schéma pro požadované a hlášené vlastnosti v dvojčatech modulu.
Důležité
IoT technologie Plug and Play definuje schéma, které používá několik dalších vlastností k synchronizaci změn požadovaných a ohlášených vlastností. Pokud vaše řešení používá ioT technologie Plug and Play, musíte při aktualizaci vlastností dvojčete dodržovat technologie Plug and Play konvence. Další informace a příklad najdete v Zapisovatelných vlastnostech v IoT Plug and Play.
Zázemní operace
Back-endové aplikace pracují s dvojčetem modulu pomocí následujících atomických operací, které jsou vystavené prostřednictvím protokolu HTTPS:
Načíst modul twin podle ID Tato operace vrátí dokument dvojčete modulu, včetně značek a požadovaných a hlášených vlastností systému.
Částečně aktualizovat dvojče modulu Tato operace částečně aktualizuje značky nebo požadované vlastnosti modulového dvojčete. Částečná aktualizace se vyjadřuje jako dokument JSON, který přidává nebo aktualizuje libovolnou vlastnost. Vlastnosti nastavené na
nulljsou odstraněny. Následující příklad vytvoří novou požadovanou vlastnost s hodnotou{"newProperty": "newValue"}, přepíše existující hodnotuexistingPropertypomocí"otherNewValue"a odebereotherOldProperty. Žádné další změny stávajících požadovaných vlastností nebo značek:{ "properties": { "desired": { "newProperty": { "nestedProperty": "newValue" }, "existingProperty": "otherNewValue", "otherOldProperty": null } } }Nahraďte požadované vlastnosti. Tato operace zcela přepíše všechny existující požadované vlastnosti a nahradí nový dokument JSON .
properties/desiredNahradit značky Tato operace zcela přepíše všechny existující značky a nahradí je novým dokumentem JSON pro
tags.Přijímat dvojí oznámení Tato operace upozorní, když dojde ke změně digitálního dvojčete. Pokud chcete dostávat oznámení o změnách dvojčete modulu, musí vaše řešení IoT vytvořit trasu a nastavit zdroj dat roven twinChangeEvents. Ve výchozím nastavení neexistuje žádná taková trasa, takže se neposílají žádná dvojitá oznámení. Pokud je míra změn příliš vysoká nebo z jiných důvodů, například z interních selhání, může IoT Hub odeslat pouze jedno oznámení, které obsahuje všechny změny. Proto pokud vaše aplikace potřebuje spolehlivé auditování a protokolování všech přechodných stavů, měli byste použít zprávy typu zařízení-cloud. Další informace o vlastnostech a textu, které jsou vráceny ve zprávě s oznámením dvojníka, najdete v tématu Schémata událostí bez telemetrie.
Všechny předchozí operace podporují optimistickou souběžnost a vyžadují oprávnění ServiceConnect, jak je definováno v článku Řízení přístupu ke službě IoT Hub.
Kromě těchto operací můžou back-endové aplikace dotazovat dvojčata modulu pomocí dotazovacího jazyka ioT Hub podobného SQL.
Operace modulů
Modulová aplikace pracuje s modulovým dvojčetem pomocí následujících atomických operací.
Načíst dvojče modulu Tato operace vrátí dokument dvojčete modulu (včetně požadovaných a ohlášených vlastností systému) pro aktuálně připojený modul.
Částečně aktualizujte ohlášené vlastnosti. Tato operace umožňuje částečnou aktualizaci ohlášených vlastností aktuálně připojeného modulu.
Sledujte požadované vlastnosti. Aktuálně připojený modul se může rozhodnout dostávat oznámení o aktualizacích požadovaných vlastností, když k nim dojde.
Všechny předchozí operace vyžadují oprávnění DeviceConnect , jak je definováno v článku Řízení přístupu ke službě IoT Hub .
Sady SDK pro zařízení Azure IoT usnadňují používání předchozích operací z mnoha jazyků a platforem.
Formát značek a vlastností
Značky, požadované vlastnosti a ohlášené vlastnosti jsou objekty JSON s následujícími omezeními:
Klíče: Všechny klíče v objektech JSON jsou kódované UTF-8, rozlišují velká a malá písmena a mají délku až 1 kB. Povolené znaky vylučují řídicí znaky UNICODE (segmenty C0 a C1), a také
.,$, a SP.Hodnoty: Všechny hodnoty v objektech JSON můžou být následující typy JSON: logická hodnota, číslo, řetězec, objekt. Podporují se také pole.
Celá čísla můžou mít minimální hodnotu -4503599627370496 a maximální hodnotu 4503599627370495.
Řetězcové hodnoty jsou kódované UTF-8 a mohou mít maximální délku 4 kB.
Hloubka: Maximální hloubka objektů JSON ve značkách, požadovaných vlastnostech a ohlášených vlastnostech je 10. Například následující objekt je platný:
{ ... "tags": { "one": { "two": { "three": { "four": { "five": { "six": { "seven": { "eight": { "nine": { "ten": { "property": "value" } } } } } } } } } } }, ... }
Rozměr modulu typu twin
IoT Hub vynucuje limit velikosti 8 kB pro hodnotu tags, a limit velikosti 32 kB zvlášť pro hodnotu properties/desired a properties/reported. Tyto součty nezahrnují prvky pouze pro čtení, jako jsou $version a $metadata/$lastUpdated.
Velikost dvojčete se vypočítá takto:
IoT Hub kumulativně počítá a přičítá délku klíče a hodnoty každé vlastnosti.
Klíče vlastností se považují za řetězce s kódováním UTF8.
Jednoduché hodnoty vlastností se považují za řetězce s kódováním UTF8, číselné hodnoty (8 bajtů) nebo logické hodnoty (4 bajty).
Velikost řetězců s kódováním UTF8 se vypočítá počítá počítáním všech znaků s výjimkou řídicích znaků UNICODE (segmenty C0 a C1).
Komplexní hodnoty vlastností (vnořené objekty) se počítají na základě agregované velikosti klíčů vlastností a hodnot vlastností, které obsahují.
IoT Hub odmítne s chybou všechny operace, které by zvýšily velikost těchto dokumentů nad limit.
Metadata dvojčat modulů
IoT Hub udržuje časové razítko poslední aktualizace každého objektu JSON v požadovaných a hlášených vlastnostech modulového dvojčete. Časová razítka jsou ve formátu UTC a kódována ve YYYY-MM-DDTHH:MM:SS.mmmZ .
Příklad:
{
...
"properties": {
"desired": {
"telemetryConfig": {
"sendFrequency": "5m"
},
"$metadata": {
"telemetryConfig": {
"sendFrequency": {
"$lastUpdated": "2016-03-30T16:24:48.789Z"
},
"$lastUpdated": "2016-03-30T16:24:48.789Z"
},
"$lastUpdated": "2016-03-30T16:24:48.789Z"
},
"$version": 23
},
"reported": {
"telemetryConfig": {
"sendFrequency": "5m",
"status": "success"
},
"batteryLevel": "55%",
"$metadata": {
"telemetryConfig": {
"sendFrequency": "5m",
"status": {
"$lastUpdated": "2016-03-31T16:35:48.789Z"
},
"$lastUpdated": "2016-03-31T16:35:48.789Z"
},
"batteryLevel": {
"$lastUpdated": "2016-04-01T16:35:48.789Z"
},
"$lastUpdated": "2016-04-01T16:24:48.789Z"
},
"$version": 123
}
}
...
}
Tyto informace se uchovávají na všech úrovních (nejen na listech struktury JSON), aby se zachovaly aktualizace, které odeberou klíče objektu.
Optimistická souběžnost
Značky, požadované vlastnosti a ohlášené vlastnosti podporují optimistickou souběžnost. Pokud potřebujete zaručit pořadí aktualizací vlastností dvojčete, zvažte implementaci synchronizace na úrovni aplikace čekáním na zpětné volání ohlášených vlastností před odesláním další aktualizace.
Dvojčata modulů mají ETag (etag vlastnost) podle RFC7232, která představuje jejich JSON reprezentaci. Můžete použít vlastnost etag v operacích podmíněné aktualizace z back-end aplikací, abyste zajistili konzistenci. Tato možnost zajišťuje konzistenci v operacích, které zahrnují tags kontejner.
Požadované a hlášené vlastnosti modulového dvojníka mají také $version hodnotu, která je zaručené jako inkrementální. Podobně jako u značky ETag můžete použít hodnotu verze k vynucení konzistence aktualizací. Například aplikace modulu pro ohlášenou vlastnost nebo back-endovou aplikaci pro požadovanou vlastnost.
Verze jsou užitečné také v případě, že pozorující agent (například aplikace modulu sledující požadované vlastnosti) musí řešit kolize mezi výsledkem operace načtení a notifikací aktualizace. Více informací najdete v části Tok opětovného připojení modulu.
Proces opětovného připojení modulu
IoT Hub nezachová oznámení o aktualizaci požadovaných vlastností pro odpojené moduly. Následuje, že modul, který se připojuje, musí kromě odběru oznámení o aktualizacích načíst celý dokument požadovaných vlastností. Vzhledem k možnosti konfliktu mezi oznámeními o aktualizaci a úplným načítáním musí být zajištěn následující proces:
- Aplikace modulu se připojuje ke službě IoT Hub.
- Aplikace modulu se přihlásí k odběru oznámení o aktualizaci požadovaných vlastností.
- Modul aplikace načte celý dokument pro požadované vlastnosti.
Aplikace modulu může ignorovat všechna oznámení s $version menší nebo rovnou než verze úplného načteného dokumentu. Tento přístup je možný, protože IoT Hub zaručuje, že verze se vždy zvyšují.
Další kroky
Pokud si chcete vyzkoušet některé koncepty popsané v tomto článku, projděte si následující kurzy ke službě IoT Hub: