Hi,
I found out how to turn off the leds of my mss425f (Meross Smart Plug Strip).
You can change the "DNDMode" (LED Mode) via MQTT by sending a request like this:

{
   "header":{
      "from":"/appliance/<device-uuid>/publish",
      "messageId":"<message-id>",
      "method":"SET",
      "namespace":"Appliance.System.DNDMode",
      "payloadVersion":1,
      "sign":"<sign>",
      "timestamp":1612261079,
      "triggerSrc":"Android"
   },
   "payload":{
      "DNDMode":{
         "mode":1
      }
   }
}

Mode 1 = LEDs off
Mode 0 = LEDs on

Well, it would be cool if something like that could be implemented in the script.

Sincerely,
Dominic

P.s. you can get an overview of all configuration settings by sending a request like this to your device:

{
   "header":{
      "from":"/appliance/<device-uuid>/publish",
      "messageId":"<message-id>",
      "method":"GET",
      "namespace":"Appliance.System.Ability",
      "payloadVersion":1,
      "sign":"<sign>",
      "timestamp":1612261079,
      "triggerSrc":"Android"
   },
   "payload":{
   }
}

The Home Assistant version of Mosquitto ships with mosquitto-auth-plug. I've had some success with connecting Meross smart plugs to the HA Mosquitto instance, however, there are a few issues:

• The Meross devices (may not be all) send a ClientId > 23 characters which contravene the MQTT 3.1 spec.
• Home Assistant does allow you to inject custom options, however, new listeners cannot be seen by the network
• Home Assistant doesn't allow you to inject custom options into the config "Per Listener"

I'm trying to setup my MSS210 - but I'm stuck in a connection error.

bodhi@bodhi:~$ npx meross setup --wifi-ssid '<SSID>' --wifi-pass '<PASS>' --mqtt mqtts://zshq-ohab:8883
npx: installed 27 in 72.512s
Setting up device with IP 10.10.10.1
┌──────────────────────────────────────────────────────┬────────────────────────
│Primary MQTT broker                                   │zshq-ohab:8883
├──────────────────────────────────────────────────────┼────────────────────────
│Failover MQTT broker                                  │zshq-ohab:8883
└──────────────────────────────────────────────────────┴────────────────────────
Error Unable to connect to device
Error Unable to connect to device
Error Unable to connect to device
Device will reboot...

Is there a way to get more info about the connection problem?

Hi there!

Been fiddling with the MSS210 plug I picked up from Amazon recently and looking to get it speaking offline to my local MQTT broker. I've gotten it working twice now (I redid it the second time to make sure the steps were accurate) and was looking to push a PR to allow switching MQTT settings separate from Wifi.

Except, it seems like I have to allow it to connect to Meross IOT broker at least once, before switching over the MQTT details to my local server. Perhaps someone knows more about the protocol can let me know why this might be?

The steps I took:

• reset the device back into pairing mode by holding the button for 5 seconds
• connected to Meross AP and was able to call ./bin/meross info
• set up Wifi and dummy MQTT (for now) with ./bin/meross setup making sure to specify both user and key (I'm not sure if these are required specifically, but if it has to talk to Meross MQTT once, then presumably so) and mqtt with 127.0.0.1:8883

The device should reboot and reconnect to the local Wifi network now correctly. I could verify this with ./bin/meross info and specifying the same key. MQTT connection is obviously broken/unconfigured at this point!

Here's where I go off track 😅 I wanted to test setting MQTT only, so was playing with modified code, specifically I just didn't call the configureWifiCredentials function, and called ./bin/meross setup with the correct MQTT local broker. This works, and the device doesn't reboot, it tries to connect to the new broker immediately. I can subscribe to the /appliance/....../publish topic and see the plug publishing messages. This is where it looks to get stuck in a loop.

It keeps publishing Appliance.Control.Bind and then Appliance.Control.Report messages before disconnecting, reconnecting and continuing the process. It seems like it's waiting for a response from Meross?

I run the same code as above, but this time with the official Meross MQTT broker details (found from pcap/debugging elsewhere) and let it sit for a minute. I then run the same code again but with my local MQTT broker details, and now it connects fine and happy, and works as expected. I get an initial Appliance.Control.Report message and then it responds to button presses with ToggleX etc.

I've tried mqtt-debug with certs, but it doesn't seem to like proxying the connection on to Meross MQTT broker for some reason, I see the CONNECT but nothing else. As I can't see the packets received when it's connecting to the official broker, I'm not sure what other magic is happening on that initial MQTT connection with the bind/report.

Anyone able to shed some light on that part?

Problem:
./meross throws TypeError [ERR_INVALID_ARG_TYPE] and cannot see what the real error is,
when ./meross with -v option and situation that occuring some network error, such as reserving inappropriate IP address to --gateway option.

Log:
10.10.10.155 is not meaningful IP address example which not exist Meross device.

$ ./bin/meross info --gateway 10.10.10.155 -v
Getting info about device with IP 10.10.10.155
> POST /config
> Host: 10.10.10.155
> Accept: application/json, text/plain, */*
> Content-Type: application/json
>
{
  header: {
    from: '',
    method: 'GET',
    namespace: 'Appliance.System.All',
    messageId: '3d09087d7574042037eb832a3a3f8ff8',
    timestamp: 1629745262,
    sign: '3c699b7bae58b4b647e8864e6b1299ac'
  },
  payload: {}
}

node:internal/process/promises:227
          triggerUncaughtException(err, true /* fromPromise */);
          ^

TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string. Received undefined
    at new NodeError (node:internal/errors:329:5)
    at validateString (node:internal/validators:129:11)
    at Url.parse (node:url:169:3)
    at Object.urlParse [as parse] (node:url:156:13)
    at new URL (/home/pi/Downloads/Meross/lib/api.js:6:35)
    at logRequest (/home/pi/Downloads/Meross/lib/api.js:62:15)
    at handleRequestError (/home/pi/Downloads/Meross/lib/api.js:99:13)
    at API.deviceInformation (/home/pi/Downloads/Meross/lib/api.js:205:13)
    at processTicksAndRejections (node:internal/process/task_queues:94:5)
    at async /home/pi/Downloads/Meross/bin/meross-info:42:5 {
  code: 'ERR_INVALID_ARG_TYPE'
}

