How to Build Direct Connected Devices

Not sure how much help I can be until you can figure out a way to look at a logfile. As I mentioned, there is a facility to create log files (which I’ve not used myself), and it looks like you enable it by defining a couple constants in /st-device-sdk-c/stdkconfig:


Look at the /st-device-sdk-c/src/iot_log_file.c to see what it does. I don’t know of any documentation on this unfortunately. Maybe someone here can provide more insight.

What kind of mobile phone do you have? I have iphone and it first asks if you want to connect to the AP. If you can verify that the device has gone into SoftAP mode and is broadcasting it’s SSID but you never see any progress in the mobile app after initiating the onboarding through Add device, then it sounds like it’s getting hung up in the TLS handshaking between mobile and device. Are you typing in the device serial number manually in the mobile app or using a QR code?

Is the button capability even working? I thought there were issues, so I was staying away from it.

That’s pretty interesting - what is your device?

Hi, @bban! @orangebucket is right, here you can find the capability definition.
In case you have more doubts about this, you can open a new post and tag us to keep this thread on the direct-connected devices topic as it is device presentation-related.

Just a typo, I’m sending in the correct values. As I stated, it works but I have double press or hold first. Presumably this changes the capability value to double or held in Smartthings, then when ‘pushed’ comes in on a subsequent press the automation is triggered. Single presses after that do not trigger the automation till you do a double or held to change the state.

To restate my question so it doesn’t get lost with the typo re-explanation. Does the button device have to reset its button capability value after sending in ‘pushed’ for subsequent pressed to to trigger an automation?

does this mean it did not out up to esp32?

[3/10] Performing build step for ‘bootloader’
[1/2] Linking C executable bootloader.elf
[2/2] Generating binary image from built executable v2.8
Generated C:/Users/eddie/st-device-sdk-c-ref/apps/esp32/switch_example/build/bootloader/bootloader.bin
ninja: build stopped: subcommand failed.
ninja failed with exit code 1
WARN : Failed to copy output file (C:\Users\eddie\st-device-sdk-c-ref\apps\esp32\switch_example\build\switch_example.bin)
WARN : Failed to copy output file (C:\Users\eddie\st-device-sdk-c-ref\apps\esp32\switch_example\build\switch_example.elf)
WARN : Failed to copy output file (C:\Users\eddie\st-device-sdk-c-ref\apps\esp32\switch_example\build\

binary path : C:\Users\eddie\st-device-sdk-c-ref\output\esp32\iotcore_switch_example_20210302_ca43c5e_f883b41


this is what i get when running

python apps/esp32/switch_example flash

raise SerialTimeoutException(‘Write timeout’)
serial.serialutil.SerialTimeoutException: Write timeout failed with exit code 1

Usage: python apps/[BSP_NAME]/[APP_NAME]
python [BSP_NAME] [APP_NAME]

emw3080 : light_example, switch_example
emw3166 : light_example, switch_example
esp32 : light_example, ota_demo, switch_example
esp32s2 : light_example
esp8266 : light_example, switch_example
rtl8195 : light_example, switch_example
rtl8720c : light_example, switch_example
rtl8721c : light_example, switch_example

ex) python apps/esp32/switch_example
ex) python esp32 light_example


It’s critical for anyone developing direct-connected device apps to know that I have discovered that there is a significant memory leak in the current core SDK code. Anyone who is using a compiled core library that uses the POSIX OS module may experience this (check your stdkconfig file entries for STDK_IOT_CORE_OS_SUPPORT_POSIX).

It’s fairly significant - consuming over 3 megs of memory in a 24 hour period - with the device app (in this case the example switch app) sitting idle for most of the time. I’ve verified this using Valgrind and have found the biggest problem to be a communications-related timer that is repeatedly created and malloc’s memory that is never freed. Of course if your platform has garbage collection, or you are using a different OS module, you may not be seeing this. I don’t know if there are similar issues with other configurations, but I’d highly recommend checking yours.

Reported this to Samsung 10 days ago on github, so Kwang-Hui is aware of it. No fix available yet.