-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MRS100 position support #73
Comments
Hello @GeorgeCaliment 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! |
Hi @krahabb |
Hi @krahabb, |
Hello @GeorgeCaliment , |
Hi @krahabb, |
Hello @GeorgeCaliment, |
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:
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 |
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. |
@GeorgeCaliment If possible, get different traces for both Http only and mqtt only |
Hi @krahabb, 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 |
Well done,
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)
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 |
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. |
Hello @GeorgeCaliment , Now you can 'control' the open and close timeouts by using the app configuration: 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) |
Hi @krahabb , |
Hello, |
Hey @GeorgeCaliment , 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:) Thank you, |
HI @krahabb, really nice job! |
That's awesome news!! |
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?
The text was updated successfully, but these errors were encountered: