MRS100 position support

[GeorgeCaliment]

Hi, I just tried the custom component, and all meross devices work great even offline.
I saw already an issue opened about mrs100 shutter switch position support. Is there any info about it?
I read on meross site that this switch at the moment doesn't support position feedback/control. Should we wait a firmware update from them?

[krahabb]

Hello @GeorgeCaliment
Thank you for sharing your experience!
I don't have any of the mrs100 shutters so I can only guess based mainly on the informations shared with @pedrompamaral in #26.
These devices should have their own 'timed position' emulated in firmware so I guess, if a device is still paired to the official Meross app there should be a way to configure it. In this scenario, meross_lan is getting the internal firmware emulated position and forwarding it into HA.
If a device is instead paired to a local MQTT, meross_lan is not able at the moment to configure this setting and so the firmware emulated position would be somewhat misconfigured.

My idea is to use the device firmware emulation and give the option, through meross_lan, to properly configure it but I would need some help/support from users like you (I'll ask @pedrompamaral too) in order to implement-test-refine this feature.

Right now I'm going to add more tracing info in order for users owning the devices to be able to dump more informations about the relevant messages involved in configuration so to help me implement the protocol.

If that route proves to be unreliable I could implement the timed behaviour myself but I suspect the latencies in communication between the device and meross_lan would badly impaire its accuracy.

Stay in touch!

[pedrompamaral]

Hi @krahabb
If you need any help from me, just ask. No problem. 🙂

[GeorgeCaliment]

Hi @krahabb,
i paired them through meross app, but even in official app there isn't a way to open/close the shutter partially (for ex. halfway). The timer configurable is only to calibrate the full open/close. The only way that i found at the moment to open halfway the shutter through this switch is using a script once you know the full open/close timing, but unfortunately there is no position feedback.
Also another thing i've just discovered, i have two switches that i "converted" to work as diverters through an automation (in few words once one get triggered sync the state with the other), triggering switch from ha is fine, but if i trigger switch from physical touch, it takes about 2-3 seconds to sync the other switch i guess cause of the polling timing (already set it to 1s). Is there a way to reduce this delay?

[krahabb]

Hello @GeorgeCaliment ,
I'm now working on the time based implementation for the cover so it should come in the next release.
As per the polling you've set to 1 , in reality I enforce no less than 5 seconds in code so to not 'abuse' the polling feature :)

[GeorgeCaliment]

Hi @krahabb,
i had to force to 1s, otherwise the sync state between those 2 switches if triggered from physical switch will take too much.
Triggering one of switches from HA works like a charm.
Is there a way to manage that through events instead of using polling, or any other way to avoid this delay without abusing polling?

[krahabb]

Hello @GeorgeCaliment,
In order to have realtime (or near to) behaviour you should pair your meross to your private mqtt broker and completely disconnect them from cloud. This way, status messages are delivered on time to HA which would make your automations work correctly.
Polling is not the solution since you're putting a big burden on the HA machine in order to do frequent (mostly) useless inquiries to the device. Of course, if there's no other option, this is the only practical way.

[krahabb]

This morning I've pushed a new 'beta' release in dev branch.

If any (or both:) of you @GeorgeCaliment and @pedrompamaral is up for a test you can download the dev branch from the repo and try it a bit and see what is happening. Reach to me for any issue in the process. This is just a 'proposal'!

This version has the following (new) features:

• increase 'tracing' facility so to inquire all of the device available messages. This could be useful to me to learn some messages payload structure and add their functionality to meross_lan
• initial implementation of timed cover position for mrs100. Right now I have a fixed 'run time' of 30 seconds. I will add the option to configure it through UI before the official release. If it works, it should report the shutter emulated position depending on time of run. Of course, on the first run, the position will be 'random' (when booting it is set to 50%) but when you completely open or close the shutter it should get into a 'solid' state. Keep in mind the 30 sec run time might be a bit longer than actual real but you should get the hang of it. You should be able, from HA, to also use the 'set position' feature of the cover. Of course, the precision will be less than ideal, especially if you operate the cover from the app or from the physical touches since HA will receive the 'update' later due to HTTP polling frequency.

In order to install it, I doubt you can easily download the dev branch through HACS. You should go the 'manual' way following any git/github guide to extract a branch other than master. Just replace the actual 'meross_lan' folder in custom_components with the newly downloaded one. This should pose no issue to HACS if any: you can still use it to reinstall the official release of meross_lan whatever is happening

[GeorgeCaliment]

Hi @krahabb, i just tried out the dev branch, the position status works fine, if used from completely open/close to x position, while if i try the open/close command from x position, after about 30s the device get "disconnected" for some seconds and then connects again.
I was trying also to use only mqtt, i managed to connect meross device to local mqtt, and i can see payload from switch (when i trigger physical switches) through mqtt_explorer, but if i force the device to use mqtt in meross_lan integration, the device becomes unavailable. Can u point me to a solution if u have ever encountered this problem?

[krahabb]

@GeorgeCaliment
That was awesome and fast!!
Thank you for trying this. If you can enable tracing from the integration configuration UI that could help trobleshooting.

If possible, get different traces for both Http only and mqtt only

[GeorgeCaliment]

Hi @krahabb,
here are some traces, i noticed that the disconnection problem happens only with the "up" button, even is triggered from completely opne position (0). For the mqtt, as I said in the post before, i have to find out how to make them work, cause they're unavailable on meross_lan integration if i force mqtt, while mqtt explorer see all payloads send to broker by meross devices

EDIT: trying only with the slider all works fine and timed well, while the up/down buttons see the default timer value (50s) and not the one that slider see (about 30s)

EDIT2: i figured out the problem with mqtt broker, now works, tried the position using mqtt, and all works fine, there isn't the problem found using http. But there is still the problem with the buttons (up/down) timing, set on default value (50s) e not the one as the scroller (30s)

mrs100-1631367819.csv
mrs100-1631368272.csv
mrs100-1631368488.csv
mrs100-1631368847.csv

[krahabb]

Well done,
I've read a bit the traces and I found the disconnections you're experiencing and that doesn't look good atm since it looks like, after a bit of HTTP requests (meross_lan runs a quick/fast polling with 1 sec period while it knows the cover is moving) the device timeouts: I'm not sure if it is random or if it is when the device itself 'reaches end of movement' and the firmware is in trouble keeping up with the HTTP requests...
We'll see, I'll better review all of the traces to see if something comes to mind and I will also try to add some other tracing info.

EDIT: trying only with the slider all works fine and timed well, while the up/down buttons see the default timer value (50s) and not the one that slider see (about 30s)

Yeah that's expected since when issuing an 'open_cover' or 'close_cover' I'll just tell the device open/close and it follows its internal timeout while with 'set_cover_position' (by the slider then) I've implemented a watch/timeout logic to interrupt movement once on target position (by timed estimate ofc)

EDIT2: i figured out the problem with mqtt broker, now works, tried the position using mqtt, and all works fine, there isn't the problem found using http. But there is still the problem with the buttons (up/down) timing, set on default value (50s) e non the one as the scroller (30s)

This is good news since the HTTP protocol suffers from those disconnection timeouts also in my devices (lights and switches) and still I haven't figured out the issue tbh. It is normally very transient and the device resumes HTTP replying in just few seconds but, if it happens, like in your tests, while meross_lan is controlling the movement timeout, that is nasty or at least very annoying

[GeorgeCaliment]

The weird thing is that the disconnection happens only on "up" command, never on "down", or atleast on about 10 tries (for each) i've done. Could be cause of the position payload being always 100, even if partially open, while the position "0" is only if completely closed.

[krahabb]

Hello @GeorgeCaliment ,
I've pushed a 'refined' implementation for timed covers. I'm a bit scared of the amount of code without proper testing and even if the previous beta was more or less working I had to refactor it a lot.

Now you can 'control' the open and close timeouts by using the app configuration:
I've basically used the same configuration info (I'm now able to read that, thanks to your uploaded traces) stored in the device.

