Confirmed supported devices by http method

[pedrompamaral]

Thanks a lot for adding this http method. Congrats to the developers.

These devices are working perfectly in my home with this LAN integration by http method.

mss510h (Simple 1 way 1 Gang Wall Switch)
mss310 (Smartplug with energy monitoring)
mss710 ("Power brick look" Smart switch)

[krahabb]

Thank you @pedrompamaral !
I will update the list of supported devices right away

[uvjim]

I've also been testing this integration. I haven't finished configuring yet but it appears that the following are discovered (and seemingly supported). Tested switching a few of the sockets on/off a couple of times.

Model numbers are: -

• mss420f
• mss425f
• mss425e

The item in the screenshot missing a model number is also mss420f but has a different hardware and firmware version. Happy to trace anything to that device if you need it.

[pedrompamaral]

Hello @krahabb
Question... The v2.0.3 update, was supposed to have changes to mrs100 shutter switch? I didn't notice any changes with these devices.

[krahabb]

Hello @pedrompamaral,
yes the 2.0.3 should have improved in mrs100 handling. The state should now report correctly when you are opening or closing the device.
Of course, going through http polling you might see delays and missed states but overall you should have a good representation of what is happening.
Could you please be more detailed in reporting the expected and the real behaviour seen through the integration?
Tomorrow I'll review your previous logs and actual code to see if something 'slipped through' my implementation or any bug I can discover by just re-interpreting the code.
Maybe we'll need another trace/log but at the moment it could be ok if you just post your observations about the states reported and the overall functioning of the integration

[krahabb]

