search

krahabb / meross_lan

Home Assistant integration for Meross devices
MIT License
407 stars 45 forks source link

Add support for Meross lights (like the MSL120B) #12

Closed almico closed 3 years ago

almico commented 3 years ago

I have a Meross light bulb model MSL120B. It is not automatically detected by your component. This is the message it publishes when powered on:

{
    "header": {
        "messageId": "78d740c90859d05fc18036e7fb9e6c75",
        "namespace": "Appliance.Control.Light",
        "method": "PUSH",
        "payloadVersion": 1,
        "from": "/appliance/1912126573785090806548e1e9131505/publish",
        "timestamp": 1616667203,
        "timestampMs": 450,
        "sign": "71d77e14018753b9de7a1e055d626e2f"
    },
    "payload": {
        "light": {
            "onoff": 1,
            "capacity": 6,
            "channel": 0,
            "rgb": 16753920,
            "temperature": 100,
            "luminance": 100,
            "transform": 0
        }
    }
}
krahabb commented 3 years ago

Hello @almico, I've asked for help in device characterization. Is it possible for you to try query your device and post the responses as stated in #13?

That would boost me a lot! Thank you

almico commented 3 years ago

Response to Appliance.System.All:

{
  "header": {
    "messageId": "",
    "namespace": "Appliance.System.All",
    "method": "GETACK",
    "payloadVersion": 1,
    "from": "/appliance/1912916573785097176548e1e9131505/publish",
    "timestamp": 1616741314,
    "timestampMs": 824,
    "sign": "63afda35be000d072467231693a295e5"
  },
  "payload": {
    "all": {
      "system": {
        "hardware": {
          "type": "msl120b",
          "subType": "us",
          "version": "2.0.0",
          "chipType": "mt7682",
          "uuid": "1912916573785097176548e1e9131505",
          "macAddress": "xx:yy:zz:zz:yy:xx"
        },
        "firmware": {
          "version": "2.1.16",
          "compileTime": "2019/11/04 19:13:46 GMT +08:00",
          "wifiMac": "xx:yy:zz:zz:yy:xy",
          "innerIp": "192.168.1.68",
          "server": "192.168.1.212",
          "port": 8883,
          "userId": 0
        },
        "time": {
          "timestamp": 1616741314,
          "timezone": "",
          "timeRule": []
        },
        "online": {
          "status": 1
        }
      },
      "digest": {
        "togglex": [
          {
            "channel": 0,
            "onoff": 1,
            "lmTime": 0
          }
        ],
        "triggerx": [],
        "timerx": [],
        "light": {
          "onoff": 1,
          "capacity": 6,
          "channel": 0,
          "rgb": 16753920,
          "temperature": 100,
          "luminance": 100,
          "transform": 0
        }
      }
    }
  }
}

Response to Appliance.System.Ability:

{
  "header": {
    "messageId": "",
    "namespace": "Appliance.System.Ability",
    "method": "GETACK",
    "payloadVersion": 1,
    "from": "/appliance/1912916573785097176548e1e9131505/publish",
    "timestamp": 1616741414,
    "timestampMs": 957,
    "sign": "c0ff6d00cba5ce6746a967887f50c078"
  },
  "payload": {
    "payloadVersion": 1,
    "ability": {
      "Appliance.Config.Key": {},
      "Appliance.Config.WifiList": {},
      "Appliance.Config.Wifi": {},
      "Appliance.Config.Trace": {},
      "Appliance.System.All": {},
      "Appliance.System.Hardware": {},
      "Appliance.System.Firmware": {},
      "Appliance.System.Debug": {},
      "Appliance.System.Online": {},
      "Appliance.System.Time": {},
      "Appliance.System.Ability": {},
      "Appliance.System.Runtime": {},
      "Appliance.System.Report": {},
      "Appliance.System.Position": {},
      "Appliance.System.Factory": {},
      "Appliance.Control.Multiple": {
        "maxCmdNum": 5
      },
      "Appliance.Control.ToggleX": {},
      "Appliance.Control.TimerX": {
        "sunOffsetSupport": 1
      },
      "Appliance.Control.TriggerX": {},
      "Appliance.Control.Bind": {},
      "Appliance.Control.Unbind": {},
      "Appliance.Control.Upgrade": {},
      "Appliance.Control.Light": {
        "capacity": 7
      },
      "Appliance.Control.Effect": {
        "capacity": 1
      },
      "Appliance.Digest.TriggerX": {},
      "Appliance.Digest.TimerX": {}
    }
  }
}
krahabb commented 3 years ago

Hello @almico, I hope you could help me a bit with testing: did you try the latest release of meross_lan? I've added support for lights and I would really appreciate if you could post some feedback i.e. if it's working or whatever issue you are experiencing. Thank you

wsw70 commented 3 years ago

I don't know about the light but I switched to meross_lan from my own implementation and it rocks!

Thanks!

almico commented 3 years ago

Here I am 😃 I've been struggling setting up a test environment with users, passwords, certificates and everything else. I thought I had everything set up properly in place, but I am facing bulb disconnections from MQTT Broker if Meross LAN integration is enabled.

First question: when I install Meross LAN integration, it asks for a device key. What should I enter there? So far, I've entered what, in the next lines, I listed as "MYKEY".

Just to tell you a bit more on my setup:

Now I have disabled Meross LAN, otherwise, the bulb would endlessly try to reconnect to MQTT. This is an example message sequence in MQTT log when Meross LAN is enabled:

1618405683: New connection from 192.168.11.81 on port 8883.
1618405684: New client connected from 192.168.11.81 as fmware:1912126573785090806548e1e9131505_sHUo1G2Z9MIdhgY6 (p1, c1, k30, u'48:e1:e9:11:5f:9b').
1618405697: Socket error on client fmware:1912126573785090806548e1e9131505_sHUo1G2Z9MIdhgY6, disconnecting.
wsw70 commented 3 years ago

I configured the bulb with ...

You may want to consider using --mqtt twice (identical ones), this may have been fixed but without that your device would not reconnect to the MQTT broker if it is off for a moment

Now I have disabled Meross LAN, otherwise, the bulb would endlessly try to reconnect to MQTT.

Have you tried running tcpdump/wireshark to see which traffic goes through?

One thing I do not understand: MEross LAN is a HA integration, to make the devices visible to HA. How is the bulb trying to reconnect to MQTT related to that?

almico commented 3 years ago

How is the bulb trying to reconnect to MQTT related to that?

The first thing that comes to my mind is that either I didn't guess what to enter in the "device key" field of Meross LAN or that I am using a setup that Meross LAN is not expecting and that the result is Meross LAN sending messages to the bulb that the bulb doesn't understand... the hard way and disconnects.

almico commented 3 years ago

You may want to consider using --mqtt twice (identical ones), this may have been fixed but without that your device would not reconnect to the MQTT broker if it is off for a moment

I've never used that option twice and everything always reconnected.

wsw70 commented 3 years ago

I've never used that option twice and everything always reconnected.

I had a look at the issue I opened regarding this and, yes, that has been fixed (I forgot it has been fixed :))

wsw70 commented 3 years ago

the result is Meross LAN sending messages to the bulb that the bulb doesn't understand... the hard way and disconnects.

Ah, that would be interesting - a DoS by MQTT :) I think one of the ways to find out would be to dump the traffic and have a look.

almico commented 3 years ago

I think the best / easiest option is to know from @krahabb if I guessed the meaning of "device key" and if my setup is supported 😄

krahabb commented 3 years ago

Hello! Sorry for the delay. @almico, you are using a very 'strict' configuration for your bulb meaning you need to check/setup the authentication part of your mqtt configuration is working. Looking at the log it seems to me (but I'm not really sure because the disconnect reason is not stated in the log) the MQTT broker is killing the connection because of this. Meross devices use a custom user authentication setup by combining the mac address and the user name: this is tricky for mosquitto since it doesnt work well with how the username is built and, if you want authentication, you have to use https://github.com/bytespider/mosquitto-auth-plug to ensure mosquitto is working properly with meross authentication (see https://github.com/bytespider/Meross/issues/12) In order to make it work without the plugin, you have to disable authentication completely for your mosquitto listener by removing the password file in mosquitto conf and allowing anonymous users. If you need authentication in your mosquitto for other devices you can setup a new 'listener' in mosquitto conf, bind it to whatever port and use it in your meross configuration too so to bypass the authentication issues (I see this is getting very complicated but it is definitely better than using the custom authentication plugin!). This way, by adding mosquitto 'listeners', you can isolate and configure different options for different kinds of mqtt clients. If you are using the 'mosquitto add-on' built into HASSIO it might be even trickier (or simpler I don't know). Again, https://github.com/bytespider/Meross/issues/12 gives some clues about configuring authentication for mosquitto/homeassistant. I really think the problem is all about authentication: bear in mind the meross device doesnt use the 'username' ("msl120b-01") for authenticating to mqtt but uses its own mac address (see https://github.com/bytespider/Meross/wiki/MQTT for a good explanation on how Meross works on MQTT)

Also, if the bulb doesn't reconnect, it is probably related to what @wsw70 said: you have to configure both of the mqtt server options when you use the @bytespider utility or be sure you are using the last version of the utility since it was fixed recently.

As for the 'device key' this works like this: when you setup meross_lan in your HA integrations you can now enter the same device key you used when configuring the physical device so you have to enter "MYKEY" in the 'options' pane of the integration. As you can see you can configure it at the 'hub' level (i.e. on the 'MQTT Hub' pane) or at the 'device' level. This way you can have a different key for each different device but I dont recommend this because it adds complication(s). It is better and simpler to use the same key for all of the devices and set it at the 'hub' level (leave it empty for the device pane since it will default to the hub one). Best of all: configure your devices with no key and leave it empty in meross_lan integration: the security added by the key is negligible overall as far as your wifi traffic is protected enough (once an hacker can get into your wifi it would be really easy to 'hack' your meross devices whatever authentication and key you set up). A clarification for how the keys are used in meross_lan: the 'MQTT hub' works only for device discovery and initial recognition so, in order to correctly detect your devices, it must be configured with the same key as the device being discovered. Once a device gets discovered and configured in HA all the traffic for that device will use the key configured for the device itself and the 'MQTT hub' device key will not be used anymore for that device.

I hope you can fix the issues with connection so we can see if the bulb actually works in meross_lan or not. I'm definitely eager to know that ;)

almico commented 3 years ago

I will have to destroy my current test environment and start from scratch 😃 Connection worked properly, but I will try to create a simpler setup.

almico commented 3 years ago

Assuming that I have "Home Assistant Add-on: Mosquitto broker" already installed for other tasks, what is an example configuration you suggest that would work with Meross LAN?

krahabb commented 3 years ago

Assuming that I have "Home Assistant Add-on: Mosquitto broker" already installed for other tasks, what is an example configuration you suggest that would work with Meross LAN?

Well, I'm trying to guess here since I have never seen any HASSIO setup before ;) first: since the meross bulb is using authentication anyway you have to configure HASSIO mqtt addon with the correct user/password for the bulb: remember meross is using '{mac-address}' as username and '{user}_ + md5({device_mac_address}{key})' as password so you have to read/calculate these values according to your bulb: if the bulb mac-address is '48:e1:e9:11:5f:9b' (I've spied your log :) and you set both the user and key as '' (empty string) when using the @bytespider utility (MerossSetup) you would have to configure hassio/mqtt like this:

logins:
  - username: "48:e1:e9:11:5f:9b"
    password: "_7e487ca93af0f768778ec8c4c6c0ffde"

(add any other login you might using for other devices and keep the rest of the configuration since it seems your bulb is connecting correctly)

If you want to keep your 'user' and 'key' values different from empty when configuring the bulb you have to calculate the md5 hash yourself and build the password for hassio/mqtt like explained by @bytespider here :https://github.com/bytespider/Meross/issues/12#issuecomment-708444689

try this and see if it works: we could be lucky enough

bytespider commented 3 years ago

@almico I've managed to set up (and write a rough guide to) Home Assistant with the Mosquitto Addon with a MSS310

It's rough so feel free to open an issue on my repo if you need help and refer to it here for others using Meross LAN

nao-pon commented 3 years ago

@almico I'm using the add-on Mosquitto broker (version: 5.1.1) on hass.io with MSS110 and MSS710. And I have a Meross device configured with "user" and "key".

I've added the logins option to the default settings for the number of Meross devices and it works fine.

logins:
  - username: '48:e1:e9:xx:xx:xx'
    password: user_eb61de8166d394ecba0bc84cab7axxxx
  - username: '48:e1:e9:xx:xx:xx'
    password: user_2c139e2f820aaac3af43d47305a8xxxx
anonymous: false
customize:
  active: false
  folder: mosquitto
certfile: fullchain.pem
keyfile: privkey.pem
require_certificate: false

Please be aware that you need to add your user and password and restart Mosquitto broker before you can configure your Meross device.

almico commented 3 years ago

@bytespider @nao-pon I'm not an MQTT authentication expert. My main concern is the visibility of things published by different users defined in different places. A quick test I did (with "anonymous: false"), suggested that things published using a username were not available to other usernames. I fear an ACL is needed. Can you help me with this?

almico commented 3 years ago

Ok. I didn't change my setup. I just restarted both HA and the bulb. Then I used MQTT Explorer using the main "mqtt" user and this is what I see at the moment: image

This should mean that the MSL120B is properly connecting, authenticating and publishing to Mosquitto Broker. I don't know why, but the circled entry appears to be empty. I thought there I should have seen the "device key" I entered with meross setup, but I might be wrong.

Now I've enabled Meross LAN integration and I'm restarting HA Core and this is what I see in Mosquitto Broker's logs:

1618650553: New connection from 172.30.33.1 on port 1883.
[11:09:14] INFO: [INFO] found mqtt on Home Assistant
1618650554: New client connected from 172.30.33.1 as mqttjs_f3528c10 (p2, c1, k60, u'mqtt').
1618650555: New connection from 172.30.32.1 on port 1883.
[11:09:15] INFO: [INFO] found homeassistant on local database
1618650555: New client connected from 172.30.32.1 as 48TjxZkGC6fYFWgKoD4qUk (p2, c1, k60, u'homeassistant').
1618650775: New connection from 192.168.1.212 on port 8883.
1618650775: New client connected from 192.168.1.212 as mqtt-explorer-9ce4bbe7 (p2, c1, k60, u'mqtt').
1618650808: New connection from 192.168.1.68 on port 8883.
[11:13:28] INFO: [INFO] found 48:e1:e9:13:15:05 on Home Assistant
1618650808: New client connected from 192.168.1.68 as fmware:1912126573785090806548e1e9131505_sHUo1G2Z9MIdhgY6 (p1, c1, k30, u'48:e1:e9:11:5f:9b').
1618651203: Socket error on client 48TjxZkGC6fYFWgKoD4qUk, disconnecting.
1618651211: New connection from 172.30.32.1 on port 1883.
[11:20:11] INFO: [INFO] found homeassistant on local database
1618651211: New client connected from 172.30.32.1 as 13gNKxVUf4Rt0ovYJ0CdJt (p2, c1, k60, u'homeassistant').

This time it looks like it is not the bulb that disconnects, but Home Assistant. The good thing is that I no longer see an endless list of disconnect / reconnect (whoever it was 😄).

Anyway: the bulb was not found. I suppose, since I enabled auto-discovery, it should have appeared automagically. Or am I missing something?

almico commented 3 years ago

@bytespider If this can be useful to debug, this is the kind of command I used to setup the bulb:

meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass "xyz" --user "msl120b-01" --key "abcd" --mqtt mqtts://192.168.1.193:8883
almico commented 3 years ago

I just rebooted HA and this is the log from Mosquitto Broker:

1618650553: New connection from 172.30.33.1 on port 1883.
[11:09:14] INFO: [INFO] found mqtt on Home Assistant
1618650554: New client connected from 172.30.33.1 as mqttjs_f3528c10 (p2, c1, k60, u'mqtt').
1618650555: New connection from 172.30.32.1 on port 1883.
[11:09:15] INFO: [INFO] found homeassistant on local database
1618650555: New client connected from 172.30.32.1 as 48TjxZkGC6fYFWgKoD4qUk (p2, c1, k60, u'homeassistant').
1618650775: New connection from 192.168.1.212 on port 8883.
1618650775: New client connected from 192.168.1.212 as mqtt-explorer-9ce4bbe7 (p2, c1, k60, u'mqtt').
1618650808: New connection from 192.168.1.68 on port 8883.
[11:13:28] INFO: [INFO] found 48:e1:e9:13:15:05 on Home Assistant
1618650808: New client connected from 192.168.1.68 as fmware:1912126573785090806548e1e9131505_sHUo1G2Z9MIdhgY6 (p1, c1, k30, u'48:e1:e9:11:5f:9b').
1618651203: Socket error on client 48TjxZkGC6fYFWgKoD4qUk, disconnecting.
1618651211: New connection from 172.30.32.1 on port 1883.
[11:20:11] INFO: [INFO] found homeassistant on local database
1618651211: New client connected from 172.30.32.1 as 13gNKxVUf4Rt0ovYJ0CdJt (p2, c1, k60, u'homeassistant').
1618651794: Socket error on client 13gNKxVUf4Rt0ovYJ0CdJt, disconnecting.
1618651838: New connection from 172.30.32.1 on port 1883.
[11:30:38] INFO: [INFO] found homeassistant on local database
1618651838: New client connected from 172.30.32.1 as 1q1iK5S2xEsAeB4lUCQMMm (p2, c1, k60, u'homeassistant').

@krahabb as you can see, this time the "homeassistant" client disconnected twice and reconnected. My best guess is that Meross LAN integration is causing something fail, hence the disconnection.

almico commented 3 years ago

Ok. I forgot that I had to turn off and on the bulb to make the discovery process of Meross LAN start. Now I see the endless bulb disconnections I experienced the last time and nothing else.

almico commented 3 years ago

I tried with a mss310h configured like the bulb and I can confirm that it connects properly only if Meross LAN is disabled, otherwise I see this:

1618653286: New connection from 192.168.1.156 on port 8883.
1618653286: Socket error on client <unknown>, disconnecting.

when the power plug tries to connect to Mosquitto and the plug, having encountered a problem connecting, resets itself to "setup" mode and I have to use meross setup again.

wsw70 commented 3 years ago

I don't know why, but the circled entry appears to be empty.

This is normal, the firmware sends a topic that starts with an empty node (/).

This is a correct payload but it is not recommended (a topic should start with a node but because people are used to filesystem paths they start with a slash)

krahabb commented 3 years ago

Thank you @almico this is something I 'm going to check asap... expect a follow up in the next hours 🤓

almico commented 3 years ago

In the meantime, I disabled this: image

re-enabled Meross LAN, restarted ha core and I don't see any power plug, but, at least, I do not see it disconnecting from Mosquitto Broker 😄

almico commented 3 years ago

@krahabb For your reference, this is my current MQTT Broker configuration in HA:

logins: []
anonymous: false
customize:
  active: false
  folder: mosquitto
certfile: fullchainmqtt.pem
keyfile: privkeymqtt.pem
require_certificate: false

Of course, I added the 2 users to HA, and the command I used to configure the power plug is this:

"c:\Program Files\nodejs\node.exe" meross setup --gateway 10.10.10.1 --wifi-ssid MYSSID --wifi-pass "mypass" --user "mss310h-01" --key "abcdefgh" --mqtt mqtts://192.168.1.193:8883

This way, I think you can reproduce my exact setup (for example, in a virtual machine using Hyper-V) and verify yourself what's going on.

krahabb commented 3 years ago

Hello @almico, It will take some time (and will;) to me to setup an hassio environment to test this out so I'm not sure I can afford it at the moment. I have some thoughts though:

krahabb commented 3 years ago

In the meantime I've also found this: https://community.home-assistant.io/t/issues-with-mqtt/131453/4 but you probably already set it up

and this: https://community.home-assistant.io/t/acl-with-mqtt-broker-4-1-hass-io/105248

bytespider commented 3 years ago

I've had a few mins to also play with this.

I think the bug is in my code not correctly setting the UserId and Key. I've updated (1.0.9) and it seems to be okay. but...

If I set the wrong device key in Meross Lan, it causes my device to do something weird and disconnect as @almico says.

@almico try either version 1.0.9 of my software to pair or use a blank device key with Meross Lan and see what happens.

Personally I wouldn't bother with userid and key, they offer nothing to security on your own Lan and are only really useful for Meross cloud

almico commented 3 years ago

@bytespider Should I use this one?

https://github.com/bytespider/Meross/tree/develop

image

Because I'm struggling to find anything referencing 1.0.9 😭

bytespider commented 3 years ago

That's the one. I should create a release really.

