Skip to content

Operation

Jump to bottom
shodge12 edited this page May 31, 2019 · 7 revisions

Meross Driver Flow Operation

Before starting, you have already configured your MQTT broker for tls operation, loaded the flow into Node-Red, configured the MQTT nodes in the flow to your MQTT server, and set up the configuration parameters as shown in the setup page.

Meross Pairing Mode

Step 1 - Get the device in 'Pairing' mode

You may have to consult the device instructions. Normally the Meross device has a power switch of some kind. Depress this switch and hold it for 5+ seconds. This will usually start the device status LED to start blinking and / or change color. At this point the device should be in pairing mode and the wireless AP from the device should be active.

I might suggest opening a MQTT monitoring window before moving on so you can see when you are configured... This can be accomplished on Mosquitto by....

mosquitto_sub -v -h 192.168.X.XX -p 1883 -t "#" -u "user" -P "password"

Configure the computer running the Node-Red driver to bind to the SSID provided by the Meross device. If successful you should optain a ip of 10.10.10.2.

Step 2 - Pairing Mode in the flow

The flow is setup to automatically detect a meross device by pinging 10.10.10.1 at 2 minute intervals. When reply is seen, the driver will automatically configure the Meross device with the parameters loaded. At this point, if successful, the device will reset, reboot, log into your wireless network and finally into your MQTT broker.

You can enable the two debug nodes 'HTTP Response' and 'WiFi ACK' to monitor the divers progress.

Note if you have reasonable responses and a ACK during the config process - look at your local DHCP server to see if the Meross device has requested a local IP. Obviously the real success is to see MQTT traffic from the Meross nodes.

Step 3 - Generate MQTT Traffic from the Meross device

The driver creates a simple database to associate the 32 character long ids with the 7 character short ids and a parameter to identify if the device is dimmable. This data array, maintained at the flow level is created automatically upon reception of Meross device MQTT traffic. So manually toggle your Meross devices on and off and if they are dimmable - change the brightness. I have 2 Meross devices and my database looks as follows (this can be examined by going to context data and looking for the variable ids under flow):

ids:
[
    {
    "longID":"1712281825467829030134298f151c4a",
    "shortID":"51c4a00",
    "Capibilities":1
    },
    {
    "longID":"1812144891717229088234298f196791",
    "shortID":"9679100",
    "Capibilities":3
    }
]

Note - the ids database is stored locally and loaded from that file to give persistence through power fails etc...

After you get the driver to create this array by listening to your Meross Devices, you are ready to sent some test commands...

Step 4 - Send Test Commands to the device

There are two different areas of the flow which have been set up to allow experimental sending of commands to Meross devices. On the left side of the flow, the 4th input node down is named '(Test) Device On'. This node and the following input nodes (in a downward direction), are used to send test messages to Meross devices through the main Meross command section. These input nodes are prewired to send onoff, dim, and device info commands. Note that this section is the RAW Meross command generation, so FULL uniqueIDs and Meross standard topics are required for inputs. Lets look at what is required for all three types of commands...

Note the following narrative alters several input nodes to specific parameters
tied to your devices.  These changes in no way will affect the operation of the
overall generic driver and are merely for educational / troubleshooting value.
The values changed need NOT be changed back to there original configuration.

  1. 'onoff' If you examine the contents of the '(Test) Device On' node you will find the payload defined as the following:

    {
    "topic": "\appliance\(32 character unique ID)\subscribe",
    "channel": "0,"
    "onoff": "1"
}

    Obviouslly, the 32 character unique ID must be one from your target devices. This can come from watching the debug node 'Watch Meross' as you manually turn it on and off. Channel is typically '0' unless your Meross device has multiple controls. For example channel 0-5 is valid for the MSS425 power strip [0 controls outputs 1-5 together, 1-3 is the AC power Outputs, and 4-5 are the USB outputs]. Once the unique ID is set to your device and the channel is set, a click on the input node should cause a generation of a full Meross message to turn you device on. Again, this presupposes you have your device paired on your local net and to your local MQTT broker. The Next 2 input nodes are configured in the same fashion. Properly configured you can toggle a device on and off with these input nodes.

  2. "lumanance" If you examine the contents of the "(Test) Set Lumanance Level 10" node you will find the payload defined as following:

    {
    "topic": "\appliance\(32 character unique ID)\subscribe",
    "channel": "0,"
    "lumanance": "10"
}

    As previously noted, the 32 character unique ID must be one from your target devices and the channel must be for the Meross output in question - typically 0. "lumanance" is the dim value for the device (0-100). Note the device must support this - i.e. sending a lumanance command to a strickly onoff device will likely result in a ACK error from the device which are NOT handled. Again, by changing the lumanance input nodes to your dimmable device you should be able to send dim commands simply by clicking on the input node.

  3. "Device Info" If you examine the contents of the "Get Device Info..." node you will find the payload defined as following:

    {
    "topic": "\appliance\(32 character unique ID)\subscribe",
    "channel": "0,"
}

    As previously noted, the 32 character unique ID must be one from your target devices and the channel must be for the Meross output in question - typically 0. Here this generic information is supplied with specific directives to the Meross device to pull lots of internal information. This data is not used by the driver, but may be of use to the user. The driver does not offer a way to query this info, except in this manual mode through the inout node click. Adding this function to the driver would be an insignificant task, although parsing the data would be 'difficult'.

Step 5 - Send Test Commands to the device via the Homeseer 'simple' driver

In step #4, we sent commands to the Meross Device in its native mode. Specifically, this involved knowing the full subscribe topic of the device including it's unique 32 character ID and it's channel id. In this step we will use input nodes to simulate the reduced overhead of the Homeseer driver to the Meross devices.

About 2/3 of the way down the page on the left side, you will find another series of input nodes starting with "(Test) MQTT CMD Device ON". This section will guide you in building a couple of these input nodes to turn on / off and dim devices. Lastly we will have a brief discussion on the simplfied responses sent back to Homeseer which completes the driver.

Opening the input node "(Test) MQTT CMD Device ON" and examining the payload, you see the simplest driver playload yet:

{
    "topic": "\cmnd\(7 character shortID)\POWER",
    Payload: {
              "onoff": "1"
            }
}

As discussed in step #3, the shortID is the least significant 5 digits of the 32 character long ID, the number "0" and the channel number (single digit) all concatenated together. Section #3 shows examples of longIDs and shortIDs. The idea of of this payload is to simulate a MQTT packett comming into the driver at the topic specified with the payload as listed. Simple eh?

You can easily see how to take the next node and set it up with the same shortID you used with the payload "onoff" set to "0". Then testing the nodes by clicking the input node.

The dim command is similar, here is an example from the "(Test) MQTT CMD Level 10...":

{
    "topic": "\cmnd\(7 character shortID)\DIM",
    Payload: {
              "dim": "10"
            }
}

Status updates to Homeseer...

All outputs from the Meross devices in the form of "Push" status packetts are translated into the reduced packets and topics to Homeseer. The topics are as follows:

\stat\(7 character shortID)\POWER
\stat\(7 character shortID)\dim

payload packets for POWER:

Payload: {
          "device": "(7 character shortID)",
          "onof": "1"
        }

payload packets for DIM:

Payload: {
          "device": "(7 character shortID)",
          "dim": "10"
        }
Clone this wiki locally