Unable to control light bulb from local MQTT broker

[mjrinker]

Hey @bytespider,

First off, just wanted to thank you for all the work you've put into this project, and to documenting it. I've already learned a ton!

I'm trying to control a light bulb (MSL120) while running a local (i.e. custom mosquitto) broker, but I can't get the light to respond to messages I'm sending it.

I've followed the instructions in the Wiki.

I set up the certificates using the exact commands in the Wiki:

$ openssl genrsa -des3 -out ca.key 2048
$ openssl req -new -x509 -days 1826 -key ca.key -out ca.crt

$ 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

For the Common Name in the CA cert, I used my name. For the Common Name in the server cert, I used the local IP of my broker.

I'm using the minimal unauthenticated config from the Wiki:

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 ran the following and my light bulb seemed to connect:

$ ./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://<BROKER_IP>

When I ran the mosquitto broker and the above meross setup command, this was the output:

$ mosquitto -c /path/to/mosquitto.conf -v
1652914301: mosquitto version 1.5.7 starting
1652914301: Config loaded from /path/to/mosquitto.conf.
1652914301: Opening ipv4 listen socket on port 8883.
1652914301: Opening ipv6 listen socket on port 8883.
1652914304: New connection from <DEVICE_IP> on port 8883.
1652914304: New client connected from <DEVICE_IP> as fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (c1, k30, u'<DEVICE_MAC>').
1652914304: No will message specified.
1652914304: Sending CONNACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (0, 0)
1652914304: Received SUBSCRIBE from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG
1652914304:     /appliance/<DEVICE_UUID>/subscribe (QoS 1)
1652914304: fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG 1 /appliance/<DEVICE_UUID>/subscribe
1652914304: Sending SUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG
1652914304: Received PUBLISH from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q1, r0, m28, '/appliance/<DEVICE_UUID>/publish', ... (396 bytes))
1652914304: Sending PUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (Mid: 28)

Then, from my client, which is a different machine, I ran the following to try to turn the light bulb off:

$ mosquitto_pub -h <BROKER_IP> -p 8883 -t "/appliance/<DEVICE_UUID>/subscribe" --cafile ~/path/to/ca.crt -m '{"header":{"from":"/app/724729-005b295660494850b26e7cfb594e4ad8/subscribe","messageId":"a83255cd8160bb9ff12ec39b90befdf3","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"d8d18b831228cba6f992fa7a745577c4","timestamp":1652912578},"payload":{"togglex":{"channel":0,"onoff":0}}}'

When I send that message, I get this in the broker logs:

1652914307: New connection from <CLIENT_IP> on port 8883.
1652914307: New client connected from <CLIENT_IP> as 10135219-a366-4f28-a06d-ae0cdf257496 (c1, k60).
1652914307: No will message specified.
1652914307: Sending CONNACK to 10135219-a366-4f28-a06d-ae0cdf257496 (0, 0)
1652914307: Received PUBLISH from 10135219-a366-4f28-a06d-ae0cdf257496 (d0, q0, r0, m0, '/appliance/<DEVICE_UUID>/subscribe', ... (324 bytes))
1652914307: Sending PUBLISH to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q0, r0, m0, '/appliance/<DEVICE_UUID>/subscribe', ... (324 bytes))
1652914307: Received DISCONNECT from 10135219-a366-4f28-a06d-ae0cdf257496
1652914307: Client 10135219-a366-4f28-a06d-ae0cdf257496 disconnected.
1652914307: Received PUBLISH from fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (d0, q1, r0, m29, '/app/724729-005b295660494850b26e7cfb594e4ad8/subscribe', ... (335 bytes))
1652914307: Sending PUBACK to fmware:<DEVICE_UUID>_tRG1738C2qeo9FzG (Mid: 29)

From all appearances, it looked like it worked, but the light bulb does not turn off.

I'm hoping you might be able to help me figure out what I'm doing wrong. It's probably some stupid little thing. Thanks!

[mjrinker]

FYI, looks like I was on an old version of mosquitto (v1.5.7) that was using MQTT v3.1.1 I upgraded to mosquitto v2.0.12 which uses MQTT v5.0/v3.1.1/v3.1

I then re-registered the device with the following:

$ ./meross setup --gateway 10.10.10.1 --wifi-ssid myssid --wifi-pass mypass --mqtt mqtts://<BROKER_IP>

Unfortunately that did not fix my issue, but it was probably a good thing to do anyway!

[timnolte]

@mjrinker I don't have the MSL120 however I have this working with Home Assistant using Mosquitto as my MQTT Broker. The key for me however was that I needed to make sure to have an account created using the Device Credentials in order for the MQTT communication to happen. In my case I am using Home Assistant and so my Mosquitto authentication is connected with Home Assistant where I created the user account based on the Meross Device Credentials. I have been able to confirm that connecting to the MQTT Broker with those credentials I can see the messages going between my Home Assistant and the Meross devices.

Noting that I'm only on version 2.0.11 of Mosquitto.

[mjrinker]

@timnolte This is good info. Looking at the step from the Wiki that you linked, it mentions passing the user and key to the meross setup command. Do I do this when I run that command to setup a device?

[timnolte]

@mjrinker so what I've been pairing my devices with is 0 as the user and a blank key, so for example the password would looking like 0_<MD5-HASH-DEVICE-MAC-ADDR>. However, if you run the meross info command you should get an output that included the currently configured Username/Password and can simply setup those in your MQTT Broker for authentication.

[mjrinker]

@timnolte Ah okay that makes sense! I'll work on that tomorrow. Thanks!

[mjrinker]

I forgot to update this but that did the trick! Thanks again @timnolte!