Received somethig else then published

TOWER
1

Hi,
I am trying to find the problem, when I publish message with some value, but in the application it is received as other value.

I publish message: node/climate:0/core/-/sleep-period/set:3600000
…but when I send confirmation message with received value I will get: node/climate:0/core/-/sleep-period/confirm:"1065353216"

The code for receiving and publishing message back is quite simple:

Can be problem with “BC_RADIO_SUB_PT_INT” → that I am receiving large number as INT? But which type to choose if this is not suitable:

BC_RADIO_SUB_PT_BOOL,
BC_RADIO_SUB_PT_INT,
BC_RADIO_SUB_PT_FLOAT,
BC_RADIO_SUB_PT_STRING,
BC_RADIO_SUB_PT_NULL

Only string looks usable if INT is not possible to use. Or of there is no problem and INT is goodchoice, do you see somethig else wrong in the code, please? Other (smaller) values are received without problem.

Thanks a lot for any idea!

2

I have one more idea… there is existing something like MQTT retained mesagges and QoS :astonished:… Probably MQQT broker is trying to publish some messages everytime. And when there is exist this bad value (topic with this message) it can be received everytime when the module listens!

3

I try get this error but no succes.

void set_value_to_eeprom(uint64_t *id, const char *topic, void *value, void *param)
{
    bc_log_info("%s %i", topic, *(int *) value);
    uint32_t val_uin32 = *(uint32_t *)value;

    char buffer[32];
    memset(buffer, 0, sizeof(buffer));
    sprintf(buffer, "%li", val_uin32);
    bc_radio_pub_string("core/-/sleep-period/confirm", buffer);

    bc_log_debug(buffer);
}

bc_radio_sub_t subs[] = {
    {"core/-/sleep-period/set", BC_RADIO_SUB_PT_INT, set_value_to_eeprom, NULL}
};

void application_init(void)
{
    // Initialize logging
    bc_log_init(BC_LOG_LEVEL_DUMP, BC_LOG_TIMESTAMP_ABS);

    // Initialize LED
    bc_led_init(&led, BC_GPIO_LED, false, false);
    bc_led_set_mode(&led, BC_LED_MODE_ON);

    // Initialize button
    bc_button_init(&button, BC_GPIO_BUTTON, BC_GPIO_PULL_DOWN, false);
    bc_button_set_event_handler(&button, button_event_handler, NULL);

    bc_radio_init(BC_RADIO_MODE_NODE_LISTENING);
    bc_radio_set_subs(subs, sizeof(subs)/sizeof(subs[0]));
    bc_radio_pairing_request("climate", VERSION);
}

image
image.png1314×863 273 KB

1 Like
4

Radio stack is different than standard mqtt protocol, for now we doesn’t support QoS setting. Sending retain topic if node in listenning is not good idea, you create radio spam. But work with retain topic is good idea, maybe it could be sent after a node reset. But that means support in bcg, because the dongle does not have enough ram.

5

Hi,
we discovered another issue in your code.

You are defining 4kB array in a function. This means that the array is defined in the stack. In embedded world, the stack is usually 512 - 2kB. So you are overflowing the RAM which can cause your issues.

Solutions:

  • use really only the RAM you need, the maximum number you could send and which will be in the buffer probably would not be longer than 32 bytes (please, check Karel’s example).
  • If you really need this big buffer, then add static prefix so: static char buffer[4096]. Then this array will be statically created and placed on fixed address in the RAM, not on the stack. The advantage also is that you will se this memory in the compilation final report (.data + .bss)(the MCU has 20kB total RAM, but it would be like 15kB max to your application)
  • Move the declaration outside of the function, this will make it “static” automatically
  • Also I would suggest using snprintf implementation, please note the n in the function name which will check if your string is not overflowing your buffer.

Martin

1 Like
6

Hi, thanks a lot! I didn’t know that. I really don’t need to use so much memory. I changed the value to 128. I will use snprintf from now.

Thank you! :+1: