Skip to main content
Graduate II
May 15, 2025
Solved

ST Sensor tile.box pro with FP-SNS-DATALOG2 , can't find the BLE UUID for Data Logging

  • May 15, 2025
  • 6 replies
  • 2238 views

I am using a ST Sensor tile.box pro with FP-SNS-DATALOG2 function pack, I have already used the Python GUI software with USB connection and ST BLE Sensor app for data logging to save into the microSD card, which works fine. 

Now , I would like to use python program to start the data logging process and possibly selecting the sensors for logging, for this, I am looking for the UUID related to these, and I can not find from the FP-SNS-DATALOG2 program. Where can I find related information for these? 

I have used a BLE Sniffer app to look for the available UUID but little to no description I found from the FP-SNS-DATALOG2 code how it actually works with the app so that I can replicate for my needs.

 

Primary service/Unknown service 01: 
COPY_CONSOLE_SERVICE_UUID	00 00 00 00 00 0E 11 e1 9a b4 00 02 a5 d5 c5 1b

Unknown Characteristics:
COPY_TERM_CHAR_UUID	00 00 00 01 00 0E 11 e1 ac 36 00 02 a5 d5 c5 1b
COPY_STDERR_CHAR_UUID	00 00 00 02 00 0E 11 e1 ac 36 00 02 a5 d5 c5 1b


Primary service/Unknown service 02: 
COPY_FEATURES_SERVICE_UUID	00 00 00 00 00 01 11 e1 9a b4 00 02 a5 d5 c5 1b

