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

The first quote is the full mosquitto.conf of my 2nd broker in the conf.d folder as you said. I think you can call it anything as long as it is .conf

The next is in the hassio addon config (1st built in broker) that “true” just lets it know you are doing more config and the mosuitto defines the folder it’s looking in

Then the last is in \share\mosquitto folder on hassio that’s what the true and mosquitto are setting up in the previous step. I get to that folder via the SMB addon, lots of other ways the text is agian the whole mosquitto.conf

Oh. Thanks for the correction.

To add device locally to MQTT, we can get by with just the Minimal unauthenticated setup and not with Authenticated users?

Then the last is in \share\mosquitto folder on hassio that’s what the true and mosquitto are setting up in the previous step. I get to that folder via the SMB addon, lots of other ways the text is agian the whole mosquitto.conf

I don’t have mosquitto folder in my \share in HA. I just create it?

\share\mosquitto\mosquitto.conf

Yes, this was my big headache, on the hassio built in broker addon i could not mix and match ( i’m sure you can but it is beyond my skillset) so in the end i setup a broker just for meross using this minimal

allow_anonymous true
require_certificate false

port 1883

listener 8883

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

It will happily talk to meross devices no user/pass needed (but the certs need creating) and also talk to my existing broker addon in hassio

It’s a long way round but for me it’s the best (or laziest) option given my setup

I think I got all the setup in place to advance forward.
What are you using to setup the meross devices to mqtt? Looks like we need to connect to the device on it’s AP first, and then run the utility.

I am at the step to connect Meross device to mqtt. After executing below, the device is at flashing green. I do not see anything on MQTT log.

./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://192.168.1.15

I think I have successfully connected the device to MQTT Broker.

Could it be my ssl certificates were not created correctly? Something about these notes?

Make sure that your CA Root uses a different Common Name to your server and the common name for the server is the server IP address

Create the certificate signing request. It's important when asked for the FQDN in these next step to use the IP or domain name of the machine your MQTT instance is on.

Note: I have not install the pyscript script yet.I don’t think that would be the issue?

Update: Almost there. It turns out that the certs has some permission issue. Make sure to change owner and permission for the 3 files.

-rw------- 1 mosquitto www-data 1294 Mar 20 16:16 ca.crt
-rw------- 1 mosquitto www-data 1184 Mar 20 16:17 server.crt
-rw------- 1 mosquitto www-data 1675 Mar 20 16:16 server.key

sudo chown mosquitto:www-data ca.crt
sudo chmod 600 ca.crt

Hi all,
for some folks like me there are tons of questions, because of our limited knowledge. If someone has the time and will, please add a more step by step guide explain how to properly configure the integration.

are you following @ dizzyikea method by installing a 2nd mqtt broker on a different server?

no, I haven’t yet. I run HA in a NUC with ubuntu 18.04 desktop version. Will it be alright to try to install the 2nd mqtt broker there?
My knowledge in linux is very limited and I am not sure if I can manage to connect it to HA properly.

I am on the same boat as dizzyikea with MQTT Addon install on HA and are being used by some clients connected non SSL. It sounds like he had a hard time figuring out how to get both non and ssl working with the addon. That is why he install a 2nd MQTT Broker and use it for SSL connection and the MQTT addon on HA, he left as it.

You can only install one MQTT on a server, in this case your NUC. If there are some connection to the MQTT now, you may run into some issue. I didn’t read above of your issue.

I am almost there with the setup. I have got the devices showing on both mqtt brokers. What is left is install the pyscript and config from there.

What issue you are having?

@ wojwoj
Can you clarify about the channel? I am confuse as what is written in the docs. You wrote that Channel 0 is for single plug and down the paragraph, you said Channel 1 is for single plug. Can you tell me what channel I need to input for the MSS110 smart plug?

Meross devices feature a concept called "channel". A channel is a way to contact a specific plug in a strip. The channel 0 is the "main channel" - the one that controls the main "on/off" button on a plug or a power strip.

For a single plug, this channel obviously is the only one available as the main "on/off" button matches the only plug available.

For a strip, further channels (1, 2 ... ) target the specific plugs (power and USB). The details depend on the device, but it is usually "number of plugs + USB if any (all USB ports are handled together) + 1 main channel"

The available configuration options are:

name (required): the name of the device, as you want to see it in the switch declaration. The switch will be called switch.<name>_<channel>.
channels (required): number of channels. Examples are 1 for a single plug, 6 for a 4 plugs + USB.
id (required): the ID of the device retrieved during MQTT configuration above

Add arrow (just this word on a single line) to the file <config>/pyscript/requirements.txt . Create the file if it does not exist.

What does this do?

Not exactly, you can install as many as you need, provided that they are separate (in docker containers for instance), and that they expose different ports.

I have on my server two MQTT containers: one that is in production and exposes the ports used by devices, and another one that I test on (with other ports).

The confusion probably comes from the numbering.

Each device has a number of channels, at least 1. The channels are numbered from 0, where 0 is the main channel - the main on/off switch, equivalent to the physical button.

A single plug has one channel, with has the number 0. It is the main and only channel because it is a single plug.

A strip with 3 plugs would have 4 channels, numbered as

  • 0: the main on/off (also wired to the physical button)
  • 1: the first plug
  • 2: the second plug
  • 3: the third plug

Some strips also have USB ports, they are all on one channel (at least the ones I saw, maybe there will be one with each port controlled independently, in which case they will have each their own channel)

Hope this clarifies the channels a bit.

The MSS110 is a single plus, do the number of channels in the configuration is 1, and this channel is referred to as 0

