That’s impressive! I think this thread is showing a ‘step-up’ in the pairing procedure not seen before. It puzzles me a bit the fact that this new ‘matter pairing’ procedure goes through 2 pairing phases: in your mitm-proxy attempts logs, where the device was going through this new standard pairing procedure, it clearly used 2 different user accounts (or 2 user ids associated with the same account)

thoughts

Going on, I think the root problem is in the inability to now setup the wifi from scratch (like it was before where the devices, once reset were setting up their own open ssid-AP). This leads to necessarily using the Meross app for pairing with all the consequences-issues. I see anyway https://github.com/bytespider/Meross/issues/72#issuecomment-1859218764 seems to have found a workaround to the current @bytespider meross utility in order to only re-configure the broker once the device is Meross paired. This way, (it looks like working), after all of the official Meross pairing, the utility is able to just ‘steal’ the device from the cloud brokers and bind to the local one. I don’t know if you were following that issue/thread but, if you were just using the current meross setup utility, @M0NsTeRRR shows it is still not up to date with the scenario

That’s not the issue I’m asking about though. WiFi is set up and working, the issue is that it won’t connect to the HA Mosquitto broker because of the TLS cipher incompatibility.

You either need to setup an older mosquito or use EMQX instead. Newer versions of mosquito do not allow : as a character in the username, which meross plugs use

PS : A PR has been made between my comment, you don’t need to comment lines, just use the --no-wifi flag

--nowifi to be precise (I couldn’t use --no-wifi in my PR since the library would parse that in a special way)

That’s not the issue I’m asking about though. WiFi is set up and working, the issue is that it won’t connect to the HA Mosquitto broker because of the TLS cipher incompatibility.

At this point, the @M0NsTeRRR trick shows we should be able (in meross_lan) to actually reconfigure the device broker at any time by just issuing the dedicated message/command. This will open up to a nice feature where, having the device (Meross app paired) fully working in meross_lan eventually with its cloud profile but doesnt matter, we could reconfigure its broker to the HA mqtt by pressing a button in meross_lan.

Of course the HA mqtt need to fullfill all of the specific requirements needed for the device to succesfully bind but it will ‘release’ the need to use the @bytespider meross setup utility

The only drawback, I guess, would be that in case of failure binding the device could factory reset itself thus needing to be reconfigured from scratch in Meross app (or whatever)

I’ll start experimenting: the covid is giving me plenty of time 😉

@krahabb OMG IT WORKS!!??

There’s a new pre-release which now also replies to the ‘ConsumptionConfig’ payload sent by the device. Cross fingers 😉

@fuomag9, In the ‘almost working’ example, the device finally sends a couple of packets (also receives a reply from its ‘Bind’ push this indicates meross_lan latest release fix is working) At one point it also sends a ‘ConsumptionConfig’ packet and then (soon after about 1 sec) disconnects and I’ve found documentation here where @arandall states this is usually replied by the meross broker with the same packet/payload. Actually, meross_lan doesn’t handle this packet so this could be another ‘missing transaction’ in the init process. As previously said, it could be latest firmwares are becoming stricter and stricter. I’ll (try) quckly publish a further fix to reply to this message and see if it finally fixes the whole process

I really hope we can solve this issue seeing your efforts! keep up!

Ok, it looks like the strange ‘topic’ in previous logs is just the one which the device subscribes and that’s ok and expected

I think I might have a possible resolution since it looks like the “Appliance.Control.Bind” the device sends needs to be replied with a correct response. There where some reports in the past where privately mqtt binded devices where ‘pushing’ these messages until they had received a proper response but, nevertheless, devices were still able to work without disconnecting and resetting if any response were not received(they just kept spamming a bit the broker). It might be newer firmwares are stricter on this transaction and they want a response in order to be sure the broker is correct.

Now the problem lies in the fact that meross_lan actually replies to this message (the reply is very dumb to be honest but it might work…we’ll see) but only once the device is configured in meross_lan so, if we’re in the initial phase of pairing like this, meross_lan doesn’t handle this message for sure.

I could easily fix and deliver a patch and see if that works but I’m in the middle of nowhere with development so I need a bit of time to setup a dedicated branch. Keep in touch, I’ll try to publish it asap since that could solve a lot of issues for the future too