Next step, before officially releasing, is to add support in HA to edit these parameters since if you don't have the device binded to the Meross app you can't actually edit those.

Nevertheless, the behaviour should be like before: if you set the position from HA it gets tracked and controlled. If you use the open_cover or close_cover it will anyway run for the full timeout even if it is 'close' (since the position is never really reliable)

[GeorgeCaliment]

Hi @krahabb ,
if u need some other traces just ask. Is there a way to catch the payload sent by "meross" once we configure cover switch timing on app?

[krahabb]

Hello,
well, if you look at the traces you'll see something like:
2021/09/11 - 15:34:24 http GET Appliance.RollerShutter.Config {"config": {}}
2021/09/11 - 15:34:24 http GETACK Appliance.RollerShutter.Config {"config": [{"channel": 0, "signalOpen": 50000, "signalClose": 50000}]}
This was extracted from yours :) and that's where I've learned how to recover the device 'native' configuration.
You can also inspect your cover entity from the 'Developer Tools' and see all of the attributes exposed by the entity beside the state: there you should find the 'recovered' parameters.
I'm eager to know if, setting the parameters in the app, the HA cover works as expected. If you still haven't, you can install the beta release through HACS too since I've published a pre-release with code from the dev branch

[krahabb]

Hey @GeorgeCaliment ,
I would really need your help to refine the feature to set cover configuration from meross_lan.

I have setup everything through integration configuration in order to configure the 'open timeout' and 'close timeout' on the device but, as soon as I tried the implemented logic trying to configure my mss310 (by using a command I guess would behave the same on the mrs100 even tho that is not the same) I see my device behaving wildly disconnecting and overall not accepting the update.

In order to test my idea you would have to go into 'Developer Tools' -> 'Services' select the meross_lan.request service and paste in this snippet editing the relevant fields:

service: meross_lan.request
data:
  namespace: Appliance.RollerShutter.Config
  host: 192.168.1.XX
  device_id: 1909180222710990802048e1e9XXXXXX
  method: SET
  payload: '{ "config": { "channel": 0, "signalOpen": 30000, "signalClose": 30000 } }'
  key: 'your_device_key_or_remove_the_key_key_from_this_request'

since you are using devices with HTTP the device_id field is not needed. Also the 'key' field must be set accordingly (removed if it works:)
If the shutter is receiving it correctly you should see that through the meross app by inspecting the configuration there.
If it's not working try to change the 'method' to 'PUSH'
You can also try different values for 'signalOpen' and 'signalClose' and see if they follow (they should represent open/close time in msec)
-CrossFingers ;)

Thank you,
I will likely post a new beta with this feature anyway since it's not really breaking any existing functionality (this code is already there but I would like to have a confirmation before going through the publishing process)

[GeorgeCaliment]

HI @krahabb, really nice job!
Just tried out with manual service call, both with http (so with device connected through meross app) and local mqtt, both worked like a charm with "SET" method (the "PUSH" one is not working). Here's some tracerts one with http (meross app connected) other with local mqtt.
mrs100-1631890353.csv
mrs100-1631891090.csv
mrs100-1631892022.csv

[krahabb]

That's awesome news!!
Tomorrow I should be able to finally publish it
Well done and thank you so much!