Executing the JSONPATH-transformation failed: Invalid path

Setup, Configuration and Use Installation
1

This is my MQTT thing configuration (as described here Using a Meross Wi-Fi switch with OpenHab2):

UID: mqtt:topic:02724a8db9:7dfc0915b5
label: Generic MQTT Thing
thingTypeUID: mqtt:topic
configuration: {}
bridgeUID: mqtt:broker:02724a8db9
location: Office
channels:
  - id: cidMerossBeng
    channelTypeUID: mqtt:switch
    label: BENGASI
    description: ""
    configuration:
      commandTopic: /appliance/2009072623298651802748e1e92fbcb9/subscribe
      transformationPatternOut: JS:meross.js
      stateTopic: /appliance/2009072623298651802748e1e92fbcb9/publish
      transformationPattern: JSONPATH:$.payload.togglex..onoff
      off: "0"
      on: "1"

And this is the log, when trying to change the state:

15:20:48.477 [WARN ] [tt.generic.ChannelStateTransformation] - Transformation service JS for pattern meross.js not found!
15:20:48.492 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Generic_MQTT_Thing_BENGASI' changed from OFF to ON
15:20:56.440 [WARN ] [tt.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path '$.payload.togglex..onoff' in '{"header":{"messageId":"da2b92531a6dc7583beff35058327d78","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/2009072623298651802748e1e92fbcb9/publish","timestamp":3,"timestampMs":569,"sign":"e5787c6f4c9eaf7732242a1c9aa3a1b3"},"payload":{"clock":{"timestamp":3}}}'

JSON Transformation Service Addon is installed…meross.js is copied to openhab/transform
-rw-rw-r-- 1 openhab openhab 9.1K Jan 12 16:19 meross.js

2

You are simply getting a much different json response from your device than the tutorial you followed, so the JSONPATH you have input has nothing to do with the JSON your asking it to parse. Here’s your JSON:

{
  "header": {
    "messageId": "da2b92531a6dc7583beff35058327d78",
    "namespace": "Appliance.System.Clock",
    "method": "PUSH",
    "payloadVersion": 1,
    "from": "/appliance/2009072623298651802748e1e92fbcb9/publish",
    "timestamp": 3,
    "timestampMs": 569,
    "sign": "e5787c6f4c9eaf7732242a1c9aa3a1b3"
  },
  "payload": {
    "clock": {
      "timestamp": 3
    }
  }
}

You JSONPATH expects payload to be the first order key, but that is header and there is neither a togglex nor an onoff key. There’s a complete mismatch.

I don’t know these meross devices at all, but either they’ve changed their output, or you’ve got a different version from the tutorial or something. But it looks like you need to do a little digging to learn about your device some more.

3

To be honest, I don’t have an idea how and using which tools, I should start digging? Postman, Wireshark, ??

4

No need for anything that dramatic. You just need to know what the actual payload from your device looks like when it comes into your MQTT binding. Just do not put any transform on the incoming signal from the channel and connect it up to a string item unaltered. That string item will capture the entire JSON and you will the use that to determine what your actual JSONPATH will look like.

5

I found this meross/protocol.md at main · arandall/meross · GitHub - so I will start there to expand my knowledge.
On the other hand, I removed transformation with that result:

07:32:48.703 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Generic_MQTT_Thing_BENGASI' received command OFF
07:32:48.715 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'Generic_MQTT_Thing_BENGASI' predicted to become OFF
07:32:48.730 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Generic_MQTT_Thing_BENGASI' changed from ON to OFF
07:32:56.194 [WARN ] [hab.binding.mqtt.generic.ChannelState] - Command '{
    "header": {
        "from": "/appliance/2009072623298651802748e1e92fbcb9/publish",
        "messageId": "4b99598c5526bd7f3c9eb1c06401188e",
        "method": "PUSH",
        "namespace": "Appliance.System.Clock",
        "payloadVersion": 1,
        "sign": "5c80e6480dab480c74ed70c36c5d2e22",
        "timestamp": 3,
        "timestampMs": 660
    },
    "payload": {
        "clock": {
            "timestamp": 3
        }
    }
}' from channel 'mqtt:topic:02724a8db9:7dfc0915b5:cidMerossBeng' not supported by type 'OnOffValue': No enum constant org.openhab.core.library.types.OnOffType.{
    "header": {
        "from": "/appliance/2009072623298651802748e1e92fbcb9/publish",
        "messageId": "4b99598c5526bd7f3c9eb1c06401188e",
        "method": "PUSH",
        "namespace": "Appliance.System.Clock",
        "payloadVersion": 1,
        "sign": "5c80e6480dab480c74ed70c36c5d2e22",
        "timestamp": 3,
        "timestampMs": 660
    },
    "payload": {
        "clock": {
            "timestamp": 3
        }
    }
}
6

Sorry, I should have been more clear. Your channel definition is for a switch channel. That will only accept commands compatible with the OH switch type. It will not accept arbitrary strings. If you want to capture the full returned JSON you not only need to not transform the data but you need have a channel and a linked item that are compatible with string data. I don’t use MQTT, so you’ll have to look int he binding docs if you are unsure how to do that.

However, you already have some information at least from the warning message, so while it would be a good step to take for troubleshooting you don’t necessarily have to work up a full string channel. That JSON string that it is displaying looks a lot like the one you first posted, and quite frankly, neither of them appear to contain anything like Switch state or toggle information. So, there is some much more fundamental disconnect here that is happening at the device/binding level which means you are not getting the information you expect.

7

What makes me think is this note in https://github.com/arandall/meross/blob/main/doc/provisioning.md:
In my testing the device sends an Appliance.System.Clock to the /appliance/<UUID>/publish topic until it gets a response. From testing the response must be sent via MQTT to the topic /appliance/<UUID>/subscribe . If a response is not received within 10 attempts the device will restart and go back to the beginning of Step 2.
So I sent to the topic /appliance/<UUID>/subscribe a message with the same payload as the request - but, sadly, device reboots…