MRS100 hardware 2.0.0

[GeorgeCaliment]

Hi, since I have some "old" device with old hardware version, even if I update firmware through meross app, the latest version I can download is 2.1.4, and, I think cause of hardware version, native position cannot be implemented on it. On older meross_lan version, with signal close and open, all worked fine. The problem is that on current meross_lan version, the signal open/close cannot be set anymore, so is set to 50s as default. Can it be enabled again, or maybe detects hardware version, and don't use native position on them but signal close/open?

EDIT: from logs, seems like the configuration is not saved to device correctly, it returns always the default 50s. mrs100-1695595965.csv

[GeorgeCaliment]

Update: I tried also using cloud configuration, and even with that the configuration of signalOpen and signalClose doesn't work, if made from HA, works only if made from official meross app. At this point I suppose they add some kind of authorization to update device config, or they save it on the cloud so on get device config, the getack returns data from the cloud. I think the only way to make it working on local mqtt configuration, is to save device config locally, and don't let getack config data overwrite it. I can upload logs for local or cloud test if need any.

[krahabb]

Nothing changed in the way meross_lan manages the 'signalOpen' 'signalClose' parameters so it looks like this is an issue of the firmware...but as you said the App is working good so the mistery remains. On your first trace it looks like the configuration messages ('SET Appliance.RollerShutter.Config') worked fine confirmed by the SETACK but then , at the next polling cycle, the readings fall back to 50 secs...

Having the configuration stored locally might prove to be a mess since this would need to not conflict with configuration stored on the device/cloud when these are still Meross paired... I'll think about it...I'm very busy atm so no clue about when :(

[GeorgeCaliment]

In the next days I will try to sniff app's http payload (since that is the only one working when trying to update device config) with albertogeniola's sniffing tool, to see if something changed. I'll update this post if I'll found something.