Does this support MSS310 Hardware Version 6 ?

[RaoulSargent]

Having worked perfectly with MSS310 Hardware Version 2 devices, I now have a number of MSS310 Hardware Version 6 (6.1.12), and sadly these brilliant tools seem to no longer work - or what am I doing wrong?

I believe the error occurs following a timeout situation, as it takes approx 60 seconds between entering the command and the error occuring.

npx meross info --verbose --include-wifi
[approx 60 seconds before the following output]

Getting info about device with IP 10.10.10.1
> POST /config
> Host: 10.10.10.1
> Accept: application/json, text/plain, */*
> Content-Type: application/json
>
{
  header: {
    method: 'GET',
    namespace: 'Appliance.System.All',
    messageId: 'ce176080b7a27fe07c8542322f08f300',
    timestamp: 1667332285,
    sign: 'BLAHBLAH'
  },
  payload: {}
}

node:internal/errors:478
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string. Received undefined
    at new NodeError (node:internal/errors:387:5)
    at validateString (node:internal/validators:162:11)
    at Url.parse (node:url:168:3)
    at Object.urlParse [as parse] (node:url:155:13)
    at new URL (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:6:35)
    at logRequest (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:62:15)
    at handleRequestError (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:99:13)
    at API.deviceInformation (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:204:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\bin\meross-info:42:5 {
  code: 'ERR_INVALID_ARG_TYPE'
}

and...

npx meross setup --gateway 10.10.10.1 --wifi-ssid SSID --wifi-pass PASS --mqtt mqtts://192.168.xx.yy:8883 --mqtt mqtts://192.168.xx.yy:8883 --verbose
[approx 60 seconds before the following output]

Setting up device with IP 10.10.10.1
┌────────────────────────────────────────────────┬────────────────────────────────────────────┐
│Primary MQTT broker                             │192.168.xx.yy:8883                          │
├────────────────────────────────────────────────┼────────────────────────────────────────────┤
│Failover MQTT broker                            │192.168.xx.yy:8883                          │
└────────────────────────────────────────────────┴────────────────────────────────────────────┘
> POST /config
> Host: 10.10.10.1
> Accept: application/json, text/plain, */*
> Content-Type: application/json
>
{
  header: {
    method: 'SET',
    namespace: 'Appliance.Config.Key',
    messageId: '4ee67857799a6868c72e75a6c425a16d',
    timestamp: 1667331904,
    sign: 'BLAHBLAH'
  },
  payload: {
    key: {
      userId: '0',
      key: '',
      gateway: {
        host: '192.168.xx.yy',
        port: '8883',
        secondHost: '192.168.xx.yy',
        secondPort: '8883',
        redirect: 1
      }
    }
  }
}

node:internal/errors:478
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string. Received undefined
    at new NodeError (node:internal/errors:387:5)
    at validateString (node:internal/validators:162:11)
    at Url.parse (node:url:168:3)
    at Object.urlParse [as parse] (node:url:155:13)
    at new URL (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:6:35)
    at logRequest (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:62:15)
    at handleRequestError (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:99:13)
    at API.configureMqttServers (C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\lib\api.js:338:13)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async C:\Users\ME\AppData\Local\npm-cache\_npx\0e1343c997790563\node_modules\meross\bin\meross-setup:89:9 {
  code: 'ERR_INVALID_ARG_TYPE'
}

[maxjiang153]

Same problem, Can't access /config path, But can open http://10.10.10.1 with config panel.

[zeppmg]

