Handling zero values in note.add and Notehub events

Hi, I am observing a strange behaviour from notecard in handling zero values (float 0.0 or integer 0).

I am reading my sensor values by an MCU and send them through note.card (LoRa) to note.hub.

Here are the code for creating the template (in setup()):

// Create new template
  req = notecard.newRequest("note.template");
  if (req != NULL) {
    JAddStringToObject(req, "file", "tdlas.qo");
    JAddNumberToObject(req, "port", 99);
    J *body = JCreateObject();
    if (body != NULL) {
      JAddNumberToObject(body, "methane", 14.1); 
      JAddItemToObject(req, "body", body);
      notecard.sendRequest(req);
    }
  }

and adding sensor value “methane” to it (in loop()):

// Send sensor data to Notehub
    J *req = notecard.newRequest("note.add");
    if (req != NULL) {
      JAddStringToObject(req, "file", "tdlas.qo");
      JAddNumberToObject(req, "port", 99);
      J *body = JAddObjectToObject(req, "body");
      if (body != NULL) {
        JAddNumberToObject(body, "methane", methane);
        // JAddNumberToObject(body, "methane", 0);
      }
      notecard.sendRequest(req);
    }
  }

methane value I get from sensor is 0.00, and I get this in serial monitor output:
[INFO]{“req”:“note.add”,“file”:“tdlas.qo”,“port”:99,“body”:“methane”:0},“crc”:“0011:09F14C3A”}

but surprisingly I get empty {} in Notehub!

I tried manually setting sensor values to 0.00 and 0 and all behave the same. Could you please advise how to resolve this?

Hi @e669danesh,

This behavior occurs because templated Notefiles, by default, use the omitempty instruction when serializing JSON objects. To override this, you can include the full:true field when adding your note.

For more details, please check the links below:

Let me know if this answers your question or if you have any other questions.

Thanks,
Youssif

Thanks, Youssif. I added this line to my note.add body but still cannot see the methane value (0.00) in my Notehub:

JAddBoolToObject(req, "full", true);

do I need to change something in note.template too? I don’t see “full” as an argument for it.

here is what I get in serial monitor:
[INFO] {“req”:“note.add”,“file”:“tdlas.qo”,“port”:99,“full”:true,“body”:{“methane”:0},“crc”:“000E:711C2E8A”}

Thanks for sharing the code snippet and trace info! No you shouldn’t need to specify "full":true when creating the template, you only need this when using note.add.

I tested this on my setup and successfully sent a 0.00 value to Notehub. Let’s dive into what might be different between our configurations to pinpoint the issue.

To start, could you please share which Notecard firmware version you’re using? You can find this with the following request:

{"req":"card.version"}

If possible, posting the full response here would be really helpful.

Thanks
Youssif

> {"req":"card.version"}
{
 "device": "dev:0080e1150045259d",
 "name": "Blues Wireless Notecard",
 "board": "3",
 "version": "notecard-wl-7.5.2.17004",
 "sku": "NOTE-LWEU",
 "ordering_code": "LZ0WZ0N0ZZBH",
 "lora": true,
 "body": {
  "org": "Blues Wireless",
  "product": "Notecard",
  "target": "wl",
  "version": "notecard-wl-7.5.2",
  "ver_major": 7,
  "ver_minor": 5,
  "ver_patch": 2,
  "ver_build": 17004,
  "built": "Nov 26 2024 14:01:26"
 }
}

Thanks @e669danesh - I’ve looked into this further and realized that on the LoRa notecard, the omitempty functionality is always enforced. This means that setting full:true when adding notes doesn’t have any effect. I’ve double checked this behaviour here with a LoRa notecard, and can confirm that I see the same results as you.

Initially, I tested this with a NOTE-WBGLW, where full:true successfully overrides the omitempty functionality. However, for the LoRa notecard, I believe the enforcement of the omitempty is intentional. Since LoRa operates over lower bandwidth and slower connections, it’s optimized to only transmit meaningful data, avoiding unnecessary data transfers for fields with zero or empty values.

I’ve reached out to the team internally to discuss the possibility of adding support for full:true on the LoRa notecard to align its behaviour with other Notecard types. I’ll keep you updated once I hear back. In the meantime, as a workaround, you can use placeholder values (e.g. 1.1) to ensure the field is included in the payload, or use another value/approach that suits your application.

Let me know if this helps or if you have further questions.

Thanks
Youssif

1 Like

Thank you @Youssif . DO you have an estimation when this will be implemented by Blues? we are working on a prototype and would appreciate if you provide a timeline to resolve this issue.

1 Like