在将真实设备连接到 IoT Central 之前,我确实建议执行以下步骤:
在 IoT Hub 上创建 3 个设备(例如 device1、device2 和 device3),每个设备具有不同的身份验证类型,例如sas、selfSigned和certificateAuthority(您也可以使用免费层)
为每种身份验证类型创建模拟设备(控制台程序),将它们连接到 IoT 中心并发送消息。
我相信所有设备都会正常工作(就像在我的测试中一样),因此通过 CA 证书(和叶证书)和自签名证书进行身份验证是可以的。
请注意,上述步骤在我的测试中通过了使用 C# 模拟设备 (.Net SDK) 以及使用我的Azure IoT Hub Tester的 MQTT 直接协议。
一旦您的模拟设备正常工作,此步骤就是用您的真实设备替换它们(sas 设备除外)。这是一个关键步骤,它将证明您的真实设备可以连接到 Azure IoT Hub。
在这一步中,我们将用 IoT Central 应用程序替换 IoT 中心。您可以创建免费的预览应用程序。您可以上传设备模板,例如FM-201 物联网网关,并从该模板创建步骤 1 中的 3 台设备。注意,使用与步骤 1 中相同的设备 ID,我们可以使用相同的设备叶证书。
使用工具dps_cstr我们可以获得 IoTC App 底层 IoT Hub 的设备连接字符串。
替换模拟设备中的主机名,您还需要从此连接字符串创建 sas 令牌,以便设备使用 sas 令牌进行身份验证。
运行连接到 IoTC App 的模拟设备。
根据我最近的测试,您会看到只有sas 设备在工作,其他设备(例如证书设备)因身份验证错误而失败。
此步骤用于排查为什么切换到 IoTC 应用程序的 X509 模拟设备未使用相同的证书进行身份验证。这个案例没有合适的文档,如果我们可以在 IoT Hub 和 IoTC App 之间切换 X509 设备,我希望 IoT Central 团队的某个人会回答这个问题,就像我们可以为sas 设备做的那样。
更新:
基于Provisioning Device Client Sample - Microsoft Azure IoT SDK for .NET,步骤 6 和 7 适用于sas 设备,其中实用程序dps_cstr将为SecurityProviderSymmetricKey注册设备。一旦设备已注册并使用此安全提供程序进行配置,则必须仅使用这种方式连接真实设备。这就是我们收到模拟 x509 设备错误的原因。因此,以下步骤是使用叶证书 (device3.pfx) 配置 X509 设备的示例。请注意,CA 证书必须上传到 IoTC 应用程序。
6a。将设备 3 (从步骤 1) 注册到IoTC应用程序
string GlobalDeviceEndpoint = "global.azure-devices-provisioning.net";
string idScope = "<idScope_IoTCapp>";
string certificateFileName = @"<your path>\device3.pfx";
//
var cert = new X509Certificate2(certificateFileName, "1234");
var securityProvider = new SecurityProviderX509Certificate(cert);
var transport = new ProvisioningTransportHandlerMqtt(TransportFallbackType.TcpOnly);
var provClient = ProvisioningDeviceClient.Create(GlobalDeviceEndpoint, idScope, securityProvider, transport);
var result = provClient.RegisterAsync().Result;
string hostname = result.AssignedHub;
string deviceId = result.DeviceId;
此时IoTC App中的设备状态为Provisioned,可以连接模拟或真实设备。
6b。 您可以使用REST API来为 IoT Central 应用程序提供设备。以下屏幕片段显示了使用 Postman 配置 X509 device3通过其叶证书进行身份验证:
在使用 REST 调用之前,我们必须将device3 叶证书添加到 Postman:
现在,我们可以调用配置服务:
PUT https://global.azure-devices-provisioning.net/0ne000AA0F5/registrations/device3/register?api-version=2019-03-31
获取registrationState对象:
GET https://global.azure-devices-provisioning.net/0ne000AA0F5/registrations/device3/operations/{operationId}?api-version=2019-03-31
如上图所示,IoTC 应用程序已准备好与真正的X509 设备连接。
"registrationState": {
"x509": {
"enrollmentGroupId": "fa472b95-b5f6-47af-a4ef-9490f45c3961"
},
"registrationId": "device3",
"createdDateTimeUtc": "2020-01-04T17:09:15.5147034Z",
"assignedHub": "iotc-bceedf66-9792-4f32-b49f-7674a6aa09ff.azure-devices.net",
"deviceId": "device3",
"status": "assigned",
"substatus": "initialAssignment",
"lastUpdatedDateTimeUtc": "2020-01-04T17:09:15.6947214Z",
"etag": "IjBmMDA3YTgzLTAwMDAtMGMwMC0wMDAwLTVlMTBjNmJiMDAwMCI="
}
请注意,在使用 REST 调用配置sas 设备(例如本测试中的device1 )的情况下,必须使用sas 令牌配置Authorization标头:
string sas = generateSASToken($"{scopeId}/registrations/{deviceId}", deviceKey, "registration");
7a。以下代码片段是从 X509 设备及其叶证书 (device3.pfx) 发送遥测数据的示例:
using (var dc = DeviceClient.Create(hostname, new DeviceAuthenticationWithX509Certificate(deviceId, cert), Microsoft.Azure.Devices.Client.TransportType.Mqtt))
{
var telemetryDataPoint = new { bleCnt = 50, telemetryLocation = new { lat = 49.85, lon = 20.99, alt = 29.41 } };
dc.OpenAsync().ConfigureAwait(false);
dc.SendEventAsync(new Message(Encoding.UTF8.GetBytes(JsonConvert.SerializeObject(telemetryDataPoint)))).ConfigureAwait(false);
dc.CloseAsync().ConfigureAwait(false);
}
此外,使用基于M2Mqtt库的Azure IoT Hub 测试器,带有叶证书device3.pfx的 device3已成功连接到 IoTC 应用程序。
基于上述更新,我想更正第 10 步。看起来,一旦在 IoTC 应用程序上配置了设备,就可以在Azure IoT Hub和 IoT Central 应用程序之间切换设备(例如 sas 和 X509)。换句话说,配置过程中的主机名(例如,来自我的测试 IoTC 应用程序预览iotc-bceedf66-9792-4f32-b49f-7674a6aa09ff.azure-devices.net)是面向设备的有效端点。
我的测试还表明,具有 MQTT 直接协议的设备使用叶证书 (device3.pfx) 连接到 IoTC 应用程序在两个方向都运行良好,包括 PnP 模型。
以下屏幕片段显示了设备端和 IoTC 应用程序:
发布一些遥测数据:
在仪表板上显示遥测数据:
以及 IoTC 应用程序上的根 CA 证书: