Offline-ONLY support
gw2princeps opened this issue · comments
Hi there,
as far as I can tell this just connects to the manufactures server. Is it possible to use this in an offline scenario?
I really dont want my plugs to talk to some foreign servers...
Thank you in advance!
~Spatium
Hi Spatium,
I am concerned about the same thing, but there is little we can do at the moment to fix that. Let me explain why.
As soon as the device boots up, it tries to connect to the Meross MQTT broker (iot.meross.com). If the connection is not possible (due to internet unreachable), the device will keep trying to connect and will eventually reboot itself if it couldn't make it. This means that, when the device is unable to talk with the remove Meross MQTT server, it won't serve its scope.
On the other hand, it is true that Meross devices can be queried locally: in fact you might issue HTTP POST requests within the LAN and the device will respond back. If you just put the device into pairing mode and connect to its open Wifi (MEROSS_SW_XXXX), you will be able to talk with it via HTTP POST messages (have a look at the wiki). However, this means that to query the device you need to connect to its AP, every time. Moreover, if you have more than a single smart plug, you will need to connect to different APs every time you want to control a different plug. You see that is not a good idea.
A viable option, that I am not considering for the moment, would be to have a local MQTT server (maybe on a raspberry PI) and update the meross remote server endpoint (that is passed via the app to the smart siwtch), so that the switch connects to the MQTT broken on the local LAN. This is a bit far from the scope of this library but if you find any easier solution, just let me know.
@albertogeniola I spent some time a week ago reversing the pairing scheme without realizing you did all the work already...
That said, I did discover that you can just send the exact same HTTP messages to the IP address of the device instead of the remote server and it'll still work.
That said, you're right in that there's absolutely no way to control the device without connecting to the MQTT server.
P.S. You don't actually need a bunch of the headers that you pass in via the Auth login request. I stripped mine down to the bare minimum, although keeping them in would make our requests look like they're from a legitimate source.
Here's my implementation if you'd like to take a look :)
Hi Bapirex!
Nice to see that there are folks out there doing the same thing. Anyways I have documented part of my discovery in the Wiki, so you can take a look. I've also seen that the mqtt address does not work as expected (I've failed in a first attempt of configuring a local MQTT address), so I just gave up. It's probably hardcoded into the firmware anyways...
Hey Guys,
I'm thinking of running a local MQTT server and then hardcore the DNS entry iot.meross.com to point to my local MQTT server (since there probably isn't an easy way to change the address in firmware). I don't currently have a meross device but I'm looking to buy MSS310, mostly I need this for energy monitoring. What I wanted to check was do you guys know if the plug required any authentication to connect to the MQTT server and does it communicate over HTTP or HTTPS?
I did some investigation via the serial port and was able to connect to a local MQTT server by changing the sever params stored on the device pair time. I’ve not yet documented that process https://github.com/bytespider/Meross
Awesome work! I imagine you were able to do so by updating the values of dev.cfg.Server and dev.cfg.Port, right?
However, I feel like the majority of people won't try to open the plug. I would not recommend to people to do so (we are still messing with something connected to the line...). Instead, is there any way to access such configuration from remote?
That's good to hear. I'll buy one then and start playing around.
I have a prototype that worked when setting the values on setup and its my belief thay
You can call /config with the Appliance.Config.Key namespace at any point to change the values. I still
Dont know what MQTT topics are supported as the app focuses on their HTTP api. Will do more investigating
That helped a great deal. I've been able to set up a plug using my own MQTT broker and watch the device send it's information https://github.com/bytespider/Meross/wiki/MQTT. Thanks for your help @albertogeniola
No problem @bytespider .
Just let me understand: setting the server key at pairing time allowed you to use a local MQTT server? When I tried that I failed: it looked like that the configuration key was not saved, but I don't remember if I did set that key during pairing or later. Have you issued any command at serial terminal or setting the server Key via HTTP was enough?
Moreover I pretty sure I did not configure the local MQTT server in any way, and probably that was an error too. I've just noticed that you needed to add a CA Root with the IP of the server as common name...
Setting at pair time was enough.
Please give my tool ago just incase its unique to my MSS310 with latest firmware.
@albertogeniola I almost got things working with a local MQTT server in late December. I gave up at that point (after I got my only plug in factory mode which is another story). After reading some of the comments above by @bytespider I decided to get more MSS310 plugs and have another go.
@bytespider is correct in that setting the local server details at pairing time work just fine.
I've got a working pairing script that keeps the device details in a ~/.local/meross/config.json file. And I can then access the devices using a very slightly modified form of your Device class.
I intend to make it easier to use when I get time but I'm happy to put the code up on github before it's "ready" if that would be any use.
@davidb24v I did the same which is what lead me to the teardown. From what I can see factory mode can only be reset back to normal via the serial. Its a fairly simple teardown, 2 screws on the back and the face is clipped in
@davidb24v That would be great, post the script so I can integrate that functionality into my library for implementing local MQTT usage.
@albertogeniola - I've pushed what I've been workin on to: https://github.com/davidb24v/meross-utils
The changes to your Device class are trivial and are in modified_device.py
setup.py contains the pairing code. The rest is really just mucking about with the config file and trying to put together a sensible command line interface.
For info, I'm running this dockerised MQTT: https://github.com/toke/docker-mosquitto and using a config file very similar to what @bytespider posted in his repo (I think I just added "allow anonymous true" to it and changed the paths to the certificates and key files).
Hey @davidb24v , you can also turn the factory mode by connecting to MEROSS_SW_XXXX hotspot and then telnet to 10.10.10.1. Username is admin there is no password.
Once logged in navigate to "meross" (Just type in meross) and then use "fac 0" to unset the factory mode or "fac 1" to set the factory mode.
@albertogeniola I've submitted a pull request to allow any Device() to be configured to use a local server.
Hi david,
Thank you so much for your contribution. I'll try to have a look at that within this week and I'll let you know!
HI @albertogeniola @bapirex @nebula-it @bytespider @davidb24v
I just found your researches in my attempt to locally control my MSS110 and MSS310
I'm just trying to figuring out what the pros and cons of all thoses implementation ...
it seems for @bytespider there is no need for any connection to meross server at all but all cloud services are down whereas with @albertogeniola solution, u still need thoses credentials to meross server and you can still use the meross apps...
Lets say i dont mind both of those approaches, i have a mosquitto server on the side and i care more about reactivity and fiability, which one of yours approaches are more recommanded (local mqtt or remote api)... cause i've read quite some place that thoses plugs need some warming http signals to keep their connection alive, so i wonder how it work with local mqtt. Does both of thoses approaches require polling data at custom intervals too ?
Thanks again for all your work
I'll jump in.....
You first have to answer what your goals / desires are, then which fits you the best. I can give you my experience.
I have no desire to use any device I buy for long term use over a 'cloud' which may only exist after a time. I also need a range of connections but lately I am centering around MQTT. So when I have seen nobody getting tasmota on these devices, @albertogeniola provided the only hope of some control.
As you surmised his interface is a door to the device the way the meross cloud works. It provides the advantage of allowing that interface to continue to work - [the disadvantage of their cloud as well].
The works of @bytespider , @davidb24v and myself take the device before it knows anything about the meross cloud, instructs it about our local Mosquitto broker and local wifi and then communicated with it directly over mqtt. This is all possible because of @albertogeniola's work on documenting the mqtt messages which the devices send AND how to generate valid signatures within them.
Difficulity... There are no 'true' caned solutions to get the device local. It WILL require your Mosquitto broker to be enabled for SSL - a small effort. @bytespider 's code will get your device on your broker. From there you are on your own. I have some node-red code which duplicated bytespiders work and allows you to play around.
Lastly, if you understand MQTT - there is no poling. It is all push or command response. You can send a request from a meross device and get its status, but you really have no need. Every command is acknowledged, then a seperate status message is pushed back so you ALWAYS know what your devices are..... If the devices change locally, they instantly push status messages to the broker of the event.
I'll end this with an example log from Mosquitto....
[This is 3 messages - a ToggleX to channel 1, ON, An Acknowledge to the ToggleX Channel 1 ON, and finally a push of status for ToggleX channel 1]
/appliance/1712281825467829030134298f151c4a/subscribe {"header":{"from":"/HaPi/MQTT","messageId":"990d2c73e566d3bb65bd90b4c305b4e2","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"d21e3d814c7377c7541a81a55964d7d1","timestamp":1557536254},"payload":{"togglex":{"channel":1,"onoff":1}}}
/HaPi/MQTT {"header":{"messageId":"990d2c73e566d3bb65bd90b4c305b4e2","namespace":"Appliance.Control.ToggleX","method":"SETACK","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1557534775,"timestampMs":905,"sign":"3098aae5000728d97129e980182f1547"},"payload":{}}
/appliance/1712281825467829030134298f151c4a/publish {"header":{"messageId":"7c2834f83f9cc5b1c7ae1049280a9f3f","namespace":"Appliance.Control.ToggleX","method":"PUSH","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1557534775,"timestampMs":955,"sign":"f07e2a7ab622997508d359cb89c74038"},"payload":{"togglex":{"channel":1,"onoff":1,"lmTime":1557534775}}}
Have Fun...
-Stan
Just amazing , I made it work on a mss110 just at the moment with my own mosquitto, using some code from this repo to generate the json , gonna check this more cause I don’t know if timestamps and the rest matter or just can be static numbers
I believe they can be static number but its just as easy to get the current timestamp. MessageID is some random numbers md5 hashed to create a long string. Obviously all are combined together with your key [the one used when you configured the device] to create the signature for the message. My devices will return a fail in the ack message if the signature is not correct. I do not supply timestampMs [this comes from the devices only].
.... and congratulations...
-Stan
Hi , after playing with multiple plugs i realised sometimes the plug disconnect from my MQTT broker (local mosquitto) and cant communicate with it without unplugging and replugging each plugs ... wonder if there is a way to force reconnecting to my local mqtt broquer without physically doing that.
I can confirm those plugs are still active on the wifi and can be access with their http api (/config)
Interesting, I have two devices which were paired > 2 weeks ago and I have never had then fall off the network. I know my dimmer does a automatic 'Push' of status at least once a day. I'm not sure of the power strip. You could create a monitor log of the traffic through the use of mosquitto_sub ...... - see if it has any info. My devices generally get cycled once per day but manually and not through the MQTT port. (usually once every 2-4 days, but I have been out of the house for 5 days in a row - no activity).
Are you sending the json requests to the localip/config address?
As a FYI I am using Mosquitto ver:
1560398449: mosquitto version 1.5.8 starting
At some point I'll order a MSS110 but at present I do not have one.
FYI...
-Stan
i have 6 x mss110 and 3 x mss310, the problem occured when mosquitto gets down (had to reboot the server and leave it down for like a day maybe) , mss110 mostly keep the wifi infos wheareas for mss310 i had to redo the sync thing (they lost wifi too)
for all thoses which kept the wifi, i was able to use the localip/config address without issues but absolutly no mqtt traffic until plug are "unplug-replug"
the config info payload for thoses not reachable with mqtt contains online : 0 which is probably why they dont emit or receive mqtt
"payload": {
"all": {
"system": {
"hardware": {
"type": "wp110b",
"subType": "us",
"version": "2.0.0",
"chipType": "mt7682",
"uuid": "xxxxxxxxxxx",
"macAddress": "xxxxxxxxxxx"
},
"firmware": {
"version": "2.1.2",
"compileTime": "2018/11/13 17:42:27 GMT +08:00",
"wifiMac": "exxxxxx",
"innerIp": "172.xxxx.53",
"server": "172.xxxxx.26",
"port": 2001,
"userId": 0
},
"time": {
"timestamp": 1560393621,
"timezone": "",
"timeRule": []
},
"online": {
"status": 0
}
},
I did a reboot and of course my objects came back - but I did not take it down for a day. My guess is that when it sends the status push and does not get a ack from the MQTT broker for the transmission - it may go offline. (not really sure of the details or if the broker actually accepts the message with a ack). I do know my node red driver does not ack these status pushes.
If you run the device info on my code it will also pull the device abilities. There is a:
["Appliance.System.Online"]
Item. I have no idea of the payload but you could try pushing that topic with a similar payload to the above when you re-boot..... (or loose communication)
-Stan
I can get the online status with Appliance.System.Online,
but if i change the request from GET to SET i get an error, so that parameter may be read only
Hmmm..
You could just try to send the config packets again to the localip/config address....
-Stan
Just an FYI, I had some storms tonight which flipped a breaker. It took me 5-10 min until I got it reset. When it came back up the MQTT server and the light did not sync. (My power strip did...??). Anyway I was in a similar situation to you in that the device was responding to pings on my local network.
I changed the post address in my node red configure routines to the local node and hit the manual config. I got several ECNErrors and it seemed to auto retry through them, then it magically worked. My node was back online with my MQTT broker.... Not sure how to make the driver auto fix this.... I'll have to think about it...
-Stan
Strange behavior, yesterday a mss110 reset itself on his own, loosing the wifi and mqtt connection at the same time and turning-on the plug...
i had to manually reconfigure it...
other strange behavior with a mss310 this morning, it keep sending a clock message every second and no more status about state ... "messageId":"5343e864b9589c064848ed6d7d65334a","namespace":"Appliance.System.Clock",
Edit: a PUSH with the same namespace "Appliance.System.Clock" seems to fix the issue ... maybe it need a clock fix every now and then
Sorry the RL got in my way. I see the clock messages for the first minute after powerup....
I've never had any of the devices go into this mode after operating correctly.
I thought about a re-pair operation through the http post but then my device would need to know the device IP - ick... [stupid idea removed]...
Just some thoughts....
-Stan
Hi Spatium,
I am concerned about the same thing, but there is little we can do at the moment to fix that. Let me explain why.
As soon as the device boots up, it tries to connect to the Meross MQTT broker (iot.meross.com). If the connection is not possible (due to internet unreachable), the device will keep trying to connect and will eventually reboot itself if it couldn't make it. This means that, when the device is unable to talk with the remove Meross MQTT server, it won't serve its scope.
On the other hand, it is true that Meross devices can be queried locally: in fact you might issue HTTP POST requests within the LAN and the device will respond back. If you just put the device into pairing mode and connect to its open Wifi (MEROSS_SW_XXXX), you will be able to talk with it via HTTP POST messages (have a look at the wiki). However, this means that to query the device you need to connect to its AP, every time. Moreover, if you have more than a single smart plug, you will need to connect to different APs every time you want to control a different plug. You see that is not a good idea.
A viable option, that I am not considering for the moment, would be to have a local MQTT server (maybe on a raspberry PI) and update the meross remote server endpoint (that is passed via the app to the smart siwtch), so that the switch connects to the MQTT broken on the local LAN. This is a bit far from the scope of this library but if you find any easier solution, just let me know.
It seems to be the idea of having a local MQTT server is still under 'research'. What about next idea :
- It's already know, what are the requests sent by the Meross Device to the Cloud (over MQTT).
- For basic devices, ie. Switch / Dimmer: they report their status with some payload. If i understood correctly, those devices get also an UserRequest (for dimming or for turning off/on). Short after, the devices will report their current state to the Cloud. (with syn-purposes).
** here my idea: a TCP server could be written and there 'mock-up' the possible responses. Here the responses represent two types: the activation/dimming request (from the user) and the second one the expected ack that the devices is waiting after reporting a change event. The most work was already done: you know what is the content sent by the device.. and you could examinate the content (sent from the cloud to the device) for preparing the mocked-up responses.
I forgot... then the server and port number on the device, should be adjusted to the TCP server.
The devices talk to the meross servers via MQTT transactions. As stated above - you can in a variety of ways (DNS steering etc...) reflect this data locally. You could create a bunch of code to respond, but again using a local MQTT server fixes the issue.
I suppose another half way point would be to create a local MQTT server to replace the meross server - and simply not use it. Instead use the library here to communicate to the device.
FYI...
-Stan
Hi all,
I was playing with the Meross Thermostat valve and I've discovered that Meross is somehow implementing LAN support. I noticed something strange: less or no MQTT traffic and I was going crazy. Then I realized: commands were were flowing via LAN. This occurs if both the smartphone and the plugs are on the same network, but did not occur before: this has changed recently.
I guess the MQTT still exists for controlling the device when the smartphone is on 4G network or connected to another wifi, but this is definitely great news. I will now remove the WONT-FIX tag as this becomes something feasible.
hi,
@albertogeniola
is it still possible to use the meross plug MSS310 without the meross mqtt server, but using a local server?
Answered through this entire thread. Yes.
You require a local MQTT server and the ability to initialize the device to point to that server. Data contained on this site and others referenced can enable you to do this....
=Stan
I can't connect the device with the local mqtt server. Can you tell me how you set up mosquitto? Are certificates necessary?
@sabinopar please read this comment by @shodge12 where the issues are explained. #1 (comment) my experiments with Local MQTT https://github.com/bytespider/Meross/wiki/MQTT
I have already used those guides, but I can't get the plug with the permanent green light. How do you generate the certificates?
Heres a guide that should help you set up Mosquitto http://www.steves-internet-guide.com/mosquitto-tls/
edit found out that it is not an ESP device but a MediaTek one, its the same config than the MSS310 Smart Plug, but packaged in a TYWE3S format. Serial command worked to leave factory mode.
Hey, sorry to highjack the thread a bit but I recently bought an MSG100 (garage door opener) that I wanted to try to reflash, it looks like it uses some rebranded TuyaMCU, chip is branded MRE3S but it does look like a TYWE3S.
Anyway tried a few things but did not manage to reflash it yet (enter program mode). And ended up entering factory mode through the web interface. However device seems to be stuck there, @davidb24v looks like you did something alike, any tips to escape factory mode?
There is some kind of loop going on the serial (115200):
cmd id 0xdd -- 0x0 seq 0x20
cmd id 0xdf -- 0x5 seq 0x21
cmd id 0xd7 -- 0x0 seq 0x22
Triplet[0] = [1, 14, 0]
cmd id 0xdd -- 0x0 seq 0x32
cmd id 0xdf -- 0x5 seq 0x33
cmd id 0xd7 -- 0x0 seq 0x34
Triplet[0] = [1, 14, 0]
cmd id 0xdd -- 0x0 seq 0x44
cmd id 0xdf -- 0x5 seq 0x45
cmd id 0xd7 -- 0x0 seq 0x46
Triplet[0] = [1, 14, 0]
cmd id 0xdd -- 0x0 seq 0x56
cmd id 0xdf -- 0x5 seq 0x57
cmd id 0xd7 -- 0x0 seq 0x58
Triplet[0] = [1, 14, 0]
cmd id 0xdd -- 0x0 seq 0x68
cmd id 0xdf -- 0x5 seq 0x69
cmd id 0xd7 -- 0x0 seq 0x6a
Triplet[0] = [1, 14, 0]
Any ideas? Thanks!
I have configure my ssl mosquitto which is working well.
But when I setup my meross310, It never connect to my WIFI. Any clue?
Upon first power up or configuration, the MEROSS devices do NOT connect to anything. They instead provide a open wifi AP with a physical address of 10.10.10.1 . If you attach to this, then you can send MQTT packets through HTTP to the device and tell it about your wifi network, password and most importantly your MQTT server. Bytespiders info and code outline it all....
-Stan
I have done everything.
What I don't understand is that the MSS310 doesn't have our server's ca.crt. How can it connect?
I made a small video :
https://youtu.be/rmbBsWveaW0
The way the clients log in - they do not have to have the key.
I see your wifi config and it looks complete and you see an ACK, but your Appliance.Config.Key has payload with [Object], a null key and a null userid.... and no ACK packet??? Are these being filled at you next level up with your MQTT address for your mosquito server, the key (should be something you provide which factors into the signed values needed for MQTT commands), and lastly, the userid for the MEROSS devices to log into the Mosquito server.
When the device accepts both packets - (you get good acks, your led should glow steady [it may have to correctly log into mosquito as well - I cannot remember].
Hope this helps...
-Stan
I have a similar issue to @batoub. I used this tutorial to setup TLS, but did not use the client certificates anywhere. I'm running mosquitto in docker.
docker-compose.yml
version: '3'
services:
mqtt:
image: eclipse-mosquitto:latest
container_name: mqtt
restart: unless-stopped
volumes:
- ./mosquitto.conf:/mosquitto/config/mosquitto.conf
- ./certs:/mosquitto/certs
ports:
- 1883:1883
- 8883:8883 # SSL
- 9001:9001mosquitto.conf:
port 8883
require_certificate false
use_identity_as_username false
cafile /mosquitto/certs/ca/ca.crt
certfile /mosquitto/certs/broker/broker.crt
keyfile /mosquitto/certs/broker/broker.key
allow_anonymous true
./meross setup --gateway 10.10.10.1 --wifi-ssid SSID --wifi-pass PASS --mqtt 192.168.1.42:8883
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.1.42', port: '8883' } ]
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Key',
messageId: '1' },
payload: { key: { gateway: [Object], key: '', userId: '' } } }
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Wifi',
messageId: '1' },
payload:
{ wifi:
{ ssid: 'SSID',
password: 'passhash' } } }
{ header:
{ messageId: '1',
namespace: 'Appliance.Config.Wifi',
method: 'SETACK',
payloadVersion: 1,
from: '/appliance/2001191627xxxxxxxxxx1e9172d83/publish',
timestamp: 14738,
timestampMs: 946,
sign: '3679ca24bxxxxxxxxxxxxx3aeeb8cc' },
payload: {} }
./meross info --gateway 192.168.1.15
Getting info about device with IP 192.168.1.15
sending payload { header:
{ method: 'GET',
namespace: 'Appliance.System.All',
messageId: '1' },
payload: {} }
{ header:
{ messageId: '1',
namespace: 'Appliance.System.All',
method: 'ERROR',
payloadVersion: 1,
from: '/appliance/2001191627xxxxxxxxxx1e9172d83/publish',
timestamp: 1592841309,
timestampMs: 152,
sign: '4fc74464xxxxxxxxxxxxxxxxxx4efb91c235' },
payload: { error: { code: 5001, detail: 'sign error' } } }
mosquitto logs:
mqtt | 1592839623: mosquitto version 1.6.10 starting
mqtt | 1592839623: Config loaded from /mosquitto/config/mosquitto.conf.
mqtt | 1592839623: Opening ipv4 listen socket on port 8883.
mqtt | 1592839623: Opening ipv6 listen socket on port 8883.
mqtt | 1592840190: New connection from 192.168.1.15 on port 8883.
mqtt | 1592840190: Socket error on client <unknown>, disconnecting.
mqtt | 1592840203: New connection from 192.168.1.15 on port 8883.
mqtt | 1592840203: Socket error on client <unknown>, disconnecting.
mqtt | 1592840221: New connection from 192.168.1.15 on port 8883.
mqtt | 1592840221: Socket error on client <unknown>, disconnecting.
mqtt | 1592840239: New connection from 192.168.1.15 on port 8883.
mqtt | 1592840239: Socket error on client <unknown>, disconnecting.
mqtt | 1592840250: New connection from 192.168.1.15 on port 8883.
mqtt | 1592840250: Socket error on client <unknown>, disconnecting.
pciavald,
In the Appliance.Config.Key, it appears you are sending a "" for the key. This ether needs to be a private key you create - or "0" if your following the documentation on this site. The error you are getting is not coming from MQTT server but the device itself.
See the wiki under the HTTP-API page and further ...
Under Login for a discussion of how the sign is calculated....
See if that helps....
-Stan
@shodge12 thanks for your answer. Is there a param i'm missing on the meross utility or should it be done directly through http ?
@shodge12 it's actually hardcoded here:
https://github.com/bytespider/Meross/blob/master/bin/src/api.js#L86
changing it to '0' instead of '' gets me this response:
$ ./meross setup --gateway 192.168.1.15 --wifi-ssid SSID --wifi-pass PASS --mqtt 192.168.1.42:8883
Setting up device with IP 192.168.1.15
Setting MQTT servers [ { host: '192.168.1.42', port: '8883' } ]
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Key',
messageId: '1' },
payload: { key: { gateway: [Object], key: '0', userId: '' } } }
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Wifi',
messageId: '1' },
payload:
{ wifi:
{ ssid: 'SSID',
password: 'passhash' } } }
{ header:
{ messageId: '1',
namespace: 'Appliance.Config.Wifi',
method: 'ERROR',
payloadVersion: 1,
from: '/appliance/2001191xxxxxxxxxxx548e1e9172d83/publish',
timestamp: 1592848011,
timestampMs: 651,
sign: '56124c3ddxxxxxxxxxxxxxx8a92593cde6c' },
payload: { error: { code: 5001, detail: 'sign error' } } }
after resetting the power plug (5s press on the button) this is the message I get, no error straight away but still the same afterwards
$ ./meross setup --gateway 10.10.10.1 --wifi-ssid SSID --wifi-pass PASS --mqtt 192.168.1.42:8883
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.1.42', port: '8883' } ]
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Key',
messageId: '1' },
payload: { key: { gateway: [Object], key: '0', userId: '' } } }
sending payload { header:
{ method: 'SET',
namespace: 'Appliance.Config.Wifi',
messageId: '1' },
payload:
{ wifi:
{ ssid: 'SSID',
password: 'passhash' } } }
{ header:
{ messageId: '1',
namespace: 'Appliance.Config.Wifi',
method: 'SETACK',
payloadVersion: 1,
from: '/appliance/20011916xxxxxxxxxxx8e1e9172d83/publish',
timestamp: 142,
timestampMs: 666,
sign: '4eb7d41xxxxxxxxxxxxxxx01e56277ebd4e' },
payload: {} }
mqtt | 1592848007: mosquitto version 1.6.10 starting
mqtt | 1592848007: Config loaded from /mosquitto/config/mosquitto.conf.
mqtt | 1592848007: Opening ipv4 listen socket on port 8883.
mqtt | 1592848007: Opening ipv6 listen socket on port 8883.
mqtt | 1592848969: New connection from 192.168.1.15 on port 8883.
mqtt | 1592848969: Socket error on client <unknown>, disconnecting.
mqtt | 1592848974: New connection from 192.168.1.15 on port 8883.
mqtt | 1592848974: Socket error on client <unknown>, disconnecting.
mqtt | 1592848981: New connection from 192.168.1.15 on port 8883.
mqtt | 1592848981: Socket error on client <unknown>, disconnecting.
When trying to POST the request described in the wiki, it does not seem to work. I've made a bash script to give it a try:
CONSTANT="23x17ahWarFH6w29"
TIMESTAMP="0"
NONCE="0123456789ABCDEF"
PAYLOAD="{\"email\": \"$1\", \"password\": \"$2\"}"
echo payload: $PAYLOAD
B64=`echo $PAYLOAD | base64`
MD5=`echo "${CONSTANT}${TIMESTAMP}${NONCE}${B64}" | md5sum | cut -d' ' -f1`
BODY="{\"params\": \"$B64\", \"sign\": \"${MD5^^}\", \"timestamp\": $TIMESTAMP, \"nonce\": \"$NONCE\"}"
echo body: $BODY
# curl \
# --cacert certs/ca/ca.crt \
# -d "$BODY" \
# -H 'Content-Type: application/json' \
# https://192.168.1.42:8883
# curl \
# -H 'Authorization: Basic' \
# -H 'Content-Type: application/json' \
# -H 'vender: Meross' \
# -H 'AppVersion: 1.3.0' \
# -H 'AppLanguage: EN' \
# -H 'User-Agent: okhttp/3.6.0' \
# -d "$BODY" \
# https://iot.meross.com/v1/Auth/Login
curl \
-H 'Authorization: Basic' \
-H 'Content-Type: application/json' \
-H 'vender: Meross' \
-H 'AppVersion: 1.3.0' \
-H 'AppLanguage: EN' \
-H 'User-Agent: okhttp/3.6.0' \
-d "{\"params\": \"eyJlbWFpbCI6ICJtZUBnb29nbGUuY29tIiwgInBhc3N3b3JkIjogInJvb3QifQ==\", \"sign\": \"E9BE76EAA17E837B81D6BCA558028A23\", \"timestamp\": 0, \"nonce\": \"0123456789ABCDEF\"}" \
https://iot.meross.com/v1/Auth/Loginthe 3 curl calls are different tries. At first i thought the mqtt broker was able to give the userId and token but it does not seem to be the case (it's my first time implementing an mqtt server), it seems it's internal to Meross ? So why do we need to authenticate anything with them ? Anyway I tried with the Meross URL and my data, did not work, and finally I tried the actual example, which returned the same as my own data:
{"apiStatus":1023,"sysStatus":0,"data":null,"info":"Sign check failed","timeStamp":"2020-06-22 19:46:02"}So it seems like there is an initial disconnect in the basic operations.
When a meross device powers up (or when it is set into config mode through a switch) it becomes a wifi AP source. Your config device must first connect to that wifi AP source and get a IP (I think is sends out a dhcp IP but you need to be sure). The device should come up as 10.10.10.1. Once this connection is made, the two packets we are discussing need to be sent via http: [encapsulated mqtt packets]. These packets [containing your wireless pas and key and any personal encryption key] will result in http responses and if successful, will result in the next steps for the device. Next the device will take down the wifi AP and attempt to connect to your wifi network with your supplied credentials. Finally it will log onto your mqtt server and the config light on the device will go solid. The device will then post some packets to the mqtt server advertising your device.
I personally use a Raspberry pi device with both a hard Ethernet connection and a wifi which is set to look for AP's - connect to them and ping 10.10.10.1 to look for new devices to load up to my mqtt server.
My code is running on Node Red and I can record the debug packets of an actual device if you think it would help....
-Stan
Loging into iot.meross with you user / password is only if you do not use your own mqtt server. I only referred to this page as it describes the signature algorithm used for all mqtt packets. [after the first two sent from http].
-Stan
OK,
So after forcing a re-boot of my MSS425 powerstrip, my Pi auto grabbed onto the AP for the device (verified by ping) and sent the following json to Http://10.10.10.1/config
{"header":{"messageId":"1","method":"SET","namespace":"Appliance.Config.Key"},"payload":{"key":{"gateway":{"host":"192.168.2.25","port":"2001"},"key":"1","userId":""}}}
This results in the following HTTP response:
{"header":{"messageId":"1","namespace":"Appliance.Config.Key","method":"SETACK","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":95,"timestampMs":771,"sign":"0188e8b8b014829e2fa0f430f0a95961"},"payload":{}}
(Note I use 1 for my key and my sign math accounts for it) I then send the following to the same Http://10.10.10.1/config
{"header":{"messageId":"2","method":"SET","namespace":"Appliance.Config.Wifi"},"payload":{"wifi":{"ssid":"zzzzzzzz","password":"zzzzzzzzzzzzzzzzzzzz"}}}
(note I killed the ssid and password data) This results with the following http response:
{"header":{"messageId":"2","namespace":"Appliance.Config.Wifi","method":"SETACK","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":100,"timestampMs":765,"sign":"bdbd38069899d6d54d7c8547f4c6b77c"},"payload":{}}
At this point the device kills off the AP and connects to the wifi as a client with your creds. It also connects to your mqtt and starts spitting out these packets on mqtt for a minute or so...(Just ignore them)...
{"topic":"/appliance/1712281825467829030134298f151c4a/publish","payload":{"header":{"messageId":"4b6d025610d34772f7557e0895932017","namespace":"Appliance.System.Clock","method":"PUSH","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":6,"timestampMs":764,"sign":"043d8b1186fd82585b1b5cb99aca1b4c"},"payload":{"clock":{"timestamp":6}}},"qos":1,"retain":false,"_msgid":"ada1a8f6.099998"}
Finally it spits out these:
{"topic":"/appliance/1712281825467829030134298f151c4a/publish","payload":{"header":{"messageId":"ea8ce034afb7877cd42d917a49f0466d","namespace":"Appliance.System.Report","method":"PUSH","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1592881013,"timestampMs":946,"sign":"9114670c20d2f7cadfe76cc30f924def"},"payload":{"report":[{"type":"1","value":"0","timestamp":1592881013}]}},"qos":1,"retain":false,"_msgid":"6f095f1d.7f4db"}
{"topic":"/appliance/1712281825467829030134298f151c4a/publish","payload":{"header":{"messageId":"018a0f42515e9b4e85f554ee92b37c80","namespace":"Appliance.Control.Bind","method":"PUSH","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1592881013,"timestampMs":955,"sign":"6ccbfb3bb4d103cbe1f65d408e679bb2"},"payload":{"bind":{"bindTime":1592881013,"time":{"timestamp":1592881013,"timezone":"","timeRule":[]},"hardware":{"type":"mss425","subType":"us","version":"1.0.0","chipType":"MT7687","uuid":"1712281825467829030134298f151c4a","macAddress":"xx:xx:xx:xx:xx:xx"},"firmware":{"version":"1.1.10","compileTime":"2018-01-11 09:09:11","wifiMac":"c0:xx:xx:xx:xx:xx","innerIp":"192.168.2.136","server":"192.168.2.xx","port":2001,"secondServer":"","secondPort":0,"userId":0}}}},"qos":1,"retain":false,"_msgid":"479b06d0.802cd8"}
and...
{"topic":"/appliance/1712281825467829030134298f151c4a/publish","payload":{"header":{"messageId":"0dfd16d5565f50663060421a98038acc","namespace":"Appliance.Control.ToggleX","method":"PUSH","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1592881015,"timestampMs":985,"sign":"92f13df48fbfe5c86ac57449844f6802"},"payload":{"togglex":[{"channel":0,"onoff":1,"lmTime":1592881015},{"channel":1,"onoff":1,"lmTime":1592881015},{"channel":2,"onoff":1,"lmTime":1592881015},{"channel":3,"onoff":1,"lmTime":1592881015},{"channel":4,"onoff":1,"lmTime":1592881015},{"channel":5,"onoff":1,"lmTime":1592881015}]}},"qos":1,"retain":false,"_msgid":"3e9f54d7.53486c"}
The mss425 powerstrip has 2 usb and 3 power outputs [and one to handle them all at once] as seen above. It also spits them out 1 at a time in 6 more packets.... Then it shuts up waiting for input mqtt packets....
Hope this helps...
[its been a little sanitized]
-Stan
no luck... i don't see anything different in your request than in mine
$ ./meross setup --gateway 10.10.10.1 --wifi-ssid <SSID> --wifi-pass <PASS> --mqtt 192.168.1.42:8883
Setting up device with IP 10.10.10.1
Setting MQTT servers [ { host: '192.168.1.42', port: '8883' } ]
sending payload
{
"header": {
"method": "SET",
"namespace": "Appliance.Config.Key",
"messageId": "1"
},
"payload": {
"key": {
"gateway": {
"host": "192.168.1.42",
"port": "8883"
},
"key": "1",
"userId": ""
}
}
}
response:
{ header:
{ messageId: '1',
namespace: 'Appliance.Config.Key',
method: 'SETACK',
payloadVersion: 1,
from: '/appliance/2001191627794425188548e1e9172d83/publish',
timestamp: 24,
timestampMs: 186,
sign: 'c7635bfd99248a2cdef8249ef7bfbef4' },
payload: {} }
sending payload
{
"header": {
"method": "SET",
"namespace": "Appliance.Config.Wifi",
"messageId": "2"
},
"payload": {
"wifi": {
"ssid": "<B64SSID>",
"password": "<B64PASS>"
}
}
}
response:
{ header:
{ messageId: '2',
namespace: 'Appliance.Config.Wifi',
method: 'SETACK',
payloadVersion: 1,
from: '/appliance/2001191627794425188548e1e9172d83/publish',
timestamp: 24,
timestampMs: 216,
sign: 'ef41d488755367316f04fc0e0e9dc9fc' },
payload: {} }
mqtt | 1592901732: New connection from 192.168.1.15 on port 8883.
mqtt | 1592901732: Socket error on client <unknown>, disconnecting.
mqtt | 1592901739: New connection from 192.168.1.15 on port 8883.
mqtt | 1592901739: Socket error on client <unknown>, disconnecting.
Hi @pciavald
When you set up mosquitto do the certificate lines point to the certificates you created?
cafile <- should be the file created in step 2 of the tutorial
certfile <- the file created in step 4
keyfile <- the file created in step 3
A couple of other pointers:
- set the common name for the server certificate to the IP of the MQTT server (192.168.1.42)
- don't set a passphrase. The only passphrase should be on the CA key
I just followed my instructions with an MSS310 fw: v2.1.14 and it connected just fine.
Hi @bytespider thank you for your reply. I had it wrong for the cert paths in mosquitto.conf, I've corrected the script to point it correctly and set the CN to the broker's IP. Still no luck though.
generate-certs.sh
# http://rockingdlabs.dunmire.org/exercises-experiments/ssl-client-certs-to-secure-mqtt
mkdir -p certs/{ca,broker}
cd certs/
wget https://github.com/owntracks/tools/raw/master/TLS/generate-CA.sh .
chmod +x generate-CA.sh
./generate-CA.sh
rm generate-CA.sh
mv ca.* ca/
mv `hostname -f`.{crt,key} ca/
rm `hostname -f`.csr
openssl genrsa \
-out broker/broker.key \
2048
openssl req \
-new \
-out broker/broker.csr \
-key broker/broker.key \
-subj "/CN=192.168.1.42/O=example.com"
openssl x509 \
-req \
-in broker/broker.csr \
-CA ca/ca.crt \
-CAkey ca/ca.key \
-CAserial ca/ca.srl \
-out broker/broker.crt \
-days 3650 \
-addtrust clientAuth
rm broker/broker.csr$ tree certs
certs
├── broker
│ ├── broker.crt
│ └── broker.key
└── ca
├── ca.crt
├── ca.key
├── ca.srl
├── homeserver.crt
└── homeserver.key
docker-compose.yml, mosquitto.conf still as per my previous post
@pciavald can you try adding tls_version tlsv1.1 to your mosquitto conf? Not that changing it on mine made any difference
Also perhaps try creating the certificates with this tutorial as I know those instructions work.
I tried just now with tls_version tlsv1.1 from plug reset to mqtt socket connection, on 2 different plugs to see if the first one was not faulty, but it's still not connecting successfully...
UPDATE i didn't see the tutorial, i'll check it out
@bytespider thank you so much, using this tutorial it worked. I tried it before and it did not work, for some other reason I guess. Now that I've got everything right, I'll repost here the full config in case someone comes here later.
set up Meross power plug to use mosquitto broker in docker
First generate the certificates needed for Mosquitto TLS
generate-certs.sh
mkdir -p certs/{ca,broker}
cd certs/
# CA
openssl genrsa \
-out ca/ca.key \
2048
openssl req \
-new \
-x509 \
-days 1826 \
-key ca/ca.key \
-out ca/ca.crt \
-subj "/CN=MQTT CA"
# broker
openssl genrsa \
-out broker/broker.key \
2048
openssl req \
-new \
-out broker/broker.csr \
-key broker/broker.key \
-subj "/CN=broker"
openssl x509 \
-req \
-in broker/broker.csr \
-CA ca/ca.crt \
-CAkey ca/ca.key \
-CAcreateserial \
-out broker/broker.crt \
-days 360
rm broker/broker.csrWrite the mosquitto config
mosquitto.conf
port 1883
listener 8883
require_certificate false
use_identity_as_username false
allow_anonymous true
cafile /mosquitto/certs/ca/ca.crt
certfile /mosquitto/certs/broker/broker.crt
keyfile /mosquitto/certs/broker/broker.key
Then up the mosquitto container (docker-compose up -d)
docker-compose.yml
version: '3'
services:
mqtt:
image: eclipse-mosquitto:latest
container_name: mqtt
restart: unless-stopped
volumes:
- ./mosquitto.conf:/mosquitto/config/mosquitto.conf
- ./certs:/mosquitto/certs
ports:
- 1883:1883 # without TLS
- 8883:8883 # TLS
- 9001:9001 # not sure if needed ?we're ready to configure the plug, get the tools:
git clone https://github.com/bytespider/Meross
cd Meross/bin/src
yarn # or npm ireset the plug (5s on button), connect to its wifi, then (in Meross/bin/src)
./meross setup --gateway 10.10.10.1 --wifi-ssid <your-ssid> --wifi-pass <your-pass> --mqtt <docker-host-ip>:8883check the logs of the mqtt broker (docker-compose logs -f) and you should see something like
mqtt | 1592914360: mosquitto version 1.6.10 starting
mqtt | 1592914360: Config loaded from /mosquitto/config/mosquitto.conf.
mqtt | 1592914360: Opening ipv4 listen socket on port 8883.
mqtt | 1592914360: Opening ipv6 listen socket on port 8883.
mqtt | 1592914362: New connection from 192.168.1.7 on port 8883.
mqtt | 1592914362: New client connected from 192.168.1.7 as fmware:2001198571866425188548e1e9172f18_gnuQsm8ueuuGpr4v (p1, c1, k30, u'48:e1:e9:17:2f:18').
next steps
specify the broker in HA
configuration.yml
mqtt:
broker: <broker-host-ip>Is there a good resource to understand how to connect the plug to Home Assistant to get live power consumption and toggle the plug ? I'm also new to Home Assistant and node-red.
Thanks all for your help and nice hack !
UPDATE added port and listener in mosquitto.conf so that it still listens on both 1883 and 8883 to allow connection in TLS from the plugs and without TLS from home assistant
Well done! I too have both ports open so other devices can run MQTT on a non TLS mode...
Glad you got it working and appreciate a clean link to configuring TLS 1.1.....
-Stan
Very nice guide guys, thanks.
i have some questions if you can answer: what are the commands to send to ON/OFF the plug?
Does the plug send power informations via MQTT? Or is it possible send an "info" command to retrieve it?
Is it possible to connect via MQTT but with user/pass authentication or it must be anonymous?
I wish it could be integrated with mqtt addons from HA.
I'im interested on doing it, just need some info :)
@Malaga82 i'm stuck with this too. Did you find any leads ?
nope, i haven't tested it since i was just interested in how it was working, didn't mind it's not really working 😄
I ended up resuming a dead project HERE : a docker container that connects to meross-cloud and then writes to an MQTT server, so i can publish and control from anywhere and manage it from another HA without many connection to cloud. And not strictly bounded to HA, since it's a separate container.
It's not your goal i know, and i personally like if there will be an offline alternative like sonoff has.
Good morning,
I had posted an issue with this question (#107) but since there seems to be some activity on this thread I thought I would ask it here. I am trying to integrate this functionality into HomeGenie via a Python Program. The issues I am running into may be related to HomeGenioe and the version of Python it is running.
I did install version 3.7 of Python on my Pi itself, and I can run the sniffer utility but what I am trying to accomplish is to get the API calls integrated into HomeGenie. What would be most helpful would be if someone has any of the Meross API Documentation and could share that with me - I think I could adapt the concepts here into what I need with that information. Any assistance would be most appreciated.
Hi,
I successfully setup one of my mss510m light switches with mosquitto broker following all of the suggestions posted here. The question now is, how do I go about turning on and off the light switch via MQTT?
I received these payloads from subscribing to the device at boot:
{ "header": { "messageId": "a8ca5a63b95dd73f7d72e0d075a3354a", "namespace": "Appliance.Control.ToggleX", "method": "PUSH", "payloadVersion": 1, "from": "/appliance/1903234239966639082034298f1db989/publish", "timestamp": 1595554327, "timestampMs": 31, "sign": "42772632988fcc70bdf54626db70d6d6" }, "payload": { "togglex": [ { "channel": 0, "onoff": 1, "lmTime": 1595554326 } ] } }
{ "header": { "messageId": "29e4c8f02f5819e958547f372ec31f89", "namespace": "Appliance.Control.ToggleX", "method": "PUSH", "payloadVersion": 1, "from": "/appliance/1903234239966639082034298f1db989/publish", "timestamp": 1595554328, "timestampMs": 42, "sign": "14a789d19c9d2c612f1ed58164bd054c" }, "payload": { "togglex": [ { "channel": 0, "onoff": 0, "lmTime": 1595554327 } ] } }
{ "header": { "messageId": "1aa5638bd26eaaaf17a0c1bc74d93e0e", "namespace": "Appliance.Control.Unbind", "method": "PUSH", "payloadVersion": 1, "from": "/appliance/1903234239966639082034298f1db989/publish", "timestamp": 1595554333, "timestampMs": 167, "sign": "1c35ca25e059068484465ac3c64fd5f8" }, "payload": {} }
{ "header": { "messageId": "2fb61555904675ab6f60182cfa5c0166", "namespace": "Appliance.Control.Bind", "method": "PUSH", "payloadVersion": 1, "from": "/appliance/1903234239966639082034298f1db989/publish", "timestamp": 1595554407, "timestampMs": 379, "sign": "eeaee58b0433dd2c22c62e4397a3b0b0" }, "payload": { "bind": { "bindTime": 1595554407, "time": { "timestamp": 1595554407, "timezone": "", "timeRule": [] }, "hardware": { "type": "mss510m", "subType": "us", "version": "3.0.0", "chipType": "mt7682", "uuid": "1903234239966639082034298f1db989", "macAddress": "xx:yy:zz:1d:b9:89" }, "firmware": { "version": "3.1.4", "compileTime": "2020/03/13 09:52:53 GMT +08:00", "wifiMac": "xx:yy:zz:a9:95:53", "innerIp": "192.168.0.xxx", "server": "192.168.0.xxx", "port": 8883, "userId": 0 } } } }
Thanks for any help
Hi,
Your first packet is the template for on/off ...
I talk to simple devices as such:
/appliance/1712281825467829030134298f151c4a/subscribe {"header":{"from":"/HaPi/MQTT","messageId":"990d2c73e566d3bb65bd90b4c305b4e2","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"d21e3d814c7377c7541a81a55964d7d1","timestamp":1557536254},"payload":{"togglex":{"channel":1,"onoff":1}}}
You will need to send it to your topic: /appliance/1903234239966639082034298f1db989/subscribe ...
The method has to be "SET". Same namesspace with a payload of togglex. Looks like yours has a channel number - follow your push format. You also have to sign the packet with the algorithm documented on this site in the wiki....
You should get a ACK packet back from the device....
See if that helps...
-Stan
I'm not getting an ACK from the device, but I am getting the SET which I guess is one of the three messages returned?
This is what I'm publishing:
{"header":{"from":"/appliance/1903234239966639082034298f1db989/publish","messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"6cd13c252a437b4452f647485f6cd4c8","timestamp":1557536254},"payload":{"togglex":{"channel":1,"onoff":1}}}
What is coming back:
{header:{from:/appliance/1903234239966639082034298f1db989/publish,messageId:a8ca5a63b95dd73f7d72e0d075a3354a,method:SET,namespace:Appliance.Control.ToggleX,payloadVersion:1,sign:6cd13c252a437b4452f647485f6cd4c8,timestamp:1557536254},payload:{togglex:{channel:1,onoff:1}}}
It appears your item coming back is a echo. (no change on thee timestamp).
It also seems you are talking to the wrong topic. Yous send commands to '/appliance/your number/subscribe'. The devices will respond on '/appliance/your number/publish'. This may fix your issue.
You should see your SET packet, followed by a transmission from the device called a SETACK. Then the device will push a status packet - the PUSH you saw when initialized.
Let me know if that helps...
-Stan
I'm not sure what I'm doing wrong now. I am publishing this on the subscribe topic but now not even getting the echo back:
/appliance/1903234239966639082034298f1db989/subscribe "{"header":{"from":"/appliance/1903234239966639082034298f1db989/subscribe","messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"6cd13c252a437b4452f647485f6cd4c8","timestamp": 1595708731},"payload":{"togglex":{"channel":1,"onoff":1}}}"
Before I published the above, I reset the device and ran the setup again but only this time I got the Report and Bind messages and not the ToggleX like before.
So I think you need to get a handle on the traffic going on. I would suggest a independent monitoring tool for the mqtt traffic. I would suggest something like MQTT Explorer (free). You could also run a instance of Node Red and set a MQTT receiver to /application/# for a topic and run it to the debug log...
The ack which is sent from the device is sent to the from line in your request. Unless you are listening to that topic
you will not see it. IF the set is successful you will get a push to show the status after the command executes. I use something like /appliance/MEROSS_driver for my from - and watch for responses there [acks]
I note you are not including a timestamp field. That may be ok - but I am using one.
I cannot remember what happens with a messed up signature, if I get time tonight - I'll run a couple of test cases...
BTW, what happens when you turn on and off the device manually? It should generate a push to the /publish topic on each change...
-Stan
So yes - the timestamp is required as it is a part of the sign calculation and thus the decode on the other end.
Without it being there - I get a response with method = error...
Note the reason these look a little funny is that they are from Node Red. It packs extra MQTT data at the end of the packet...[like topic]
Here is what I send - like yours with no timestamp...
{"payload":{"header":{"from":"/appliance/HaPi/MeRossDriver","messageId":"6a21502fa5a13e0999a9a0a188153e4a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"1d3f4f85979e1ddae3257f131fe806f3"},"payload":{"togglex":{"channel":1,"onoff":1}}},"_msgid":"a72a8fc.043aa7","topic":"/appliance/1712281825467829030134298f151c4a/subscribe","qos":2,"retain":"false"}
response...
{"topic":"/appliance/HaPi/MeRossDriver","payload":{"header":{"messageId":"6a21502fa5a13e0999a9a0a188153e4a","namespace":"Appliance.Control.ToggleX","method":"ERROR","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1595722282,"timestampMs":176,"sign":"f1446105b428699c52b67f3d94e9f551"},"payload":{"error":{"code":5001,"detail":"sign error"}}},"qos":1,"retain":false,"_msgid":"f75ecc94.6c6cc"}
As a experiment - I put back the timestamp and messed up the signature routine and got the same method error response...
So bottom line your should be seeing responses if you are really sending commands.... (and you have to have the timestamp field in your commands)
I hope this helps...
-Stan
Thanks for all your help thus far, I'm still not able to get messages flowing.
When I flick the light switch on and off like you suggested, I do see messages for both states.
I just can't seem to get the publish command to publish anything. I don't know if it's syntax or content or both.
I'm subscribing to both the /appliance/number/publish and the same 'from' topic as you but both do not receive anything.
This is my complete publish command to the /appliance/number/subscribe topic:
mosquitto_pub -h 192.168.0.xxx -p 8883 -m "{"header":{"from":"/appliance/HaPi/MeRossDriver","messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"36af237230694e2916d3bfd9c29539bb","timestamp":1595739458},"payload":{"togglex":{"channel":1,"onoff":1}}}" -t "/appliance/1903234239966639082034298f1db989/subscribe" --cafile /etc/mosquitto/certs/ca/ca.crt -d --insecure
subscriptions
mosquitto_sub -h 192.168.0.xxx -p 8883 -t "/appliance/1903234239966639082034298f1db989/publish" --cafile /etc/mosquitto/certs/ca/ca.crt -d --insecure
mosquitto_sub -h 192.168.0.xxx -p 8883 -t "/appliance/HaPi/MeRossDriver/" --cafile /etc/mosquitto/certs/ca/ca.crt -d --insecure
I really appreciate your time in helping me.
I redid the 'sign' algorithm a couple of times as from what I've read, it has to be a timestamp and not just 0. The 'timestamp' field is the same timestamp as what is in the algorithm. Even if I omit the timestamp and sign elements, nothing happens at all.
Your packet looks good and it appears receive is functioning. My guess is that something is wrong with the mosquitto_pub command. Its been awhile since I make that work, but I'll play with it some tomorrow... Its seems like you have to tell it to use tls v1.1 if my memory is correct... [wrong, not necessary - see below]
-Stan
OK - I stayed up.... Using mosquitto_pub is a little troublesome. The json is getting mangled by linux, so you have to escape the double quotes..... I got this to send to my device....
Everywhere you want a " you must use a \ followed by ". You cannot type it here as the editor removes the escaping.
I changed ip, port to my local server. I used a local device id for the topic. Here is the command/response...
/appliance/1712281825467829030134298f151c4a/subscribe {"header":{"from":"/appliance//appliance/1903234239966639082034298f1db989/subscribeHaPi/MeRossDriver","messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"36af237230694e2916d3bfd9c29539bb","timestamp":1595739458},"payload":{"togglex":{"channel":1,"onoff":1}}}
/appliance//appliance/1903234239966639082034298f1db989/subscri {"header":{"messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","namespace":"Appliance.Control.ToggleX","method":"ERROR","payloadVersion":1,"from":"/appliance/1712281825467829030134298f151c4a/publish","timestamp":1595745843,"timestampMs":938,"sign":"31705538988619c5dea5250c2ceb7869"},"payload":{"error":{"code":5001,"detail":"sign error"}}}
Note the quotes come through on pub...
This is my monitoring command [in another console]
mosquitto_sub -v -h 192.168.2.25 -p 1883 -t "#" -u "mqtt_user" -P "dhdfhfhhdhjdhd"
Try this.... You really may want to install Node Red - its so much easier to send and receive mqtt packets with...
-Stan
As a FYI, this is my mosquitto.conf file...
# Place your local configuration in /etc/mosquitto/conf.d/
#
# A full description of the configuration file is at
# /usr/share/doc/mosquitto/examples/mosquitto.conf.example
pid_file /var/run/mosquitto.pid
bind_address 192.168.2.25
per_listener_settings true
port 1883
persistence true
persistence_location /var/lib/mosquitto/
allow_anonymous false
password_file /etc/mosquitto/p1.txt
#log_type debug
connection_messages true
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d
listener 2001
#log_type debug
cafile /etc/mosquitto/certs/m2mqtt_ca.crt
certfile /etc/mosquitto/certs/m2mqtt_srv.crt
keyfile /etc/mosquitto/certs/m2mqtt_srv.key
require_certificate false
allow_anonymous true
tls_version tlsv1.1
Thanks for providing so much info!
The response is not liking the 'sign' I'm providing - similar to the sample you shared - and I think it's the timestamp portion. I'm getting Unix epoch time from the web and putting it in the algorithm, but I think it doesn't like it because it's old by the time I send the message. Is that right?
How can I auto generate the timestamp field and also put that value in the algorithm on the fly? My coding skills are not sufficient for this part.
At least I'm getting some message back now. Node Red I'll have to look into...
Its great news that you are at least talking to the device and seeing a response. You realize I copied your packet and just adjusted the topic - and thats why I got the error....
The time between when you get the timestamp and when its processed does not matter. The timestamp is just another item included in the computation of the signature. When it is received on the device, that same timestamp is used in the verification of the signature. The real time has nothing to do with it...
I'll post the code I am using in Node Red to add the message id, timestamp and sign...
to follow...
-Stan
First - remember the key you set during the set up IS used in this calculation....
Here is the java....
`
var date = new Date();
var timestamp = date.getTime();
function randomString(length, chars) {
var result = '';
for (var i = length; i > 0; --i) result += chars[Math.floor(Math.random() * chars.length)];
return result;
}
var MD5 = function(s) {
function L(k,d) { return(k<<d)|(k>>>(32-d))}
function K(G,k){var I,d,F,H,x;F=(G&2147483648);H=(k&2147483648);I=(G&1073741824);d=(k&1073741824);x=(G&1073741823)+(k&1073741823);if(I&d){return(x^2147483648^F^H)}if(I|d){if(x&1073741824){return(x^3221225472^F^H)}else{return(x^1073741824^F^H)}}else{return(x^F^H)}}
function r(d,F,k){return(d&F)|((~d)&k)}
function q(d,F,k){return(d&k)|(F&(~k))}
function p(d,F,k){return(d^F^k)}
function n(d,F,k){return(F^(d|(~k)))}
function u(G,F,aa,Z,k,H,I){G=K(G,K(K(r(F,aa,Z),k),I));return K(L(G,H),F)}
function f(G,F,aa,Z,k,H,I){G=K(G,K(K(q(F,aa,Z),k),I));return K(L(G,H),F)}
function D(G,F,aa,Z,k,H,I){G=K(G,K(K(p(F,aa,Z),k),I));return K(L(G,H),F)}
function t(G,F,aa,Z,k,H,I){G=K(G,K(K(n(F,aa,Z),k),I));return K(L(G,H),F)}
function e(G){var Z;var F=G.length;var x=F+8;var k=(x-(x%64))/64;var I=(k+1)*16;var aa=Array(I-1);var d=0;var H=0;while(H<F){Z=(H-(H%4))/4;d=(H%4)*8;aa[Z]=(aa[Z]| (G.charCodeAt(H)<<d));H++}Z=(H-(H%4))/4;d=(H%4)8;aa[Z]=aa[Z]|(128<<d);aa[I-2]=F<<3;aa[I-1]=F>>>29;return aa}
function B(x){var k="",F="",G,d;for(d=0;d<=3;d++){G=(x>>>(d8))&255;F="0"+G.toString(16);k=k+F.substr(F.length-2,2)}return k}
function J(k){k=k.replace(/rn/g,"n");var d="";for(var F=0;F<k.length;F++){var x=k.charCodeAt(F);if(x<128){d+=String.fromCharCode(x)}else{if((x>127)&&(x<2048)){d+=String.fromCharCode((x>>6)|192);d+=String.fromCharCode((x&63)|128)}else{d+=String.fromCharCode((x>>12)|224);d+=String.fromCharCode(((x>>6)&63)|128);d+=String.fromCharCode((x&63)|128)}}}return d}var C=Array();var P,h,E,v,g,Y,X,W,V;var S=7,Q=12,N=17,M=22;var A=5,z=9,y=14,w=20;var o=4,m=11,l=16,j=23;var U=6,T=10,R=15,O=21;s=J(s);C=e(s);Y=1732584193;X=4023233417;W=2562383102;V=271733878;for(P=0;P<C.length;P+=16){h=Y;E=X;v=W;g=V;Y=u(Y,X,W,V,C[P+0],S,3614090360);V=u(V,Y,X,W,C[P+1],Q,3905402710);W=u(W,V,Y,X,C[P+2],N,606105819);X=u(X,W,V,Y,C[P+3],M,3250441966);Y=u(Y,X,W,V,C[P+4],S,4118548399);V=u(V,Y,X,W,C[P+5],Q,1200080426);W=u(W,V,Y,X,C[P+6],N,2821735955);X=u(X,W,V,Y,C[P+7],M,4249261313);Y=u(Y,X,W,V,C[P+8],S,1770035416);V=u(V,Y,X,W,C[P+9],Q,2336552879);W=u(W,V,Y,X,C[P+10],N,4294925233);X=u(X,W,V,Y,C[P+11],M,2304563134);Y=u(Y,X,W,V,C[P+12],S,1804603682);V=u(V,Y,X,W,C[P+13],Q,4254626195);W=u(W,V,Y,X,C[P+14],N,2792965006);X=u(X,W,V,Y,C[P+15],M,1236535329);Y=f(Y,X,W,V,C[P+1],A,4129170786);V=f(V,Y,X,W,C[P+6],z,3225465664);W=f(W,V,Y,X,C[P+11],y,643717713);X=f(X,W,V,Y,C[P+0],w,3921069994);Y=f(Y,X,W,V,C[P+5],A,3593408605);V=f(V,Y,X,W,C[P+10],z,38016083);W=f(W,V,Y,X,C[P+15],y,3634488961);X=f(X,W,V,Y,C[P+4],w,3889429448);Y=f(Y,X,W,V,C[P+9],A,568446438);V=f(V,Y,X,W,C[P+14],z,3275163606);W=f(W,V,Y,X,C[P+3],y,4107603335);X=f(X,W,V,Y,C[P+8],w,1163531501);Y=f(Y,X,W,V,C[P+13],A,2850285829);V=f(V,Y,X,W,C[P+2],z,4243563512);W=f(W,V,Y,X,C[P+7],y,1735328473);X=f(X,W,V,Y,C[P+12],w,2368359562);Y=D(Y,X,W,V,C[P+5],o,4294588738);V=D(V,Y,X,W,C[P+8],m,2272392833);W=D(W,V,Y,X,C[P+11],l,1839030562);X=D(X,W,V,Y,C[P+14],j,4259657740);Y=D(Y,X,W,V,C[P+1],o,2763975236);V=D(V,Y,X,W,C[P+4],m,1272893353);W=D(W,V,Y,X,C[P+7],l,4139469664);X=D(X,W,V,Y,C[P+10],j,3200236656);Y=D(Y,X,W,V,C[P+13],o,681279174);V=D(V,Y,X,W,C[P+0],m,3936430074);W=D(W,V,Y,X,C[P+3],l,3572445317);X=D(X,W,V,Y,C[P+6],j,76029189);Y=D(Y,X,W,V,C[P+9],o,3654602809);V=D(V,Y,X,W,C[P+12],m,3873151461);W=D(W,V,Y,X,C[P+15],l,530742520);X=D(X,W,V,Y,C[P+2],j,3299628645);Y=t(Y,X,W,V,C[P+0],U,4096336452);V=t(V,Y,X,W,C[P+7],T,1126891415);W=t(W,V,Y,X,C[P+14],R,2878612391);X=t(X,W,V,Y,C[P+5],O,4237533241);Y=t(Y,X,W,V,C[P+12],U,1700485571);V=t(V,Y,X,W,C[P+3],T,2399980690);W=t(W,V,Y,X,C[P+10],R,4293915773);X=t(X,W,V,Y,C[P+1],O,2240044497);Y=t(Y,X,W,V,C[P+8],U,1873313359);V=t(V,Y,X,W,C[P+15],T,4264355552);W=t(W,V,Y,X,C[P+6],R,2734768916);X=t(X,W,V,Y,C[P+13],O,1309151649);Y=t(Y,X,W,V,C[P+4],U,4149444226);V=t(V,Y,X,W,C[P+11],T,3174756917);W=t(W,V,Y,X,C[P+2],R,718787259);X=t(X,W,V,Y,C[P+9],O,3951481745);Y=K(Y,h);X=K(X,E);W=K(W,v);V=K(V,g)}
var i=B(Y)+B(X)+B(W)+B(V);
return i.toLowerCase()
};
msg.payload.header.timestamp = parseInt(timestamp/1000);
var rnd_string = randomString(16,'0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ');
msg.payload.header.messageId = MD5(rnd_string);
//msg.payload.header.sign = 1;
msg.payload.header.sign = MD5(msg.payload.header.messageId + flow.get("key") + msg.payload.header.timestamp);
return msg;
`
I'm starting with a clean slate because I think I messed the process up the first time around.
My understanding is this:
From my home network, POST to iot.meross.com as per the wiki, to obtain the key needed for MQTT communication.
Once the POST response is received, connect to the device AP and run the meross setup.
Like another user experienced, the response I get from the POST is
{ "apiStatus": 1023, "sysStatus": 0, "data": null, "info": "Sign check failed", "timeStamp": "2020-07-27 19:15:35" }
I read your response to the error, but I cannot quite make sense of the procedure.
So it is true we both may be confused at what you are attempting. This web site /project is about some routines which can control MEROSS devices in conjunction with the MEROSS iot server. albertogeniola has some beautiful code set up for this.
However, a few of us are highly disturbed with our devices going out of our local network for this type of traffic. This is where this thread started. albertogeniola figured out how the device initializes and bytespider came up with a real nice piece of code which will simply program a MEROSS device to your local MQTT server on device initialization. With this approach - the MEROSS iot server is NOT involved in anyway with transactions to your devices... This is what I thought we were debugging - I apologize if I misinterpreted your direction...
If your are attempting to be "off the MEROSS network', then the following applies....
[bytespiders software does this once your connected to the device AP] On device initialization the device becomes a WIFI AP and you must connect to that WIFI at something other than 10.10.10.1. (i.e 10.10.10.10) The software sends a couple JSON packets over http to 10.10.10.1 to initialize the device. These packets contain, wifi SSID, userid password, MQTT server, sign key.... Once the device gets these packets correctly, it reboots and attaches to the wifi with the info sent and then attaches to the MQTT server sent. The key necessary for packet signature is something YOU supply during the init proceedure. If you use bytespiders init routine he sends "" for a key so it falls out of the calculation (no key) so the sign is computation is simply
MD5(msg.payload.header.messageId + msg.payload.header.timestamp);
This is java simply concatenating the string messageId with the string converted timestamp then creating a MD5 hash from the result.
so taking your packet
{"from":"/appliance/HaPi/MeRossDriver","messageId":"a8ca5a63b95dd73f7d72e0d075a3354a","method":"SET","namespace":"Appliance.Control.ToggleX","payloadVersion":1,"sign":"36af237230694e2916d3bfd9c29539bb","timestamp":1595739458},"payload":{"togglex":{"channel":1,"onoff":1}}}"
We take the messagid 'a8ca5a63b95dd73f7d72e0d075a3354a' concatenate timestamp '1595739458' and the result is:
a8ca5a63b95dd73f7d72e0d075a3354a1595739458
the MD5 hash is:
90CDEDC567659A9D8D1B14C8D4C013C3
You can try using this as the sign in the packet and see what happens.... (it will only work if you are using bytespider code to init the device OR your own code is supplying "" for a key)
-Stan
Thanks for your patience. I was definitely confused in how I was approaching this. I do want to eliminate the MEROSS cloud.
I followed your instructions, and now I am receiving the SETACK as well as the PUSH and ultimately turning on and off my light switches!!
For my light switches I'm publishing this for off.
"{\"header\":{\"from\":\"/appliance/HaPi/MeRossDriver\",\"messageId\":\"a8ca5a63b95dd73f7d72e0d075a3354a\",\"method\":\"SET\",\"namespace\":\"Appliance.Control.ToggleX\",\"payloadVersion\":1,\"sign\":\"90cdedc567659a9d8d1b14c8d4c013c3\",\"timestamp\":1595739458},\"payload\":{\"togglex\":{\"channel\":0,\"onoff\":0}}}"
and this for on.
"{\"header\":{\"from\":\"/appliance/HaPi/MeRossDriver\",\"messageId\":\"a8ca5a63b95dd73f7d72e0d075a3354a\",\"method\":\"SET\",\"namespace\":\"Appliance.Control.ToggleX\",\"payloadVersion\":1,\"sign\":\"90cdedc567659a9d8d1b14c8d4c013c3\",\"timestamp\":1595739458},\"payload\":{\"togglex\":{\"channel\":0,\"onoff\":1}}}"
Can't thank you enough!
Now on to free my MEROSS garage door...
Wonderful....
Now you just need a code base to create unique ids, update timestamps, and computer MD5 's for the signature for each message....;-)
Really glad you got it....
-Stan
Hi again @shodge12 , I've now setup my mqtt server with username/password and trying to reconnect all of my meross devices. When I run the setup utility, the command does not take and the device light keeps flashing. Is there a way to specify the mqtt username and password in the setup command? I'm not sure how to get through this obstacle and so hoping you'll be kind enough to help again.
Hi again....
Hmm I am not using a userid password on my secure port, only on my unsecure port (likely stupid but it is not exposed to the internet). I looked at the packet template I am using in node red and see the following:
{
"header": {
"messageId": "1",
"method": "SET",
"namespace": "Appliance.Config.Key"
},
"payload": {
"key": {
"gateway": {
"host": "{{{flow.MQTT_Address}}}",
"port": "{{{flow.MQTT_Port}}}"
},
"key": "{{{flow.key}}}",
"userId": ""
}
}
}
Obviously host and port are the mqtt server, but there is a userId which I have set to "". This ether came from albert or bytespider and they may have more insight. Your also may look at the config responses to see if the fields show up there....
Bottom line - I don't know if userid password is supported on the meross devices on attaching to the local mqtt server. It appears there is a userId field but as to the password????
Hope this helps..
-Stan
Hi colin,
All that is here is getting mqtt to talk to meross. Anything higher level is for another group.
-Stan
Hello all,
I spent a day of horror not managing to get the Meross MSS310 plug to connect to my MQTT server in a docker container.
I tried all instructions many times and finally decided to abandon and give a try to the actual Meross app in my mobile... Maybe it'll do a firmware update...
So I configure the plug, I give my location and wifi password to an evil company and the plug works ok on the app.
Just before going to bed, I decide to reset the plug and randomly start the setup command a last time before I'll send everything in fire. The led turns green and I get a connection in my MQTT log...
@pciavald and @bytespider, do we actually need to connect to Meross at some point to get the plug activated ?
@rfenouil as far as I have seen, no, but its possible your device had old firmware that predates this work
Ok it actually needs an access to internet to be able to connect to my local MQTT server.
Forbidding plug access to internet (from router confguration) just does not allow to get the solid green light, even though it can access local network and MQTT server.
Can you confirm this on your configuration ?
Do you know what it actually does or connects to ?
My firmware version is 2.1.9
@bytespider Thank you for your answer.
It looks like my plug tries to do something online and does not even try to connect to MQTT server before it's done.
Maybe this behavior could explain why @bgnt44 experienced some problems with plugs not reconnecting to local MQTT server, internet connection was maybe not up yet.
I always forbid internet access to my iot devices, they always try to get/send stuff there...
Ok it actually needs an access to internet to be able to connect to my local MQTT server.
Forbidding plug access to internet (from router confguration) just does not allow to get the solid green light, even though it can access local network and MQTT server.
Can you confirm this on your configuration ?Do you know what it actually does or connects to ?
On mss310 with local mqtt, i get solid green in this case. I can operate the plug (on/off) and read state through http and mqtt, but voltage and power reading report 0. If I enable internet access, they start working again after power cycle.
AFAIK it needs wan access port port 443 on some AWS hosts with wildcard certificate *.meross.com, and also to port 123 (NTP). Port 53 for dns, which may be overriden internally if you pass a valid DNS server on your network.
Hi guys,
I've started to work on this matter. It will definetely help integrations as HomeaAssistant, which require higher polling rates with respect to the limits imposed by the Meross mqtt broker.
Thanks to the work of many guys in here (especially @bytespider), I'm starting to write some more specific documentation about the pairing protocol, which will help people to develop their own pairing systems/ecosystems for Meross devices.
For the moment, I can cofirm that connecting Meross plugs to self-hosted MQTT broker is possible.
I encourage everyone on this thread to review and velidate the docs I am writing: https://albertogeniola.github.io/MerossIot/meross-protocol.html.
I encourage everyone on this thread to review and velidate the docs I am writing
Ciao Alberto,
This is such a great news!
What I did was just following Bytespider's instructions literally. It works perfectly, I just see 2 issues:
-
I need to let plugs access wan on startup, otherwise I get flashing green light. I sniffed some kind of traffic to mqtt.meross.com:443 and some ntpv4 servers.
-
I get non power readings in mqtt topic or with a curl to the plug either (always reports 0 volt and 0 watt). On/off/status work (via curl, I did not understand how to send these via mqtt). On MSS310.
Cheers!
Hi @override80 ,
Thanks a lot. I will check what does the plug get from the HTTP api at startup. I did not realize that since my LAN has WAN access (via gateway), so WAS access is still possible for the plug. That sure complicates things as to intercept that call we need some sort of http server responding as mqtt.meross.com on the local network. However, I suppose there is some setting we can change during the pairing process to tell the plug which domain to contact, making it point to some local http server instead.
Hi @albertogeniola it lloks that today i get a solid green even after blocking WAN. I still don't undestand why i receive an ampty payload when doing a curl:
[OMISSIS]
"payload": {
"electricity": {
"channel": 0,
"current": 0,
"voltage": 0,
"power": 0,
"config": {
"voltageRatio": 188,
"electricityRatio": 100
}
}
}
}
Current, voltage and state should (?) be pushed to local mqtt, but doing a: mosquitto_sub -h 10.10.10.98 -p 9883 --cafile ca.crt -t '#' -v
shows an empty queue, just see some Appliance.System.Clock passing by on startup.
If I open WAN, the previous curl works:
[OMISSIS]
"payload": {
"electricity": {
"channel": 0,
"current": 54,
"voltage": 2350,
"power": 6053,
"config": {
"voltageRatio": 188,
"electricityRatio": 100
}
}
}
}
Yet I see no consumption/electricity reading in the pubsub queue.
Hi @albertogeniola !
Very glad you are interested in taking your code base local. This can give these devices a long and safe life.
As stated previously I have a working node-red flow which makes use of you and bytespiders work to use devices locally. Its been working for over a year. It is from that base which I have offered occasional help here for those trying to go local.
I can offer a couple of pieces of data...
-
I just cut off internet access from both nic addresses and can confirm - no traffic is moving during pairing process or during access for the MSS425 [addressable power strip] or MSS560m [wall dimmer module].
-
On rare occasion [like the MQTT server re-boot or power fail], the MSS560m dimmer will get into a partial config mode. It has a IP address, but will not talk via MQTT. This unit requires a manual re-config to bring it back online. The MSS425 does not have this issue.
FYI...
-Stan