Configuration of Meross devices connected to a local MQTT (https://github.com/wsw70/meross-local-mqtt)

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 :slight_smile:
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 ?

Not exactly. I moved the plugs to my own MQTT broker but I was concerned by the fact that “volatile plugs” (the ones that get plugged in and out would stay in an “unavailable” state (and then get flagged by my monitoring system).

It ended up not being a problem - I finally do not have many “volatile plugs” (very few, actually - and zero when I am not experimenting), and the ones that are on and off just need to be manually removed from the integration.

What you mentioned was, incidentally, a problem I had in the past: some entities would get stuck in the configuration. Initially, I was hand-editing the files in .storage but ended up editing them in the UI and somehow it works and I do not have the issue anymore. I guess that the slow move to managing devices in the UI rather than in the configuration file(s) is the reason.

Hi. I have read the entire discussion and also the bytespider’s wiki about MQTT, but finally I didn’t understand so much…
I have already installed a standalone MQTT broker (mosquitto) on my raspberry pi, which I’m using as bridge between Home Assistant Core and Node-Red.
I’ve followed the simplest and straightforward tutorial to install and configure Mosquitto, so my mosquitto.conf is that:

pid_file /run/mosquitto/mosquitto.pid

persistence true
persistence_location /var/lib/mosquitto/

log_dest topic
log_type error
log_type warning
log_type notice
log_type information
connection_messages true
log_timestamp true

allow_anonymous false
password_file /etc/mosquitto/passwords

log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
listener 1883

I read in the bytespider wiki that configuration:

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’m confused:

  1. What is the difference between listener and port?
  2. in which directory should I create the certificates? In my install I have the folders /etc/mosquitto/ca_certificatse and /etc/mosquitto/certs, should I place the ca.crt in the folder ca_certificates and server.crt + server.key in folder certs?
  3. how should I change the permissions for the certificates?

Thanks!

The correct name of the mosquitto configuration is listener. It is the TCP port that will be exposed to the network to get MQTT messages.

The configuration is somehow confusing because you configure a listener (so an open port) by stating

listener 7777

(where 7777 is the port you want to use, typically 1883, 1884, 8883, 8884 but this is just a convention)

Below this, and until the next listener entry, you add the relevant configuration (which, as in your case, can be empty)

You can put them where you want, and tell mosquitto about the path (better use an absolute path)

The permissions should be such that mosquitto is able to read them. If it is started with the user mosquitto, you would do the following (for each file)

chown mosquitto /path/to/ca.crt
chmod 600 /path/to/ca.crt

Thanks @WoJWoJ

I have the Meross MSS110 plugs. Can this plug get a watt reading? I see in mqtt so much data, but no watt to be found.

{
  "header": {
    "messageId": "2153717a8d291373a177b59108dbb2a3",
    "namespace": "Appliance.System.All",
    "method": "GETACK",
    "payloadVersion": 1,
    "from": "/appliance/2009221460240251802948e1e934ad13/publish",
    "timestamp": 640799,
    "timestampMs": 75,
    "sign": "7da17c60ac670b35915b74e5cfecf0e3"
    "timestamp": 640859,
    "timestampMs": 32,
    "sign": "1273300f27f2bf1a1d726c93dae0ded5"
  },
  "payload": {
    "all": {
      "system": {
        "hardware": {
          "type": "mss110",
          "subType": "us",
          "version": "5.0.0",
          "chipType": "mt7682m",
          "uuid": "2009221460240251802ed9e1e934ad13",
          "macAddress": "84:e1:9e:34:da:31"
        },
        "firmware": {
          "version": "5.1.1",
          "compileTime": "2020/07/18 10:30:54 GMT +08:00",
          "wifiMac": "e4:c3:a2:27:56:f4",
          "innerIp": "192.168.1.249",
          "server": "192.168.1.15",
          "port": 8883,
          "userId": 0
        },
        "time": {
          "timestamp": 640799,
          "timestamp": 640859,
          "timezone": "",
          "timeRule": []
        },
        "online": {
          "status": 1
        }
      },
      "digest": {
        "togglex": [
          {
            "channel": 0,
            "onoff": 1,
            "lmTime": 639982
          }
        ],
        "triggerx": [],
        "timerx": []
      }
    }
  }
}

No, there is no information about power consumption.

So I have Meross LAN setup using the Cloud implementation. I order to switch the devices I already have to MQTT do I actually have to remove them or can I just switch the configuration from auto to mqtt?

Additionally, I already have the Mosquito MQTT addon installed and setup with Zigbee2MQTT. Am I able to use the same Mosquito MQTT instance with Meross LAN using MQTT or do I have to setup a whole second MQTT instance?

I currently only have my HA setup on a Raspberry Pi 3b so I’m concerned about overloading it with another MQTT instance. I’m pretty new to all of this so I’m trying to make use of what I have without spending a ton of money on HA hardware itself. I could probably scrounge together another machine to run a dedicated MQTT on it if that is the only way to go about it. Thanks!

I assume you are referring to GitHub - krahabb/meross_lan: Home Assistant integration for Meross devices as the solution you want to use, right?

If so you need to configure your MEross device so that it looks for a MQTT server. Any MQTT server.
This is done with MQTT · bytespider/Meross Wiki · GitHub or GitHub - albertogeniola/Custom-Meross-Pairer: Android APP that allows pairing Meross Devices with third party MQTT brokers. You put your Meross device in pairing mode (long press on something, usually), and then configure it through the apps above.

As for the MQTT server, you will need - it can b anything but it is almost always Mosquitto. Note that you will need to add an extra configuration for TLS-based communication (“encrypted”), this is explained in the docs of any (or at least - some) of the links above.

After that, you have meross devices that exclusively discuss with your MQTT server and not the cloud anymore.

The same MQTT broker can be used for other things: Zigbee2MQTT for instance. I use it for many of my own programs when I need to have asynchronous bus communication.

Yeah, I am already using the Meross LAN add-on. From what you describe though it does in fact sound like I will need to setup all of my Meross devices again in HA, even with the Meross LAN add-on, there is no magic that will switch the same devices from the cloud to the local MQTT setup. I’ll have to test out getting the local MQTT working with one of my Meross smart plugs that I haven’t used yet and then come up with a plan to redo all of my devices and automations. Thanks!

Will these steps work with a Meross device that has homekit as the main connection?

Hi. I’m back. So if I want to move over to the Meross lan integration. I just need to install via hacs, reboot HA & it will pick up any device I have plugged in?

Currently using your method . I do not need to remove any setup of yours when installing Meross lan? Sorry it’s been awhile since I did this & I knew binding the devices was a tribal process.

So, at what console login level am I supposed to be able to issue the openssl commands? What I mean is that I am running the HAOS on a Raspberry Pi. I have the “Terminal & SSH” add-on installed and is how I remote to my HA server, however if I attempt to execute an openssl command I just get a command not found error. Am I going to be force to shut everything down so that I can move my RPi somewhere to hook up a keyboard and screen in order to do this? I sure hope not as it’s a huge pain.

Well, after going the route of plugging int a monitor and keyboard and finally manually mounting the USB drive and copying the authorized_keys files I managed to at least get SSH to the host, however I don’t think this is the right place to be either. I see mentions in this thread about /etc/mosquitto/certs I already have certs in the ssl directory as created by Let’s Encrypt for SSL to my host and I don’t want to mess those up. Though, perhaps if I already have Let’s Encrypt certs that I don’t need to create a CA?


OK, so my certificate setup was already good to go. And once I used my work Linux machine with the meross pairing tool, instead of my Chromebook Linux container, I was able to see the WiFi networks and finally get a spare Meross plug paired. It looks like it’s all good to go and ready for both Meross & ZigBee to use the standard HA Mosquito MQTT add-on. Now it will be just a matter of removing all of my cloud Meross devices and moving them over the my HA MQTT.


Ugh. stupid 3 consecutive posts limitation is forcing me to edit my last post…

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. Since this was the only/main light switch(actually it turns on/off outlets for floor lamps) I needed to just get it back and working for now. I’m not sure if this switch just isn’t supported for some reason?

I wanted to provide an update. I was able to manage getting the Android pairer app to work with the mss510 switch and get it paired with my HA Mosquito MQTT. It took some trail-and-error to figure out how to get things working but I think I’ve figured out a setup that works. Once I’ve managed to convert another one of these switches, and even the mss550 switch, then I’ll probably put together some clear documentation on my working setup and how others can get this setup as well.