Hey @uvjim,
I'm sorry but your comment went a bit forgotten in the mess of recent days.
Thank your for reporting your experience and showing that 'rebel' mss420. What is the 'state of the art' now with the latest (2.0.3) release?
By the look of it I guess the integration is unable to use it (since being 'untyped' means some important bit of discovery informations are missing!)
On the other hand, if the integration presented the UI to configure the device it might be that some euristhic code behind the scenes is making some use of the device (more or less: if the device presents itself as something switchable than it should be switchable even if we don't know the model).

So, if you're in the lucky position of having it configured and somehow working you can for sure easily post a nice trace so I can better understand what's going on for this piece of hardware.
If you've read some other posts you should know now it's possible to trace the communication of the single device by just activating tracing in the integration configuration UI (No Hass log, no Debug flag, no restart, nothing). Then after 10 minutes of working (or not) the trace will be done and you'll find the file under 'custom_components/meross_lan/traces'

I'll wait for that ;)
Thank you

[uvjim]

Thanks for coming back to me. It's actually a bizarre thing. A restart of HA actually brings the device in with all information (assuming I just left it as a discovered item). I have since added another mss425f and this showed a similar problem. I actually think it is a Meross issue because this device was also having issues renewing it's DHCP lease - it would always stay on the first address it picked up even though I'd since reserved one on the DHCP server.

Again, I restarted HA for something and all information came back in again. I do have another device that I'm looking to add in the coming days - it too has been having IP renewal issues (nothing other than Meross devices is exhibiting this problem in the network) so I'll see if that does similar.

I'll turn on tracing before supplying it with power and see what happens.

Other than that everything is working really well. I moved over from the Meross Cloud integration for the local capabilities and they're working well. I didn't see the recent issue you fixed re: timing on the mss425f because I only ever control from HA so I'm guessing the state stays reflecting my desired state (unless it genuinely failed to send the request).

I'm also finding it slightly more responsive than the Meross Cloud integration, which I suppose is to be expected. I haven't gone down the route of using my own MQTT server yet, even though I have that in HA for ZigBee2mqtt.

[krahabb]

Other than that everything is working really well. I moved over from the Meross Cloud integration for the local capabilities and they're working well. I didn't see the recent issue you fixed re: timing on the mss425f because I only ever control from HA so I'm guessing the state stays reflecting my desired state (unless it genuinely failed to send the request).

I'm also finding it slightly more responsive than the Meross Cloud integration, which I suppose is to be expected. I haven't gone down the route of using my own MQTT server yet, even though I have that in HA for ZigBee2mqtt.

Yes, talking directly HTTP to the device(s) is faster than even local mqtt and if you set the state only from HA you'll never experience any 'lack' of state from the device of course. The 'mss425f' mentioned in the other post by the way was really 'polled' the wrong way: by inspecting the trace I came up learning (the hard way) that those multi-plugs don't expose the full state in some messages while they do so in other type of inquiry so I've updated (2.0.3) to try to always use a more general status inquiry.

Regarding your network issues with Meross devices I can't confirm the exact same mis-behaviour but I've often struggled to pair them: when they're reset and they're broadcasting their AP I had a lot of issues connecting to that. My windows PC beside showing the AP never wanted to pair while a 'legacy' raspberry PI was able to connect randomly (50% more or less). In the end I'm now only using my android phone with either the Meross App or this custom pair app (https://github.com/albertogeniola/meross_pair) and even then I'm sometimes unable to connect to the AP

[pedrompamaral]

Hello @krahabb
At this moment, the integration with the mrs100 don't let me have full control of the shutters. For example, i have one shutter 50% open, but the HA tells me that it is tottaly closed, so the integration don't let me close , only open. If i want to open 20% more, i can do it, but i can't close not even a inch until the integration don't recognise that its fully closed.
The meross app let me open, stop and close freely. The problem here is that the HA don't recognise mid positions of the shutters. If, for example, the shutter is fully closed, i can open it, and i can stop it when i want, but it don't let me close it again until i fully open it first.
Probably the meross app also don't know the shutter position, because it works with time, not the shutter position. Rhe problem here is this i can't open or close mid-way and then reverse the movemebt untit it finish the programmed time on the app.
I hope you can understand my explanation. If it's still hard to understand, i can try make a video. I don't know if i can attach it here.

[krahabb]

Hello @pedrompamaral ,
Sadly enough I can't really figure out what's going on. The last release should have just refined the status polling so it should have worked like the previous or better.
I have a couple of theories:

• since the RollerShutter 'guesses' the position by an internal timer, maybe this is too short (or too long) and so the position reading is totally out of reality and prevents you from moving the shutter consistently. I have one of those cheap sonoff-like roller-shutters and they can be programmed in some way so to not consider the movement ended too soon and to report the position in a more or less accurate fashion. To make them really working I had to configure an opening time 'well beyond' (almost twice) the real full transition duration else they would not want me to open more (since they thought the shutter was already open) or close more (for the same, opposite, reason). Also, since the electro-mechanical system has a bit of hysteresis things are even worse on small movements.
• the HA UI for covers wont let you use the 'close' command if the cover is reported 'closed' and the same wont let you 'open' the cover when the state reports 'opened' so this is likely your case. To overcome this 'UI limitation' you could create an automation/script to directly call the underlying HA service in order to directly move the cover with these services: 'cover.close_cover' and 'cover.open_cover'. This should operate the cover whatever the reported state is. If this works and you can report to me I could then think of a workaround to 'fool HA a bit' in order to always be able to operate the cover. If not, then the problem could lie in the command message I'm sending which works like a 'set position to 0' to close and 'set position to 100' to open but maybe gets discarded by the mrs100 itself if it thinks it's already in position (closed/opened).

I will anyway try to 'overdrive' the next release with some more tricks so to see if they improve the cover behaviour.

In the meantime, if you can test the services invocation and collect some more traces I will try to better understand what is happening. Even if you can't setup the service invocation script please try to collect a trace with the issue.
Try to not include too many operations in it: could be nice to have a sequence (with the device operated only through HA) where you send the commands which HA allows so fo instance, starting from (really) closed:

• you open
• you stop
• you try to close (should not work)
• you try to open (should work) letting it open fully
• you try to close (should work?)
• you stop it halfway
• you tell me which command works :)
• you continue until closing completely again
  Set the polling interval for this trace to a 'fast' 5 seconds period so to have a rich sampling of the mrs100 state and when describing the steps write down when you issue a command and it doesnt work or when you want to issue a command and you cant (because HA UI forbid you). Also, if HA reports the cover partial position in the UI (like 0, 30, 50,80,100) note it down at every step
  Thank you

[pedrompamaral]

Hello @krahabb

Thanks you for your answer.
When you said: "the HA UI for covers wont let you use the 'close' command if the cover is reported 'closed' and the same wont let you 'open' the cover when the state reports 'opened' so this is likely your case. "
Thats exactly my case. Tomorow morning i will try to do what you said and report back to you.
I also will do the tests you asked for and send the results.
Thank you for you work.

[pedrompamaral]

Hello @krahabb
I have to say, you really are a genius man. The script "trick" worked perfectly. I created 3 scripts for each command (open, stop and close), in each script i created the "call service" option for each actual command of the shutter. That way HA let me freely control the shutter, no problems.
I got the traces with the script commands and by the "traditional" way (the problematic HA UI). I don't know why, but this time some of the personal information was already hidden. You will the in the files the "*" symbol i use to hide the characters, but the ones with the "X" where already hidden.
I used 5 seconds polling time for both traces.
The first and second files are for the script test.
The third and forth files are for the HA UI test.

Let me know if i did everything right and if it helps.

Thanks a lot

Command list with scripts.txt
Script trace.txt

Command list by normal HA UI.txt
HA UI trace.txt

[krahabb]

Ah well...
easy thing first:
the trace now automagically hiddens what I consider sensitive info: the uuid of the appliance too could be a reasonable candidate to hide so expect that in the next releases (not yet done...I might forget that :). As for the first 3 bytes of the mac that's unique for the vendor so every device has (or should have) the same that's why you don't see that hidden ;)