1 Like

I only have MSS310’s so i do not know about channels. I used http://mqtt-explorer.com/ to watch my brokers for connections this helped a lot as i could instantly see if things where talking to my servers

arrow is a Python modules that simplifies the management of dates. In order to import in in the code, it has to be installed on the system.

Pycharm has provision for that: if you add the names of the modules in requirements.txt, pycharm will install the module if it is not already available in the system.

See User Guide - pip documentation v24.0 for details, and pyscriptdocumentation (Reference — hacs-pyscript 1.5.0 documentation):

Pyscript can install required Python packages if they are missing. Depending on how you run HASS (eg, using a minimal Docker container) it might not be convenient to manually install Python packages using pip. If your pyscript code requires particular Python packages that are not already installed by HASS, add a requirements.txt file the /pyscript directory. This file lists each required package one per line, with an optional version if you require a specific version or minimum version of that package,

1 Like

Yes, the devices talk to specific topics on MQTT. The actual plug that is being addressed (or that is speaking) is referred to by its channel on the strip.

If you run Ubuntu anyway, you may consider using docker.

It has a lot of advantages, among others that you have self-updating containers, you can separate the services (HA separated from MQTT for instance), you can use a reverse proxy to manage HTTPS easily.

All this can be done directly on the server as well but it will make maintenance more complicated.

This is a personal opinion of course, other do not agree (I am using Linux since 1993, having administered a load of them with services directly installed on the machines. Discovering docker opened anew world in terms of ease of maintenance)

1 Like

Ah ok channel just = topic then,just another way of saying it. I’m familiar with that from my tasmota flashed 4 gang + USB which has 5 “channels”

No, not exactly.

The topic is the ID:

image

Then when you look at the payload you see

{
  "header": {
    "messageId": "f0f82a53f5f081228268fd6b99efd805",
    "namespace": "Appliance.Control.ToggleX",
    "method": "PUSH",
    "payloadVersion": 1,
    "from": "/appliance/2006174814872951801348e1e91fba47/publish",
    "timestamp": 1616247301,
    "timestampMs": 91,
    "sign": "0937f2e369b8c468546953a1db19703a"
  },
  "payload": {
    "togglex": [
      {
        "channel": 0,
        "onoff": 0,
        "lmTime": 1616247301
      }
    ]
  }
}

channel: 0 means that the main switch was used (this is on a single plug), and was switched off (onoff)

This is an example for a strip: one topic (again, the ID of the device), and many channels (plugs, main switch, USB):

"togglex": [
          {
            "channel": 0,
            "onoff": 1,
            "lmTime": 1615742725
          },
          {
            "channel": 1,
            "onoff": 1,
            "lmTime": 1616246288
          },
          {
            "channel": 2,
            "onoff": 1,
            "lmTime": 1616246288
          },
          {
            "channel": 3,
            "onoff": 0,
            "lmTime": 1616219610
          },
          {
            "channel": 4,
            "onoff": 0,
            "lmTime": 1616219610
          },
          {
            "channel": 5,
            "onoff": 1,
            "lmTime": 1616246288
          }
        ],
1 Like

Wonderful. I just fully tested one of the Meross devices I have and it works.

Is there anything I should be aware of if I want to rename the current switch name? Duplicates?

switch.sp1_0

Here is the naming strategy I developed over the years of using various smart switches. There are others but this one ended up being the more stable and future-proof.

Each of the plugs or strip I have gets a serial number. I write it directly on the plug with a sharpie. Why? Because there is no eye-readable serial number on the plugs, something that could identify a plug when having it in hand.

I then flash the plug and retrieve the ID. Both of these information go to the configuration file:

meross:
  - name: meross01
    id: 2006176333738751801348e1e91fb91a
    channels: 1
  - name: meross02
    id: 2005281078830290814148e1e91d807b
    channels: 6
(...)

With this, when I see a plug in a box, or if I want to move it from one place to another one, I know how it i addressed in HA. At some point I used a name related to the place it was (such as room_michael_on_the_right_next_to_the_blue_table :)) but then I moved it somewhere else and it was a mess.

Now back to HA, Configuration → Devices shows meross01 and meross02:

image

Ah, meross01 is not visible? This is normal: it means that the plug physically exists (it is in the configuration), but is not plugged in (if you look at the diagram in my README you will see that there is a function that periodically checks if a configured plug is actually live, and removes it from HA when it is not. Once it is plugged back it reappears with the same name).

This is the device. Each device has entities. The entities, in practical terms for a plug , correspond to the device the plug manages (a lamp, …). I will take the example of meross02 (which is a strip, with multiple sockets):

Here the socket 3 and 4 are used, and I renamed the entity to give it a relevant name. I did that by clicking on the entity and changing the name, and the switch name. This way I can use them in the lovelace configuration by a name I can make sense of. The other advantage is that HA will not allow for a duplicate name.

So what happens when I move a plug?

  • unplug it
  • plug it back in the new place
  • make sure it is back online (the check is every minute)
  • in the UI go to the name of the plug (meross02)
  • change the name of the entity that has a plug plugged in (meross02_3 → arbre and switch.meross02_3 → switch.arbre - as an example)
  • modify lovelace if needed (though if you changed the name of the entity, it is logical that you want to change it in lovelace as well)

You could of course skip the renaming of the entity, and then use in your configuration names such as meross02_1 (or sp1_0 in your case) but I found it bothersome to glance everywhere all the time to remember what is actually plugged to switch.meross02_1 (as opposed to switch.livingroom_lamp_white_right)

Let me know if this is not clear.

1 Like