My environment:
Hardware : Raspberry Pi 1 (Yes, it's old)

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
$ node -v
v15.6.0
$ npm -v
7.21.0

Cause?:
In

My workaround:
In

Log with applying workaround:
Shows error normally (without TypeError).

$ ./bin/meross info --gateway 10.10.10.155 -v
Getting info about device with IP 10.10.10.155
> POST /config
> Host: 10.10.10.155
> Accept: application/json, text/plain, */*
> Content-Type: application/json
>
{
  header: {
    from: '',
    method: 'GET',
    namespace: 'Appliance.System.All',
    messageId: '848fbdb9951232b81a9f1d5858406023',
    timestamp: 1629746553,
    sign: '42006e85b09bf0d4da77427515cab7ff'
  },
  payload: {}
}

Error connect EHOSTUNREACH 10.10.10.155:80

Hello Bytespider
Few days ago, i've bought 3 new meross smart switch MSS710 with hardware:6.0.0 firmware:6.1.3 and hardware:6.0.0 firmware:6.1.6

So, when I`m trying to enroll them to my WiFi using command:
sudo ./meross-setup --gateway 10.10.10.1 --wifi-ssid name XXX --wifi-pass XXX --mqtt mqtt://XXX:8883

I hear clicks, led changes flashing green, and later going back into pairing mode.
In my DHCP server logs there are any dhcp request from device.

I've tried to manually assign IP addres to device, but still no wifi connection.
Using the same configuration with MS310 working fine

But! When I'm using official meross app to configure them, they connect to my wifi with any trouble
Where should I look to solve it?
Thanks

I rebooted my router and since have "lost" several meross devices. It is possible they have changed IP.

meross lan: 2.5.5
HA: 2022.2.9

Can these devices be recovered? Do I need to remove and read the integration?

It looks like tls_version tlsv1.1 is no longer required, and makes testing with mosquitto_sub impossible. Removing it from my mosquitto config still allowed my to connect my MSS110's.

/appliance/XXXXXXX/publish {"header":{"messageId":"a1605224f8b808178c8bdac5d8e239dc","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/XXXXXXX/publish","timestamp":4,"timestampMs":257,"sign":"27f5352964c535596c659880231f8ff9"},"payload":{"clock":{"timestamp":4}}}
/appliance/XXXXXXX/publish {"header":{"messageId":"113bb9db042646b5d561b8c74058d0ed","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/XXXXXXX/publish","timestamp":6,"timestampMs":265,"sign":"0bbeb9f303ad83b96861fc934307eb37"},"payload":{"clock":{"timestamp":6}}}
/appliance/XXXXXXX/publish {"header":{"messageId":"a97dd90c9e0f42a8de14fd6510bf98f7","namespace":"Appliance.System.Report","method":"PUSH","payloadVersion":1,"from":"/appliance/XXXXXXX/publish","timestamp":1594520169,"timestampMs":272,"sign":"ba847d1fe461a7f7e49e9117813a8f80"},"payload":{"report":[{"type":"1","value":"1","timestamp":1594520169}]}}
/appliance/XXXXXXX/publish {"header":{"messageId":"9565a7b2576e1cc1ef3a71014aef14af","namespace":"Appliance.Control.Bind","method":"PUSH","payloadVersion":1,"from":"/appliance/XXXXXXX/publish","timestamp":1594520169,"timestampMs":281,"sign":"6917de4509bd834dd600041d6289c1ce"},"payload":{"bind":{"bindTime":1594520169,"time":{"timestamp":1594520169,"timezone":"","timeRule":[]},"hardware":{"type":"mss110","subType":"us","version":"2.0.0","chipType":"mt7682","uuid":"XXXXXXX","macAddress":"48:e1:e9:XX:XX:XX"},"firmware":{"version":"2.1.19","compileTime":"2020/04/15 17:02:04 GMT +08:00","wifiMac":"0c:80:63:XX:XX:XX","innerIp":"172.16.XX.219","server":"172.16.XX.2","port":8883,"userId":0}}}}

When I've updated my MS310 to version 6.1.10, meross-setup stopped working.
Now it even not connecting to wifi, configured with your utility.
Same problem with MSS710
#34 (comment)

Getting info from an MSS520H with 3.1.1 firmware fails:

sending payload { header:
   { method: 'GET',
     namespace: 'Appliance.System.All',
     messageId: '1' },
  payload: {} }
{ RequestError: Error: read ECONNRESET
    at new RequestError (/home/pi/Meross/bin/src/node_modules/request-promise-core/lib/errors.js:14:15)
    at Request.plumbing.callback (/home/pi/Meross/bin/src/node_modules/request-promise-core/lib/plumbing.js:87:29)
    at Request.RP$callback [as _callback] (/home/pi/Meross/bin/src/node_modules/request-promise-core/lib/plumbing.js:46:31)
    at self.callback (/home/pi/Meross/bin/src/node_modules/request/request.js:185:22)
    at Request.emit (events.js:189:13)
    at Request.onRequestError (/home/pi/Meross/bin/src/node_modules/request/request.js:881:8)
    at ClientRequest.emit (events.js:189:13)
    at Socket.socketErrorListener (_http_client.js:392:9)
    at Socket.emit (events.js:189:13)
    at emitErrorNT (internal/streams/destroy.js:82:8)
  name: 'RequestError',
  message: 'Error: read ECONNRESET',
  cause:
   { Error: read ECONNRESET
       at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' },
  error:
   { Error: read ECONNRESET
       at TCP.onStreamRead (internal/stream_base_commons.js:111:27) errno: 'ECONNRESET', code: 'ECONNRESET', syscall: 'read' },
  options:
   { url: 'http://192.168.1.171/config',
     headers: { 'Content-Type': 'application/json' },
     json: { header: [Object], payload: {} },
     method: 'POST',
     callback: [Function: RP$callback],
     transform: undefined,
     simple: true,
     resolveWithFullResponse: false,
     transform2xxOnly: false },
  response: undefined }
undefined

Node is version V10.15.3.

The URL in the intro of MQTT wiki page is outdated, the code now seems to be here: https://github.com/albertogeniola/MerossIot/blob/0.4.X.X/meross_iot/manager.py

Hi,

I configured a custom mqtt server to my switches that are already setup with homekit. The servers a stored properly in the devices but the mqtt server logs don't show any activity from the switches to connect the server. Do you know if mqtt action is disabled when setup with homekit?

Martin

Hello again @bytespider
Was busy for few day with a server migration and now back to this. I was able to connect to local MQTT server by just pointing the iot.meross.com and smart.meross.com DNS entries to my local MQTT server. The device publishes info to MQTT fine, e.g if I use the physical button to turn on/off this is the MQTT message that is posted:
{"header": {"messageId":"ac071f0d81fe2e07d1c2a9c4c8f523a7", "namespace":"Appliance.Control.Toggle", "method":"PUSH", "payloadVersion":1, "from":"/appliance/mydeviceUUID/publish", "timestamp":1553413590, "timestampMs":440, "sign":"e410105ebe776395645a9aa33ce8b919"}, "payload": {"toggle":{ "onoff":0, "lmTime":1553413590} } }

I'm wondering how you are posting mesages to topic that MS310 is subscribed to so we can control it directly from there. I looked on other MS310 libraries but they are all using HTTP POST requests to interact with MS310. This seems like a json message that can be published and then MS310 will read it from its subscribed topics. Have you done something in this regards?
Cheers

Hi,

I'm trying to configure a MSS210 switch to connect to my mosquitto broker using your tool.

I've followed your tool and it correctly configures the swtich connect to my wifi network. I also send the data for the mqtt broker:

The command a sent and its response is below (somewhat sensitive data ofuscated).

$ ./meross setup --gateway 10.10.10.1 --wifi-ssid <SSID> --wifi-pass <SSID-PASSWORD> --mqtt mqtts://192.168.1.<OCT>:8883
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.1.<OCT>', port: '8883' } ]
sending payload { header:
   { method: 'SET',
     namespace: 'Appliance.Config.Key',
     messageId: 'bea90e4e1bc5f3f921479de4f4ccae45',
     timestamp: 1602454838,
     sign: '2274d8d30f46d2d59f2612564065a0eb' },
  payload:
   { key:
      { gateway: { host: '192.168.1.<OCT>', port: '8883' },
        key: '',
        userId: '' } } }
sending payload { header:
   { method: 'SET',
     namespace: 'Appliance.Config.Wifi',
     messageId: '1fe27ef18f573a87344984faa71a692d',
     timestamp: 1602454838,
     sign: 'f33a8fe0204aaefdcb3f5540bcd293ad' },
  payload:
   { wifi: { ssid: '<SSID-BASE664>', password: '<SSID-PASSWORD-BASE664>' } } }
Got response: { header:
   { messageId: '1fe27ef18f573a87344984faa71a692d',
     namespace: 'Appliance.Config.Wifi',
     method: 'SETACK',
     payloadVersion: 1,
     from: '/appliance/<UUID>/publish',
     timestamp: 230,
     timestampMs: 85,
     sign: 'c21cc4813383639bb321519b6c0fe54c' },
  payload: {} }
$

A few seconds later in the mosquitto logs the following entries appear:

(...)
2020-10-11T23:29:47: New connection from 192.168.1.<OCT2> on port 8883.
2020-10-11T23:29:47: Sending __CONNACK__ to 192.168.1.<OCT2 __(0, 5)__
2020-10-11T23:29:47: Socket error on client <unknown>, disconnecting.
(...)

The mosquitto has the following configuration for the tls listener:
listener 8883

require_certificate false
use_identity_as_username false

cafile /etc/mosquitto/ca_certificates/RootCA.crt
certfile /etc/mosquitto/certs/mqtt.vpnserver.crt
keyfile /etc/mosquitto/certs/mqtt.vpnserver.key

I've tried several different configuration options such as the allow_annonymous without success.
I've also tried issuing different certificates to use as the server certificates. To the IP address to the host name, etc but nothing worked.

From the log results CONNACK (...) (0, 5) it indicates that the TCP connection was estabilished, that the TLS handshake was successful (and an encrypted TLS channel was estabilished) and also that a MQTT session was requested but failed due to "Connection refused, not authorized" (result code taken from https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/)
This leads me to think that some authentication data is not being sent to/retrieved from the switch so that it's connection is accepted.

Are you configuring anything related with the client authentication on the switch or on the mqtt broker?
Could you please help me?

Thanks.
Regards,
chegancasb

Hi,
I followed the instructions to the letter but I can't in any way get an MSH300 to communicate with my Mosquitto Broker running on a raspberry pi4.

This is my mosquitto.conf

port 1883

listener 8883

require_certificate false
use_identity_as_username false
allow_anonymous true

cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key

But after a single try after pairing tentative I see in the log

06/02/2021 15:56:49
1612623408: Socket error on client , disconnecting.
06/02/2021 15:56:49(-0.1 seconds)
1612623408: New connection from 192.168.1.141 on port 8883.

And my MSH300 start again to flashing orange-green

Thanx

p.s. nice work !!!

Dear all,

after spending many hours I still have no success in connecting my new smart WiFi plugs Refoss MSS210W to Mosquitto.
I am following the procedure by Rob Griffiths, but am stuck at where the meross-setup utility is used. After I try to bind the plug to my Mosquitto broker at 192.168.188.30 with the command
./meross-setup --gateway 10.10.10.1 --wifi-ssid assid162 --wifi-pass 3438XXXXXXXXXXXX7725 --mqtt mqtts://192.168.188.30 --mqtt mqtts://192.168.188.30
the plug

• clicks
• probably reboots
• changes its IP from 10.10.10.1 to 192.168.188.31
• changes its LED states from blinking red/green to blinking green
• sends out Appliance.Control.Bind- and Appliance.System.Report-messages every ≈30 seconds

The plug remains in this state forever. I have no clue on how to proceed and would highly appreciate any suggestions.
The plugs work correctly when connected to the Meross cloud / eHomeLife-App.

The Mosquitto server was installed from mosquitto-2.0.15-install-windows-x64.exe on a Windows10 machine with IP 192.168.188.30. The instance uses the following mosquitto.conf, which corresponds to that of Rob Griffiths:

listener 8883
allow_anonymous true
require_certificate false
cafile   ssl/ca.crt
certfile ssl/broker.crt
keyfile  ssl/broker.key

The three certificate files have been created on WSL/Ubuntu with this script makeCerts.sh, based on the one from ElBobo:

# !/usr/bin/env bash
mkdir ssl 
ssldir=./ssl 
   
# CA: certification authority
openssl genrsa                                           -out $ssldir/ca.key     2048 
openssl req    -new -x509 -days 1826 -key $ssldir/ca.key -out $ssldir/ca.crt     -subj "/C=CH/ST=BE/L=BE/O=Private/OU=Dep0/CN=stdifferent.30" 
 
# certificate 
openssl genrsa                                           -out $ssldir/broker.key 2048 
openssl req    -new             -out $ssldir/broker.csr  -key $ssldir/broker.key -subj "/C=CH/ST=BE/L=BE/O=Private/OU=Dep1/CN=192.168.188.30"

openssl x509   -req -in $ssldir/broker.csr -CA $ssldir/ca.crt -CAkey $ssldir/ca.key -CAcreateserial -out $ssldir/broker.crt -days 1826 

cp makeCerts.sh $ssldir/.

Note that it does not use the -des3 option which Rob uses. I also made sure that the Organisational Names are not identical, as pointed out by sheran29.

I have opened a second commandline window on the PC and successfully attached a subscriber to the running Mosquitto broker:
mosquitto_sub -h 192.168.188.30 -t "#" -t "/#" --cafile ssl/ca.crt

It successfully receives messages that I send from a third commandline window, e.g.:
mosquitto_pub -h 192.168.188.30 -p 8883 -t "test7" -m "message7" --cafile ssl/ca.crt

Here is a screenshot of the broker with three blocks:

• blue line: startup
• orange line: the subscriber connects
• yellow line: the publisher sends a message

From this I would say that Mosquitto and the certificates are OK.

Now, as I said in the beginning, after the plug is reconfigured with
./meross-setup --gateway 10.10.10.1 --wifi-ssid assid162 --wifi-pass 3438XXXXXXXXXXXX7725 --mqtt mqtts://192.168.188.30 --mqtt mqtts://192.168.188.30
it behaves as stated above. The Mosquitto broker and hence the subscriber see messages of types Appliance.Control.Bind and Appliance.System.Report, and this continues forever. What can I do?

Output from the broker:

1690725142: New connection from 192.168.188.31:52884 on port 8883.
1690725143: New client connected from 192.168.188.31:52884 as fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (p1, c1, k120, u'48:XX:XX:XX:XX:17').
1690725143: No will message specified.
1690725143: Sending CONNACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (0, 0)
1690725143: Received SUBSCRIBE from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725143:     /appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe (QoS 1)
1690725143: fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA 1 /appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe
1690725143: Sending SUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725143: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m227, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (388 bytes))
1690725143: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (388 bytes))
1690725143: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m227, rc0)
1690725143: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m228, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725143: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725143: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m228, rc0)
1690725148: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m229, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725148: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725148: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m229, rc0)
1690725153: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m230, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725153: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725153: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m230, rc0)
1690725158: Received DISCONNECT from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725158: Client fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA disconnected.
1690725167: New connection from 192.168.188.31:52885 on port 8883.
1690725167: New client connected from 192.168.188.31:52885 as fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (p1, c1, k120, u'48:XX:XX:XX:XX:17').
1690725167: No will message specified.
1690725167: Sending CONNACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (0, 0)
1690725167: Received SUBSCRIBE from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725167:     /appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe (QoS 1)
1690725167: fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA 1 /appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe
1690725167: Sending SUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725167: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m232, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (389 bytes))
1690725167: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (389 bytes))
1690725167: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m232, rc0)
1690725167: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m233, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725167: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725167: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m233, rc0)
1690725172: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m234, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725172: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725172: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m234, rc0)
1690725177: Received PUBLISH from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (d0, q1, r0, m235, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725177: Sending PUBLISH to auto-4899B759-2D01-9D43-97C8-918DF0A9A65A (d0, q0, r0, m0, '/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish', ... (766 bytes))
1690725177: Sending PUBACK to fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA (m235, rc0)
1690725182: Received DISCONNECT from fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA
1690725182: Client fmware:2211XXXXXXXXXXXXXXXXXXXXXXXX7317_qqocyGoCpeCzBsXA disconnected.

Output from the subscriber:

{"header":{"messageId":"f81cXXXXXXXXXXXXXXXXXXXXXXXX5bc1","namespace":"Appliance.System.Report","method":"PUSH","payloadVersion":1,"from":"/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish","uuid":"2211XXXXXXXXXXXXXXXXXXXXXXXX7317","timestamp":1690724715,"timestampMs":338,"sign":"c435XXXXXXXXXXXXXXXXXXXXXXXX918a"},"payload":{"report":[{"type":"1","value":"1","timestamp":1690724715}]}}
{"header":{"messageId":"4ddbXXXXXXXXXXXXXXXXXXXXXXXX10b5","namespace":"Appliance.Control.Bind","method":"SET","payloadVersion":1,"from":"/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe","uuid":"2211XXXXXXXXXXXXXXXXXXXXXXXX7317","timestamp":1690724715,"timestampMs":372,"sign":"df58XXXXXXXXXXXXXXXXXXXXXXXX9b67"},"payload":{"bind":{"bindTime":1690724715,"time":{"timestamp":1690724715,"timezone":"","timeRule":[]},"hardware":{"type":"mss210","subType":"un","version":"6.0.0","chipType":"rtl8710cf","uuid":"2211XXXXXXXXXXXXXXXXXXXXXXXX7317","macAddress":"48:XX:XX:XX:XX:17"},"firmware":{"version":"6.2.3","compileTime":"2021/10/22-11:13:43","encrypt":1,"wifiMac":"5c:XX:XX:XX:XX:03","innerIp":"192.168.188.31","server":"192.168.188.30","port":8883,"userId":0}}}}

The same in prettyfied form:

{
  "header": {
    "messageId": "f81cXXXXXXXXXXXXXXXXXXXXXXXX5bc1",
    "namespace": "Appliance.System.Report",
    "method": "PUSH",
    "payloadVersion": 1,
    "from": "/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/publish",
    "uuid": "2211XXXXXXXXXXXXXXXXXXXXXXXX7317",
    "timestamp": 1690724715,
    "timestampMs": 338,
    "sign": "c435XXXXXXXXXXXXXXXXXXXXXXXX918a"
  },
  "payload": {
    "report": [
      {
        "type": "1",
        "value": "1",
        "timestamp": 1690724715
      }
    ]
  }
}

{
  "header": {
    "messageId": "4ddbXXXXXXXXXXXXXXXXXXXXXXXX10b5",
    "namespace": "Appliance.Control.Bind",
    "method": "SET",
    "payloadVersion": 1,
    "from": "/appliance/2211XXXXXXXXXXXXXXXXXXXXXXXX7317/subscribe",
    "uuid": "2211XXXXXXXXXXXXXXXXXXXXXXXX7317",
    "timestamp": 1690724715,
    "timestampMs": 372,
    "sign": "df58XXXXXXXXXXXXXXXXXXXXXXXX9b67"
  },
  "payload": {
    "bind": {
      "bindTime": 1690724715,
      "time": {
        "timestamp": 1690724715,
        "timezone": "",
        "timeRule": []
      },
      "hardware": {
        "type": "mss210",
        "subType": "un",
        "version": "6.0.0",
        "chipType": "rtl8710cf",
        "uuid": "2211XXXXXXXXXXXXXXXXXXXXXXXX7317",
        "macAddress": "48:XX:XX:XX:XX:17"
      },
      "firmware": {
        "version": "6.2.3",
        "compileTime": "2021/10/22-11:13:43",
        "encrypt": 1,
        "wifiMac": "5c:XX:XX:XX:XX:03",
        "innerIp": "192.168.188.31",
        "server": "192.168.188.30",
        "port": 8883,
        "userId": 0
      }
    }
  }
}

What can I do?

Hi Rob,
I am not a skilled programmer, but I'm still trying, following your instructions, to connect my MSS310 to the MQTT broker I use with Home Assistant.

I installed the merossiot libraries and the various dependencies related to the execution of your scripts. Mosquitto is regularly installed and working and I entered the basic configuration in the Mosquitto .conf file.

By executing the command:

./meross info wlan0

I receive the information concerning the device ID.

However, I execute the command:

./meross setup wlan0 --wifi-ssid xWIFISSIDx --wifi-pass xWIFIPSWx --mqtt 192.168.1.xx: 8883

I receive this error message:

Setting up device with IP 10.10.10.1 on wlan0
(node: 2690) UnhandledPromiseRejectionWarning: ReferenceError: URL is not defined
    at mqtt.map (/home/pi/Meross/bin/src/api.js:51:23)
    at Array.map ()
    at API.configureMqttServers (/home/pi/Meross/bin/src/api.js:48:24)
    at / home / pi / Meross / bin / src / meross-setup: 43: 30
    at Object. (/ home / pi / Meross / bin / src / meross-setup: 51: 3)
    at Module._compile (module.js: 652: 30)
    at Object.Module._extensions..js (module.js: 663: 10)
    at Module.load (module.js: 565: 32)
    at tryModuleLoad (module.js: 505: 12)
    at Function.Module._load (module.js: 497: 3)
(node: 2690) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, $
(node: 2690) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.j $

I can't understand where I'm wrong.
Could you help me?

Sorry for my bad English, I'm writing from Italy hahaha
Thanks a lot!

Hi,
I just got a bunch of MSS310 smart plugs, with firmware 2.1.16, h/w version 2.0.0.
I've already got an existing mosquitto server (v1.4.10).

When I run the setup as desribed in the wiki, the device does connect to my wifi (I can see it on my routers dashboard), but it doesn't connect to the broker - I see lots of the following messages, and the light on the device remains green.

1621232550: New connection from 10.0.10.147 on port 1883.
1621232550: Socket error on client <unknown>, disconnecting.

The device works fine when connected via the Meross servers, so not sure what else to try here. My mosquitto server is not configured with certificates - if that helps, and there is no username auth.
Other devices connect fine to this server

Hey guys,

I don't even know if here is the right place to ask this but I need some help.
I got MSS425 smart surge protector and a local MQTT server.

Running meross setup ... works fine, connection to wifi too. But the device wont stop blinking.
The log from the MQTT server shows the problem:

meross-mqtt | 1636472729: New connection from 172.16.0.xxx:58709 on port 8883.
meross-mqtt | 1636472729: New client connected from 172.16.0.xxx:58709 as fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (p1, c1, k30, u'xx:xx:xx:xx:xx:xx').
meross-mqtt | 1636472739: Client fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH disconnected.
meross-mqtt | 1636472742: New connection from 172.16.0.xxx:58710 on port 8883.
meross-mqtt | 1636472742: New client connected from 172.16.0.xxx:58710 as fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (p1, c1, k30, u'xx:xx:xx:xx:xx:xx').
...

This does happen to infinity. Starting mosquitto with verbose output is logging:

meross-mqtt | 1636473181: New connection from 172.16.0.xxx:58768 on port 8883.
meross-mqtt | 1636473181: New client connected from 172.16.0.xxx:58768 as fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (p1, c1, k30, u'xx:xx:xx:xx:xx:xx').
meross-mqtt | 1636473181: No will message specified.
meross-mqtt | 1636473181: Sending CONNACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (0, 0)
meross-mqtt | 1636473181: Received SUBSCRIBE from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH
meross-mqtt | 1636473181:       /appliance/1804260831712629081034298f158de3/subscribe (QoS 1)
meross-mqtt | 1636473181: fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH 1 /appliance/1804260831712629081034298f158de3/subscribe
meross-mqtt | 1636473181: Sending SUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH
meross-mqtt | 1636473181: Received PUBLISH from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (d0, q1, r0, m386, '/appliance/1804260831712629081034298f158de3/publish', ... (306 bytes))
meross-mqtt | 1636473181: Sending PUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (m386, rc0)
meross-mqtt | 1636473183: Received PUBLISH from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (d0, q1, r0, m387, '/appliance/1804260831712629081034298f158de3/publish', ... (306 bytes))
meross-mqtt | 1636473183: Sending PUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (m387, rc0)
meross-mqtt | 1636473185: Received PUBLISH from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (d0, q1, r0, m388, '/appliance/1804260831712629081034298f158de3/publish', ... (306 bytes))
meross-mqtt | 1636473185: Sending PUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (m388, rc0)
meross-mqtt | 1636473187: Received PUBLISH from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (d0, q1, r0, m389, '/appliance/1804260831712629081034298f158de3/publish', ... (306 bytes))
meross-mqtt | 1636473187: Sending PUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (m389, rc0)
meross-mqtt | 1636473189: Received PUBLISH from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (d0, q1, r0, m390, '/appliance/1804260831712629081034298f158de3/publish', ... (306 bytes))
meross-mqtt | 1636473189: Sending PUBACK to fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH (m390, rc0)
meross-mqtt | 1636473191: Received DISCONNECT from fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH
meross-mqtt | 1636473191: Client fmware:1804260831712629081034298f158de3_4Wvskv3yzf52FUeH disconnected.

What can I do to fix the connection?

EDIT: I forgot my server config for my mosquitto server. Here it is:

listener 8883

allow_anonymous true
require_certificate false

cafile /certs/ca.crt

certfile /certs/server.crt
keyfile /certs/server.key

I just picked up a 4 pack of MSS110 US plugs and thought I'd share what the info command shows. Hardware version 6.0.0 and firmware 6.1.4 with a Realtek RTL8710cf. Just now working on getting TLS working in mosquitto so I'll let you know if there's any issues. Let me know if you want me to collect and specific information.
[CODE]
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: 'a3548a78936b95d462f51dbef5198e16',
timestamp: 1613841348,
sign: '3b7da8133320c9d6a1f352995272991b'
},
payload: {}
}
< 200 OK
< content-type: application/json
< connection: close
<
{
header: {
messageId: 'a3548a78936b95d462f51dbef5198e16',
namespace: 'Appliance.System.All',
method: 'GETACK',
payloadVersion: 1,
from: '/appliance/2008192442191190825548e1e92cb133/publish',
timestamp: 250848,
timestampMs: 165,
sign: 'c4a60115316d723da29e7f12d2b199cb'
},
payload: {
all: {
system: {
hardware: {
type: 'mss110',
subType: 'us',
version: '6.0.0',
chipType: 'rtl8710cf',
uuid: '2008192442191190825548e1e92cb133',
macAddress: '48:e1:e9:2c:b1:33'
},
firmware: {
version: '6.1.14',
compileTime: '2020/07/27-17:24:33',
wifiMac: '00:00:00:00:00:00',
innerIp: '10.10.10.1',
server: '',
port: 0,
userId: 0
},
time: { timestamp: 250848, timezone: '', timeRule: [] },
online: { status: 2 }
},
digest: {
togglex: [ { channel: 0, onoff: 1, lmTime: 2 } ],
triggerx: [],
timerx: []
}
}
}
}
[/CODE]

Hey bytespider,

Thank you for the extensive work. I finally got my MSS310 and Im trying to push the config change to point it to my local MQTT server. I had quite some trouble with running the node.js app, I wasn't able to install the dependencies, netroute was failing to install on Windows. I even tried it on WSL Ubuntu but it was failing there as well so I finally gave up and hard coded gateway address and removed netroute from package.json. With this I was finally able to run "meross info wifi0" and it returned the values, Next I'm moving to "meross setup" but I want to confirm the process beforehand, If I create a cert from my local CA and use it on MQTT server how are we forcing the MSS310 to trust that cert?

Also, I'm no developer by any shot and this is my first time working a node.js app, I tried to go over the code seems like its doing everything with the HTTP requests (Get, Post) is that correct? If so I would try to implement this in PowerShell.
Finally, the console that you got to via serial cable can be accessed by telnet as well by connecting to MSS310's Wi-Fi but once its connected to a Wi-Fi and is communicating with iot.meross.com it will block any attempts to its IP by telnet or SSH. The menu options were in different place than in serial output that you posted but that might have changed with the firmware. Also MSS310 I got has lot more pins on the backside than just 4 I can see on the photos you posted. (Just little observation)
Thank you again for the great work. Cheers

Hello.
Right now it's impossible to use meross devices with mqtt broker, because mqtt does not allow ":" symbol in usernames, and meross devices uses their mac address as username.
Double quotes username as you re doesn't work neither :(

https://mosquitto.org/man/mosquitto_passwd-1.html

Hi @bytespider ! thanks for the new release which is promising!!!

I'm also stuck with 2018 plugs, the behaviour is similar to what is described in #15 i.e.:

• info and setup seem to work
• plug reboots but fails to join the wifi network (blinks green then reboot back into configuration mode)

Note:

• No logs showing the plug on the wi-fi router side, DCHP is enabled
• Plugs work with Meross app and I've tried various combination of plugs and even different physical Wifi APs.
• using npm version 12, and latest Meross commit of today

Posting the logs in case this can help identifying the issue. (x's = sanitized data)

xxx@xxx:~/Meross/bin$ ./meross-info --verbose  --gateway 10.10.10.1 
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: 'a28817986ef4a6ba2b0baa16c4d54221',
    timestamp: 1617135599,
    sign: '47de1547d7a9af6779d014dc0520dbd1'
  },
  payload: {}
}

< 200 OK
< server: HTTPD
< date: Thu, 01 Jan 1970 00:06:14 GMT
< pragma: no-cache
< cache-control: no-cache
< content-type: application/json;charset=UTF-8
< connection: close
<
{
  header: {
    messageId: 'a28817986ef4a6ba2b0baa16c4d54221',
    namespace: 'Appliance.System.All',
    method: 'GETACK',
    payloadVersion: 1,
    from: '/appliance/1801164732796825131634298f1xxxxx/publish',
    timestamp: 374,
    timestampMs: 440,
    sign: '5ab121e75515dae92db1698ddd764b95'
  },
  payload: {
    all: {
      system: {
        hardware: {
          type: 'mss310',
          subType: 'us',
          version: '1.0.0',
          chipType: 'MT7688',
          uuid: '1801164732796825131634298f1xxxxx',
          macAddress: '34:29:8f:11:15:5c'
        },
        firmware: {
          version: '1.1.18',
          compileTime: '2018-12-03 11:15:36',
          wifiMac: '01:00:00:00:d0:88',
          innerIp: '0.0.0.0',
          server: '',
          port: 0,
          secondServer: '',
          secondPort: 0,
          userId: 0
        },
        time: { timestamp: 374, timezone: '', timeRule: [] },
        online: { status: 2 }
      },
      control: { toggle: { onoff: 1, lmTime: 0 }, trigger: [], timer: [] }
    }
  }
}

┌─────────────────┬───────────────────────────────────────────────────────────────────────────
│Device           │mss310 us MT7688 (hardware:1.0.0 firmware:1.1.18)                          
├─────────────────┼───────────────────────────────────────────────────────────────────────────
│UUID             │1801164732796825131634298f1xxxxx                                           
├─────────────────┼───────────────────────────────────────────────────────────────────────────
│Mac address      │34:29:8f:1x:xx:xx                                                          
├─────────────────┼───────────────────────────────────────────────────────────────────────────
│WIFI             │0.0.0.0 (01:00:00:00:d0:88)                                                
├─────────────────┼───────────────────────────────────────────────────────────────────────────
│Status           │Configuration                                                              
├─────────────────┼───────────────────────────────────────────────────────────────────────────
│Credentials      │User: 0                                                                    
│                 │Password: 0_93249be6091bab57e8ec2370258bafb1                               
└─────────────────┴───────────────────────────────────────────────────────────────────────────
xxx@xxx:~/Meross/bin$ ./meross setup --verbose  --gateway 10.10.10.1 --wifi-ssid XXXX --wifi-pass xxxxxxxxxxxxxxxxxxxxx --mqtt mqtts://192.168.x.x
Setting up device with IP 10.10.10.1
┌────────────────────────────────────────────────────┬────────────────────────────────────────
│Primary MQTT broker                                 │192.168.x.x:8883                        
├────────────────────────────────────────────────────┼────────────────────────────────────────
│Secondary MQTT broker                               │192.168.x.x: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: 'c54df717ed6e05a09ec5d5e551774a20',
    timestamp: 1617135673,
    sign: 'f0e130470adea4d23c9e4b4d8494e553'
  },
  payload: {
    key: {
      gateway: {
        host: '192.168.x.x',
        port: '8883',
        secondHost: '192.168.x.x',
        secondPort: '8883'
      },
      key: '',
      userId: ''
    }
  }
}

< 200 OK
< server: HTTPD
< date: Thu, 01 Jan 1970 00:07:28 GMT
< pragma: no-cache
< cache-control: no-cache
< content-type: application/json;charset=UTF-8
< connection: close
<
{
  header: {
    messageId: 'c54df717ed6e05a09ec5d5e551774a20',
    namespace: 'Appliance.Config.Key',
    method: 'SETACK',
    payloadVersion: 1,
    from: '/appliance/1801164732796825131634298f1xxxxx/publish',
    timestamp: 448,
    timestampMs: 610,
    sign: 'ca9f6544d0aa70ca87586e33f592a75f'
  },
  payload: {}
}

┌───────────────────────────────────────┬─────────────────────────────────────────────────────
│Encoded WIFI SSID                      │xxxxxxxxxxxxxxxx=                                     
├───────────────────────────────────────┼─────────────────────────────────────────────────────
│Encoded WIFI password                  │xxxxxxxxxxxxxxxxxxxxxxxxxxxxx=                         
└───────────────────────────────────────┴─────────────────────────────────────────────────────
> POST /config
> Host: 10.10.10.1
> Accept: application/json, text/plain, */*
> Content-Type: application/json
>
{
  header: {
    method: 'SET',
    namespace: 'Appliance.Config.Wifi',
    messageId: '77a3a9e286dc27bc21e2cc67a1e8e719',
    timestamp: 1617135674,
    sign: '8afe91cb6c2d71b6e3de19c9eddaa183'
  },
  payload: {
    wifi: {
      ssid: 'xxxxxxxxxxxxxxxx=',
      password: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxx='
    }
  }
}

< 200 OK
< server: HTTPD
< date: Thu, 01 Jan 1970 00:07:28 GMT
< pragma: no-cache
< cache-control: no-cache
< content-type: application/json;charset=UTF-8
< connection: close
<
{
  header: {
    messageId: '77a3a9e286dc27bc21e2cc67a1e8e719',
    namespace: 'Appliance.Config.Wifi',
    method: 'SETACK',
    payloadVersion: 1,
    from: '/appliance/1801164732796825131634298f1xxxxx/publish',
    timestamp: 448,
    timestampMs: 730,
    sign: '45e008d3664c08ea59c06fb8f519ec97'
  },
  payload: {}
}

Rebooting device

cheers!

The wiki states that the iot device is connecting to the MQTT broker wit a password like {user}_md5({MAC}{key}). I'm wondering how the Mac address is formatted. Can anyone make up an example?

Hi

I have a Meross MSS710.
Is it possible to upgrade the software so it become a dimmer and not just a on/off switch?

Thank you

Andreas

Hello,

I've been trying for a few days, but I'm afraid I am totally unable to make this code work. I'm sure it's my fault, but I would be grateful for some suggestions on where to direct my troubleshooting because I'm feeling pretty stupid at the moment...

If I put the plug in pairing mode and connect to its AP, this utility is successfully able to query the plug with the 'info' command, and it is successfully able to send payloads to the plug with the 'setup' command. The plug restarts as expected, but it never manages to join the wireless network. There is no indication on my router that the plug is attempting to connect; there are no errors, no connection attempts, nothing at all from that MAC address as far as the router is concerned. (Obviously this explains why no mqtt connections ever show up in the server log either.) The plug just blinks green for a long time, and eventually it gives up and resets itself back into pairing mode.

My network is all one single subnet. The official Meross app has no trouble joining the plug to any of my 2.4GHz SSIDs; it is only when I try to use this code that it fails.

I have tried:
-- setting up a separate wifi network with a simple SSID and password (to avoid any problems with password special characters)
-- using both guest mode and normal mode for the 2.4GHz network on my router
-- many various iterations of quoting and double-quoting the SSID and password in the setup command
-- using two separate node.js installs on different platforms (Kali Linux and MacOS Catalina)
-- upgrading the plug firmware using the Meross app (successfully: it's on 1.1.28 now)
-- running wireshark to see if I can spot any clues to the connection failure (none: I see the payloads, but after the plug restarts I see no broadcasts or anything on the destination SSID net)

I have also followed the SSL configuration you describe, and I am able to connect via TLS to my mqtt server no problem (using the openssl client), but as the plug never actually shows up in the router I don't think the mqtt or tls configuration is the issue.

Here is the output of the commands when I execute them:

$ bin/src/meross info --gateway 10.10.10.1
Getting info about device with IP 10.10.10.1
sending payload {
  header: {
    method: 'GET',
    namespace: 'Appliance.System.All',
    messageId: '52555f34249a6e75a64f2309df0fe846',
    timestamp: 1611114830,
    sign: '083d7ffaf12355231cfbe3a692f51f8b'
  },
  payload: {}
}
Got response: {
  header: {
    messageId: '52555f34249a6e75a64f2309df0fe846',
    namespace: 'Appliance.System.All',
    method: 'GETACK',
    payloadVersion: 1,
    from: '/appliance/1712126291560325130734298f107d35/publish',
    timestamp: 63,
    timestampMs: 610,
    sign: '7766643a4c322e46f7e6c10400b22dcd'
  },
  payload: {
    all: {
      system: {
        hardware: {
          type: 'mss110',
          subType: 'us',
          version: '1.0.0',
          chipType: 'MT7688',
          uuid: '1712126291560325130734298f107d35',
          macAddress: '34:29:8f:10:7d:35'
        },
        firmware: {
          version: '1.1.28',
          compileTime: '2019-11-25 16:15:37',
          wifiMac: '01:00:00:00:a8:e5',
          innerIp: '0.0.0.0',
          server: '',
          port: 0,
          secondServer: '',
          secondPort: 0,
          userId: 0
        },
        time: { timestamp: 63, timezone: '', timeRule: [] },
        online: { status: 2 }
      },
      control: { toggle: { onoff: 1, lmTime: 0 }, trigger: [], timer: [] }
    }
  }
}


$ bin/src/meross setup --gateway 10.10.10.1 --wifi-ssid TEST --wifi-pass 123456789 --mqtt mqtts://192.168.2.7:8883
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.2.7', port: '8883' } ]
sending payload {
  header: {
    method: 'SET',
    namespace: 'Appliance.Config.Key',
    messageId: 'aec466c8270c05f6c23fe351c38322a1',
    timestamp: 1611115057,
    sign: '8ba32cd78956600b277393cf965a663a'
  },
  payload: {
    key: {
      gateway: { host: '192.168.2.7', port: '8883' },
      key: '',
      userId: ''
    }
  }
}
sending payload {
  header: {
    method: 'SET',
    namespace: 'Appliance.Config.Wifi',
    messageId: '7445c822f426ba1669a69cd48381107c',
    timestamp: 1611115057,
    sign: 'a5a869b5f6681544c30dfbbb3f9e7f8e'
  },
  payload: { wifi: { ssid: 'VEVTVA==', password: 'MTIzNDU2Nzg5' } }
}
Got response: {
  header: {
    messageId: '7445c822f426ba1669a69cd48381107c',
    namespace: 'Appliance.Config.Wifi',
    method: 'SETACK',
    payloadVersion: 1,
    from: '/appliance/1712126291560325130734298f107d35/publish',
    timestamp: 290,
    timestampMs: 980,
    sign: '353be22eb626cbd30cdc2122a9797050'
  },
  payload: {}
}
$ 

Any suggestions on where I should look, or something else I should try?

Thanks so much for your efforts on this! This project is what actually first prompted me to try and gain local control over my Meross devices. Now if only I could make it work...

Not a issue, but some related implementations based on this code and work done by
https://github.com/albertogeniola/MerossIot.

https://github.com/shodge12/Meross-Node-Red-Comm

BTW - thanks for all your work...
-Stan

First of all - thank you very much for your wonderful utility. It allowed me to move my devices into my MQTT broker and the reactivity increased greatly.

I have a problem with power strips, though. I do not believe that this is related to the utility (which, if my understanding is correct, provides the device another MQTT server than the Meross cloud one).

When disconnecting my MQTT server, Meross power strips do not reconnect. They do not even try.
I forcefully removed them from the wifi (forcing them to reconnect) but this did not trigger MQTT messages either.

OTOH, single plugs eventually reconnect.

Has anyone seen such behaviour?

This project looks really nice but tried today to reconfigure MSS210 and MSS310 so to use local mqtt servers but those are not even able to connect to the WiFi network and get stucked just blinking green. Had to recover them using Meross APP.

Setup command didn´t report any error though. I´m testing this from OSX 11.2.1

Any idea how I can troubleshoot this?

Thanks

First of all, thank you for developing a great tool.

In previous versions I configured it with a string for user-id and used it fine, but recent versions seem to only accept user-id integers.

Is the reason for such a change to cause something wrong?

On this page I read the following:

user is the string you provided with --user and key is the strig you provided with --key on setup.

but I cannot find any other reference to that --user (and --key).
Could you, please, clarify?
Thank you 🥰

I just upgraded the firmware on my MSG100 (w/HomeKit) to version 4.2.6 and now both meross-info and meross-setup (both previously working) are failing with the error message "Incorrect shared key provided"

Hi folks, more a question than a issue. When i setup a mqtt broker with tls enable. How on earth i give the ca to hass/device?

You can see in the mosquitto_pub/sub the user needs to pass the cafile... but based on the meross setup all i have to pass is the mqtts://ipserver

cheers!

Hello,

I am using several devices (mss110, mss210, mss310, mss710) with a local mqtt.
The ntp port is open.

The device with 5.1.1 firmware (mss110 and some mss310) do not synchronise the time with ntp.
At the boot, the timestamp starts at 0 up to ~2200000

For the devices with firmware <5, there is not problem : the timestamp is well synchronized.

Is there a some configuration on mosquitto or somewhere to do ?

Hi,
After a short desperation and a bit of debugging i found out that the user, if you don't specify it during setup, is not 0 but "undefined", so the displayed password is wrong.
This is also the case if the user string is too long (or similar?).

Sincerely,
Dominic

Hi bytespider,

First of all, congrats for this amazing work. I'm a huge fan of meross devices and currently I use a few of them with MQTT and Nodered for IoT stuff.

In my current implementations, I'm always using the same messageId, with the same sign and timestamp, and I would say I haven't had a problem for doing that (of course, those values are not random, are based on a valid verification to be sure the device does not reject the http request. I forgot to mention that all 'input' interactions I do with the devices are based on http requests.

So my question is...what is the different between using a new generated messageId, etc. per call versus using the same again and again?

Best regards!

Hi,
I just bought a new MSS310 and followed your instructions to get this device working in LAN without pairing to the cloud. Your tools worked fine and the device is also usable by HA. I can switch and get usage Information. The only issue is that the LED keeps blinking green (fast) if the switch is on. When it is turned off, the LED is off, too.
According to the manual, the LED should be simply green.

Hardware: 2.0.0
Firmware: 2.1.16

Do you have any hint on this?

Hi!

First at all, what a great work setting these Meross devices cloud-free! Thanks a lot!

Unfortunately I tried your setup script on a Meross Power Strip and it seemed to work. My powerstrip now is linked to my access point (green light blinking quickly forever), and connects to my mosquitto server, but I only get loads of lines like this:

1637259948: Socket error on client <unknown>, disconnecting.
1637259951: New connection from 192.168.1.122 on port 1883.
1637259951: Socket error on client <unknown>, disconnecting.
1637259954: New connection from 192.168.1.122 on port 1883.
1637259954: Socket error on client <unknown>, disconnecting.
1637259957: New connection from 192.168.1.122 on port 1883.

The command I used is this:

npx meross setup --gateway 10.10.10.1 --wifi-ssid WLAN_XX --wifi-pass XXXXXXXX --mqtt mqtt://192.168.1.15

No password or certificates implied.

My device is identifies as mss425e eu MT7687 (hardware:1.0.0 firmware:1.1.9)

Do I need the user and password your tool shows in mosquito configuration?

After upgrading an ms110 switch to firmware 7.3.19 using meross-setup without a user and key setup results in an error.

The user (as returned from meross-info is the MAC address of the device. Trying to set this as the user in meross-setup results in the app trying to interpret the string as an integer which then fails validation.

I'm using a a MSS310 mss210 un mt7682 (hardware:2.0.0 firemwa:2.1.16)
My HomeAssistant is operating on a Raspberry pi 4 b, along with the MQTT server plugin.

The config for this is:

logins: []
customize:
  active: false
  folder: mosquitto
certfile: server.crt
keyfile: server.key
require_certificate: false
allow_anonymous: true
cafile: ca.crt

I've added a new user as per your instructions: https://github.com/bytespider/Meross/wiki/Home-Assistant-(HASSIO)

When this starts up it indicates that it can find the SSL certs, so I believe I've put them in the correct location on the pi. I feel my issue is either the certificates have not been generated correctly or perhaps something else is misconfigured.

This is the output of generating the Self Signed Cert:

william@fuel-ubuntu:~/ssl$ openssl genrsa -des3 -out ca.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
..+++++
.............................................................................................................................................................................................................................................+++++
e is 65537 (0x010001)
Enter pass phrase for ca.key:
Verifying - Enter pass phrase for ca.key:
william@fuel-ubuntu:~/ssl$ openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
Enter pass phrase for ca.key:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:Western Australia
Locality Name (eg, city) []:Perth
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Home
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:ha
Email Address []:
william@fuel-ubuntu:~/ssl$ openssl genrsa -out server.key 2048
Generating RSA private key, 2048 bit long modulus (2 primes)
............................................................................................+++++
..............+++++
e is 65537 (0x010001)
william@fuel-ubuntu:~/ssl$ openssl req -new -out server.csr -key server.key
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:WA
Locality Name (eg, city) []:Perth
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Server-cert
Organizational Unit Name (eg, section) []:test
Common Name (e.g. server FQDN or YOUR name) []:192.168.2.103
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
william@fuel-ubuntu:~/ssl$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360
Signature ok
subject=C = AU, ST = WA, L = Perth, O = Server-cert, OU = test, CN = 192.168.2.103
Getting CA Private Key
Enter pass phrase for ca.key:
william@fuel-ubuntu:~/ssl$ scp ca.crt server.crt server.key [email protected]:/ssl/
ca.crt                                                                                                                          100% 1289     1.1MB/s   00:00
server.crt                                                                                                                      100% 1192     1.3MB/s   00:00
server.key                                                                                                                      100% 1675     2.1MB/s   00:00
william@fuel-ubuntu:~/ssl$

From the output you can see the HA is running on 192.168.2.103, which is what I've used for the CN of the server cert and I've explicitly used a different CN for the CA, as I've seen you've suggested this as a potential issue.
I've also not provided any value for the challenge password.

This is the setup command I'm sending to the Smart Socket:

./bin/meross setup --wifi-ssid 'Tribe Of Bruce' --wifi-pass '<some password>' --mqtt mqtt://192.168.2.103

This seems to connect to the wifi correctly and tries to establish a connection to the MQTT broker, but this is the output:

1622612400: New connection from 192.168.2.48 on port 1883.
1622612400: Client <unknown> disconnected due to protocol error.
1622612408: New connection from 192.168.2.48 on port 1883.
1622612408: Client <unknown> disconnected due to protocol error.
1622612427: New connection from 192.168.2.48 on port 1883.
1622612427: Client <unknown> disconnected due to protocol error.
1622612444: New connection from 192.168.2.48 on port 1883.
1622612444: Client <unknown> disconnected due to protocol error.
1622612508: New connection from 192.168.2.48 on port 1883.
1622612508: Client <unknown> disconnected due to protocol error.
1622612610: New connection from 192.168.2.48 on port 1883.
1622612610: Client <unknown> disconnected due to protocol error.
1622612798: New connection from 192.168.2.48 on port 8883.
401: Unauthorized1622612799: Socket error on client <unknown>, disconnecting.
1622612829: New connection from 192.168.2.48 on port 8883.
1622612829: Socket error on client <unknown>, disconnecting.
1622612876: New connection from 192.168.2.48 on port 1883.
1622612876: Client <unknown> disconnected due to protocol error.
1622612894: New connection from 192.168.2.48 on port 1883.
1622612894: Client <unknown> disconnected due to protocol error.
1622612903: New connection from 192.168.2.48 on port 1883.
1622612903: Client <unknown> disconnected due to protocol error.
1622612923: New connection from 192.168.2.48 on port 1883.
1622612923: Client <unknown> disconnected due to protocol error.
1622612978: New connection from 192.168.2.48 on port 1883.
1622612978: Client <unknown> disconnected due to protocol error.
1622613045: New connection from 192.168.2.48 on port 1883.
1622613045: Client <unknown> disconnected due to protocol error.
1622613188: New connection from 192.168.2.48 on port 1883.
1622613188: Client <unknown> disconnected due to protocol error.
1622613202: New connection from 192.168.2.48 on port 1883.
1622613202: Client <unknown> disconnected due to protocol error.
1622613214: New connection from 192.168.2.48 on port 1883.

If I try using mqtts://192.168.2.103 as the --mqtt value, the device simply goes back into configuration mode.

Any help with this would be greatly appreciated, really love the work you've done with your tooling.

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'
}

I'm not sure what I'm doing wrong, but watching the Mosquitto log, I keep seeing the device connect, subscribe, publish a few times, and disconnect. I have over 60 different Meross switches that I will eventually all pair to my home assistant, but only after I can reliably control one.

Mosquitto version:

  mosquitto version 2.0.14 starting

Config:
port 8883

require_certificate false
use_identity_as_username false
allow_anonymous true

capath /etc/mosquitto/certs

# replace with your CA Root and server certificate and key paths
cafile /etc/mosquitto/certs/mqtt_ca.crt
certfile /etc/mosquitto/certs/mqtt.crt
keyfile /etc/mosquitto/certs/mqtt.key

persistence true
persistence_location /var/lib/mosquitto/

log_dest file /var/log/mosquitto/mosquitto.log
log_type all

include_dir /etc/mosquitto/conf.d

Log:

1650919713: New connection from 192.168.1.171:54012 on port 8883.
1650919713: New client connected from 192.168.1.171:54012 as fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (p1, c1, k120, u'48:e1:e9:43:e9:bc').
1650919713: No will message specified.
1650919713: Sending CONNACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (0, 0)
1650919713: Received SUBSCRIBE from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb
1650919713:     /appliance/2012317778118925583748e1e943e9bc/subscribe (QoS 1)
1650919713: fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb 1 /appliance/2012317778118925583748e1e943e9bc/subscribe
1650919713: Sending SUBACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb
1650919713: Received PUBLISH from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (d0, q1, r0, m3, '/appliance/2012317778118925583748e1e943e9bc/publish', ... (347 bytes))
1650919713: Sending PUBACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (m3, rc0)
1650919713: Received PUBLISH from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (d0, q1, r0, m4, '/appliance/2012317778118925583748e1e943e9bc/publish', ... (731 bytes))
1650919713: Sending PUBACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (m4, rc0)
1650919720: Received PUBLISH from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (d0, q1, r0, m5, '/appliance/2012317778118925583748e1e943e9bc/publish', ... (731 bytes))
1650919720: Sending PUBACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (m5, rc0)
1650919726: Received PUBLISH from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (d0, q1, r0, m6, '/appliance/2012317778118925583748e1e943e9bc/publish', ... (731 bytes))
1650919726: Sending PUBACK to fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb (m6, rc0)
1650919732: Received DISCONNECT from fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb
1650919732: Client fmware:2012317778118925583748e1e943e9bc_bVUplGdeu4lGBUtb disconnected.
1650919736: New connection from 192.168.1.171:54013 on port 8883.

Hey bytespider,

I have been fighting with this for past few days but still unable to connect to my WiFi using the ./meross setup command. I ran packer capture on my WiFi interface no DHCP requests there or even a single packet from the device, seems like its not able to connect at all. Any ideas?

Hey @bytespider,

First off, just wanted to thank you for all the work you've put into this project, and to documenting it. I've already learned a ton!

I'm trying to control a light bulb (MSL120) while running a local (i.e. custom mosquitto) broker, but I can't get the light to respond to messages I'm sending it.

I've followed the instructions in the Wiki.

I set up the certificates using the exact commands in the Wiki:

$ openssl genrsa -des3 -out ca.key 2048
$ openssl req -new -x509 -days 1826 -key ca.key -out ca.crt

$ openssl genrsa -out server.key 2048
$ openssl req -new -out server.csr -key server.key

$ openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 360

For the Common Name in the CA cert, I used my name.
For the Common Name in the server cert, I used the local IP of my broker.

I'm using the minimal unauthenticated config from the Wiki:

port 8883

allow_anonymous true
require_certificate false

# replace with your CA Root
cafile ../certs/ca.crt

# replace with your server certificate and key paths
certfile ../certs/server.crt
keyfile ../certs/server.key

I ran the following and my light bulb seemed to connect:

$ ./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://<BROKER_IP>

When I ran the mosquitto broker and the above meross setup command, this was the output:

$ mosquitto -c /path/to/mosquitto.conf -v
1652914301: mosquitto version 1.5.7 starting
1652914301: Config loaded from /path/to/mosquitto.conf.
1652914301: Opening ipv4 listen socket on port 8883.
1652914301: Opening ipv6 listen socket on port 8883.
1652914304: New connection from <DEVICE_IP> on port 8883.
1652914304: New client connected from <DEVICE_IP> as fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (c1, k30, u'<DEVICE_MAC>').
1652914304: No will message specified.
1652914304: Sending CONNACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (0, 0)
1652914304: Received SUBSCRIBE from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG
1652914304:     /appliance/<DEVICE_UUID>/subscribe (QoS 1)
1652914304: fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG 1 /appliance/<DEVICE_UUID>/subscribe
1652914304: Sending SUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG
1652914304: Received PUBLISH from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q1, r0, m28, '/appliance/<DEVICE_UUID>/publish', ... (396 bytes))
1652914304: Sending PUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (Mid: 28)

Then, from my client, which is a different machine, I ran the following to try to turn the light bulb off:

$ mosquitto_pub -h <BROKER_IP> -p 8883 -t "/appliance/<DEVICE_UUID>/subscribe" --cafile ~/path/to/ca.crt -m '{"header":{"from":"/app/724729-005b295660494850b26e7cfb594e4ad8/subscribe","messageId":"a83255cd8160bb9ff12ec39b90befdf3","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"d8d18b831228cba6f992fa7a745577c4","timestamp":1652912578},"payload":{"togglex":{"channel":0,"onoff":0}}}'

When I send that message, I get this in the broker logs:

1652914307: New connection from <CLIENT_IP> on port 8883.
1652914307: New client connected from <CLIENT_IP> as 10135219-a366-4f28-a06d-ae0cdf257496 (c1, k60).
1652914307: No will message specified.
1652914307: Sending CONNACK to 10135219-a366-4f28-a06d-ae0cdf257496 (0, 0)
1652914307: Received PUBLISH from 10135219-a366-4f28-a06d-ae0cdf257496 (d0, q0, r0, m0, '/appliance/<DEVICE_UUID>/subscribe', ... (324 bytes))
1652914307: Sending PUBLISH to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q0, r0, m0, '/appliance/<DEVICE_UUID>/subscribe', ... (324 bytes))
1652914307: Received DISCONNECT from 10135219-a366-4f28-a06d-ae0cdf257496
1652914307: Client 10135219-a366-4f28-a06d-ae0cdf257496 disconnected.
1652914307: Received PUBLISH from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q1, r0, m29, '/app/724729-005b295660494850b26e7cfb594e4ad8/subscribe', ... (335 bytes))
1652914307: Sending PUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (Mid: 29)

