A complete meross integration guide

[Ostepanov]

How to configure MQTT and enroll Meross devices in your Home Assistant

Preamble

The main idea of this guide is gather and simplify all steps to enroll meross devices, because all existent manuals don't give all information about it, and simply doesn't work because of bugs in MQTT 6. That's why I'll explain all installation process and show how to do it. From 0 to hero.
Steps in configuration process:

• Install Ubuntu, using windows 10 WSL
• Configure and install all necessary packages
• Create SSL certificates
• Remove MQTT6 and install MQTT5 with all necessary configuration
• Enroll Meross devices

What do you need before start

• A laptop with wifi
• Home Assistant server
• A bit of free time

Installing and configuring Ubuntu on laptop with WiFi

• Install ubuntu on your windows 10 laptop using this manual:
  https://ubuntu.com/wsl
• launch ubuntu, update it and install necessary packages using these commands:

apt-get update
apt-get upgrade
apt install npm
npm install commander
npm install uuid

the last ones we need to make work meross scripts correctly

Create SSL Certificates using previously installed Ubuntu

First, create a key for the CA
openssl genrsa -des3 -out ca.key 2048
Create a certificate for the CA using the CA key that we created
openssl req -new -x509 -days 1826 -key ca.key -out ca.crt
Now we create a server key pair that will be used by the broker
common name is important and should be IP address of HA.

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

Create a client private key.
openssl genrsa -out client.key 2048
Create a certificate request and use the client private key to sign it.
Use the same common name which you used when creating a server key pair
openssl req -new -out client.csr -key client.key
Create a client certificate
openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 360

Now you can open windows explorer accesing to your Ubuntu virtual disk writing:
\\wsl$\your_installed_Ubuntu\home\your_username
Copy these certificates to a folder in your desktop:

• ca.crt – The Certificate authority certificate
• client.crt – The client certifcate file
• client.key – The client private key
• server.crt - Server certificate
• server.key - Server key

Preparing Home Assistant and installing MQTT 5 broker

Before you copy anything to your HA - remove the existing add-on and restart HA (hard reboot (Reboot Host) from Supervisor/System)!

Fetch an older version of the component

Direct link:
https://github.com/home-assistant/addons/archive/14cbbc63fcc33ae698c00c136421729694b964a3.zip
You should end up with a zip archive with the repo name and commit.
Extract the folder and fetch only the files you need - mosquitto folder in addons for MQTT Broker.

Install Samba Share addon and create username and password for it

Now you can copy previosly downloaded mosquitto folder to your HA using file explorer:
\ip of your HA\addons
After that, its necesary to open config.json in folder and change name parameter to Mosquitto broker 5
IMPORTANT! You need to copy your SSL certificates created earlier, in a folder:
\ip of your HA\share\SSL
Now you need to create a folder mosquitto in \ip of your HA\share
It should be like that: \ip of your HA\share\mosquitto
Inside of it, create two files:
accesscontrollist (no extention) and mosquitto acl.conf

After that, open both of them with text editor like notepad or notepad++ and put
In accesscontrollist:

topic readwrite #
pattern readwrite #

In mosquitto acl.conf:
acl_file /share/mosquitto/accesscontrollist

Installing MQTT 5 in HA

After copying all necessary files, you should reboot your HA.
After reboot, in supervisor/addons-store will appear Mosquitto broker 5 as local add-on.
Now you can install it, and use this configuration:

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

Now you have a full functional MQTT broker. Don't forget to disable auto updates.

Enrolling Meross devices

At this point, we should have mqtt5 already installed and working with ssl certificates.
For this step, we need to use our Ubuntu, as we did for generate SSL certs.

• Download meross-master from github
  https://github.com/bytespider/Meross
  Direct link:
  https://github.com/bytespider/Meross/archive/refs/heads/master.zip
• open windows file explorer and copy Meross-master files to \wsl$\your_installed_Ubuntu\home\your_username
• in ubuntu use commands:

cd Meross-master\bin
sudo chmod u+x meross-info
sudo chmod u+x meross-setup
sudo chmod u+x meross

• connect to WIFI network of your MEROSS device and execute this script:
  sudo ./meross-info
  You will see all info about your device. save it to any txt file. Just in case.
  IMPORTANT! create user with same username and password (which you get from device using ./meross-info) in your HA and reboot HA
  If necessary, you can disconnect from device's WiFi and connect to it on next step
• When usernames in HA are created and server restarted, you can execute this script:
  sudo ./meross-setup --gateway 10.10.10.1 --wifi-ssid your ssid name --wifi-pass your wifi pass --mqtt mqtt://yourhaip:8883

Now your device should connect to your WiFi and mqtt broker.

UPDATE:
After seeing that device is connected to mqtt broker you need to:

• Add integration Meross Lan indicating ip of your device. I recommend to add a static IP for each meross device
• Set timezone and mode auto in meross lan integration for each meross device.

Now you are done

Special thanks to:
@bytespider, @dyordan1, @krahabb
You've made the best tools and helped a lot to all home assistant community, making our lives easier
Links:
bytespider/Meross#28
http://www.steves-internet-guide.com/creating-and-using-client-certificates-with-mqtt-and-mosquitto/

[Ostepanov]

Hi @krahabb !
Can you add this manual to wiki page of your addon? Because there are still a lot of people who don't know why their devices not connecting to HA and how make them work.
If necessary, you can make any change in it.
Thanks

[krahabb]

Thank you very much @Ostepanov,
I guess I'll have to start a proper wiki sooner than later since I've delayed this too much. I'll be happy to use your 'paperwork' for that, just a couple of days until I'm 'back on track' with the integration (actually on vacation ;)

[homonto]

That guide is amazing
However, some issues at the stage of executing meros-info:

sudo ./meross-info 
internal/modules/cjs/loader.js:638
   throw err;
   ^

Error: Cannot find module 'uuid4'
   at Function.Module._resolveFilename (internal/modules/cjs/loader.js:636:15)
   at Function.Module._load (internal/modules/cjs/loader.js:562:25)
   at Module.require (internal/modules/cjs/loader.js:692:17)
   at require (internal/modules/cjs/helpers.js:25:18)
   at Object.<anonymous> (/home/parallels/ha/Meross-master/lib/api.js:12:15)
   at Module._compile (internal/modules/cjs/loader.js:778:30)
   at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10)
   at Module.load (internal/modules/cjs/loader.js:653:32)
   at tryModuleLoad (internal/modules/cjs/loader.js:593:12)
   at Function.Module._load (internal/modules/cjs/loader.js:585:3)

any help would be more than appreciated ;-)
thank you

[homonto]

Sorted out by command:

npm install uuid

;-)

[bytespider]

Probably better to just npm install then you get all package dependencies. Or use npx meross info and npx meross setup

[homonto]

all right - my Meross sockets are now ok - PERFECT guide! thank you

however there is quite a big issue and maybe you can help with that
the link to add ons you provided brings Mosquitto 5.1.1 and - as per this link - https://community.home-assistant.io/t/mosquitto-5-1-1add-on-is-broken/286979/19 - this version is total disasters - majority of MQTT clients are not working
I am trying to find out the link to 5.1 or anything else but apparently I am not able to do so - could you share the link please?

[homonto]

that is what I thought ;-(
ping please when you are done ;-)

[Ostepanov]

@kr0ner Thank you for mentioning where should be be certificates and @homonto to check it out!
I've added this information to guide

[homonto]

;-)

[kr0ner]

@homonto PING
the docker images are there 🥳
I've also added an option (verbose_auth) to enable verbose logs from the auth_plugin

[homonto]

round-trip min/avg/max/stddev = 8minutes

;-)

• can I stop the MQTT 5.1 , disable autostart, install MQTT SQLite and test without uninstalling?
• do I need to do anything with config or keep vanilla?
• certs needed or nothing ?

thx

[yagrasdemonde]

Hello,

Question : How can I follow this guide or adapt it when Home Assistant (core-2021.8.8) installed in Docker container in Synology Diskstation, and also, with eclipse-mosquitto:openssl image in Docker container ?
I would appeciate some helps to integrate my meross devices with mqtt and not http.
Thank you very much

[Ostepanov]

Hi @yagrasdemonde
You mean that you have HA and mqtt broker separated?
I think you can use this guide almost completely, except mqtt downgrading part.
Mqtt configuration should be the same: anonymous enabled, ssl enabled, usernames and passwords from devices added to mqtt configuration

[JartX]

yes, have 13 MSS310 working with mqtt mosquitto 5.1 because 6 is broken, also have msl120dr with rtl chipset working with mqtt but the problem is: msl120d eu MT7686 (hardware:4.0.0 firmware:4.1.8) that chipset and firmware dont say anything to mqtt, your addon not is the problem, the problem is the device

[homonto]

yes, have 13 MSS310 working with mqtt mosquitto 5.1 because 6 is broken

we are testing MQTT 6.x with SQL instead of files for password - I shall see if it works (others already confirmed it does) - but I have only 12 pieces ;-)

[JartX]

Excuse me, I did not want to sound obscene, but I have many meross products working with meross lan, even light bulbs, but a particular model of light bulb does not work :(

[nao-pon]

I share my experience.

I have Hass.io (Home Assistant OS 6.2) installed on my Raspberry-pi.

The MQTT broker has the MQTT broker installed by Supervisor.

Some (older) Meross devices will fail to authenticate with a certificate created with the Let's Encrypt or DuckDNS add-on, so you will need to create and use a self-signed certificate using the method described here.

If you feel that the "-days 360" option is too short, you can make it as long as you like.

Currently, the official MQTT broker add-on is 6.0.1. If you want to use this official add-on, you need to create an HA user for each Meross device. The username is the MAC address of the Meross device. The password can be obtained with the bytespider/Meloss setup command.

I have multiple Meross devices connected and I don't like to add them to HA users. So I configure it using the "logins:" option of the MQTT broker add-on, which is not available with the official MQTT broker add-on 6.0.0 and above. There are currently two options for using it.

1. Use the official MQTT broker add-on 5.1.1
2. Use kr0ner/mosquitto listed in PR #2137 (SQLite version)

If you have a backup using the official MQTT broker add-on than before, I think it's better to use it.

If you choose 2., you can install it by adding the custom repository "https://github.com/kr0ner/mosquitto" to your supervisor's add-on store. Or you have the option of waiting for the PR to be accepted.

If you are already using the official MQTT broker add-on, you will need to perform the following steps to enable the MQTT broker add-on for your custom repository.

1. Install SQLite version
2. Copy official add-on (5.1.1) settings to SQLite version
3. Back up the official add-on (5.1.1)
4. Uninstall official add-on (5.1.1)
5. Remove MQTT integration
6. Launch the SQLite version
7. Configure MQTT integration
8. Restart HA

[userMak]

@nao-pon
Hi, right now I have the 5.1.1 MQTT broker (I haven't update to 6.0.0) and I have created a HA user for each Meross device. (I have 8 devices) - (my problem is that although all meross devices are working of the switches blinking red)

Do you know if it will be enough to just create and use a self-signed certificate using the method described here?

My main problem is that I use HAs MQTT broker for other integrations too (which are working fine) and I am afraid if I do something wrong that I will brake all the other integrations too.

[nao-pon]

@userMak Yes, I was the same.

It looks like it's working fine because it's working in http mode. However, since it is not operating in mqtt mode, changes to the Meross device (such as On / Off) are not immediately reflected in HA. Since this is detecting the state by http polling, there will be a maximum polling interval time lag.

In my experience, I created my own self-certified certificate and used it to connect to mqtt and everything worked fine.

I also use mqtt in Tasmota, but it's not a TSL connection (1883 port) so it wasn't affected.

Also, the relatively new Meross device (mss110 5.0.0 --firmware 5.1.1) was able to connect with the certificate created by DuckDNS, but there is no problem even after switching to the self-signed certificate.

[nao-pon]

P.S. I set the expiration date for both ca.crt and server.crt to 100 years later (-days 36500). ;-)

Also, don't forget to set the FQDN correctly to the HA local IP address for the question.

[userMak]

hi
hope someone is here to help me a bit.
I am trying to create my personal CA files and probably did something wrong because I am at the step which I have to copy the below files in my desktop but I only have 3 of them? I don't have the clients?

ca.crt – The Certificate authority certificate
client.crt – The client certifcate file
client.key – The client private key
server.crt - Server certificate
server.key - Server key

Can I start over again? Is there something else I can do?

[userMak]

no it is not good. I found this
`The .key file is probably your PRIVATE key

The .csr file is a CERTIFICATE REQUEST probably signed with your private key

What you need is probably a .crt : a certificate corresponding to your csr signed by a certificate authority (or self signed, depending what you want to accomplish)

node (like another web server) is supposed to ask you 3 thing : - your private key - the certificate - the certificate chain, eventually, depending of the certificate

What you can do is open with a text editor the different files, and see if you see the certificate inside:

you should see things like -----BEGIN CERTIFICATE----- or -----BEGIN PRIVATE KEY----- or -----BEGIN CERTIFICATE REQUEST----- , that will told you the exact content of the files.`

[userMak]

@homonto
hi are you here?

common name is important and is usually the domain name of the server.
what am I suppose to place here? I gave the address of HA and mosquito broker eg 192.168.1.13
is that correct?

[homonto]

I gave: mydomain.duckdns.org

[userMak]

without https. right?

[homonto]

true, certs are not only for http - it can be for email as well so yes, without http

[userMak]

well, (I think) I did the crt files

I copy them to ssl folder of HA
I changed the configuration file as the example
restarted HA (glad that it opens)
BUT the broker won't start
I get the following

[s6-init] making user provided files available at /var/run/s6/etc...exited 0. [s6-init] ensuring user provided files have correct perms...exited 0. [fix-attrs.d] applying ownership & permissions fixes... [fix-attrs.d] done. [cont-init.d] executing container initialization scripts... [cont-init.d] done. [services.d] starting services [services.d] done. [20:47:23] INFO: Setup mosquitto configuration [20:47:23] INFO: No local user available [20:47:23] INFO: Initialize Home Assistant Add-on services [20:47:23] ERROR: Can't setup Home Assistant service mqtt [20:47:23] INFO: Initialize Home Assistant discovery [20:47:23] INFO: Start Mosquitto daemon 1630086443: Error: Unable to open include_dir '/share/mosquitto'. 1630086443: Error found at /etc/mosquitto.conf:33.

edit: If I change the config file like it was before the broker (and my rest devices) are working.
logins: []
anonymous: false
customize:
active: false
folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false

Can anyone help?

[homonto]

(I don't remember Windows really but):
1- open the notepad or some editor like this
2- put this there:
acl_file /share/mosquitto/accesscontrollist
3- save it as: acl.conf
4- save in the folder /share/mosquitto
5- new file: put there:

topic readwrite #
pattern readwrite #

6- save it as: accesscontrollist - no extension!
7- save it in /share/mosquitto
8- that should be it
9- make sure there is no extra extension like txt or so (I am not sure how Windows behaves - I did not use for last 20 years)

[userMak]

F@^(
It has been fixed!! Everything is working and the red blinking stopped!!
THANKS!!!!

[Ostepanov]

@userMak Perfect!
Can you tell us, which exactly step fixed your issue?

[homonto]

@userMak Perfect!
Can you tell us, which exactly step fixed your issue?

that is easy: he killed my "movie evening" yesterday ;-)
just kidding - but I am happy I was able to help - finally not only I was looking for help but could help someone else ;-)

[userMak]

Sorry for that @homonto. Your help was decisive!

@Ostepanov
I followed the steps homonto proposed 1 - 7 and end up with the following (with the notepad)

in mosquitto config I add
logins: []
anonymous: true
customize:
active: true
folder: mosquitto
certfile: server.crt
keyfile: server.key
require_certificate: false
cafile: ca.crt

As I said last night I already was with Mosquitto 5.1.1 and had configured all the users in Home Assistant

So it worked with a restart...

If someone needs any clarifications please ask (and I hope I can help too)

Thanks again both of you!

[Ostepanov]

DO NOT UPDATE YOUR DEVICES!!! AFTER MEROSS UPDATE V6.1.10, CONFIGURATION UTILITY IS NOT WORKING ANYMORE
After last update for all meross devices, configuration utility stopped working.
Do not update your devices until @bytespider can fix it

[homonto]

thanks for info but I hopped once I integrated with Meross LAN and configured with my MQTT server, the Meross company has NO ACCESS to my sockets anymore, no?

[Ostepanov]

thanks for info but I hopped once I integrated with Meross LAN and configured with my MQTT server, the Meross company has NO ACCESS to my sockets anymore, no?

False alarm. Sorry. I'm too retarded to check out if my ssid name was correct

[homonto]

;-)