Same problem here with same version :(

[bitsonbitsoff]

I've experienced the timeout with a 6.0.0 device and 6.1.10 fw. The timeout is originating from the device and might be based on one or more of the values in the payload. Testing different payloads with a REST tool I was able to configure the device with combinations of resetting the switch and modifying the messageId & timestamp values in the header object.

6.0.0 device on 6.3.21 firmware doesn't work at all. The password in the wifi payload doesn't appear to be just base64 encoding the clear text string, so I think that's why the device fails to connect after the setup request.

[lechercheur123]

Hello @bitsonbitsoff,

I have a device with fw 6.1.12. Can you share us the payload that worked with fw 6.1.10 ?

[bitsonbitsoff]

Hello @bitsonbitsoff,

I have a device with fw 6.1.12. Can you share us the payload that worked with fw 6.1.10 ?

Its similar to the payload sent with the bytespider setup utility. The extra fields I sniffed from the iOS app, but I'm not certain they are required. I was able to configure the device with the bytespider setup at one point, but it was inconsistent and only after a factory reset. It feels like the firmware gets stuck on some requests, keeps the socket open and blocks subsequent calls, which could be why the factory reset helps in some cases.

I'm not getting predictable results everytime, so I hope this doesn't lead you astray.

{
  "payload": {},
  "header": {
    "messageId": "<replace with message id>",
    "method": "GET",
    "from": "http:/10.10.10.1/config",
    "payloadVersion": 1,
    "namespace": "Appliance.System.All",
    "sign": "<replace with signed value>",
    "triggerSrc": "iOS",
    "timestamp": <replace with unix timestamp>
  }
}

[bytespider]

Unfortunately I don't have these devices to test.

You could try using mqtt-debug to see if that still works on these to observe the communication between the device and the Meross IOT servers. https://github.com/bytespider/mqtt-debug

[RaoulSargent]

Thank you for the suggestion to use matt-debug - I will give it a try as soon as I can and provide feedback.

[RaoulSargent]

In the interim, as a stop-gap, I registered the HWv6 devices with the Meross application (as you would normally), thence registered I block their internet access. Then I was able to add them manually in HA using the authorisation key as per the others. So not ideal, as a stop-gap it means they are working with HA (Meross Lan integration) but have no internet connection as I dont want them talking to anyone else.
Obviously I want to get the 100%-offline mode working again and using MQTT locally not HTTP polling.
But, until we can get these HWv6 devices supported, this is at least a stop-gap.

[Ashthos]

I also have some new Meross plugs (mss310 un rtl8710cf (hardware:6.0.0 firmware:6.3.6))

When I apply the mqtt configuration to them, they reboot and seemingly connect to the wifi correctly (as they are discovered by HA - but only as 'Meross Lan' devices), however, after about 60 seconds, they reboot themselves and revert to AP mode.

However, after trying, and retrying, to apply the settings they finally appear to have stuck. In Home assistant they are discovered correctly as "Meross Smart Plug (mss310)"

The only change to the settings that I was making was changing the mqtt broker address from an IP address to a dns alias (and back).

I'm using - v1.0.12 of this the meross-info app.

Not a huge amount of help to those unable to get the new firmware working, but it appears if you keep trying they stick eventually.

[DominikGebhart]

I added a PR that might fix the wifi connection issue on newer revisions / firmwares.

[RaoulSargent]

In addition to my v2.0.0 hardware devices with firmware 2.1.15 and my V6.0.0 hardware devices with firmware 6.1.12; I now have some more V6.0.0 Hardware devices but with different firmware. I do not upgrade the ones I have, these new ones shipped with the newer firmware.

So I can now test against firmware versions 2.1.15, 6.1.12 and 6.3.6 as soon as a new version of the tool is available.

[RaoulSargent]

In the interim, as a stop-gap, I registered the HWv6 devices with the Meross application (as you would normally), thence registered I block their internet access. Then I was able to add them manually in HA using the authorisation key as per the others. So not ideal, as a stop-gap it means they are working with HA (Meross Lan integration) but have no internet connection as I dont want them talking to anyone else.
Obviously I want to get the 100%-offline mode working again and using MQTT locally not HTTP polling.
But, until we can get these HWv6 devices supported, this is at least a stop-gap.

Update to this (not so good) workaround.
although I had previously had my v6 hardware devices running with internet access totally blocked, when the plug was powered off (removed from socket) and then back on (plugged back in) it stopped reporting sensor values to HA.

The DND and Power On/Off continued to work but the voltage/current/etc stopped reporting.

After some playing I believe the plugs need access to an NTP server, at least at power on.
some wireshark-ing revealed that they take no notice of not servers provided by DHCP, and repeatedly query for a number of NTP servers including some in China. (Aliyun).

I have therefore blocked all internet access except the non-Chinese NTP servers. Although only been a couple of days it seems the two v6 HW firmwares behave differently and I am still getting some issues.

None of this is ideal, the ultimate aim being to configure the MQTT settings for local only use.

But in case it helps others I will update again if I conclude anything more about the plugs behaviour whilst trying to disconnect them from the internet as far possible.

But again, local MQTT is the ideal solution.

[DominikGebhart]

My mss310 v6 plugs all on firmware v6.1.12 run exclusively on my local broker. Apart from some issues with the Home Assistant integration (need to either restart HA or run a trace command, i.e. initiate home assistant to talk to it) they work quite well.

As an aside: The ntp requests i did not see on my v6 ones, and i doubt they try it as the v6 run on a rtl8710cf microcontroller. The v2 used a small linux inside iirc, the requests might come from those. The only traffic i was able to capture was mqtt on the v6. Another plus on the v6 is the consumption once configured is only about 0.3 0.675 watts.

[lechercheur123]

@RaoulSargent Did you try to set the time through MQTT ?
I explained the necessary payload in #61

[RaoulSargent]

@RaoulSargent Did you try to set the time through MQTT ?
I explained the necessary payload in #61

Currently I cannot get any of my hardware v6 MSS310's to be configured with local MQTT broker, so sadly I cannot communicate with them via MQTT.

[RaoulSargent]

My mss310 v6 plugs all on firmware v6.1.12 run exclusively on my local broker.

How did you get the v6 hardware plugs to talk to your local MQTT Broker ?
Am I being stupid? I only ever get the errors as described at the head of this issue, no matter how many times I factory reset and try again.

[DominikGebhart]

With the code from this PR i successfully got them into my wifi and configured for the local mqtt broker. Inside the bin directory i issued ./meross-setup --use-wifi-x --wifi-ssid SSID --wifi-pass PASS --mqtt 192.168.X.X:8883

You should be able to test it with the referenced branch from the PR im my fork.

Edit: However, i never had any errors issuing meros-info, so it might not be the same issue.
Edit2: Maybe its a problem with node, node -v says v19.6.1. Also: When installing the dependencies, try to use npm ci instead of npm install. That way you make sure to get exaclty the version as specified in the packages.config and not a newer version.

[RaoulSargent]

SUCCESS - THANK YOU :-)