From all appearances, it looked like it worked, but the light bulb does not turn off.

I'm hoping you might be able to help me figure out what I'm doing wrong. It's probably some stupid little thing.
Thanks!

From the README:

Before you can use the tool to setup your device you need to put it into paring mode and connect to it's Access Point. It's IP address is known as the --gateway parameter and is typically 10.10.10.1.

I recently paired a device and was confused by --gateway (it's been a long time since I paired something). The README mentions that this parameter is its IP address.

Which IP address, exactly?

• is this the address of the access point, and I will get an appropriate IP upon joining the AP SSID? (in which case I should never need it)
• or is this the IP address of the paired device? (once it has rebooted and joined my own network). I used it in that context to get information about an existing and running device:

PS > node .\bin\meross-info --gateway 192.168.10.183

Getting info about device with IP 192.168.10.183
(then comes the table with the device info)

Very interested in your work , any chance it works with mss100 and other Meross plugs ?

I seem to have tried everything in guides around the interwebs to convince my Meross(?) device to connect to my Home Assistant MQTT broker. The reason I put (?) is because I'm not entirely convinced it's a Meross but it presents itself in that way. The WiFi SSID for setup is Meross_SW_XXXX and ./meross info seems to work just fine. However, it displays an MSS560m model, which I couldn't find on the Meross website, neither visually nor by model number. Only places I could find selling a Meross MSS560m are Ali Express and Alibaba. The switches were present when I moved in so I have no history on them :)

With the history out of the way, here's my meross setup command & output:

./meross setup --wifi-ssid '<SSID>' --wifi-pass '<PW>' --mqtt mqtts://192.168.1.<HA>
Setting up device with IP 10.10.10.1
┌────────────────────────────────────┬────────────────────────────────────────────────────────┐
│MQTT broker                         │192.168.1.<HA>:8883                                     │
├────────────────────────────────────┼────────────────────────────────────────────────────────┤
│MQTT broker                         │192.168.1.<HA>:8883                                     │
└────────────────────────────────────┴────────────────────────────────────────────────────────┘
┌─────────────────┬───────────────────────────────────────────────────────────────────────────┐
│Device           │mss560m us mt7682 (hardware:3.0.0 firmware:3.1.6)                          │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│UUID             │<REDACTED>                                                                 │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│Mac address      │<MAC>                                                                      │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│WIFI             │ (<MAC>)                                                                   │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│MQTT broker      │192.168.1.<HA>:8883                                                        │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│Status           │Online                                                                     │
├─────────────────┼───────────────────────────────────────────────────────────────────────────┤
│Credentials      │User: 0                                                                    │
│                 │Password: 0_<MD5(MAC)>                                                     │
└─────────────────┴───────────────────────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────────────┬────────────────────────────────────────┐
│Encoded WIFI SSID                                   │<REDACTED>                              │
├────────────────────────────────────────────────────┼────────────────────────────────────────┤
│Encoded WIFI password                               │<REDACTED>                              │
└────────────────────────────────────────────────────┴────────────────────────────────────────┘

After running the command, the switch does indeed restart and goes right back into pairing mode (with the pairing WiFi still available).

I've validated that the MQTT broker at 192.168.1.<HA>:8883 is available by sending a message with mosquitto_pub, but it does use a custom ca cert. I've read Meross switches don't validate CAs so I'm hoping that's not a tripping point. The broker will accept anonymous messages (as long as I give the ca cert to mosquitto_pub), but it does seem to reject with Connection error: Connection Refused: not authorised. if I use the verbatim -u '<MAC>' -P '0_<MD5(MAC)>'. I did read in #12 that Home Assistant will do some user encoding before passing on the username, so I'm hoping this is a non-issue, but would like to verify what a good mosquitto_pub u/P would be to sanity check whatever username/password the switch attempts using will actually publish to my local broker.

I also noticed a fair bit more logging / debugging data in #12 - is there any way to enable that level of logging for the info/setup tools? Couldn't parse it out of the JS source, but maybe I missed something.

What's my logical next steps to figure out what's going on here?

So, today I tried setting up a new Meross MSS510 switch using the local only MQTT setup. I first attempted running the npx meross info command after connecting to the switches WiFi. While it was attempting to pull the switch information it toggled the switch on/off a couple of times and then just timed out. I ran with the verbose option and got this 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: '483cdbd7553e6dacfd6fe1ecb2de5e8f',
    timestamp: 1652554693,
    sign: '2df1f5d866c518eb3de9171ddb614132'
  },
  payload: {}
}

