arduino_bootstrapper
                                
                                
                                
                                    arduino_bootstrapper copied to clipboard
                            
                            
                            
                        Wrong json document returned by BootstrapManager::parseQueueMsg when the payload is a numerical value
Hello,
for simple MQTT messages with a numerical value such as: Topic: SET/TEMP Payload: 21.5, the parseQueueMsg function returns a json document which contains only the string 21.5 and not as expected {"value":21.5}.
I have tested different MQTT messages:
Topic: CMD Payload: ON returns {"value":"ON"} - correct
Topic: SET Payload: {"TEMP":21.5} returns {"TEMP":21.5} - correct
Topic: SET Payload: 21.5 returns 21.5 - failed
Topic: SET Payload: t1t1 returns true - failed, and I noticed that deserializeJson function was returning no error
This strange behavior is coming from the deserializeJson function which returns no error when the payload is a numeric value or a string such as 'toto', 't1t1', 'true', 'false' ... but delivers a json object not formatted as expected.
So I have modified the code as below (see modifications in 3rd line):
 DeserializationError error = deserializeJson(jsonDoc, (const byte *)payload, length);
  // non json msg
  if (error || ((char)payload[0] != '{'))   // instead of if(error) - tests if the payload looks like a json structure
  {
    JsonObject root = jsonDoc.to<JsonObject>();
    root[VALUE] = message;
    if (DEBUG_QUEUE_MSG)
    {
      String msg = root[VALUE];
      Serial.println(msg);
    }
    return jsonDoc;
  }
  else
  { // return json doc
    if (DEBUG_QUEUE_MSG)
    {
      serializeJsonPretty(jsonDoc, Serial);
      Serial.println();
    }
    return jsonDoc;
  }
Then for the example of Topic: SET Payload: 21.5 returns 21.5, I get the result {"value":21.5} as expected.
Then I suggest to implement this modifications in a future version.
This apply also for the BootstrapManager::parseHttpMsg function.
pull request will be really appreciated, in case I'll not see a pull request I'll do it in the next release :) thank you very much for all the help and for the smart ideas you gived to this small bootsrapper. 👍
Ok, I will propose soon a pull request after some testing but I saw that a version 1.12.7 is in preparation that seems to address a similar issue. Should I wait that you release this version before ?
I have just released the 1.2.7, I fixed a similar issue, basically I addressed a problem where integer values was returned as null { "someval": 2 }
but I lack the part you pointed out... you can pull request from now on :)
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days