[krahabb]

thanks for info but I hopped once I integrated with Meross LAN and configured with my MQTT server, the Meross company has NO ACCESS to my sockets anymore, no?

You should be right @homonto , Meross is not accessing your devices. To be honest we would need a 'monitor/sniffer' to be sure traffic between any device and the manufacturer is totally off.
At any rate, even without any 'independent confirmation', I'm (pretty;) sure my devices are not communicating with anyone else since they're fully isolated (If I can trust my router that's it) and work without any internet connectivity right now

[homonto]

if I knew how to use wireshark... ;-)
there are few ways they could address sockets (I think) by any server that is in sockets:

• using IPv6 of sockets - if router assigns IPv6
• or built in IPv4 that is assigned from vendor's pool (highly unlikely - who would pay for it?)
• or MAC address somehow?

I seriously don't have this knowledge - I was "sick" in the school when they were teaching us this ;-)

[jaytea33]

Finally got this working! Thanks to everyone who had a hand in this. Wow, hurdle after hurdle and it took about 20 hours but it was all worth it. My MSG100 is now completely under my control with MQTT only. Hopefully these tips help someone else:

1. Don't downgrade to MQTT5 and just use kr0ner's SQLite Mosquito fork https://github.com/kr0ner/addons/tree/kr0ner_mosquitto_sqlite
2. On the Ubuntu environment, replace the existing /lib/api.js file with the one here: https://github.com/hnakai0909/Meross/blob/patch-1/lib/api.js - I also had to upgrade nodejs to the latest v16, as both Ubuntu and Ubuntu LTS come with v6 and I kept getting errors.
3. If you upgraded to 3.2.3 firmware and need your device key, you can refer to the solution by franza83 to trick the device into giving it you: MSG100 (garage opener) stopped working after a firmware update (3.2.3) #43 - note that when you add it to meross_lan via MQTT at the very end, the device key will be blank.
4. The MAC Address as a regular HA user doesn't seem to work. I had to put it in the Mosquitto config "logins" section. I used MQTT Explorer in Windows to confirm my certs were valid and it only authenticated successfully once I put it in the Mosquito config. I then deleted the user from HA since it wasn't needed and left my main MQTT user in the HA config. This makes sense since the SQLite fork is taking care of the colon problem introduced with MQTT6.
5. When creating the certs, use the MQTT broker's IP address for the Common Name on the Client and Server certs. Note that you don't have to fill in all the fields like Organization and whatnot, you can leave them blank and leave out the "extra attributes" as well.

Good luck everyone!

[kr0ner]

On the Ubuntu environment, replace the existing /lib/api.js file with the one here: https://github.com/hnakai0909/Meross/blob/patch-1/lib/api.js - I also had to upgrade nodejs to the latest v16, as both Ubuntu and Ubuntu LTS come with v6 and I kept getting errors.

Seems that this is not necessary. It is a fork of @bytespider's repo and is 0 commits ahead.

My bad ... github app always selects master when you click on a link -_-

[fajrstartr]

Hi, i have noob question.

How exactly do i use kr0ner's SQLite Mosquito fork.
Should i download something from that page an copy in addons?

Thanks

[Topolynx]

Hi. I haven’t still tried to follow your guide @Ostepanov, but I’ve followed the @bytespider ‘s one without success: I’ve tried its “minimum unauthenticated” mosquitto configuration but once configured my plug (mss310) didn’t connect to my local MQTT.
I would like to go on with your guide but I have HA Core installed, so I really don’t understand well what should I do.
Could you - or someone else- help me please? I will be very grateful to you, the situation of my Meross plugs at home is really explosive, I suffer of hundreds disconnections from the Meross server every day since a week (said my lan - wan are ok), can’t stay more with my devices linked to the damn Meross server…

[krahabb]

Hello @Topolynx !
welcome aboard the MQTT bandwagon ;)
if yo're not on HASSIO and would like/need to setup your mosquitto have you tried following https://github.com/krahabb/meross_lan/wiki/Mosquitto-Mon-Amour
I've tried to streamline a mosquitto-homeassistant(core) installation based mainly on @bytespider work.
Check it out

[Topolynx]

Hi @krahabb !
Yep I read only now your wiki...
As soon as I'll back at home I will try to follow your guide...

[Ostepanov]

Hi @Topolynx which version of mqtt are you using?

[Topolynx]

@Ostepanov I suppose that my version is 2.0.11 as reported by Portainer

VERSION	2.0.11
DOWNLOAD_SHA256	7b36a7198bce85cf31b132f5c6ee36dcf5dadf86fb768501eb1e11ce95d4f78a
GPG_KEYS	A0D6EEA1DCAE49A635A3B2F0779B22DFB3E717B7
LWS_VERSION	4.2.0
LWS_SHA256	a57e9a4765dbcd4d880feba8089b43ed69995eaf10d5d61a07981d9ddd975f40
CJSON_VERSION	1.7.14
CJSON_SHA256	fb50a663eefdc76bafa80c82bc045af13b1363e8f45cec8b442007aef6a41343

[userMak]

Hi everyone. Surprisingly everything still works fine with the new setup. :)
I would like to ask IF and WHENever we will be able to update the Mosquitto broker from 5.1.1 to a new version that works with our setup to let us know if possible.
Thanks

[yagrasdemonde]

Hi, I am completely lost... I have been trying to connect my garage opener (MSG100) to MQTT for 2 days.

Unfortunately, I will soon have no more hair ..... 😀

I followed this guide, but no success …

Environment

HomeAssistant is installed on a Synology NAS in docker, accessible via the address 192.168.1.5:8123

MQTT is also in docker, with the eclipse-mosquitto:openssl

The docker was created with the command

sudo docker run --name=mqtt -itd --restart=always --net=host -v /volume1/docker/mqtt/config/ssl:/mosquitto/certs -v /volume1/docker/mqtt/config:/mosquitto/config -v /volume1/docker/mqtt/data:/mosquitto/data -v /volume1/docker/mqtt/log:/mosquitto/log -v /volume1/docker/mqtt/config/mosquitto.conf:/mosquitto/config/mosquitto.conf eclipse-mosquitto:openssl

The MQTT server has the address 192.168.1.5:1883
(I am working with a MacBook Pro with Big Sur)

This is my mosquito.config file

persistence true
persistence_location /mosquitto/data
log_dest file /mosquitto/log/mosquitto.log
log_timestamp_format %Y-%m-%dT%H:%M:%S
#Main
per_listener_settings true
#Default
listener 1883 192.168.1.5
allow_anonymous true
password_file /mosquitto/config/pwfile
#Meross
listener 8885 192.168.1.5
require_certificate false
allow_anonymous true
capath /mosquitto/config/ssl
cafile /mosquitto/config/ssl/ca.crt
certfile /mosquitto/config/ssl/server.crt
keyfile /mosquitto/config/ssl/server.key

Certificates generation