(node:3996662) UnhandledPromiseRejectionWarning: TypeError [ERR_INVALID_ARG_TYPE]: The "url" argument must be of type string. Received undefined
    at validateString (internal/validators.js:120:11)
    at Url.parse (url.js:159:3)
    at Object.urlParse [as parse] (url.js:154:13)
    at new URL (/home/tnolte/.npm/_npx/3996214/lib/node_modules/meross/lib/api.js:6:35)
    at logRequest (/home/tnolte/.npm/_npx/3996214/lib/node_modules/meross/lib/api.js:62:15)
    at handleRequestError (/home/tnolte/.npm/_npx/3996214/lib/node_modules/meross/lib/api.js:99:13)
    at API.deviceInformation (/home/tnolte/.npm/_npx/3996214/lib/node_modules/meross/lib/api.js:204:13)
    at processTicksAndRejections (internal/process/task_queues.js:97:5)
(node:3996662) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 2)
(node:3996662) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

I didn't having any problem with the Meross Smart Plug (MSS110) that I was initially testing with. I ended up just setting up the switch through the Meross app and got it added via Meross LAN the normal way. Is this switch not supported for some reason?

From the Meros app this is the details for the device:

• Model Number: mss510x
• Firmware Version: 3.2.2
• Hardware Version: 3.0.0