almico commented 3 years ago

@bytespider

That's the one

Ok, I got that zip and set up again the power plug, but now the password is no longer correct. It was previously. Did the way it should be computed change?

almico commented 3 years ago

@bytespider Ah! Now the code states the user must be an integer! Sorry, I didn't understand that. An error message would have been nice, though 😄

bytespider commented 3 years ago

Beta software done in the few minutes I get free ;)

almico commented 3 years ago

@bytespider Great news! I managed to authenticate. I think there was some kind of cache in the users' list somewhere. Some user deletion and a good old reboot made things work much better 😆

@krahabb Now I have the mss310h auto-discovered by Meross LAN. Unfortunately, the first thing I did was rename it this way: image

And now that entity appears as unavailable. Did I make any mistake or might it be your component doesn't support that kind of renaming yet?

almico commented 3 years ago

@krahabb I tried (and succeeded) to delete the plug. I had to confirm this dialog: image

I think "device" would be easier to understand than "integration", but may be it's internally seen as an "integration". I'm reporting this just in case you have the power to change that word. I mean... I'm just testing, but if I had, say, 30 Meross devices connected and was told that I was going to "delete this integration", I don't know if I would have confirmed 😄

wsw70 commented 3 years ago

Great thread, reads like a Tom Clancy book. A few comments:

And now that entity appears as unavailable. Did I make any mistake or might it be your component doesn't support that kind of renaming yet?

I noticed that with Meross devices, it seems that the information is not updated reliably in that case. If you switch the plug on and off (with the button), does it become available? (it works in my case)

I'm just testing, but if I had, say, 30 Meross devices connected and was told that I was going to "delete this integration", I don't know if I would have confirmed

I had the same comment to the creator of the Shelly integration :)

almico commented 3 years ago

@krahabb Update! I managed to connect both the mss310h and the msl120b. While the mss310h was properly auto-discovered and I could switch it on and off using Lovelace, the msl120b wasn't auto-discovered and started to generate the endless list of

1618677994: New connection from 192.168.1.68 on port 8883.
1618677994: New client connected from 192.168.1.68 as fmware:1912126573785090806548e1e9131505_zaGyD8Tt1Rcb7xeQ (p1, c1, k30, u'48:e1:e9:13:15:05').
1618678009: Socket error on client fmware:1912126573785090806548e1e9131505_zaGyD8Tt1Rcb7xeQ, disconnecting.

Thus, I fear the issue on @bytespider end is now fixed (as the mss310h demonstrates), but there is some issue on your end that still hits bulbs.

almico commented 3 years ago

@krahabb I was going to shut down my test server and noticed this: image

I think there should have been the "MQTT Hub" too. Maybe it died or entered some odd state, disappearing from there?

bytespider commented 3 years ago

@almico if you go up to the left top corner of that panel there should be a back button. Its a weird implementation. Like you say the devices should be devices and not integrations but it is what it is and it works

krahabb commented 3 years ago

Lot of stuff going on here! Good news overall so the situation is becaming more stable now..

@krahabb I tried (and succeeded) to delete the plug. I had to confirm this dialog: image

I think "device" would be easier to understand than "integration", but may be it's internally seen as an "integration". I'm reporting this just in case you have the power to change that word. I mean... I'm just testing, but if I had, say, 30 Meross devices connected and was told that I was going to "delete this integration", I don't know if I would have confirmed 😄

This is to be asked to the hass team but yeah..in the overall picture it's an integration configuration entry which is going to be deleted and that could really represent anything in HA terms...'Configuration Entry' would be the correct term since you have (or could have) more than one all belonging to the same 'Integration'

@krahabb I was going to shut down my test server and noticed this: image

I think there should have been the "MQTT Hub" too. Maybe it died or entered some odd state, disappearing from there?

