Problem about the temperature sampe and the remote monitoring sample running on ublox C027

[shaoenliu]

I am recently using the mbed ublox C027 device, but when I run the sample temp_sensor_anomaly, and an error showed up which is "can not open source input file "cstdbool" " ; Another sample is reomte_monitoring , which I can successful compile but from the terminal there is only showing: Info: IoT Hub SDK for C, version 1.1.14. And in the iothub there is not sign of data from the device. So if anyone knows the problem, it will be very great.

[markrad]

Hi @shaoenliu,

I am not familiar with the particular device you are using. Do you build the code for this device using the web based IDE from MBED? If so, then please start by trying this piece of code: https://developer.mbed.org/users/markrad/code/NTPTest/. All this piece of code does is connect to the Internet and acquire the current time from an NTP server. It was built for the FRDM-K64. You will need to build it for your device.

Mark Radbourne MSFT

[shaoenliu]

Hello @markrad, Thanks for the information. Yes, I am using the web based IDE from MBED, and I have successfully ran the NTP code that you provided, and the time is showing with no error. But I still can not run the temp_sensor_anomaly because of its compiling errors. When it is possible, you can try to import this program and compile it with the platform of FRDM-K64, I think the same error will appear. And if you have any ideas, please tell me.

[markrad]

Hi @shaoenliu,

I tried compiling the sample you referenced for the FRDM K64 and I did encounter the same error as yourself. I was able to circumvent this issue by simply commenting out the line that references cstdbool in _iothub_clientauthorization.h. Unfortunately that was not enough to get the code to compile. I also had to change the reference in main.c to platform.h to read

#include "azure_c_shared_utility/platform.h"

and furthermore I changed two references to _IOT_AGENTOK to read _CODEFIRSTOK. I suspect that some changes in the SDK have broken this sample. Try those changes and let me know if it will compile and execute successfully.

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad Thank you, I did the changes that you mentioned, and the code can be compiled and executed. But from the serial terminal there is only one line showing: Info: IoT Hub SDK for C, version 1.1.16 The Iothub received nothing and the lcd showed nothing as well, from the point of my view, the problem could be the code line IOTHUB_CLIENT_LL_HANDLE iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString(connectionString, HTTP_Protocol); Beacuse I print some numbers to the serial terminal, and the numbers ended before this line. And I think the sample of remote_monitoring has the same problem. Do you know the problem? I am so confused now.

[markrad]

Hi @shaoenliu,

Ensure you have updated the connectionString variable to contain the connection string of one of your IoT hub devices. If you run Windows the easiest way to do that is to use the Device Explorer tool, right click on a device and select 'copy connection string'. Paste that into the appropriate location. The reason I ask this is that the code does not actually attempt to connect to the hub until you send the first message. If the function you have called out is failing it is likely a parsing error.

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad , Yes, the connectionString and deviceID are all in the right position, and when I use the Device Explorer to monitor the device, there is no reaction from it. From the code, I think the temperature and the humidity should be showed in the serial terminal and the device explorer as well. And for the function, it is just a guessing from my side, and the real reason lead to this, I am really not sure.

[markrad]

Hi @shaoenliu,

I would expect you to see some sort of error on the serial output. If you just leave it sit does it ever produce any output?

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad When I run the code, there is only one line on the serial output which is: Info: IoT Hub SDK for C, version 1.1.16 Do you have any idea?

[markrad]

Hi @shaoenliu,

No I have not seen an issue like this before. You said that the NTP test code worked so it doesn't seem likely that it is hanging on that. Can you add some printf statements through the main function so that we can see what function it calls before stopping?

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad , Yes, I did some printf test in the main function, and the printf stoped at the code line IOTHUB_CLIENT_LL_HANDLE iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString(connectionString, HTTP_Protocol); So I think it is hanging on there, but I dont know the reason for that.

[markrad]

Hi @shaoenliu,

That is a very odd place for the code to hang. It does not connect to the IoT hub at this point but defers it until you send your first message. Can you test your connection string with a different client please? The node js sample is reasonably quick and easy to set up and run: https://github.com/Azure/azure-iot-sdk-node/blob/master/device/samples/readme.md. It will run on either Windows or Linux.

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad I think the connection string has no problem, I think at least two of the samples hanged on the place that I mentioned. And what do you mean by sending the first message. I would like to run the node js code, but unfortunately my device is mbed ublox C027 and it only support C language. And I am eager to connect it to the iothub. Here are the screen shot of my connection string, printftest and the output from serial terminal

[shaoenliu]

Hi @markrad By the way, what do you mean by changing a different clint? Is that means change another connection string?

[markrad]

Hi @shaoenliu,

I was suggesting that you use a different IoT Hub client such as the node js client SDK on a Windows or Linux machine. With that you could use the same device connection string and see if it works that way. This would simply be a test of your device connection string. Since I don't have one of your devices, I cannot test this for myself. However, you can modify the SDK code and add additional logging into our code. I would start be adding some logging to the function create_iothub_instance in the file iothub_client/src/iothub_client.c.

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad, The connection string has been tested by my college using node js SDK, and I think there is no problem for that. And I have a question for the temp_sensor_anomaly sample, I did comment some place of the code, which make it running futher, however hanging on another place FrdmDevice* frdmDevice = CREATE_MODEL_INSTANCE(Contoso, FrdmDevice, true); I was wondering that the function above can only be used in FRDM-K64F or it can also be used for other mbed devices?

[markrad]

Hi @shaoenliu,

There are multiple devices that use the MBed web IDE to build the SDK in the Azure Certified Devices catalog so I don't have a good reason that it would fail in your device's environment.

What did you comment out to get it to go further? This may give me a clue about why you are unable to run the code.

Mark Radbourne MSFT

[shaoenliu]

Hi @markrad, So basicly my idea is to trace the defination of the function when the function does not works. For this code is, the code hangs on the function line IOTHUB_CLIENT_LL_HANDLE iotHubClientHandle = IoTHubClient_LL_CreateFromConnectionString(connectionString, HTTP_Protocol); So I go to the iothub_client.c and iothub_client_ii.c to find the function IoTHubClient_LL_CreateFromConnectionString. And in the file iothub_client_ii.c, I did some printf test, which shows that the code hang on somewhere, and I comment two part of this file. and the LogInfo lines are the printf test.

[shaoenliu]

And for the main function, in order to continue, I also comment the code if (IoTHubClient_LL_SetOption(iotHubClientHandle, "TrustedCerts", certificates) != IOTHUB_CLIENT_OK) { printf("failure to set option \"TrustedCerts\"\r\n"); } (void)printf("Checkpoint 4.1.\r\n");

[markrad]

Hi @shaoenliu,

On the Mbed you will need the TrustedCerts code or you will either not be able to connect to the hub or the connection will be unable to validate the server certificate.

Let's try and address these other instance one at a time.

Is the code hanging on the call to tickcounter_create?

[shaoenliu]

Hi@markrad yes, it is hanging on tickcounter_create, and for this reason, I comment it out, but it seems it doesd not influence the whole project. And what is the TrustedCerts code, there is a cert.h and cert.c in the code, I am not sure is that what you mean. If I understand it corret, the NTP test is to test weather the device is connected to the Internet instead of Iothub, right? Beacuse so far I am not so sure it connected to Iothub or not.

[shaoenliu]

Hi,@markrad Btw, I have to mention that the device I am using(Ublox C027) have only 32KB RAM, but from the documentation it says we need at least 64KB RAM for Azure-SDK-C. Could this be the fatal problem?

[markrad]

Hi @shaoenliu,

Possibly. Without a suitable device to use to test the code for myself though I can only speculate. You might try using the PaHo MQTT library and communicate with the Azure IoT Hub with that instead. Its more work and I can't actually guarantee that it will result in lower RAM requirements. I have a sample implementation for the ESP8266 that may help. You can find it here https://github.com/markrad/Azure-IoT-ESP8266

Mark Radbourne MSFT

[markrad]

Hi @shaoenliu,

Since I have not heard from you I have closed this issue.

Mark Radbourne MSFT

[ghost]

@markrad Just an FYI, the problem you mentioned above about "changed two references to IOT_AGENT_OK to read CODEFIRST_OK" on June 12, 2017 are still present in the latest SDK. I downloaded and ran into the same issue when compiling; there is no IOT_AGENT_OK defined anywhere in the SDK that I can find so I put a simple #define IOT_AGENT_OK CODEFIRST_OK to resolve the compile issue. This appears to be a bug that should probably be fixed so people don't keep tripping over it.

FYI, I am using arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 7-2018-q2-update) 7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]

[markrad]

HI @jflynn129,

I've notified the product group of this issue. Thanks for letting us know.

Mark Radbourne MSFT