Would you mind highlighting the points that are not clear? I would be glad to modify the README to make it more straightforward?
1 Like
Hi
I think that the read me file is ok, my problem (and I guess of some more people with limited knowledge like me) is that I donāt understand most of the steps of the installation procedure.
my main problems are the following
your MEROSS device must be connected to your local MQTT broker, not to the company cloud. How to do it is explained here.
you must know the unique ID of the Meross device. You retrieve it when connecting your device via @bytespider's utility, it will be similar to 2005280221783980814148e1e91d7af1.
I donāt think that this is your problem at the end but my limited knowledge
OK, so the problem is with the connection to MQTT.
To be frank, this requires some tinkering and quite a bit of installation. You need to have your own MQTT server that you configure with TLS (certificates). Then you need to start the utility to configure your plug to connect to that broker. I would say that if this does not sound right (or understandable) then you may want to consider staying with the cloud implementation.
I absolutely do not want to discourage you, but having the plug connecting to a local MQTT broker means reading @bytespider utility docs (which are fine, the utility is really great).
If you have some specific issues with that part I will be glad to help but having a step-by-step explanation including how to install a local MQTT broker, etc. is a bit too much.
But if you have specific questions do not hesitate to bring them in.
1 Like
I was also stuck trying to figure out what we need and do at this point. After a few minutes I figured it out.
You need a computer with wifi access. (to be able to connect to the meross deviceās AP)
On the same computer, you need to download these files.
Navigate to /bin/src and run these commands to get the uuid # and setup the device to talk to your mqtt broker.
# find the uuid of the device
./meross info --gateway 10.10.10.1
# configure the device to connect to MQTT Broker
./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://192.168.0.2
Itās basically the same thing when you use the Meross app to setup the devices. Only this time, you will not be connecting to Merossās Cloud, but your local Mqtt Broker.
I was fortunate to have a pc with a built-in wifi. I use my pc wifi to connect to the device AP and use the script provided by bytespider to run the commands via the Windows CMD. On Windows it is a little different.
node meross info --gateway 10.10.10.1
node meross setup --gateway 10.10.10.1 --wifi-ssid ssidNetwork --wifi-pass wifiPassWord --mqtt mqtts://192.168.1.15
1 Like
@duceduc I am not sure if this was already fixed, but it it is better to use --mqtt mqtts://192.168.0.2 twice (two times the same parameter).
It is the conclusion of a long discussion where I was finding my Meross device not reconnecting to my MQTT broker if th broker was down for a few minutes. Using the parameter twice solved the issue.
I think that the script was about to be changed to automatically do this but I am not sure.
This is just a comment in case someone would see that behaviour that was driving me crazy (and I had real concerns about moving the devices).
After using the solution the reconnection is rock solid.
1 Like
There is also an Android based solution ([Local Only Support] Android Pairing APP - Testers needed Ā· Issue #162 Ā· albertogeniola/MerossIot Ā· GitHub) but at least in my case it was having the same issue with reconnection (and I suggested to push two MQTT servers, similarly to the workaround in my previous answer)
I was not able to get the app working tried on 3 different android devices. The command line one worked every time (once i had MQTT itself sorted) I did use linux for the cmd line stuff just as i was not aware it worked on windows (doh)
All is good now
Great then!
Just make sure the device does reconnect when the MQTT broker is down for a few minutes.
I am not sure if this was already fixed, but it it is better to use
--mqtt mqtts://192.168.0.2twice (two times the same parameter).
So input like this instead??
# configure the device to connect to MQTT Broker
./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://192.168.0.2 --mqtt mqtts://192.168.0.2
Yes, thatās right.
My handwaving theory is that if there are two MQTT brokers, the firmware goes into a cycle of checking them alternatively when they are not available (and therefore reconnect when it gets back online). With only one the check is not done.
This is a wild guess, but it closely follows the pattern of āone MQTT broker configured ā no reconnection, two configured ā reconnectionā. Knowing how these firmwares are written, it is in the realm of possibilities.
1 Like
Just wanted to say thanks for all the activity in this thread and over at https://github.com/krahabb/meross_lan. I am a complete novice and getting this stuff working has been a pleasure with so many helpful people on board
You are welcome. These things are hard, especially with a closed firmware.
I appreciated the help I got when I started in that area, it reminded me what we had when developing the early (pre 1.0) Linux kernel - a very helpful community.
thanks for the instructions. I have considered going full mqtt with meross, this will make it easier
Is anyone using local MQTT with garage door opener with this implementation? MSG100
I am currentlty using node red with meross https://flows.nodered.org/node/node-red-contrib-meross for local control, but it still involves the meross cloud. Only thing stopping me from changing to full local mqtt is that I like how google home needs a pin code to open garage door with meross cloud. it is ālocal controlā but meross cloud is still connected
I think that is a larger question on your HA system not really this implementation. Personally i only have two cloud connected devices, my car (as there is no other way) and my heating system as i like it and the cloud system does a very good job. The reason i even started commenting here was for the love of local, once it is yours you can do as you please.
Since that uses a sniffer for meross app is it local?
You can PIN control node red
https://flows.nodered.org/flow/7bcb0b049df4fa3c962294137ebaec19
when I ask google home, is what I am looking for. yes local once u sniff a valid timestamp and msgid
I would say give it a go, you can always revert 
Iām loving what the guys here have done.
Been an enjoyable week or so of my life jump in and have a go
looks pretty straight forward, just wondering if anyone is using it with the garage door opener
with my garage door connected to google home I am not a fan on the ability of someone yelling through my window āopen garage doorā. with plugs it is fine I dont care as much. Meross cloud will ask what the pin is before opening, I havent found a way to duplicate that
hi all
I manage to connect one of my switches in HAās mosquito!
now (since I donāt know much from mqtt) can you help me please how can I make a switch in HA so I can control it?
Message 150 received on /appliance/181201375653952908999298f18976e/publish at 2:48 PM:
{
"header": {
"messageId": "f8335915158484579177a229c990629de0",
"namespace": "Appliance.Control.ToggleX",
"method": "PUSH",
"payloadVersion": 1,
"from": "/appliance/181201375653952908999298f18976e/publish",
"timestamp": 1622375309,
"timestampMs": 616,
"sign": "0c67e77cafcaa9d078e7f7276709f89c"
},
"payload": {
"togglex": [
{
"channel": 0,
"onoff": 1,
"lmTime": 1622375308
}
]
}
}
QoS: 0 - Retain: false
@Makis have a look at GitHub - krahabb/meross_lan: Home Assistant integration for Meross devices - this is by far the simplest way to add your Meross device to HA.
1 Like
I 've read your readme file. So you have converted all your plugs to meross lan, but there are stale entities lingering and you cannot find ways to get rid off ?