Regular Warning in Log: KeyError(0) in NamespaceHandler

[sparment]

I'm getting a regular Warning in my HomeAssistant log. I have

Version of the custom_component

v5.0.4

Home Assistant Log

This error originated from a custom integration.

Logger: custom_components.meross_lan.msg200_###############################0
Source: custom_components/meross_lan/helpers/__init__.py:274
integration: Meross LAN (documentation, issues)
First occurred: April 25, 2024 at 8:03:28 PM (2 occurrences)
Last logged: 8:30:25 AM

KeyError(0) in NamespaceHandler(Appliance.GarageDoor.State)._handle_list: payload={'state': [{'lmTime': 0, 'channel': 0, 'open': 1}], 'reason': {'online': {'timestamp': 1714089809}}}
KeyError(0) in NamespaceHandler(Appliance.GarageDoor.State)._handle_list: payload={'state': [{'channel': 0, 'open': 1, 'lmTime': 0}], 'reason': {'online': {'timestamp': 1714221026}}}

Describe the bug

Warning that shows up in my Home Assistant log. Device: msg200 4.0.0 The device enables 2 garage doors

[krahabb]

Hello @sparment, could you post either a diagnostic or a trace log?

[sparment]

Hello @krahabb I'm not an expert with the logs... I enabled the logger to pickup more information on meross_lan and attached the output. I'm not sure this is exactly what you are looking for though. Please let me know. Thanks for your help! home-assistant_2024-05-01T00-20-10.481Z.log

[krahabb]

Hello @sparment, could you post either a diagnostic or a trace log?

The debug log you've posted doesn't contain the low level messages so it is not enough. In the previous post (linked here) you'll find reference to the instructions for tracing/diagnostics...either is fine, the diagnostic is easier to get since you just have to hit the 'Download diagnostics' menu item from the configuration entry (the '3 dots' menu at the right of the 'CONFIGURE' button)

At any rate, that message, at the moment, seems just a bit illogical and the warning log comes from the fact that the msg200 usually has 3 channels named '1' - '2' -'3'...so there's no channel '0'

Beside the warning, do you have any apparent malfunction with the device?, are you using all of the channels?

[sparment]

Thanks for the response @krahabb. Attached is the diagnostic file.

Aside from the warning, I do on occasion see the 2 garage doors I have as non-responsive.

config_entry-meross_lan-c130e798ea2c3a32b9556a61a4c1b75f.json

[sparment]

I'm not sure if this would be an issue, but I see that I have 2 hubs showing up in the integration in HA. One is called "msg200 - Meross Bridge" and has 1 device and 22 entities. The other has my email address as the name (my user ID for Meross online) and shows no devices and no entities.

I've attached the diagnostic from that hub here as well.

config_entry-meross_lan-887c2b8d66655ae52bef8e1b0783f7fb.json

[krahabb]

Hello @sparment, The diagnostic from the device entry is ok: it confirms the 'strangeness' of an additional toggle channel (these devices had always exposed those 'toggle-like' entities but in meross_lan they're ignored since I don't have a clue about their meaning and the integration looks like working even if they're ignored. The new fact here is that there's an additional toggle channel that 'confuses' my algorithm so I'd need to patch this a bit.

As for the device becoming unresponsive it might be the http connection sometimes fails (there are always issues on the HTTP protocol which I'm still trying to fix)

In order to improve connection reliability you could enable the 'Allow mqtt publishing' option in your Meross cloud profile entry (the second you attached i.e. the one labeled with the email account name) This will allow the code to switch-over to cloud mqtt in case of http failures (the code will anyway try to re-establish http connectivity as soon as possible) Using cloud mqtt might be risky on your Meross account since Meross has a policy about maximum traffic over their cloud servers but meross_lan has a rate-limiting in place which should be safe enough (it is very very limiting)

[sparment]

Thanks for the responses @krahabb! Please let me know if I can do anything to help with further testing of a solution.

[madasus]

@krahabb I'll move the discussion to this thread. It looks like this is tagged as fixed but i'm still having issues.

For example - I have channel 2 and 3 disabled on my MSG200 so only channel 1 is enabled. On initial load it created

cover.meross_mh_garage_middle_garage

once i opened and closed the garage the integration created

cover.meross_mh_garage_middle_garage_1

Right now the garage is closed and showing as closed in the Meross app directly but HA shows

cover.meross_mh_garage_middle_garage = Open cover.meross_mh_garage_middle_garage_1 = Closing

I have three MSG200's and all seem to be showing the same behavior. All of them were working on a few weeks ago and i'm not sure which update broke this.

Any ideas?

[krahabb]

Hello @madasus, There's another fix (in 5.2.2) involving a broad range of possible issues like this and #439. If I'm not wrong you said you're on 5.2.1 so I suggest you to update and see if the fix helps.

[madasus]

Confirmed - looks much better. Will continue testing today.

[madasus]

It looks like it is working better but is still randomly creating duplicate entities. Today

cover.meross_mh_garage_middle_garage_4

Just randomly appeared and shows as open.

cover.meross_mh_garage_middle_garage is the original entity and that is still working fine

[krahabb]

Wow..that should be due to a message indexing channel '4'...I'm completely lost for the matter..I hope these are just bugs in the meross fw that will be fixed..else we'd just have to wait and see. Incoming release has a more 'discrete' approach to the issue by completely discarding these unexplicable message/channels unless the device entry is configured to create 'diagnostic sensors'

[madasus]

i wonder if its really channel 4 or whether HA is just creating a duplicate and it has already created _1,_2 and _3

[krahabb]

Yeah..you're right..it could be the automatic entity id generation from HA. At any rate, the last version should totally avoid generating entities by default (except toggles (switch) if any is published).

Only enabling 'create diagnostic entities' in config would generate a diagnostic sensor (not a cover for the matter) so I don't get why a cover was generated again.. I'll check if anything is working as expected before releasing the next official Moonlight.3