I am not sure if mqtt are part of the core development - but I guess, as I don't have to install them extra, that they are part of the core nodes.
When I use the mqtt-in Nodes (and I know that in mqtt this is standard) all messages, which come in are strings or a buffer and therefore this is the default mode.
However with this option to create as output an analyzed JSON object this is fantastic to get real data types (JSON objects and works also for scalar type as booleans and numbers). However with this setting I get a problem in case of strings - that these strings produces an Error that this no JSON string which can be interpreted. For sure this is correct.
I can use a catch node and so I can retrieve the strings still as normal strings.
So at this moment I have to options:
If I configure the output if the mqtt-in node in default auto - I get everything as strings - which needs a lot of translations to get real numbers and booleans.
If I use information to get the output as analyzed JSON object - I get real numbers, booleans and JS Objects out of JSON strings - but errors when I recieve normal strings.
So my request is - why it is not possible to combine both options and to get real data- types strings, numbers, booleans and JS Objects or Arrays out of JSON Strings for all mqtt-in messages?
In case no JSON string is detected - the node should simply send a string or buffer - instead of raising an error.
If you had multiple data types coming in when subscribed to a single topic, wouldn't you need to test them when the msg exits the mqtt-out node to see what it contains?
Or are you suggesting that the node have a seperate output for each data type? Would the node have selectable options and if ou check two only two outputs would appear on the output side of the node or will we end up with the 'mqtt-out node having 5 outputs?
Are you going to take a look at the node and try to create a PR with the changes?
As I described - when I use the option that output is an analyzed JSON object - I get correct numbers, booleans and JS objects as output.
If I use this option in the mqtt-in Node and the topic contains a simple string then I get an error - that this is not a JSON string.
So the only change would be that with this option instead of rising an error that the string is not a JSON string - the output should be the string - as it works for simple numbers and booleans as well.
The advantage would be that I have not to convert manually - and get pre analysed data types as output.
So you can try this with numbers, booleans in a topic and it works perfectly to keep datatypes - only simple strings will rise an error.
Hi. I understand your request and at first glance it seems reasonable to ask for the payload to be auto converted however I'm still pondering the effort Vs benefit right now.
subscribing to a # topic that returns many payloads with different types of payload means at some point further down your flow you are going to have to recognise this type and route your messages accordingly.
The better solution is to subscribe to the topics of interest as mqtt is far better (designed for) this.
If you must subscribe to a # topic with differing payload types, it could be the structure of the publisher is not ideal.
If it is because you don't know upfront what topics will arrive, then I understand why you are requesting this but will also go on to say, it's not terribly difficult to handle (a sub flow that auto converts the payload would be ideal for this)
Lastly, if you are in control of the publishing, an additional solution might be to make use of MQTT v5 content type, you could then simply use switch to route the msg through a JSON node (or not)
The # is not always the root level - it could be device topic which contains different datatypes. Yes and I want to prefer to react on data types within the flow instead of having different triggers which start different flow parts . If you say the structure of the publisher is not ideal - this could be - but you cannot influence this.
I would also prefer to be flexible and to decide by myself when I split my flows. I can use switch nodes to differentiate between data types - but I don't want to start a discussion what is a better flow.
For sure I can work as it is - but I made a proposal for an improvement to get native data types pre analysed by the mqtt in node - which already works - with the exception of strings.
And in my opinion it should be no big issue to implement this. I can simulate the desired behavior with this configuration of the mqtt-in node in addition with a catch node - which I can use to get the string.
For sure - converting data is always possible - but I can not see the issues - why it is so difficult to improve the mqtt-in node to retrieve all native datatypes - as it works already - except for strings.
Not to be overly pedantic, but it does work for strings if you provide properly formatted JSON strings surrounded by quotes - "like this"
We aren't going to change the behaviour of the node - being able to detect invalid payloads as they don't parse as JSON is a perfectly valid and useful thing to do.
But we could consider adding an extra checkbox that is shown when the 'parsed JSON Object' mode is selected as to how invalid JSON should be handled. The default would be the existing behaviour - trigger Catch nodes. But if the option is enabled, then pass on the payload as a String.
If, for any reason, the received payload fails to convert to a String (MQTT is a binary protocol after all), then we would still log an error as we do today.
Personally I think that this is what auto mode should do... It should try to parse to the highest level first (json) - then fail to string mode - then binary... I know it's a change in behaviour which is why it wasn't made part of auto when we added the json option - but could be changed as part of v3.0. (Likewise the http request node does already do this and so either way we should be consistent across more nodes)
The next opportunity will be the 2.2.0 release at the end of this month. But it requires someone to do the actual work. I may have time, but I can't guarantee it as I have a busy couple of weeks for my day job ahead.
Thank you - no problem if it takes time. I only wanted to know in which release this could be the case, because I didn't found it in the change log of the Node-RED 2.2.0 beta.
As I read your release notes for 2.2.0 I still cannot see a change in the mqtt nodes. There is something mentioned for json nodes - but this is a different story. So I would repeat my question - when the auto mode in the mqtt-in node would be a complete auto mode (incl. strings)?