mss210 us rtl8710cf (hardware:6.0.0 firmware:6.1.12) not working with mosquito. The plug goes tries to connect to the internet but fails. I hear to clicks. First when the led changes flashing green and later going back into pairing mode.

my mosquitto conf is;
`port 1883
listener 8883
#use_username_as_clientid true
allow_anonymous true
capath /etc/ssl/certs

certfile /etc/mosquitto/certs/mqtt_server.pem
keyfile /etc/mosquitto/certs/mqtt_server.pem

tls_version tlsv1.1
My command:./meross setup --gateway 10.10.10.1 --wifi-ssid XXX --wifi-pass XXX --mqtt 192.168.2.201 --key XXX --mqtt 192.168.2.206

Setting up device with IP 10.10.10.1
┌────────────────────────────────────────────────┬────────────────────────────────────────────┐
│Primary MQTT broker │192.168.2.201:1883 │
├────────────────────────────────────────────────┼────────────────────────────────────────────┤
│Failover MQTT broker │192.168.2.206:1883 │
└────────────────────────────────────────────────┴────────────────────────────────────────────┘
┌────────────────────┬────────────────────────────────────────────────────────────────────────┐
│Device │mss210 us rtl8710cf (hardware:6.0.0 firmware:6.1.12) │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│UUID │2012174007893251804648e1e9425940 │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│Mac address │48:e1:e9:42:59:40 │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│IP address │10.10.10.1 │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│Current MQTT broker │192.168.2.201:1883 │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│Credentials │User: 48:e1:e9:42:59:40 │
│ │Password: 0_952716e80f5c54ff4493465156d32aa0 │
├────────────────────┼────────────────────────────────────────────────────────────────────────┤
│MQTT topics │Publishes to: /appliance/2012174007893251804648e1e9425940/publish │
│ │Subscribes to: /appliance/2012174007893251804648e1e9425940/subscribe │
└────────────────────┴────────────────────────────────────────────────────────────────────────┘
`
Form mosquitto when trying to sub the plug (sudo mosquitto_sub -d -t "/#" --cafile /etc/mosquitto/certs/mqtt_server.pem):
Client mosqsub|12810-PlatoPi sending PINGREQ
Client mosqsub|12810-PlatoPi received PINGRESP

This is from the log: (sudo tail -f /var/log/mosquitto/mosquitto.log)
New client connected from 192.168.2.50 as fmware:20040808158569251h3748e1e9197500_uBD0TymGUdnTTzoZ (c1, k30, u'48:e1:e9:19:75:00').
1629319822: Socket error on client mosqsub|12433-PlatoPi, disconnecting.

Thank you for helping =)

First of all many thanks for you efforts!

I bought two 3-sets from the MSS310 plugs and while one set works very well with your instructions, the other 3 don't. I run the „Meross setup „ command and everything looks good, but when the plug reboots it can’t connect to the WiFi (flashes green very long and then re-enters config mode).

I'm quite sure, that this is related to different hardware versions (2.0.0 vs.1.1.18).

I'm just wondering whether you already know this, or maybe there is someone around who knows a solution.

I attached the output of "meross info..." for both versions.
1_InfoFromMerossScript.txt
2_InfoFromMerossScript.txt