The 0 zero value problem when json field/path is missing in subscribed message

I have multiple assets with MQTT agent links. The payloads that are received sometimes do not contain the specific object keys that the JSON path has for the specific attribute. In this case, the attribute value is set to 0 where actually it needs to be left as is with whatever was the final value.

I tried to set the messageMatchFilters and messageMatchPredicate thinking this was their purpose but with no luck.

Any help will be appreciated !

Here is the config JSON:

“id”: “7LJMnBVeuqJSwfdjKXi1h2”,
“valueFilters”: [
“type”: “jsonPath”,
“path”: “$.decoded.payload.temperature”,
“returnFirst”: true,
“returnLast”: false
“messageMatchPredicate”: {
“predicateType”: “string”,
“match”: “CONTAINS”,
“caseSensitive”: false,
“value”: “temperature”,
“negate”: false
“messageMatchFilters”: [
“type”: “substring”,
“beginIndex”: 0
“subscriptionTopic”: “dvm_helium/24E124725C461822/rx”,
“type”: “MQTTAgentLink”

If the message payload does not contain decoded.payload.temperature, which sometimes happens, the temperature will be set to 0. This looks like the following in the historic graphs:

Any help will be appreciated…

1 Like

Hey Odengiz,

I am sorry, unfortunately I don’t know how to solve it but I was hoping you could help me clear out something.
If I understand correctly, in the case that you are describing you are receiving data from a temperature sensor and then sending it to a subscribed MQTT agent.

Is the sent data going back to another python code or does it stay in OpenRemote?
If so, how do you manage to send in the data to the MQTT agent, I don’t manage to figure out how to send data to another agent… al I can do is enable a subscription but I do not understand how the agent is supposed to receive the data.

Dear Casentive, no actually I am only receiving data via MQTT using the agent. The attribute values are getting their values based on the json path that is applied to the MQTT message payload being received.


Hi odengiz,

sorry, that you have waited so long for a repsonse.

Hopefully @Don or @Rich can help you.


Apologies for the late reply.

Your understanding of the intent of message match predicate is correct but…

When I created the MQTTAgent I didn’t anticipate needing message match predicate; generally MQTT subscription should be specific enough to already ensure it receives a publish with a valid payload but I guess that isn’t the case here.

I can look to make a change to the MQTTAgent so that it respects the message match predicate if it is set so that way a publish will be evaluated by applying any message match filters and then applying the message match predicate.

P.S. your message match filter is un-necessary as it just returns the whole string, but guess you were just experimenting.

Let me know if this is of use to you so I can figure out a priority on an update.