Yes, somehow you probably deleted it or maybe it is 'disabled' since there's a new feature in HA which allows you to 'disable' 'Config Entries' in order to remove them without actually deleting. Check the UI if you're seeing all of the integrations (i.e. they're not filtered out).

At any rate keep in mind, like I explained before, the 'MQTT Hub' config entry is used to configure the key for the discovery mechanism so, if it's either missing or disabled, it's built anyway in my code !!BUT!! with default settings that means you're discovering things with an empty key

@bytespider Great news! I managed to authenticate. I think there was some kind of cache in the users' list somewhere. Some user deletion and a good old reboot made things work much better 😆

@krahabb Now I have the mss310h auto-discovered by Meross LAN. Unfortunately, the first thing I did was rename it this way: image

And now that entity appears as unavailable. Did I make any mistake or might it be your component doesn't support that kind of renaming yet?

Renaming an entity ID is not something I would expect the homeassistant UI should allow since it normally relates to hardware or other internal integration features... To be honest I've never tried to rename any ID and if asked I was sure it would be impossible. I expect my component would recreate a new entity on reload since it cannot rebind to the same old one in the HA entity database. The entity ID's in my code are generated at runtime and not configurable so the 'disappearing behaviour' is expected. Renaming the 'Name' instead should work correctly!

Keep in Touch!!

P.S. I guess I'm going to buy one of these MSLXXX...they're intriguing to say the least..and some color could be nice in my home too (even tho my wife rejects having these 'chinese rubbish' - with all due respect to China and all their cheaply priced appliances) I hope my last comment doesnt get banned or signaled for 'irrespective language about nationality' ;)

P.P.S. Nevertheless Meross should not even be a Company from China from what I remember even tho the bulbs are built there...for sure

almico commented 3 years ago

This is to be asked to the hass team

I feared that. I will consider pointing that out on their website 😃

Renaming an entity ID is not something I would expect the homeassistant UI should allow

I think it is the very first thing I do for every device I add. Like this: image

even tho my wife rejects having these 'chinese rubbish'

I wonder if your wife is really aware of the boundaries of her statement 😆

almico commented 3 years ago

@krahabb I tried again and, unfortunately, if I turn on the light bulb, see it properly connecting to MQTT Broker, and then enable MQTT Hub, the bulb soon disconnects, then reconnects in an endless loop 😢

krahabb commented 3 years ago

I've ordered a couple MSL100 and MSL120 to do some real testing..I hope to be able to return them to Amazon ;) If it works I could then jump on to humidifier and the 'most wanted' valves...abusing it a bit Let's see

almico commented 3 years ago

I have 4 valves behind the MSH300. It would be a bit more difficult to decide to remove a perfectly working setup for beta testing, though 😄

krahabb commented 3 years ago

I've received the two bulbs and checked them working and ...the MSL100 works great and is now supported (at least mine) but the MSL120 was probably bugged since after several tries I wasn't able to even pair it with the meross app so I think I was unlucky with this one. The strange thing is that the bulb, when paired with my local mqtt, was pushing just two messages (at least a light payload ...) but was not responding to any interrogation. I tried over http and I was able to get some replies but overall the bulb looked a bit slugghish and also the timestamps where not correct so maybe it was unable to get the correct time on startup from ntp and the firmware was impaired by that. I'm sending back the bulbs now as per my original plan, at least one of them would have been returned anyway.

almico commented 3 years ago

FYI: my MSL120 was originally connected to the Meross app and it happened flawlessly.

yauyauwind commented 3 years ago

Thank you so much~~ I finally can work with Meross Lan

I setup the MQTT server very smooth and device connected to the MQTT server however I can't add devices to HA, I have no idea about this , after that I try to use pyscript "provided by wsw70"

the MQTT showing the devices from HA , but unable to control "I use MQTT Explorer to confirm the devices has been connected to MQTT and appliance showed"

When I want to give up, I press the MSS310 power switch to off, then the MQTT receive msg. and the device turn to available

Oh... I finally know that, I need to press the Meross to make the devices communicated with the MQTT server

then I try this Meross Lan "Thanks krahabb" but no luck, haven't devices can be detected, even I press the Meross switch after some try..... Finally, when I del the Device key from the Meross Lan magically, the devices can be detected

I want to say Thanks with the following person

@albertogeniola

He make the Meross IOT library and make me easier to join the Meross to HA "until the Meross always banned me, so I have a long time can't use meross from HA and seeking the local MQTT"

@bytespider

He make the utility for Meross connect to local MQTT , and setup guide

@wsw70

He make the pyscript, and let's me confirm my config is work

@krahabb

Meross Lan is amazing

Thank you all~~~

krahabb commented 3 years ago

Thank you..it is very nice helping each other🙂