This is what I did in terminal

openssl genrsa -des3 -out ca.key 2048

   => Passphrase ca.key = MYPASSWORD

openssl req -new -x509 -days 1826 -key ca.key -out ca.crt

   => Country Name =
   => State or Province Name =
   => Locality Name =
   => Organization Name =
   => Organizational Unit Name =
   => Common Name = GaMa
   => Email Address =

openssl genrsa -out server.key 2048

openssl req -new -out server.csr -key server.key

   => Country Name =
   => State or Province Name =
   => Locality Name =
   => Organization Name =
   => Organizational Unit Name =
   => Common Name = 192.168.1.5
   => Email Address =
   => A challenge password =

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

openssl genrsa -out client.key 2048

openssl req -new -out client.csr -key client.key

   => Country Name =
   => State or Province Name =
   => Locality Name =
   => Organization Name =
   => Organizational Unit Name =
   => Common Name = 192.168.1.5
   => Email Address =
   => A challenge password =

openssl x509 -req -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -days 3650

Then, I put these files in the ssl folder of the mqtt docker.

I started the mqtt server and here is the log

2021-09-11T19:49:49: mosquitto version 2.0.12 starting
2021-09-11T19:49:49: Config loaded from /mosquitto/config/mosquitto.conf.
2021-09-11T19:49:49: Opening ipv4 listen socket on port 1883.
2021-09-11T19:49:49: Opening ipv4 listen socket on port 8885.
2021-09-11T19:49:49: mosquitto version 2.0.12 running
2021-09-11T19:49:49: New connection from 192.168.1.5:56137 on port 1883.
2021-09-11T19:49:49: New client connected from 192.168.1.5:56137 as zigbee2mqtt (p2, c1, k60, u'max').
2021-09-11T19:49:50: New connection from 172.17.0.3:53052 on port 1883.
2021-09-11T19:49:50: New client connected from 172.17.0.3:53052 as mqttjs_87334f47 (p2, c1, k60, u'max').
2021-09-11T19:49:55: New connection from 192.168.1.39:32940 on port 1883.
2021-09-11T19:49:55: New client connected from 192.168.1.39:32940 as mqttjs_f6bae740 (p2, c1, k60, u'max').
2021-09-11T19:49:57: New connection from 192.168.1.5:56665 on port 1883.
2021-09-11T19:49:57: New client connected from 192.168.1.5:56665 as home-assistant (p2, c1, k60, u'max').
2021-09-11T20:06:06: mosquitto version 2.0.12 terminating
2021-09-11T20:06:06: Saving in-memory database to /mosquitto/data/mosquitto.db