MSS310 Hardware v6 Firmware 6.3.6 WORKED
MSS310 Hardware v6 Firmware 6.1.12 WORKED (sign errors, see below)

MSS310 Hardware v6 Firmware 6.3.6
2x Devices connected to local MQTT Broker and happily updating in HomeAssistant with Meross Lan local integration.

MSS310 Hardware v6 Firmware 6.1.12
1x Device connected to local MQTT Broker and happily updating in HomeAssistant with Meross Lan local integration.
(I have another 5x devices on 6.1.12 to be configured shortly)

However, for the Firmware 6.1.12 device I am seeing these "SIGN ERROR" messages in MQTT at every update interval:

Examples:

{"header":{"messageId":"15419275f57bebee8720af506f2b5438","namespace":"Appliance.Control.Bind","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972478,"timestampMs":366,"sign":"efa361abcOBFUSCATED2b0e0cf"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

{"header":{"messageId":"4eb42fb6c584409aa9c6eaf78af9d334","namespace":"Appliance.Control.Electricity","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972663,"timestampMs":888,"sign":"ebbOBFUSCATEDcdbf605f"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

{"header":{"messageId":"2d088ea94d7b4ce89cd33a3f000721d8","namespace":"Appliance.Control.ConsumptionX","method":"ERROR","payloadVersion":1,"from":"/appliance/OBFUSCATED/publish","uuid":"OBFUSCATED","timestamp":1676972635,"timestampMs":434,"sign":"4ca46OBFUSCATEDfb66d"},"payload":{"error":{"code":5001,"detail":"sign error"}}}

[DominikGebhart]

Regarding

when the plug was powered off (removed from socket) and then back on (plugged back in) it stopped reporting sensor values to HA.

The DND and Power On/Off continued to work but the voltage/current/etc stopped reporting.

This could be the same issue as reported here and should be fixed in the next release of meross lan.

[lechercheur123]

The PR is also working for me. Thank you @DominikGebhart !
For information my MSS310 has 6.1.12 for firmware.

I don't have any sign issue, but I use a custom signing key provided during setup.

Anyway, I still have a small issue: my plug keep sending Appliance.Control.Bind and Appliance.System.Report messages every 10 seconds or so.

{
  "header": {
    "messageId": "c9b684b568c218bc667cfdb1eea5cf4f",
    "namespace": "Appliance.Control.Bind",
    "method": "SET",
    "payloadVersion": 1,
    "from": "/appliance/myuuid/subscribe",
    "uuid": "myuuid",
    "timestamp": 1677067980,
    "timestampMs": 322,
    "sign": "9b2d58e12a61ed84ae521ae31ca6bf11"
  },
  "payload": {
    "bind": {
      "bindTime": 1677067980,
      "time": {
        "timestamp": 1677067980,
        "timezone": "",
        "timeRule": []
      },
      "hardware": {
        "type": "mss310",
        "subType": "un",
        "version": "6.0.0",
        "chipType": "rtl8710cf",
        "uuid": "myuuid",
        "macAddress": "myMACaddress"
      },
      "firmware": {
        "version": "6.1.12",
        "compileTime": "2022/05/26-15:39:26",
        "encrypt": 1,
        "wifiMac": "wifimac",
        "innerIp": "192.168.2.78",
        "server": "mqttdomainname",
        "port": 8883,
        "userId": 0
      }
    }
  }
}

{
  "header": {
    "messageId": "995fc71c49836e33a34e90145a8a6794",
    "namespace": "Appliance.System.Report",
    "method": "PUSH",
    "payloadVersion": 1,
    "from": "/appliance/myuuid/publish",
    "uuid": "myuuid",
    "timestamp": 1677067988,
    "timestampMs": 855,
    "sign": "57a56f25e8ba8da24423de0072d14040"
  },
  "payload": {
    "report": [
      {
        "type": "1",
        "value": "0",
        "timestamp": 1677067988
      }
    ]
  }
}

Do you have an idea what could cause this and how to fix it ?

[DominikGebhart]

Sorry, no idea. This should only get sent once after setup. Have you tried to reset those devices and pair them fresh?

If the problem persists best to create an issue in the meross lan integation project. In this issue there is a similar problem but for a different device.

[lechercheur123]

The issue you mentionned seems promising, and I will implement the proposed solution (aka reply with an empty SETACK).

Thanks ;)

[lechercheur123]

Just to confirm that my issue is fixed. My MSS310 do not send Bind messages envery 10 seconds anymore, its LED is solid green, and I have correct power measurments. :)

Thanks @DominikGebhart and everyone else !

[bytespider]

Sorry I totally missed this. Thank you @DominikGebhart for working this out.