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:
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:
What is the difference between listener and port?
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?
how should I change the permissions for the certificates?
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)
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!
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!
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.
The complicated part is usually setting up the MQTT broker for TLS (and maintaining it). Once this works (easiest to test is with an MQTT client such as MQTT Explorer or MQTTx) my routine is to put the device in pairing mode, pair with the app above and it works.
I recently had to re-do a pairing 6 months or so after the least one, so I forgot how to do it. I was surprised it is that straightforward after all.
@WoJWoJ yeah, I think the problem for new people, like myself, is that the mobile pairing app is not very clear in terms of documentation when using the MQTT option. When you first start up the app it has these “login” options that neither are actually appropriate for the MQTT setup, and using the Manual option becomes even more foreign. I think for own sake, in the event I would need to set this all up again, I want to document everything I did to get this to work, and maybe it will also help someone else.
So one thing I’m finding in an effort to move my Meross devices from the cloud to MQTT/Local is the lack of consistent setup happening. I’ve posted in a few places now that only my MSS510 smart switches actually managed to connect via MQTT and are working in Meross LAN, the other 3 devices(MSS550 smart switches & MSS110 smart plug) have ended up pairing for IP/HTTP to Meross Lan in HA. The devices are no longer in my Meross phone app but they are functioning, with some limited functionality(missing the LED indicator control) in HA. I need to do some more testing with the MSS110 that I paired and see if I can manage to get it successfully working over MQTT. I’m on the fence if I should try to move my MSG100 garage door opener over or not as I also don’t want it to be limited in some functionality as a garage door opener control is a little more of a concern than just lights or fans.
a device must be made manageable (usually a long press)
it has to be detected by the configuration app
the configuration app pushed to the device the configuration, specifically the MQTT address
the device now sends its messages to the MQTT broker
HA has the Meross LAN integration installed
a new device, through 4., informs HA that it is available (HA Discovery)
the device is configured in HA
Where exactly are you stuck?
I have several MSS110, I do not have an MSS510/550 but they look great and I will get one promptly. I also have several Meross strips. All of them were set up the same way and behave the same way.
Again - sorry for being dumb here but I like very much your idea of improving the documentation for that great product (I did it at the very early stages of Meross LAN)
@WoJWoJ just to follow up with some details. Here’s the basic steps I’ve been taking to migrate my Meross devices from the Meross app/cloud to Meross LAN.
Remove device from the Meross Android app.
Remove device from Meross LAN in HA.
Ensure device is “factory reset” and in pairing mode. (led flashing).
Taking note of the MAC address of the device, that I already setup static DHCP entries for, and creating a HA User using the MAC address as the username, as well as the password being 0_<MD5 HASH of MAC address>.
Use the “Custom Pairer for Meross Devices” Android app to begin the paring process.
Discovery of the Meross device WiFi SSID and connecting to is with the Custom Pairer app.
Initiate the pairing setting the WiFi SSID that I want the device to connect to as well as the MQTT IP address and port(8883) that I want the device to connect to. Then proceed with letting the app send the configuration to the device.
When I take these steps the results I’m finding are the MSS510 switches are discovered in HA under Meross LAN ready to be added, and when completing adding them to HA if you look at the Configuration for the device you can clearly see that the device says Host: MQTT. However, on the MSS550, and the single MSS110, devices when I go through that whole same process the devices show up in HA under Meross LAN but when completing the setup, they have the IP address of the device listed, and then if you go back into the “Configuration” of that device you can clearly see that the Host: is set to the IP address of the device. This means in fact that HA/Meross LAN is connecting directly via IP/HTTP to those devices instead of going through MQTT. The other result of this is that there are missing entities(at least the LED indicator control) on those IP/HTTP connected devices.