(The 2nd client 172.17.0.3 is a vacuum robot and the 3rd 192.168.1.39 client is the latter's card.)

The home-assistant and zigbee2mqtt clients are well connected to the MQTT server.

Garage door connecting

I downloaded meross-master https://github.com/bytespider/Meross

Then I put the device into pairing mode (Yellow/Green alternating) and connect to it's AP (Meross_MG_F72D Wifi network).

I execute the command

./meross info

I get

Device => msg100 us MT7686 (hardware:4.0.0 firmware:4.1.14)
UUID => XXXXXXXXXXXXX72d
Mac address => 48:XX:XX:XX:XX:2d
IP address =>
Credentials =>
	User: 48:XX:XX:XX:f7:2d
	Password: 0_170f7eb3044af42f0054befe6beb62b5
MQTT topics =>
	Publishes to: /appliance/XXXXXXXXXXXXX72d/publish
	Subscribes to: /appliance/XXXXXXXXXXXXX72d/subscribe

I create a new user with the same username and password in home assistant, and restart the home assistant server.

Then I run the command:

./meross setup --gateway 10.10.10.1 --wifi-ssid MyWifi_SSID --wifi-pass my-password-wifi --mqtt mqtt://192.168.1.5:8883

I get

Primary MQTT broker  => 192.168.1.5:8883
Failover MQTT broker => 192.168.1.5:8883
Device => msg100 us MT7686 (hardware:4.0.0 firmware:4.1.14)
UUID => XXXXXXXXXXXXX72d
Mac address => 48:XX:XX:XX:XX:2d
IP address =>
Current MQTT broker => 192.168.1.5:8883
Credentials =>
	User: 48:XX:XX:XX:XX:2d
	Password: 0_170f7eb3044af42f0054befe6beb62b5
MQTT topics =>
	Publishes to: /appliance/XXXXXXXXXXXXX72d/publish
	Subscribes to: /appliance/XXXXXXXXXXXXX72d/subscribe

The device reboot.
The device led is still blinking green, and I have no new client connection in the mqtt server log.

So I'm here. My Meross device is visible on my local network (ip address of the type 192.168.1.196) but not in mqtt.

And so I still tried to add the device in the Meross Lan integration of home assistant, I can add it but it works only in http and not in mqtt, and the led of the device always flashes in green.

I am at your disposal to solve my problem Thank you in any case

[krahabb]

It would be nice to have someone testing (by raw sniffing the TCP traffic) this devices in order to know whats wrong. I guess they're not so different in classic mqtt protocol behaviour and it's maybe a very simple fix that needs to be added.
One thing coming to mind is the mqtt server TLS signature which, in older devices, is not checked against so, every simple self-signed certificate for the MQTT broker would work. Maybe, these homekit upgraded devices are stricter on this side.
At the moment I have no homekit devices to test so I can't really help.

A first 'easy' step for the volunteers would be to enable super verbose logging on mosquitto (I don't know how and the implications!) and see if anything comes up at the broker when trying to pair these devices.

[timnolte]

@krahabb I'll have to see if I can do some sniffing, I may need to pickup another Meross device that has HomeKit support to also do some testing on. To a degree I have my devices in state where they are functional, just not setup how I want though, and I hate messing around with them and breaking things for the rest of the family. I know it's not going to necessarily be apples-to-apples with a different model device but it still might glean something. These newer HomeKit devices seem to generally have issues with most of the Meross libraries/apps so there seems to be something common.

I'm curious about the certificate aspect. Right now I've got my IoT network setup to use external DNS only so no internal-only domains will resolve, however I'm using the Nginx SSL Proxy & Let's Encrypt with a domain name I have setup in Cloudflare so I have a valid certificate on my HA when accessed locally however devices on the IoT network can't use that domain name to access HA, I have to use the IP address only. This results in certificate validation failures because the LAN IP address is not in the certificate. I won't go into why I have my network setup this way as it's not relevant to the topic.

When I get a bit more time I'll have to see if I can try to get some more details and help figure out how we need to handle this newer hardware. I suspect this will only begin to be a growing problem for anyone newer to Home Assistant & smart home that starts using Meross devices. The only reason I have mss510 & mss110 devices that aren't HomeKit compatible is that I got them as a cheap deal as a set on Amazon, probably like a clearance thing since there is probably more demand for the newer HomeKit compatible devices. Other than a couple of Macs we are pretty much a non-Apple house(Android devices, Chromebooks, Google devices), so I could care less about HomeKit. I'm actually pretty annoyed that I have to deal with these stupid HomeKit Controller devices showing up in HA to be honest. Maybe I'm just being a bit too anti-Apple and should be open to leveraging the built-in HomeKit support in HA. Maybe that would be a better solution for these Meross devices that are HomeKit compatible and not working MQTT. I personally like the stability and the pub/sub features of MQTT which is why I'm also using Zigbee2MQTT.

Anyways, sorry, I get long winded as I'm thinking through all of this stuff. I'll try to find time in the next few weeks to dig into this some more and report back anything more I can find out.

[krahabb]

I guess I could say more or less the same about my feelings on the matter. Luckily enough I don't have any homekit stuff around (kind of a 'respectful Apple ban')
Nevertheless, as you said, going the homekit way might be wiser for the matter. I don't know how stable it is, nor how stable the meross implementation is too. But, from what I know, it is local and it works more or less plug and play so that should be a good foundation to build up. Why not?

As for the mqtt broker certificate setup I remember I built mine (self signed and with the local ip of the broker set in the CN field of the certficiate according to most of the guides around setting up mosquitto for meross devices) and everything worked but that was on 'legacy' devices.

I agree all of this is growing hard but, for a starter, I'd just try to get the most out of the mosquitto logs. If there's any issue with certificates or any other compatibility layer (say TLS version or so) this would show up. At least, knowing the device is at least trying to reach the configured local broker would be a point.

[ggggh]

Did you have a chance to investigate on the Homekit-compatible versions? I'm stuck with one and don't really want to use it unless on local mqtt. The tools can't seem to be able to update it, but interestingly there is a default open webpage on 10.10.10.1 which seems to allow uploading firmware to it.

[krahabb]

I'm sorry @ggggh but I don't have any Homekit device to be able to do some tests on it (nor I'm planning to buy any)

[jaytea33]

I noticed that despite my MSG100 being connected to Meross LAN via MQTT only, my router was being spammed with outbound requests by the device (I block the WAN Outbound at the router level). I figured this likely had to be NTP, so I went back into the Meross LAN config and took off the "Device Time Zone" I had set so that it's now left blank. After doing so, the device is no longer spamming packets trying to reach outside of my network and is restricted only LAN the way I want. So if you want to use your Local NTP such as Chrony, it seems that "Device Time Zone" area should be left blank.

[krahabb]

Hello @jaytea33 ,
thank you for sharing your insights about devices behaviour.
The device TimeZone feature was specifically added to address power metering plugs reporting power usage 'x day' and they needed that info to correctly align to your own timezone.
The feature is there for any device so far but, it is surely safe to disable (blank) it since the device don't really need to be aware of the absolute local time in order to work.
Nowadays, with new 'energy platform' in HA it would not be needed even for power metering plugs but it shouldnt be harmful anyway.
It is interesting to know this and maybe further investigate it but there is probably no solution beside 'blanking' the TimeZone configuration.
Maybe this piece of knowledge could anyway prove helpful in the future

[jaytea33]

Appreciate the confirmation, krahabb - good to know that it won't cause any issues 'blanking' the TimeZone because it's working great since I did that. Loving the addon!

EDIT: I spoke too soon; the device is still reaching for NTP via the WAN even with the TimeZone blanked in meross_lan. I checked my router again and I've confirmed it's definitely NTP. I was able to get this info from my router's firewall logs:

Source Port: 61910
Destination Port: 123

NTP IPs and Names obtained via Traceroute:
204.93.207.12 tick.chi1.ntfo.org
162.248.241.94 ns1.backplanedns.org
209.94.190.139 network190-139.c1d.net

If outbound UDP port 123 is blocked, the MSG100 tries like its life depends on it to connect to NTP, spamming the router with packets that it's set to drop.

I've now set a rule to allow only outbound UDP port 123 for the time-being and with this configuration, the MSG100 only requests about roughly once every hour.

At this point I'd consider it an issue since it's technically not restricted to just LAN due to the internet-dependent NTP requirement.

UPDATE: I suspected maybe the timezone wasn't 'blanked' properly when I cleared the setting and that it's still holding onto whatever was set previously. I enabled the debug tracing and it confirmed what I suspected - it's still seeing my timezone as "America/Los_Angeles" despite the field being empty. I switched it to "US/Pacific" and reloaded the integration (not sure if necessary), then rebooted HA, and debug tracing reflected "US/Pacific." I then cleared the timezone setting again and did the same thing - reloaded the integration, rebooted HA, enabled debug tracing, and it showed US/Pacific. So I suppose the real issue is that once you set a timezone you can't clear the timezone. Is there a way to clear this setting? I suppose I could always reinstall the integration but it took so long to get this stable that I'd rather mess with it as little as possible.

Debug logs attached
msg100-1632092798.csv
msg100-1632093061.csv
msg100-1632093469.csv
.

I'll open an issue on the Issue section.

[fajrstartr]

ERROR: Can't setup Home Assistant service mqtt is killing me

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] done.
[services.d] starting services
[services.d] done.
[23:23:31] INFO: Setup mosquitto configuration
[23:23:31] INFO: Found local users inside config
[23:23:32] INFO: Initialize Home Assistant Add-on services
[23:23:32] ERROR: Can't setup Home Assistant service mqtt
[23:23:32] INFO: Initialize Home Assistant discovery
[23:23:32] INFO: Start Mosquitto daemon
1653859412: Loading config file /share/mosquitto/acl.conf
1653859412: mosquitto version 1.6.3 starting
1653859412: Config loaded from /etc/mosquitto.conf.
1653859412: Loading plugin: /usr/share/mosquitto/auth-plug.so
1653859412: |-- *** auth-plug: startup
1653859412: ├── Username/password checking enabled.
1653859412: ├── TLS-PSK checking enabled.
1653859412: └── Extended authentication not enabled.
1653859412: Warning: ACL pattern '#' does not contain '%c' or '%u'.
1653859412: Warning: ACL pattern '#' does not contain '%c' or '%u'.
1653859412: Warning: ACL pattern '#' does not contain '%c' or '%u'.
1653859412: Warning: ACL pattern '#' does not contain '%c' or '%u'.
1653859412: Opening ipv4 listen socket on port 1883.
1653859412: Opening ipv6 listen socket on port 1883.
1653859412: Opening websockets listen socket on port 1884.
1653859412: Opening ipv4 listen socket on port 8883.
1653859412: Opening ipv6 listen socket on port 8883.
1653859412: Opening websockets listen socket on port 8884.
1653859412: Warning: Mosquitto should not be run as root/administrator.
1653859412: New connection from 192.168.50.148 on port 1883.
[23:23:33] INFO: [INFO] found homeassistant on local database
1653859413: New client connected from 192.168.50.148 as mqtt-explorer-99f8b9bc (p2, c1, k60, u'homeassistant').
1653859414: New connection from 192.168.50.197 on port 1883.
1653859414: New client connected from 192.168.50.197 as 5ASCH9n06cetGgJchaAmc5 (p2, c1, k60, u'homeassistant').

[Ostepanov]

Hello @fajrstartr You need create a user in HA which hase the same username and password which you obtain with ./meross-info

[timnolte]

@ggggh I haven't purchased a test only HomeKit device yet so I haven't been able to do any testing. Basically, I've resorted to setting up my 3 HomeKit devices with both MerossLAN and HomeKit in Home Assistant. I end up having to choose which version of the device in HA I'm going to build an automation on, which I've chosen HomeKit for now. To be clear you can pair HomeKit devices with HA without Apple. I have no Apple devices to configure HomeKit so I'm just relying on the local HomeKit support in HA.

[mdisabato]

At the end of the guide, way back at the beginning of this thread, @krahabb states:

After seeing that device is connected to mqtt broker you need to:
Add integration Meross Lan indicating ip of your device. I recommend to add a static IP for each meross device
Set timezone and mode auto in meross lan integration for each meross device.

I have been messing with this for a couple days now and cannot figure out how to do both of those, specifically set a static IP in the Meross device (MSS110). I can get everything else to work.

Thank you.

[krahabb]

Hello @mdisabato,
That guide was not 'super' correct since when you pair devices to your MQTT broker (that's what this thread is for) meross_lan doesnt need any IP configuration and 'just' discovers the devices automatically. Moreover, for devices discovered over MQTT meross_lan doesn't even allow you to re-configure the IP address (unless HA also receives a valid DHCP message for the device MAC address..at that point the intgeration knows it can manage an IP address and allows you to do so)

So in the end:

• If you're able to pair your devices to local MQTT: forget about IP configuration in meross_lan and just 'wait' until devices get discovered
• If you cant or dont want MQTT re-pairing, manually add a device and enter the IP address of the device together with the device key

[mdisabato]

Hello @krahabb,

Thank you for your reply. I am relatively new to MQTT, but not IT and networking in general. A quick read of the MQTT standard and a couple of websites showed me where I went wrong. MQTT is an application-layer protocol like HTTP. I don't know why I got wound up thinking it was lower level than that. Part of the confusion may be the Node-RED Meross nodes need an IP address, and if that address changes, it stops working. Hence the perceived need for static IPs. I'm thinking this isn't quite right.

As far as the configuration tool, I have the certificates installed and the tool installed, but the MacBooks I'm using can't connect directly to the MSS110's. I will be reconfiguring one of the Raspberry Pis I have to see if that will. If not, I'll have to use the Meross app to get them on line.

Thank you for your help. I love these communities!

[Write]

Hello, I just managed to connect to my mosquitto broker my three MSS310, they work perfectly, but they are still blinking "green".
Anyway I added them to meross_lan, and disabled the DND led, but still. I wonder why it's blinking Green, I'm thinking issue may arise because of that.

I think it's some sort of setup that couldn't be"finished" on the plug side ?

Thanks alot .

[krahabb]

I'm not sure this is the case but isn't the green blinking when it is trying to connect to wifi?
This is maybe different among versions of the device but it should be that

[bytespider]

I believe it can also happen if the broker doesn't send a response message when first paired bytespider/Meross#57 (comment)

[krahabb]

@Write,
As per the comment from @bytespider this reminds me it was addressed in meross_lan (i.e. the code should be able to reply to the 'binding' message from the device)
At any rate, you could start a diagnostic trace and see if the binding transaction has been fullfilled (like here)

You should be able to see the Appliance.Control.Bind SET request from the device and a corresponding SETACK sent from meross_lan (or just post the trace here for me to inspect:)

To be honest, there's another part of the transaction which is not managed at all and it is about the Appliance.System.Report PUSH message. In my setup on local mqtt with mss310, msl120 (smart light), msh300 (smart hub) it appears only the msh300 is pushing this message and it isn't replied (I did some tests in the past and they were unsuccesful) by meross_lan. I don't know if my msh300 is blinking though since it is hidden in the general mains distribution block ;)

[Tuin344]

Whist looking for LAN only Meross integration I stumbled on this solution. However, running MQTT 5.1.1 without getting massive problems with other MQTT integrations is something that worries me. Just wondering if 2 years later one is still expected to install this very old version? Don't want to sound like a total bitch, but shouldn't this integration be made 6.2 compatible by now?

[krahabb]

Hello @Tuin344 ,
no worries, as far as you don't offend anyone ;) (and you're not!)

The MQTT protocol level compatibility problem (if any) is between the devices and the broker so it is the device mqtt client stack that should be updated to the latest MQTT features (I hardly think this will be the case). In that regard, I'm not expert of MQTT/Mosquitto, but I guess you will always be able to setup a proper (maybe dedicated listener) configuration for whatever Meross mqtt protocol level even if this is not the freshiest MQTT standard.

On the other side meross_lan uses the HA mqtt broker component so it works 'out of the box' at this level.

A different issue is about the 'application level' protocol management (and this thread might mix issues related to really different problems like the transport layer or the application one)

As an example, the blinking green LED, could either be a network issue (wifi not connecting or whatever) between the device and the LAN or (likely in this latest posts) an application level protocol misbehavior..

[fireheadman]

excuse my question if this has been previously asked.... (was hoping to find the answer in the original post).
Does the MEROSS LAN integration supersede/replace the need for running the Meross Local Addon (broker) and Meross Integration (hacs) ?

I've been pulling my hair out with which path to take.

[krahabb]

I don't really know all of the features of that component stack (Meross local addon and Meross integration) but the philosophy is the same: i.e. allowing to control the Meross devices (almost) only locally. I can't say which is better since they're both mantained and current. Again, I (as mantainer of meross_lan) don't know the level of features and implementation of the other component stack but I've sometimes digged into that code to understand 'this and that'
So yes they're alternative:
meross_lan uses the default HA mqtt component in the scenario where you want to bypass the Meross cloud.

In either stack, in order to use a local/private broker you have to 'manually' pair your devices to this broker so they're not using the offical cloud infrastructure.

Both stacks however can work locally (on HTTP) on 'officially paired' devices thus not using MQTT at all or, if configured so, using the Meross cloud brokers

A quick 'usage cases' list for meross_lan:

• devices officially paired (Meross app): local only connectivity (side by side) to devices via HTTP (need to retrieve the device key from the cloud account in order to configure but there's a function in place that allows you to do so by entering meross account user/pwd)
• devices officially paired (Meross app): local (HTTP) and cloud (MQTT) connectivity by configuring your Meross account in the component
• devices privately paired (to your own broker): both HTTP and MQTT protocol connection to the devices

[fireheadman]

That answer is more than expected. Thank you very much for being explaining the details! It does clear the waters to know which components are meant to work together. I'm most interested in the simplest and most effective solution to manage devices within home assistant.

As side note, Alberto just mentioned his code is now affected by a recent api login change, unsure if this will impact your code as well?

[fireheadman]

This need better explanation....

Now you can copy previosly downloaded mosquitto folder to your HA using file explorer:
\ip of your HA\addons
After that, its necesary to open config.json in folder and change name parameter to Mosquitto broker 5
IMPORTANT! You need to copy your SSL certificates created earlier, in a folder:
\ip of your HA\share\SSL
Now you need to create a folder mosquitto in \ip of your HA\share

I'm using the supported OS = Debian 12 with docker (HA Supervised) installation.

HA by default is installed under /usr/share/hassio/homeassistant
Trying to follow the above snippet I get lost and unsure if maybe it used to exist in this place and has changed??
Here is a tree structure of the "addons" directory which is being mentioned to copy mosquitto v5 into.... however I do not see any of my other addons at this level.

Should it maybe be placed under "data" directory instead? When I placed mosquitto into the addons directory and rebooted, nothing was seen in HA for the addon.

[fireheadman]

Can disregard the previous posts....

I was able to get this working with the default MQTT addon (v6.3.1)
All that was needed was the Meross Lan integration and a macbook (or linux if you have that).
I am running HA Supervised on Debian 12 (bookworm) in docker. This is a standard build using the HA install script.

Steps taken:
Created the SSL server with cmds in OP
sudo mkdir /usr/share/hassio/ssl/mqtt (created separate dir as to not mix up certs from other addons)
sudo mkdir /usr/share/hassio/share/mosquitto (created the accesscontrollist and acl.list files in here from OP)
In UI, made it look like this...

Then started up the default MQTT addon and viewed the logs to see it was all good and ready for connections... (my insecure connections came in immediately (sonoff plugs)

Did a reboot of entire server (HA physical server)

MSG100 --> plugged in device via usb to a powered hub, made sure it was blinking green/amber
my macmini is hardwire to internet, so used my wifi radio to attach to the meross ap signal
NOTE: I had to fiddle around with homebrew on macos sonoma to get node at version 18, then installed the npm (commander, uuid, and meross) extensions. Once this got working I was able to get the devices configured.

npx meross info -g 10.10.10.1

NOTE: Had to add the user/passwd to HA first, else the device would keep resetting to default for unknown reasons...
Take the mac addr and password and create a local only user in HA (Users)
check the "Can only log in from the local network" and Display Name can be anything you want

npx meross setup --gateway 10.10.10.1 --wifi-ssid xxxxxxx-IoT --wifi-pass xxxxxxxxxx --mqtt mqtts://192.168.4.xxx:8883

can verify the ip addr a couple way...
I was able to look up the mac addr in my unifi console, then started an active ping to it
Can also check the mosquitto logs

2023-11-01 22:22:49: New connection from 192.168.4.xxx:60679 on port 8883.
2023-11-01 22:22:50: New client connected from 192.168.4.xxx:60679 as fmware:220523xxxxxxxxxxxxxxxxxxxxxx_44g5sxxxxxxxxxxxl (p1, c1, k120, u'48:xx:xx:xx:xx:xx').

npx meross info -g 192.168.4.xxx

Unplugged the USB device and plugged back in for hard reboot to verify it held its data/ip info
NOTE: It will still continue to blink green
Went over to Integrations in HA and saw this...

Once you configure it, the led will become solid green

Its online, but noticed the firmware is not updated...

If you go back to the meross lan integation, click the Configure and select the "auto" for connection protocol so you can fall back to http or mqtt... I did not have to set a device key in any of the screens, every function is working too.
NOTE: Oddity, noticed once I upgraded the firmware, the option to set the TimeZone goes away.
UPDATE: After restarting HA and still on the older firmware, the TimeZone field is now gone so might be something with the Meross Lan integration???

**I personally think there is some value to first adding these devices into the Meross phone app first to get firmware and any other settings in place. Then reset them and add into HA.

Hopefully this helps others.

[krahabb]

Awesome! This is a very clear procedure to setup Meross devices to fully work locally in the 'standard' HA environment with the default mqtt addon and using the @bytespider utilities.
Issues and troubles have been reported in the years for this setup but in my opinion they are (or were) related to 'evolving' mosquitto configuration and the corresponding HA mqtt addon but in general the setup should really be stable right now.

As for the device key, in this setup, unless you explicitly use a different default with the @bytespider utility, the devices are configured with an empty ("") key so meross_lan, accordingly, works out of the box with the same default/empty key

Finally, the timezone setting:
meross_lan only shows the option in configuration if it 'knows' the device supports it (historically all of them have it) and it recognizes the device as actively connected through the local mqtt.
This notion of beeing locally mqtt paired is not 'well known' in meross_lan (i.e. it is not configured) since it is instead dynamically detected during the normal device interaction. This can lead to times (or better, transient times) where meross_lan cannot assure itself the device is locally mqtt paired and so it doesn't show the timezone configuration option.
In this example, maybe, the mqtt connection with the device was not (yet or again) active at the moment of the meross_lan device configuration UI popping up.
The reason behind this is the fact that when devices are Meross cloud paired, they receive the timezone configuration from the cloud and I've (historically) preferred to not mess with that (the timezone set feature is by the way under review in the current development so things may change in coming releases)

[fireheadman]

Slight update for what I posted above... little sleep has me back at it with more thoughts.
I deleted my 2nd device from HA (then restarted HA) and added it with the Meross phone app (iphone)... no need in going through that process here as it is very intuitive/easy.

Now back in HA, I have this available in integrations...

So this fetched my device key for me...

At this point, the MSG100 is connected to both HA (Meross Lan) and Meross Cloud. I can operate them from each app.
Looking at the overview of Meross Lan, can tell a difference in how it adds them...
The local only displays the UUID (Can rename this in options menu)
The cloud only displays the name pulled from Meross Cloud
And for whatever reason, my email address is pulled for some type of placeholder??

Clicking Configure next to my email address shows this...
I have 1 device left to add so will no upgrade the firmware in the iphone App to see if HA can perform this task for me.???

Clicking the Configure next to the Cloud device now has the device key stored in it.. (all I did here was enable the auto for connection protocol)

Next steps would be to migrate the Cloud connected MSG100 to be MQTT. Will use the commands performed in last post to do this.
NOTE: I had to hold the reset button down for 10 seconds. This erases all configuration from the device and removes the connection to the Meross Cloud once MQTT is configured to use the HA MQTT Broker.
Also, will need to record the device id and delete the device from HA, then restart HA
Now will see this in Integrations area (and again, unsure why the one on the left is present... It is wanting to verify the DeviceID from Meross Cloud, but the cmd to pull it into local severed the connection.)

========================
So here is my issue.
I have 2 devices configured to communicate with MQTT, I see the connection status in the logs.
I then deleted ALL devices in HA for Meross LAN, then restarted HA.

Now I see 2 devices wanting to be configured.
Each wants its Device ID.
When I insert the Device ID that was retrieved from Meross Cloud (in previous steps), it fails and asks to retry (Device key error
The provided key is wrong. Choose an option)
If I leave the ID part blank, then it adds the device (without DeviceID)
The device will functions fine.
If I force the Connect Protocol to MQTT, the device stops responding, so it only works on http mode.

Something seems amiss here
What can I help you with the figure out why the Device ID will not be accepted?

[bytespider]

I could be wrong here @krahabb will have to verify, but Device ID/Key is synonymous with --key in my tools

[fireheadman]

you are correct.... I was able to use this command to reprogram an existing msg100 to use my mqtt without needing to reset it.

npx meross info -g 192.168.4.xxx -k 6c16xxxxxxxxxxxxxxxxxxxxxx
npx meross setup --gateway 192.168.4.xxx --wifi-ssid xxxxxxxx-IoT --wifi-pass xxxxxxxxxxx --mqtt mqtts://192.168.4.xxx:8883 -k 6c16xxxxxxxxxxxxxxxxxxxxxx

but also ran into an issue where it decided to reset the IP back to 10.10.10.1.

[bytespider]

I can only imagine that would happen if it reset itself into factory pairing mode.

[fireheadman]

correct, this could just be a network blip or bad transmit on a packet causing it to enter a failsafe and reset to save itself. Most of the time it works flawlessly.

[krahabb]

There is a bit of confusion in terms here:

Each wants its Device ID.
When I insert the Device ID that was retrieved from Meross Cloud (in previous steps), it fails and asks to retry (Device key error
The provided key is wrong. Choose an option)
If I leave the ID part blank, then it adds the device (without DeviceID)
The device will functions fine.

What you call 'Device ID' is the 'device key' (better clarify since devices also have an ID which is sometimes reported as device UUID and is the device identifier)

The behavior you see is correct: the 'device key' is a parameter set/configured in the device and used to validate message communication. Any software that wants to communicate with the device needs to know this. It is configured when the device is paired so this is what happens:

• pairing with Meross App: the device is configured with a secret key, which is generated once when you create your Meross account and stored there. So, when you want to communicate with devices which are 'Meross paired' you need to use this very same key. If you're in trouble knowing this key value, meross_lan offers you to read this key from your Meross account by entering proper username/pwd in UI and then showing you the retrieved key
• pairing with npx meross setup: the device is configured with a key you can provide on the command line: by default it is "" (somewhat empty)

In meross_lan you can (or have to) configure the device key for each device, even if it appears as redundant (99% of the times your devices will always have the same key) since this parameter might be different among devices: think about some are 'Meross bound' and some are 'local MQTT bound'. Also, you could add devices from different Meross accounts (say you'd want to control your grandma plugs too;) or, when using npx meross setup you'd want each device to have a different key....

As for what are the different HUBS shown in the integration UI I guess I'd need to expand the wiki but a quick short explanation would say:
There are 3 different types of HUB(s) in meross_lan

• Device: this is the configuration of each device. Being it over HTTP or MQTT (local or cloud), you have one for each known Meross device. They are discovered either by DHCP, local MQTT, or by queryng the Meross cloud profile or, if you know the IP address you can manually add your entry
• Meross cloud profile: this is the configuration allowing to query your Meross cloud profile infos and allows meross_lan to use (cloud) MQTT to connect to 'Meross bound' devices. This is also used to periodically query/discover the list of cloud devices, retrieve their name, check for updates (the update is not carried on though). It also helps you in setting the device key for a discovered device since, as previously said, this key is stored in the cloud account. You can add more of this if you want to connect devices from more accounts. This entry, finally, establishes and control the connection to the cloud MQTT. Without it, you can still control your 'Meross bound' devices over HTTP (provided they have the right key) but you completely loose cloud MQTT.
• MQTT Hub: this is a special type of entry created automatically whenever meross_lan detects a Meross device over HA MQTT. This is useful to help HA MQTT discovery in case you use npx meross setup with a different key than empty. In fact, if you decide to set a custom key when you locally bind your device, meross_lan needs to know this in order to correctly and automatically identify the device. If not (i.e. meross_lan doesn't know the proper key) the discovery process would be 'less automated'

[fireheadman]

Firmware shows up (when it is avaialable).... pending you have it configured to use the Meross Cloud MQTT connection

Doesn't actually do anything, perhaps the app could have more info in the UI for this.
Reviewing the logs I see that it is not yet supported and to use the Meross Phone App instead
2023-11-02 11:00:51.515 WARNING (MainThread) [custom_components.meross_lan] MerossDevice(Garage - Cottage): MLUpdate(update.garage_cottage_update_firmware) The firmware update feature is not (yet) available: use the Meross app to carry the process

I will keep one of my devices behind incase you need a tester when you get this working

[fireheadman]

had a slight change of plans... ended up returning the meross devices for now.
they do work great, but found out 1 of my garage openers was not compatible and I would rather have all using the same technology instead of confusing my family to use APP1 for these doors and APP2 for those doors.

[Hamishsw]

I found this repo while searching for a how I would get power usage monitoring in HA for my just purchased MSS315 plugs. My HA is running in a Raspberry PI and I only have Mac computers.
The front page of this repo provides steps for adding the integration in HA but is there a guide for Mac users on how I can get the integration available for install? Any plans to make this integration available within the add integration search without other setup/install steps?
Thanks

[krahabb]

Hello @Hamishsw,
The easiest way to add this integration would be through HACS, and this way it's almost as easy as a 'regular' integration: you just install the component from the HACS UI and restart HA

Adding meross_lan to the official HA integrations is something I've never considered since I've always thought HACS was enough...I might consider this though and see what effort is required to comply with those "official" integrations

Thank you for your thoughts!

[Hamishsw]

Great thanks. I got this working with your suggestions. Many thanks!

[jcxldn]

Hi all, I'm having an issue with local MQTT brokers on Meross LAN v4.4.1. Up until I set the mqtt address, everything works as expected (both over meross' mqtt and over HTTP), but when I switch it to use a local mqtt broker, the device reboots, HA picks it up and starts talking over MQTT, but then after 10-15 seconds the device resets itself (flashing green and amber).

I am using the non-HomeKit Smart Plug Mini. (MSS305, MSS305KITUK v8.0) Interestingly this device does not broadcast an AP and instead uses Bluetooth and the Meross app for setting up the wifi network.

I am using the following command to set the MQTT broker:

./meross setup --wifi-ssid "<ssid>" --gateway <device ip> --mqtt mqtt://<mqtt ip>:8883 -k "<key>" -v --wifi-pass <wifi password> --use-wifi-x

If I don't use the WiFi-X parameter the debug logs show the password encoded in base64 but with an extra '%' on the end of the password after decoding, so the device does not connect to the network upon a reboot.

I also tried updating to firmware 8.3.10 (the latest at the time of writing), but this did not help.

Many thanks and thank you for this project,
James

[krahabb]

Hello @jcxldn,
the issue might lie in the 'meross setup' utility since many things are changing lately.
But maybe the utility is working ok and the device rightly connect to the broker but then, the application protocol initialization fails and the device resets itself as a 'safety measure'

In order to inspect and understand where the problem arises you should try 'deeply' log the mqtt connection and messages sent from the device when it tries to connect to the broker.
If the device is unable to correctly establish an mqtt session with the broker then the issue is in 'meross setup' else, if the device succesfully connects and starts sending mqtt messages, then the issue may lie at the application level where the device expects some meaningful responses which HA/meross_lan are unable to send.
Up until now, it never happened such an 'application level' issue since, once mqtt connected, the device is ok and don't expect any particular reply or handshake (some devices try to exchange timing information for setting up their own time but this was never critical i.e. even if the synchronization transaction failed, the device were keeping the connection and working nevertheless)

[bytespider]

In addition to what @krahabb as asked, are you pasting your WIFI credentials or typing them? Please also use single quotes when wrapping option parameters.

[cwoac]

Given the setup is over bluetooth rather than wifi on the 305, how are you getting to the point of running setup?

[krahabb]

@cwoac ,
I think you would find precious info here

[DoSe-dev]

Am I the only one whose mss310 units dont open a wifi hotspot at all? I had to connect them to my home network through the meross app to be able to communicate with them. I then ran the setup without wifi config and its working now.

[krahabb]

I think new HK/Matter devices are moving to a different provisioning approach (compatible with those standards) and so dropping the legacy hotspot configuration procedure.
There's a thorough experience described here #346

[timnolte]

If this is the case with the newest HomeKit devices I'm going to do my best to try and buy only the older non-HK devices as long as they are still available. I've been using the Meross Android Pairer app which has been working successfully for me and I'd rather not be stuck with other more problematic solutions. I've been more on the resistant side of adopting HK devices even though Home Assistant can technically manage them directly. I don't have a compatible IPv6 local network in order to be able to use Matter.

[zaggash]

I'm late here in the battle.
But I wonder why there are so many shenanigans regarding certificate creation and openssl signing key when in the end the broker setup uses:

require_certificate: false

There is no way to even pass the CA to the Meross device so what is the point, did I miss something ?

[zaggash]

Problem was the certificate chain needs to be full RSA.
Do not create ECDSA signing key or certificate.

[slotdawg]

Hm, I'm also battling MQTT certs. I generated my CA, keys, and server certs per the guide and configured eclipse-mosquitto to use the certs with require_certificate false flag, however I'm continually seeing the following error in the container logs for mosquito:

OpenSSL Error[0]: error:1402542E:SSL routines:ACCEPT_SR_CLNT_HELLO:tlsv1 alert protocol version

I upgraded OpenSSL to v3.3.0 and regenerated certs/keys, however that didn't seem to fix things.
I also tried setting the tls_version to tlsv1.1, but that too did not help.

Anything I could be missing here?

[slotdawg]

Aha - silly me, I had read further above from @mdisabato that MQTT is just like HTTP, nothing lower level... and yeah, just like HTTP, it means SSL traffic needs to listen on a different port than non-SSL traffic. So after modifying my mosquitto.conf file to look like the following, I was in good shape:

#pid_file /var/run/mosquitto.pid

persistence true
persistence_location /mosquitto/data/

user mosquitto
allow_anonymous true
password_file /mosquitto/config/mosquitto.passwd

# Port to use for the default listener.
#port 1883
listener 1883

log_dest file /mosquitto/log/mosquitto.log
log_dest stdout

#include_dir /mosquitto/config/conf.d

# MQTT over TLS/SSL
listener 8883
acl_file /mosquitto/config/accesscontrollist
certfile /mosquitto/config/server.crt
keyfile /mosquitto/config/server.key
cafile /mosquitto/config/ca.crt
require_certificate false

# Plain WebSockets configuration
listener 9001
protocol websockets

# WebSockets over TLS/SSL
listener 9002
protocol websockets
certfile /mosquitto/config/server.crt
keyfile /mosquitto/config/server.key
cafile /mosquitto/config/ca.crt
tls_version tlsv1.2

After that I was able to correctly register the Meross device to mqtt via SSL and finish the configuration in Home Assistant. One "hiccup" worth noting was the Meross "device key" kept on returning an error even after multiple attempts to retrieve it from cloud. I tried adding the device manually (via IP) with no device key and it was picked right up by the Meross LAN add-on. I wouldn't have expected that, but hey, I'm not going to argue.

Thanks for everyone in this thread, happy to have gotten this working in my setup and not have to rely on yet another external cloud service.

[krahabb]

The 'cloud key' is only valid when devices are Meross (cloud) paired. When you pair your devices to a private mqtt either using the pairer app or any command line utility, you also setup the device key (which, nevertheless, is empty by default).

Sadly enough, when meross_lan configures a device it expects a whole lot of different scenarios so it might be 'fooled' thinking the cloud key would 'fit' while instead it would be better either trying an empty one. I'll try review the config process to see if anything might be improved (likely yes) to reduce 'friction' in configuration :)

[Andreitos97]

Thank you @krahabb for you effort! :D