As for the shutter behaviour I'm pleased to see that 'overriding' the HA UI the device works as expected. The problem nevertheless lies in the 'actual' position reported by the device itself in protocol: that's always either 0 (closed) or 100 (open) and I don't see any intermediate value in the traces so that means it is totally useless expecially since it still reports 0 after you've already opened the shutter a bit (and that's why you can't close it anymore: HA still thinks it's closed).

I'm likely going to completely ignore the position(ing) info: HA cover implementation is flexible enough to work with covers like that but still, not having any information about the 'real' shutter position could be tricky since I can't state for sure if the shutter is either totally closed or totally opened. I guess I'll have to 'fool' HA by stating the cover is always 50% opened that way HA will always allow both close/open but the state itself will always be fake (not only the intermediate positions: even fully closed or fully open)
Let's see. I'll take a few days more before releasing a suitable fix.
Thank you for your precious feedback!

[pedrompamaral]

Hello @krahabb
Well, i was thinking, several brands offer the positioning control of the shutter by time, and not by the position it self. Maybe you can do the same here. The meross switch it self don't offer the possibility of knowing the position of the shutter (not even by the meross app), so maybe you can add to meross_lan the possibility to let us set the total travel time of the shutter (from 0 to 100), and them make the HA UI calculate the positioning by the travel time.
For example, my shutters take 24 seconds to go from totaly closed to totaly open. If i can set that info in meross_lan and you can make HA calculate the time everytime the shutter moves up or down, then HA can tell us the shutter position. Do you think that's possible?
If thats not possible, your last sugestion ("fooling" HA) is algo very good to garantee excelent control. For me, for example, i use the shutters almost allways on the same positions, so, when i open the shutter of the living room, i can set an automation to send the "open" command for 10 seconds, and then stop. The shutter of the living room have a different travel time, bit its always the same time every day, so i can set another automation for that ahutter, with a different time.
Only for the people who don't have a routine for the shutters have to do that manualy, but at least they have full control.
Thank you for your work

[pedrompamaral]

Hello @krahabb
I have some good news and bad news.
Good news, after the last update, HA let me freely control the shutters.
Bad news, the automation that HA let me do are still based on position of the shutter, so i can't create an automation to open or close the shutter within a defined time. For example, i still can't make the shutter close for 5 seconds, because HA forces me to give it a shutter position. (Screenshot attached)
I can do these kind of aitomation, but they are based on calling services, just like the scrips from before.
Maybe i'll wait for the improvement you talked about. Meanwhile, i can make it work by the "call service" option. I have to create an automation for the time i want to open the shutter, and another one for stoping the shutter some seconds later.
You idea sound excelent, so maybe you can continue to work on that, and i'll continue to use the "call services to do the automations until you succeed. No worries.
If you need me for anything, just let me know.
Thanks

[krahabb]

Hello @pedrompamaral ,
I'm happy it works (I still have no way to even see if my code 'compiles' correctly for devices like covers since my unit tests are lackluster..so to say..)
As for the timer behaviour I'm going to definitely build an implementation for that. Right now I'm a bit 'scared' Meross is closing down on a 'flaw' which could let me 'hack' their protocol and easily communicate with devices without even knowing their 'device key'. Nothing really critical but with new official firmware updates some devices could need to be configured with a proper 'key' in my integration and the extraction of this key must be done 'manually' at the moment (see #40)

[pedrompamaral]

Hello @krahabb
If that happens, we can right the key manualy. At this point, we can easily get access to the devices keys with your integration. We can just save that and use it later if its needed.
Either way, people like me (who use these shutter switches) can use them and make automations freely. A bit arder to configure, but doable. We can wait for you to see what you can do.
As for the switches firmwares, updates is it really important doing those updates? Because Meross can have the idea of doing something that makes your code not work for good, or am i wrong?

[krahabb]

Hey @pedrompamaral ,
a good 'rule' for firmware updates should be: if it works don't update.
A bit rude and always objectable but the fact is: any update could break either intentionally or by chance an existing feature which you are relying on. So, to be safe, unless your current firmware is not working correctly, do not update.
Of course this is hard to follow since new firmwares could also bring in new features and if your devices are paired with the official app this features might be appealing to use.
Personally I always update since having a red (or yellow) icon somewhere telling me there's a (shining?) new version of a software is almost irresistible...if you know what I mean..
Anyway: like I said here #35 I don't see an upgrade preventing my integration from totally working except the key-hack fix which is a reasonable update/fix and probably happening here #40.
Unless Meross is committed to 'avoid' any device use outside the intended official api/infrastructure and so they might be planning to make it harder for softwares like mine to be able to work
Time will tell

[pedrompamaral]

Hello @krahabb

I think i will play safe for now and don't update Meross devices. I saw that Meross seem to have lots of "problems" having people use their devices freely. I've seen one of my switches blocked by Meross twice, because of that "10 second rule". I was making experiences with automations in smartthings app, and the big responce of this "online use" made my switch go crazy, going on and off quickly. Meross blocked my switch temporarily because of their "anti-hack" protection. I dind't liked that. My device, my will, my responsability. Thats one of the reasons i want a "offline" use of my devices.
I don't know, i don't want to take changes and lose the use of your awesome software.

[tokyotexture]

Just tried out this integration for my MSG200 (homekit version) garage door opener, and it worked just fine. Not sure if auto-discover is supposed to work, but adding the host manually worked.

[krahabb]

Hey @tokyotexture ,
Thank you for reporting this 'new' supported device. I see the msg200 is the big brother of the msg100 which I had the opportunity to test and refine thanks to #29.
Are you using it with more than 1 channel? if so, are all the channels working correctly? If the Meross implementation is 'straight' enough my code should work on more than 1 channel but 'The devil is in the details'