Open daveRobert1441 opened 7 months ago
Hello @daveRobert1441! Are you running into this issue still if you don't modify the example to use your telemetry properties? And to confirm, is your code based off of this sample? https://github.com/Azure/azure-sdk-for-c-arduino/tree/main/examples/Azure_IoT_Central_ESP32
Hi @vaavva, I was able to get it working by commenting out this function: //(void)azure_pnp_send_device_info(&azure_iot, properties_request_id++); I think it hit the EXIT_IF_TRUE statement and stalled execution...?
Interesting - I'm surprised the log for the error isn't showing up, plus the result for that function doesn't look like it stalls execution (https://github.com/Azure/azure-sdk-for-c-arduino/blob/main/examples/Azure_IoT_Central_ESP32/Azure_IoT_Central_ESP32.ino#L435). It would keep telemetry from being sent until the next iteration of the loop, but that should still happen within 10-20 seconds at maximum. A precondition failing could look like this since there wouldn't be an error printed and execution would halt so you can connect a debugger - perhaps this within send device info is the culprit https://github.com/Azure/azure-sdk-for-c-arduino/blob/main/examples/Azure_IoT_Central_ESP32/AzureIoT.cpp#L609, but I'm not sure why the message span wouldn't be at least size 1.
Thanks for the info, I'll look into your suggestions.
Hello, Sorry to bother you. I'm a newbie having a problem with the same example app as you (as mentioned by @vaavva) but my problem is really simple. From the look of your trace, you can do what I can't so I'm hoping you can shed some light.
As shown below, I always get a provisioning failed error when I run the app. (FWIW, I have written a different app in which I had no difficulty connecting directly to a device I had manually-created in an IotHub so I'm not totally ignorant ! It's only the automatic device registration mechanism of DPS that I'm having trouble with).
2024/7/24 11:55:04 [INFO] WiFi connected, IP address: 192.168.254.50 2024/7/24 11:55:04 [INFO] MQTT client target uri set to 'mqtts://global.azure-devices-provisioning.net' 2024/7/24 11:55:04 [INFO] MQTT client connecting. 2024/7/24 11:55:05 [INFO] MQTT client connected (session_present=0). 2024/7/24 11:55:05 [INFO] MQTT client subscribing to '$dps/registrations/res/#' 2024/7/24 11:55:05 [INFO] MQTT topic subscribed (message id=23166). 2024/7/24 11:55:05 [INFO] MQTT client publishing to '$dps/registrations/PUT/iotdps-register/?$rid=1' 2024/7/24 11:55:05 [INFO] MQTT message received. 2024/7/24 11:55:05 [ERROR] Device provisisioning failed. 2024/7/24 11:55:05 [INFO] MQTT done processing received message 2024/7/24 11:55:05 [ERROR] Azure IoT client is in error state. 2024/7/24 11:55:05 [INFO] MQTT client being disconnected.
My Azure has no Iot Central so I'm just hoping/expecting DPS to create a new device in the (single) IotHub connected to that DPS after I run the code. But that never happens. As I'm not using an X509 CERT (the Enrollment Group connected to my DPS is set for Symmetric Key attestation), it seems the only values I should need to set in iot_config.h are DPS_ID_SCOPE IOT_CONFIG_DEVICE_KEY IOT_CONFIG_DEVICE ID
I understand SCOPE is the scope value recorded on my (only) DPS page but I"m confused by the names of the next two. IOT_CONFIG_DEVICE_ID would seem to be the unique ID of the thing I want DPS to add to my IotHub and I'm guessing that IOT_CONFIG_DEVICE_KEY is - despite the name - the Primary Key of my only Enrollment Group (Why isn't it called DPS_PRESHARED_KEY I'm wondering ?)
Anyway, since it doesn't work, I guess I must be wrong. Can you possibly clarify this for me ?
Thanks in advance, John
Unfortunately I have no experience with Azure IoT Hub, as I've only ever used the IoT Central App. Looks like you're using a very similar library within the Azure_SDK_for_C. Did you use the Azure_IoT_Hub example in the library?
Query/Question I'm using an ESP32 to connect to my IOT Central Application. The device connects and registers through DPS, it is automatically added to the correct template. However the LOG stalls after this point (see below), nothing is published. I've edited the ESP32 example to use my telemetry properties.
Full log output: 1970/1/1 00:00:02 [INFO] WiFi connected, IP address: 192.168.**.64 1970/1/1 00:00:02 [INFO] Setting time using SNTP ...... 2024/5/3 18:30:50 [INFO] Time initialized! 2024/5/3 18:30:50 [INFO] Telemetry frequency set to once every 10 seconds. 2024/5/3 18:30:50 [INFO] Azure IoT client initialized (state=2) 2024/5/3 18:30:50 [INFO] MQTT client target uri set to 'mqtts://global.azure-devices-provisioning.net' 2024/5/3 18:30:50 [INFO] MQTT client connecting. 2024/5/3 18:30:51 [INFO] MQTT client connected (session_present=0). 2024/5/3 18:30:51 [INFO] MQTT client subscribing to '$dps/registrations/res/#' 2024/5/3 18:30:51 [INFO] MQTT topic subscribed (message id=51357). 2024/5/3 18:30:51 [INFO] MQTT client publishing to '$dps/registrations/PUT/iotdps-register/?$rid=1' 2024/5/3 18:30:52 [INFO] MQTT message received. 2024/5/3 18:30:52 [INFO] MQTT client publishing to '$dps/registrations/GET/iotdps-get-operationstatus/?$rid=1&operationId=4.4c1b5bdabbfbb01b.f01df5a6-bb3d-4b76-8b2d-e2f1ecd2922a' 2024/5/3 18:30:52 [INFO] MQTT message received. 2024/5/3 18:30:55 [INFO] MQTT client publishing to '$dps/registrations/GET/iotdps-get-operationstatus/?$rid=1&operationId=4.4c1b5bdabbfbb01b.f01df5a6-bb3d-4b76-8b2d-e2f1ecd2922a' 2024/5/3 18:30:55 [INFO] MQTT message received. 2024/5/3 18:30:55 [INFO] MQTT client being disconnected. 2024/5/3 18:30:55 [INFO] MQTT client target uri set to 'mqtts://iotc-2696ce99-6da9-499a-88b8-879dbdec3bf1.azure-devices.net' 2024/5/3 18:30:55 [INFO] MQTT client connecting. 2024/5/3 18:30:56 [INFO] MQTT client connected (session_present=0). 2024/5/3 18:30:56 [INFO] MQTT client subscribing to '$iothub/methods/POST/#' 2024/5/3 18:30:56 [INFO] MQTT topic subscribed (message id=56104). 2024/5/3 18:30:56 [INFO] MQTT client subscribing to '$iothub/twin/res/#' 2024/5/3 18:30:56 [INFO] MQTT topic subscribed (message id=62637).
No telemetry sent.
Why is this not a Bug or a feature Request? I don't think this is a bug, perhaps something I'm overlooking.
Setup (please complete the following information if applicable):