Unknown Characteristics:
COPY_MACHINE_LEARNING_CORE_CHAR_UUID	00 00 00 0F 00 02 11 e1 ac 36 00 02 a5 d5 c5 1b
COPY_HIGH_SPEED_DATA_LOG_CHAR_UUID	00 00 00 11 00 02 11 e1 ac 36 00 02 a5 d5 c5 1b
COPY_EXT_CONFIG_CHAR_UUID	 00 00 00 14 00 02 11 e1 ac 36 00 02 a5 d5 c5 1b
COPY_PNPLIKE_CHAR_UUID	 00 00 00 1b 00 02 11 e1 ac 36 00 02 a5 d5 c5 1b
COPY_RAW_PNPL_CONTROLLED_CHAR_UUID	00 00 00 23 00 02 11 e1 ac 36 00 02 a5 d5 c5 1b

 @SimonePradolini @Federica Bossi 

    This topic has been closed for replies.
    Best answer by SimonePradolini

    @makerbox wrote:

    @SimonePradolini Ok, now i have got an idea about how to create PnPL messages. Sorry again if i am going round in round. This is my test script in python using USB 

     message = "{\"stts22h_temp\":{\"enable\":true, \"odr\":1}}"
     print(PnPLCMDManager.create_set_property_cmd("stts22h_temp", "enable", True ))
     print(hsd_link.send_command(hsd_link_instance, device_id, message))
    
     print(PnPLCMDManager.create_command_cmd("log_controller", "start_log", "interface", 0))
     message = PnPLCMDManager.create_command_cmd("log_controller", "start_log", "interface", 0)
     print(hsd_link.send_command(hsd_link_instance, device_id, message))
    
     time.sleep(4)
    
     print(PnPLCMDManager.create_command_cmd("log_controller", "stop_log", "interface", 0))
     message = PnPLCMDManager.create_command_cmd("log_controller", "stop_log", "interface", 0)
     print(hsd_link.send_command(hsd_link_instance, device_id, message))

    this is the output

    2025-07-01 13:10:03,796 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - Platform Architecture: 64bit
    2025-07-01 13:10:04,258 - HSDatalogApp.stdatalog_core.HSD_link.HSDLink - INFO - Commmunication Opened correctly
    HSDLink Version: High Speed Datalog DLL v2
    
    {"stts22h_temp": {"enable": true}}
    2025-07-01 13:10:04,853 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - PnPL Response: {"PnPL_Response":{"message":"","value":true,"status":true}}
    {"PnPL_Response":{"message":"","value":true,"status":true}}
    {"log_controller*start_log": {"interface": 0}}
    Command sent successfully!
    {"log_controller*stop_log": {"interface": 0}}
    2025-07-01 13:10:09,236 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - PnPL Response: {"PnPL_Response":{"message":"Error: Acquisition stop failure. Already stopped.","status":false}}
    {"PnPL_Response":{"message":"Error: Acquisition stop failure. Already stopped.","status":false}}
    
    ---> End of HSDLink APIs test script.

     

    Wasn't it supposed to start the logging through USB? but the stop log command says it is already stopped, do i need any more commands?

    USB channel is 1. Try with 

    message = PnPLCMDManager.create_command_cmd("log_controller", "start_log", "interface", 1)

    But it is still not clear to me how your setup should work. Are you managing the DATALOG2 firmware via USB (so streaming data via USB) or via BLE (so saving data onto SD)? The firmware can't let you save data onto SD card if the controller is a USB interface or stream data via USB if the controller is a BLE device. Only USB to USB or SD/BLE to SD are managed by the firmware.

     


    @makerbox wrote:

    Question 2 : I am assuming this the same setup for BLE implementation? For BLE i need to write to UUID using following the Packet Headers 

     BLE_COMM_TP_START_PACKET = 0x00,
     BLE_COMM_TP_START_END_PACKET = 0x20,
     BLE_COMM_TP_MIDDLE_PACKET = 0x40,
     BLE_COMM_TP_END_PACKET = 0x80,
     BLE_COMM_TP_START_LONG_PACKET = 0x10
    1. What is the actual UUID to write? is it ( COPY_EXT_CONFIG_CHAR_UUID )?

    No, BLE characteristics is the PNPL you already tested before: COPY_PNPLIKE_CHAR_UUID = "0000001b-0002-11e1-ac36-0002a5d5c51b" 

     


    @makerbox wrote:
    1.  
    2. Does the messages looks like this? ( this is random hex )
     #temp setup packets
     packet1 = "007b22737474733232685f74656d70223a7b2265"
     packet2 = "406e61626c65223a747275657d207b226f647222"
     packet3 = "803a20317d7d"
     #log start packets
     packet4 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet5 = "407b2273746172745f6c6f67223a20747275657d"
     packet6 = "807d"
     #log end packets
     packet7 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet8 = "407b2273746172745f6c6f67223a2066616c7365"
     packet9 = "807d7d"

     


    Packet message seems ok.


    @makerbox wrote:

    3. Is there any time (seconds) between sending this to specific messages? or what sequence? setup > start log > wait > stop log ? or any other? 


    There is no specific timeout, but the communication protocol is based on responses. In other words: for each command/ set-get property, the firmware always answers with a response. So that, the host can always be aware about the board status and if the request just sent has been executed or acknowledged.

    So, I strongly suggest you to implement a mechanism with ack (i.e.: send a command and wait for a response before moving to the next one).

     

    Best regards,

    Simone

    6 replies

    ST Employee
    May 16, 2025

    Hi @makerbox,

    You can find a lot of information for datalog2 package in this attached document.
    Also consider the various links present for descriptions of downloadable SW packages for the BLE.

     

    Hope this could help.

    makerboxAuthor
    Graduate II
    May 16, 2025

    I have checked this file over and over and it is clear to me, and I went through the example code itself for Sensor tile box pro. I can’t find how the android software is communicating with the Datalog2 software. I get the gest that, it is communicating with datalog2 with pnpl and some internal mechanism. But i want to communicate with the datalog2 with python script and BLE.. I cant find the UUID related to each commands, for example which UUID is responsible for Start Logging? or which command is it x01 or start or START? I have used nRF BLE app to find UUIDs exposed, i have listed them above, those matches with what i can find in the code examples. But, which one really communicating that was my question! 

     

     

    Technical Moderator
    May 19, 2025

    Hello @makerbox 

    I'm sorry for the very long response, but I need to describe you all the communication process to give you the best answer as possible.


    DATALOG2 communication channel is based on two concepts: PnPL communication protocol and Device Template models. We’re describing a bit those concepts also in the User Manual chapter 2.5 and 2.6.

    A Device Template is a JSON file expressed with the Digital Twins Definition Language (DTDL) V.2 language, as defined by Microsoft Azure. It defines the characteristics and behaviors of a type of device that connects to an application. Telemetries, property changes, and commands get encapsulated into the so called PnPL messages and exchanged between the SDK, the cloud, and devices that have direct internet access. DATALOG2 device models are distributed both in STDATALOG-PYSDK (to be used locally) and in an online catalog (used by BLESensor app).

    PnP-Like messages are derived by a Device Template and are independent of the communication interface used (BLE, USB, serial, …). PnP-Like is a language shared and known by each element in the whole platform virtualization architecture. Knowing the Device Template each host can parse or create PnP-Like messages. They are used to:

    • configure device parameters (pnpl SET (writable) Property messages, for example: Set a specific sensor's ODR)
    • get current parameters values (PnPL GET Component/Device status messages: for example: Properties of a sensor (ODR, FS, enabling status, …))
    • control the device behavior using commands (PnPL COMMAND messages: for example: Start/stop logging).

     

    So, going back to your original question: there’s no specific UUID for each command, but each command is a JSON and all of them are streamed on the same BLE characteristic (you called COPY_PNPLIKE_CHAR_UUID). The BLE app knowing the related Device Template can generate/parse the JSON command properly. PYSDK is doing the same through the dedicated pnpl package. From the firmware side, commands and properties are exposed as a sort of API in the files contained into the PnPL folder of the project.

    If you'd like to build up your Python/BLE application, we’re also providing some Python example scripts you can have a look into. Refer to these scripts and these Python notebooks. I strongly suggest starting from them.

     

    I wish this (very long) post can clarify a bit and answer you question.

    Best regards,

    Simone

    Technical Moderator
    May 20, 2025

    Hello @makerbox 

    I'm sorry, but it is not clear to me the purpose of your application. I'd like to help you, but I need to better understand your final goal. Would you like to create a "BLESensor app" in Python, so to enable a new BLE channel between a PC and a board? If so, you can have a look into the BLESensor Android application source code or BLESensor iOS application source code.

    The commands you are creating seems well formatted, but remember that the DATALOG2 firmware manages BLE channel only for configuration. Sensor data will be saved onto SD card only, no sensor data are streamed via the BLE characteristic. Considering your application working properly, is already there an SD card into the board?

     

    Best regards

    Simone

    makerboxAuthor
    Graduate II
    May 20, 2025

    Yes, you have guessed it exactly what i want to do. 

    Basically we have few Sensor tile box pro, and we want to use the Datalog 2 software. We want to select each Sensor tile box and start data logging into the SD card. Not much of functionality is needed so far, just to control 5/6 available sensors on board and save logged data onto the sd card. If BLE allows, stream the data through BLE later on but not the current priority. Currently, we are using BLE sensor app to control the Datalog 2 firmware, but it needs to be done by a Raspberry Pi hence the Python BLE combination.

     

    I have actually went through the Android and IOS app before, but as i am not really proficient on swift or android coding, i have to go through again, with keeping all the new information on mind. 

     

    Hence, posting in here to know, if simply writing the text format to the UUID Would initiate the logging, so far i couldn't achieve, it works with BLE sensor app, simply writing it doesn't do anything.

    Technical Moderator
    May 20, 2025

    Hello,

    Once BLE connection is established between two nodes, they negotiate each other the packet length (MTU - do you know the acronym?). Maybe in your setup the length is less then the length of the message, so the message isn’t received correctly (and so isn’t valid).

    By default it’s 20 (\0 character included). When the string is longer, we built a transfer protocol to manage this situation, both in firmware and in the BLE app.

    From the firmware side, the code portion related to this protocol is in the BLE_Manager.c file. 

    BLE_Command_TP_Parse and BLE_Command_TP_Encapsulate are the C methods that we developed to parse and to prepare the BLE packet.

    I wish this can help you.

     

    PS: have you ever launched the stdatalog_examples\function_tests\stdatalog_API_examples_HSDLink.py from the PYSDK? It will show you the main function that demonstrates the usage of the HSDLink API, including PnPL commands. It’s necessary to connect a compatible device to the PC to run the script. You can play with to check the validity of the JSON command you'd like to build.

     

     

    Best regards,

    Simone

    Technical Moderator
    June 19, 2025

    Hello @makerbox 

    Any news on the topic? Did you succeeded building up your application?

     

    Best regards,

    Simone

    makerboxAuthor
    Graduate II
    June 20, 2025

    I could use USB to write commands to the device that works fine but BLE I could not.

    I tried to write into this UUID

    COPY_PNPLIKE_CHAR_UUID = "0000001b-0002-11e1-ac36-0002a5d5c51b"

     These were my message 

    {\"stts22h_temp\":{\"enable\":true} {\"odr\": 1}}
    {\"log_controller\": {\"start_log\": true}}
    {\"log_controller\": {\"start_log\": false}}

    according to packet headers

     BLE_COMM_TP_START_PACKET = 0x00,
     BLE_COMM_TP_START_END_PACKET = 0x20,
     BLE_COMM_TP_MIDDLE_PACKET = 0x40,
     BLE_COMM_TP_END_PACKET = 0x80,
     BLE_COMM_TP_START_LONG_PACKET = 0x10

    I then convert those messages to packets ( MTU = 20, packet = MTU-1 , 19bytes )

     #temp setup packets
     packet1 = "007b22737474733232685f74656d70223a7b2265"
     packet2 = "406e61626c65223a747275657d207b226f647222"
     packet3 = "803a20317d7d"
     #log start packets
     packet4 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet5 = "407b2273746172745f6c6f67223a20747275657d"
     packet6 = "807d"
     #log end packets
     packet7 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet8 = "407b2273746172745f6c6f67223a2066616c7365"
     packet9 = "807d7d"

     Then I use this python code (note code is formed by Ai and online resources )

    import asyncio
    from bleak import BleakScanner, BleakClient
    
    DEVICE_NAME = "HSD2v30"
    WRITE_UUID = "0000001b-0002-11e1-ac36-0002a5d5c51b"
    
    async def find_device_by_name(name):
     print("Scanning for BLE devices...")
     devices = await BleakScanner.discover(timeout=5.0)
     for d in devices:
     if d.name == name:
     print(f"Found device: {d.name} ({d.address})")
     return d.address
     print(f"Device named '{name}' not found.")
     return None
    
    async def send_ble_packets():
     address = await find_device_by_name(DEVICE_NAME)
     if not address:
     return
    
     async with BleakClient(address) as client:
     if not client.is_connected:
     print("Failed to connect.")
     return
    
     print(f"Connected to {DEVICE_NAME} ({address})")
    
     # temp setup packets
     packet1 = bytes.fromhex("007b22737474733232685f74656d70223a7b2265")
     packet2 = bytes.fromhex("406e61626c65223a747275657d207b226f647222")
     packet3 = bytes.fromhex("803a20317d7d")
    
     # log start packets
     packet4 = bytes.fromhex("007b226c6f675f636f6e74726f6c6c6572223a20")
     packet5 = bytes.fromhex("407b2273746172745f6c6f67223a20747275657d")
     packet6 = bytes.fromhex("807d")
    
     # log stop packets
     packet7 = bytes.fromhex("007b226c6f675f636f6e74726f6c6c6572223a20")
     packet8 = bytes.fromhex("407b2273746172745f6c6f67223a2066616c7365")
     packet9 = bytes.fromhex("807d7d")
    
     # send in order
     for i, packet in enumerate([packet1, packet2, packet3]):
     await client.write_gatt_char(WRITE_UUID, packet)
     print(f"Sent setup packet {i+1}")
    
     await asyncio.sleep(0.1)
    
     for i, packet in enumerate([packet4, packet5, packet6]):
     await client.write_gatt_char(WRITE_UUID, packet)
     print(f"Sent start-log packet {i+1}")
    
     await asyncio.sleep(10)
    
     for i, packet in enumerate([packet7, packet8, packet9]):
     await client.write_gatt_char(WRITE_UUID, packet)
     print(f"Sent stop-log packet {i+1}")
    
    asyncio.run(send_ble_packets())

    so far this makes the Device unresponsive meaning BLE status Blink turned off. I was not sure about what the device is receiving and if I am writing at the correct UUID. 

     

    makerboxAuthor
    Graduate II
    June 25, 2025

    Hi, @SimonePradolini  so, apparently my above command messages were wrong to being with, to start the datalogging, I have checked the message in stdatalog_API_examples_HSDLink.py

    {\"log_controller\": {\"start_log\": true}}

     like this,

    message = "{\"log_controller\": {\"start_log\": true}}"
    print(hsd_link.send_command(hsd_link_instance, device_id, message))

    ( I want to start the logging onto the SD card, I believe, the interface has to be "0" , i do not know how to form that message )

    here I get this output,

    2025-06-25 16:36:04,353 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - PnPL Response: {"PnPL_Error":"No writable Properties in DeviceInformation"}
    {"PnPL_Error":"No writable Properties in DeviceInformation"}

     

    In the stdatalog_API_examples_HSDLink.py start_log and stop_log is used directly but not through messages/command message, if I want to use BLE write, I would need these as a messages.

    after looking at the python program (stdatalog_API_examples_HSDLink.py) it gets me nowhere to the bottom on  how to form the message, it just ends at hsd_dll.py  and finally wrapper file libhs_datalog_V2.dll which i cant check.

     ( Note that, I have added few prints to check what is the output, but the output does come from here but the python program takes me there )

     def hs_datalog_send_message(self, dId : int, msg : str, msg_len : int) -> [bool, int, str]:
     dIdC = ctypes.c_int(dId)
     print(f'from hsd_dll dIdC {dIdC}')
     msgC = ctypes.c_char_p(msg.encode('UTF-8'))
     print(f'from hsd_dll msgC {msgC}')
     msg_lenC = ctypes.c_int(msg_len)
     print(f'from hsd_dll msg_lenC {msg_lenC}')
     data_lenC = ctypes.c_int(0)
     print(f'from hsd_dll data_lenC {data_lenC}')
     dataC = ctypes.c_char_p()
     print(f'from hsd_dll dataC/ctypes.c_char_p() {dataC}')
     res = self.hsd_wrapper.hs_datalog_send_message(dIdC, msgC, msg_lenC, ctypes.byref(data_lenC), ctypes.byref(dataC))
     print(f'from hsd_dll ctypes.byref(data_lenC) {ctypes.byref(data_lenC)}')
     print("from hsd_dll {}".format(ctypes.byref(dataC)))
     if res != ST_HS_DATALOG_ERROR:
     if dataC.value is not None:
     # data = dataC.value[:msg_len].decode('UTF-8')
     data = dataC.value.decode('UTF-8')
     print("from hsd_dll {}".format(data))
     print("{} - HSDatauuulogApp.{} - INFO - PnPL Response: {}".format(logger.get_datetime(), __name__, data))
     else:
     data = "Command sent successfully!"
     print(f'from hsd_dll {data}')
     else:
     return (False, 0, "[ERROR] - Command not sent correctly!")
     self.__hs_datalog_free(dataC)
     return (res == ST_HS_DATALOG_OK, data_lenC, data)

     

    I would simply like to control few sensor tile box pro with datalog2 software using BLE and Python. Can you test at your end and describe it simply. I  appreciate your time.

    makerboxAuthor
    Graduate II
    July 1, 2025

    @SimonePradolini  is it possible to review this?

    Technical Moderator
    July 1, 2025

    Hello @makerbox 

    Sorry for the late reply, I lost the notification of your message.

    You did a great job, and you worked in the right way by using stdatalog_API_examples_HSDLink.py as example. You just missed the right syntax for the start command.

    By referring to the Python example script, the command you must create is:

    message = PnPLCMDManager.create_command_cmd("log_controller","start_log", "interface",2)
    # send ble message with your custom command 
    # USB message should be: hsd_link.send_command(hsd_link_instance, device_id, message)

    The “interface” field is defined in the DATALOG2 framework as: 0 for SD card, 1 for USB, 2 for Bluetooth® LE. It represents the host that controls the firmware and streams the commands. Then, it’s the firmware that manages the recording device with respect to the host interface. When the controller interface is SD card or Bluetooth® LE, data will be always recorded onto SD card. Hence, if the controller interface is the USB, data will be always recorded via USB.

    By using the above command, you should be able to start recording into your setup.

    Notice that hsd_dll is meant to be used by USB channel only. DLL isn’t supporting other channels than USB. If you'd like to control a board running DATALOG2 firmware via Bluetooth® LE, you must create all the commands and manage all the properties by building up json strings. You’re free to write down the json manually or by using the

    PnPLCMDManager.

     

    Best regards,

    Simone

    makerboxAuthor
    Graduate II
    July 1, 2025

    @SimonePradolini Ok, now i have got an idea about how to create PnPL messages. Sorry again if i am going round in round. This is my test script in python using USB 

     message = "{\"stts22h_temp\":{\"enable\":true, \"odr\":1}}"
     print(PnPLCMDManager.create_set_property_cmd("stts22h_temp", "enable", True ))
     print(hsd_link.send_command(hsd_link_instance, device_id, message))
    
     print(PnPLCMDManager.create_command_cmd("log_controller", "start_log", "interface", 0))
     message = PnPLCMDManager.create_command_cmd("log_controller", "start_log", "interface", 0)
     print(hsd_link.send_command(hsd_link_instance, device_id, message))
    
     time.sleep(4)
    
     print(PnPLCMDManager.create_command_cmd("log_controller", "stop_log", "interface", 0))
     message = PnPLCMDManager.create_command_cmd("log_controller", "stop_log", "interface", 0)
     print(hsd_link.send_command(hsd_link_instance, device_id, message))

    this is the output

    2025-07-01 13:10:03,796 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - Platform Architecture: 64bit
    2025-07-01 13:10:04,258 - HSDatalogApp.stdatalog_core.HSD_link.HSDLink - INFO - Commmunication Opened correctly
    HSDLink Version: High Speed Datalog DLL v2
    
    {"stts22h_temp": {"enable": true}}
    2025-07-01 13:10:04,853 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - PnPL Response: {"PnPL_Response":{"message":"","value":true,"status":true}}
    {"PnPL_Response":{"message":"","value":true,"status":true}}
    {"log_controller*start_log": {"interface": 0}}
    Command sent successfully!
    {"log_controller*stop_log": {"interface": 0}}
    2025-07-01 13:10:09,236 - HSDatalogApp.stdatalog_core.HSD_link.communication.PnPL_HSD.hsd_dll - INFO - PnPL Response: {"PnPL_Response":{"message":"Error: Acquisition stop failure. Already stopped.","status":false}}
    {"PnPL_Response":{"message":"Error: Acquisition stop failure. Already stopped.","status":false}}
    
    ---> End of HSDLink APIs test script.

     

    Wasn't it supposed to start the logging through USB? but the stop log command says it is already stopped, do i need any more commands?

     

    Question 2 : I am assuming this the same setup for BLE implementation? For BLE i need to write to UUID using following the Packet Headers 

     BLE_COMM_TP_START_PACKET = 0x00,
     BLE_COMM_TP_START_END_PACKET = 0x20,
     BLE_COMM_TP_MIDDLE_PACKET = 0x40,
     BLE_COMM_TP_END_PACKET = 0x80,
     BLE_COMM_TP_START_LONG_PACKET = 0x10
    1. What is the actual UUID to write? is it ( COPY_EXT_CONFIG_CHAR_UUID )?
    2. Does the messages looks like this? ( this is random hex )
     #temp setup packets
     packet1 = "007b22737474733232685f74656d70223a7b2265"
     packet2 = "406e61626c65223a747275657d207b226f647222"
     packet3 = "803a20317d7d"
     #log start packets
     packet4 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet5 = "407b2273746172745f6c6f67223a20747275657d"
     packet6 = "807d"
     #log end packets
     packet7 = "007b226c6f675f636f6e74726f6c6c6572223a20"
     packet8 = "407b2273746172745f6c6f67223a2066616c7365"
     packet9 = "807d7d"

     

    3. Is there any time (seconds) between sending this to specific messages? or what sequence? setup > start log > wait > stop log ? or any other? 

    makerboxAuthor
    Graduate II
    August 18, 2025

    @SimonePradolini  Hi Simone,

    I keep getting 

    {"PnPL_Error":" Component doesn't exist"}

    as a response whereas when i send over pnpl command over BLE with a python application, in github i have searched for possible code section which could reply this, i couldn't find any. Could you please assist here? 

    I have attached the python code in above comment.

    Thanks.

    Technical Moderator
    August 19, 2025

    Hello @makerbox 

    I'm really sorry for the late reply, also on my side I partially misunderstood the BLE protocol. I asked internally for further support and finally I got the issue.

     

    BLE_COMM_TP_START_PACKET and BLE_COMM_TP_START_END_PACKET BLE messages require also 2 bytes describing the total message length. This was introduced in the BLE transfer protocol to manage memory allocation properly: once received a start package, firmware can be aware about the total message length, allocate the memory, and then start saving message bytes.

     

    So, a BLE_COMM_TP_START_PACKET must be composed in the following way:

    00 (BLE TP header) | 2-byte total message length payload | payload.

    Similarly, for BLE_COMM_TP_START_END_PACKET the packet will be:

    20 (BLE TP header) | 2-byte total message length payload | payload.

     

    For example: 

    {"stts22h_temp":{"enable":true, "odr":1}}

    Is a message whose total length is 41 bytes (41 characters, so 41 bytes, 0029 as HEX). So, assuming an MTU length of 20 bytes, the command should be packaged as the following 3 messages:

    0000297b22737474733232685f74656d70223a7b
    4022656e61626c65223a747275652c20226f6472
    80223a317d7d

    The first package is formed by 1 byte for the header (00), 2 bytes for the total message length (0029) and the remaining MTU - 3 bytes for the payload. All the others contain 1 byte for the header (40 or 80) and MTU - 1 for the payload.

     

    Let me know if this can solve your issue and let you have a fully working setup.

    Best regards,

    Simone

    makerboxAuthor
    Graduate II
    August 19, 2025

    Perfect. @SimonePradolini   Many people would be benefitted by your help.

    Scanning for device...
    Connected to HSD2v30 (D1:85:1F:DF:37:D2)
    
    {"stts22h_temp":{"enable":true, "odr":1}}
    Sent packet 1/3: 0000297b22737474733232685f74656d70223a7b
    Sent packet 2/3: 4022656e61626c65223a747275652c20226f6472
    Sent packet 3/3: 80223a317d7d
    [Notification] Raw: 207b22506e504c5f526573706f6e7365223a7b226d657373616765223a22222c2276616c7565223a747275652c22737461747573223a747275657d7d00 | Decoded: {"PnPL_Response":{"message":"","value":true,"status":true}} 
    
    
    {"log_controller*start_log": {"interface": 0}}
    Sent packet 1/3: 00002e7b226c6f675f636f6e74726f6c6c65722a
    Sent packet 2/3: 4073746172745f6c6f67223a207b22696e746572
    Sent packet 3/3: 8066616365223a20307d7d
    [Notification] Raw: 207b22506e504c5f526573706f6e7365223a7b226d657373616765223a22222c22737461747573223a747275657d7d00 | Decoded: {"PnPL_Response":{"message":"","status":true}} 
    
    
    {"log_controller*stop_log": {"interface": 0}}
    Sent packet 1/3: 00002d7b226c6f675f636f6e74726f6c6c65722a
    Sent packet 2/3: 4073746f705f6c6f67223a207b22696e74657266
    Sent packet 3/3: 80616365223a20307d7d
    [Notification] Raw: 207b22506e504c5f526573706f6e7365223a7b226d657373616765223a22222c22737461747573223a747275657d7d00 | Decoded: {"PnPL_Response":{"message":"","status":true}} 
    Listening for responses...
    Done.