Unquoted NaN is not a valid JSON value

[glrs]

I have noticed that once I unplug a DHT sensor from arduino, and then try to read from it, it returns nan temp = nan & hum = nan. With the next piece of code, I create a JSON object and send it to RPi. When the sensor is disconnected, the returned nan values are transformed into NaN (unquoted) by the ArduinoJson. According to json.org the only acceptable unquoted value for a missing/undefined value is null. Passing unquoted NaN, causes problems to parse that JSON object - at least - in Javascript.

Here is part of my code:

#include <ArduinoJson.h>

#include <DHT.h>
#include <DHT_U.h>

float hum;
float temp;
...
void loop() {
  hum = dht.readHumidity();
  temp= dht.readTemperature();

  StaticJsonDocument<200> root;

  root["AirTemp"] = temp;
  root["Humidity"] = hum;

  serializeJson(root, Serial);
  delay(30000);
}

I suggest to either pass "NaN" as string (I mean quoted, not String datatype necessarily), or just pass null.

[bblanchon]

Hi @glrs,

ArduinoJson's support for NaN and Infinity in both the serializer and the deserializer is a great feature, and I don't want to remove it.

The fact that you don't know if it should be either a string, a null, or no value at all, proves that it's not a decision that can be made by the library. On the contrary, it's a per-application policy and, therefore, it must be implemented by the user.

In your case, I would say "no sensor = no value":

if (isfinite(temp)) {
  root["AirTemp"] = temp;
}

Best regards, Benoit

[glrs]

Hi Benoit,

I don't understand how it is a "great feature", since it doesn't follow the JSON protocol. Sure, it can be a great feature, but the it's not strictly JSON. Someone that wants to work with the library will try to conform with the known protocol, and not specifically with the library. This can cause confusion and frustration to a developer that falls into that pitfall.

It should, at least, be well stated (and be obvious in the documentation) when a feature deviates from the underlying protocol. A good example is the various SQL implementations (mySQL, postgresql, etc.), which specifically state any divergence from the SQL protocol (even though the SQL protocol in many parts is open to interpretation, while JSON is very specific).

Best, G

[bblanchon]

Hi G,

It's a great feature because that's what most people expect, simply because very few people are interested in following the JSON format strictly, they just want to write code that works.

I've been writing this library for years, and I saw many invalid JSON documents produced by other libraries, or by humans. Should I reject a JSON document because it contains a NaN? or a comment? or a single quote? or a floating point starting with a dot?

Most people don't care about JSON compliance; they just want something that works. If I switch gears now, they'd be hundreds of complaints... and they'd be right! The original JSON specification is too strict, that's why we see initiatives like JSON5, but currently, ArduinoJson is not fully compliant with JSON5 either.

Also, let's be specific about this problem and not talk about generalities. What is the official JSON answer for NaN and Infinity? Nothing. I'm sorry, but this is not an acceptable answer. Again, the simple fact that you don't know what the right behavior should be is a sign that it's not for the library to decide. Lastly, remember that you can fix your program with a simple if statement.

I'm sorry you mistook ArduinoJson for a strict parser / strict generator, but I don't think anything is misleading in the documentation. If so, please quote the specific part that I should change, and I'd be glad to do so.

Best regards, Benoit Blanchon

[glrs]

Hi Benoit,

Great that you clear it out. I wouldn't say there is something misleading in your documentation. In the contrary, ArduinoJson is one of the most well documented libraries out there. Well done and thank you for that! However, I'd like to know if there is no compliance to the JSON protocol, and what are the specific differences. Or if it is closer to JSON5, it would be enough to mention it (since in json5.org they specifically note "Numbers may be IEEE 754 positive infinity, negative infinity, and NaN", etc.).

Keep up the good job and thanks for your time! Best, G

[macedolfm]

Well, this "NaN" is a current issue to me and to others in the NodeRED community as there plataform is a very common place backend for Arduino´s (discussion here )

Can´t we find a middle ground here and create a library global configuration parameter to deal with NaN and Infinity ?

I myself would love to receive a "null" (a valid value according to json.org), others may like to stay with the NaN & Inifinity and others may want the assignment of a NaN to fail or be ignored at all...just saying.

By the way @bblanchon you are the ONE !! Congrats for such a great library !!!

[bblanchon]

I don't get it. If you don't want a NaN in the output, why do you put it in the JsonDocument?

[macedolfm]

In my case NaN is very exceptional condition that may happen if a sensor malfunction, devices times out & etc. Having to deal in code with every one of this possible exceptions in order to avoid a NaN (instead of a valid null) to be sent to my Node server is much more prone to error than just setting something like: DynamicJsonBuffer.mode("express NaN&Infinite as NULL") or anything like that. Much clear and safe that checking every value being set in thousands of places if its NaN or not like you suggested (if (isfinite(temp))..). The thing is that most Jason parser outside Arduino world do not like the NaN, in fact, I did not find anyone that validate a simple {"age":NaN} successfully. Just saying, not complaining at all.

[bblanchon]

Guys, you were right to insist. I didn't realize that most other JSON serialize produce null and most other parsers refuse NaN.

I'll add a compilation option for that.

[bblanchon]

I added ARDUINOJSON_ENABLE_NAN to configure the support for NaN in JSON. The default is currently 1 but I'll probably change it to 0 before v6.11.0.

PS: thanks again for insisting on this change