-
Notifications
You must be signed in to change notification settings - Fork 43
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
Appliance.Control.Multiple failed with no response #399
Comments
Similar issue. Logger: custom_components.meross_lan.mss425f_###############################1 Appliance.Control.Multiple failed with no response: requests=2 expected size=2089 ~~ |
Yep, By design, it is expected to happen particularly on older devices firmware right after initial loading since the integration expects this to work in general but, as stated, some older fw might be more prone to exposing this failure. If you can share the device type and hw/fw version for devices experiencing the warning, I could better make up my mind about the behavior of different devices and maybe better tune this |
In mi case I have a couple of "mss425f". Both with firmware version 3.1.2 and hardware version 3.0.0. One is very close to the main router and the other one is close to an Aimesh node. Both show signal strength 100%. |
Pour moi, l'avertissement indiqué est uniquement pour les mss310. J'ai également 2 msg100 pour lequels il ny a pas d'avertissement. |
I too am getting the same warning every time I reload the integration. Logger: custom_components.meross_lan.mss310_###############################2 Appliance.Control.Multiple failed with no response: requests=3 expected size=2271 MSS310 x 3 |
Happy to put this into a separate thread if preferred. mrs100 7.0.0
|
I had slightly different warnings for all my MSS310 devices after installing the latest update to 5.0.1, Hardware 6.0.0. Firmware 6.3.22. WARNING (MainThread) [custom_components.meross_lan.mss310_###############################7] Appliance.Control.Multiple failed with no response: requests=3 expected size=3888 After reboot they appear one minute later, then again exactly a minute later again. No more after that. |
That's expected: When this happens (beside the warning) the code is able to recover by automatically reissuing the single messages and that's why it is just reported as a warning..it could even likely better be logged as DEBUG since in terms of functionality the code is working ok. (but I preferred the warning in order to gather behavior informations from the 'field' :) Also, when this happens, the code reduces its expectations about maximum payload length and that's why, after a while, this log should not appear anymore since, once the algorithm is tuned, everything should go smooth. In my experience, older devices should 'fail' more (I have an old msl120 which is really strict and overflows with very little payload sizes but, again, after 1 or 2 logs, meross_lan is able to manage this 'tiny payload size') Sadly, there's no way to tell exactly, for each device and fw, which is the limit, hence the 'auto-tuning' feature with the hassle of these warning logs. Also, as an added complexity, the allowed maximum payload size might be different when the device is queried over HTTP or over MQTT. For the latter there might be even more issues (size limits at the broker or different internal buffer sizes in device fw) and so, some devices might behave more erratically (when configured to communicate on both protocols) than just logging a few warning at startup. Given the explanation I'd like to keep receiving notes or updates about this behavior so that the component could be better tuned (one thing likely coming is to really 'demote' this message at the DEBUG level so to not scare anyone) |
Thanks for the update, I think a debug entry would be better if the behaviour being exhibited here is a normal and expected part of this tuning process you describe. For 'normal' behaviour to generate a 'warning' that something has 'failed' is a little bit alarming I think ... 😉 |
I'm now getting this warning logged constantly once every minute for one of my three MSS310 devices, each entry shows a 'size' of 1898, so it doesn't even look like it's doing any kind of auto-tuning, it looks like it's stuck in a loop or something...
Reloading the integrations hasn't solved the problem, in fact it has now started repeating every minute for all 3 devices (I reloaded all 3 instances of the integration because I didn't know which one was generating the warnings). Even after a restart of HA, one of the devices is still logging repeating warnings. EDIT: I've now rolled back to version 4.5.3 to avoid my HA logs getting filled with these warnings |
@RedEarth1 , |
Hi, I believe HA is using HTTP to communicate with them because they're still accessible to the Meross cloud via the manufacturer's app. |
I'm not sure if this helps but for me it is only the MSS310 devices that generate these message, I also have MSL420, MSL430 lamps, MSG100 garage door controller and HP110AHK white noise lamp (Cherub). None of these generate messages. Update: I found this message generated 55 minutes after rebooting ... a different content from the others. Before rebooting I reconnected 2 x MSL430 that had been disconnected for a month or so, I have five altogether, so not sure which one this was. All have the same hardware version 4.0.0 and firnware 4.2.6. I don't get these messages continuing like RedEarth. One message per MSS310 one minute after rebooting, then one minute later only. Apart from the MSL430 with its single message 55 minutes after rebooting. |
MSS310s are smart plugs with an energy monitor so I guess it makes sense that they would need generating more traffic than those other devices you mentioned |
@RedEarth1, yes that's true, the fact that the log is once every 1 minute is a further indication the issue arises (only) when the power/energy readings are queried. |
@krahabb Hi, thanks for your help, always happy to re-upgrade and grab some logs if it helps to solve the problem :-) |
The message I reported earlier about timestamp is popping up at apparently random times. "WARNING (MainThread) [custom_components.meross_lan.msl430_##############################10] Incorrect timestamp: -5 seconds behind HA" Now four of them a few hours apart. Does the number after the string of #### mean something? I have 10, 11, 1, 2. I have not made any changes since my post last week but these warnings are new (other than plugging in a couple of these that had been disconnected for a few weeks). Update: A few hours later and my MSL420 and HP110AHK have both reported the same 5 seconds time error for the first time. I don't know if I can reset the time so have just done a full hardware reboot. |
@dabbler68, |
I upgraded to 5.0.2, it's definitely looking better. Warnings are gone from the log, no errors for this integration, and all the functionality seems to be working OK. |
Hello,
After the upgrade to last version I received the following error for all mss310 devices:
Cette erreur provient d'une intégration personnalisée
Logger: custom_components.meross_lan.mss310_###############################3
Source: custom_components/meross_lan/helpers/init.py:246
Integration: Meross LAN (documentation, issues)
First occurred: 09:04:59 (1 occurrences)
Last logged: 09:04:59
Appliance.Control.Multiple failed with no response: requests=2 expected size=3526
Thanks
The text was updated successfully, but these errors were encountered: