Collect informations to support improving Alexa support

[IvoGruber]

The idea of this discussion is to collect information about how Alexa deals with matterbridge-shelly devices to make better decisions on how to improve the plugin to better support it.

[IvoGruber]

As as first observation Alexa creates a device called "Matterbridge aggregator" of type "Hub". This lists all supported devices and some of their components.

There is always one device for the composed device in the devices list of matterbridge. This gets the same name in Alexa as in the name column of the device list in matterbridge. The type of these devices depends on the type of the shelly device and is either "Sonstiges" ("Other") or "Fernbedienung" ("Remote"). Looks like all devices with an input component like switches result in a device of type "Remote", others have the type "Other".

All supported components result in additional "Verbundene Geräte" (connected devices) of their "main" device as described above.
These get generic names like "Erste Steckdose" ("first outlet"), "Zweites Licht" ("Second Light") etc.

[Luligu]

Is frustrating that way I agree with you...

[IvoGruber]

Do not know, why I see this only now, but disabling exposing input component turns the composed device into on of type "Other". So it seems, that Alexa just gives the first component in the composed device the "real" name and appends all others below this.

This gives some hope that being able to disable all components despite the "light" or "switch/outlet" will result in a more usable initial state of the device in Alexa. See https://github.com/Luligu/matterbridge-shelly/issues/97.

[Luligu]

In the last im coding using Alexa to check and this child endpoints name behaviors of Alexa is really uncomfortable 😣

[Luligu]

[1.1.0] - 2024-12-14

Added

• [package]: Verified to work with matterbridge edge (matter.js new API).
• [package]: Requires matterbridge 1.6.6.
• [shelly]: Remove from discovered devices the device with mongoose firmware. We ignore them.
• [shelly]: Add shellyIdentifyCommandHandler.
• [BLU]: Add validate against white and black list for BLU devices. If you put a shelly BLU in the white list, you need to put also his BLU gateway on the white list.
• [BLU]: Add global and single device component black list. You can now exclude a shelly component globally or on a device base (available also for BLU devices).
• [matter]: Add tagList to the descriptor cluster.

Changed

• [shelly]: Refactor shellySwitchCommandHandler.
• [shelly]: Refactor shellyLightCommandHandler.
• [shelly]: Refactor shellyCoverCommandHandler.
• [colorControl]: Refactor configuration of the cluster.
• [electricalSensor]: Refactor electrical measurements initial configuration.
• [matter]: Update all device types.
• [package]: Updated dependencies.

[IvoGruber]

I wonder what would happen, if there is just on endpoint with the main component, since if we have an input device, Alexa treats this like a remote control. If there is none, it treats it as "Other".

But even disabling all non-primary components does not help yet. I wonder if the "PowerSource" endpoint is still in the way. MY older attempts to remove it codewise ended in the device not to appear in the matterbridge list. Even moving it behind other components did not help (still had the same endpoint number, but was listed later in matterbridge).

@Luligu is it possible to make the PowerSource-Endpoint to be disabled as well via component black list?

If that is not possible or does not help I see only one remaining chance to male Alexa support easy: Expose every component as single device and do not compose things (if a special configuration flag is set [globally or per device]). This still needs a good naming schema. The main component could be named after the device name in the devices web ui and all others after this name with some more or less useful (configurable) suffix that depends on the component name.

[Luligu]

I will make some test about removing PowerSource via component black list.
That should be possible I guess. Even if I don't know what advantage we can get with Alexa before I try.

[IvoGruber]

Just tell me if there is something I can try out and I will test it as soon as possible.

[IvoGruber]

Removing PowerSource works now in the dev-Branches but did not help. This is what I did to check and get more insights:

1. Configured a ShellyDimmer2 as the only device on the whitelist (to investigate only on that device)
2. Disabled input-components (set exposeInput and exposeInputEvent to disabled at the inpul-config-section) globally (to get rid of that in the entpoint list)
3. Disabled PowerSource (at the endpoint-config-section) globally (to get rid of that in the endpoint list)
4. Restarted matterbridge (via button) to check if I only have that dimmer device and only the compose- and switch component for it.
5. Stopped matterbridge.
6. Removed everytihng in the folder (.matterbridge) despite the matterbridge-shelly.cofig.json file to get rid of all the old stored infos and get fresh endpoint numbers after restart.
7. Added matterdbridge-shelly to matterbridge again (since that got lost by the removal)
8. Startet matterbridge again

I now had new endpoints main (id 2) and switch:0 (id 3) for the dimmer and everything as nice and clean as wanted. Now I added everything to alexa:

1. Removed the old bridge connection in alexa app as well
2. Recommissiond the bridge again with the new qr code.

I now still got an "ohter"-type main device named "Dimmer Gästezimmer" (the name from the web-ui of the shelly-device) and an "Erstes Licht" (first light) secondary device.

Next I set exposeInputEvent from disabled to mandatory (kept exposeInput to disabled) in the matterbridge-shelly-config and got the two input components of the dimmer back in the endpoint list with id 4 and 5 in the endpoint list of the device. Than recommisoned again and as previously mentioned alexa now makes the "main" device that gets the name of the shelly device a "Fernbedinung" (remote control) instead of "Ohter" as before.

So endpoint id numbering and order in the devices endpoint list in matterbridge both are not the reason why it can pick up a remote control but not the light as first device.

Assumption currently is, that it is related to the device type number. The input-endpoints is 0x00f, main is 0x0013 and light is 0x101 in this case. Maybe alexa orders things in a "device" by this number and thus got the input first, second main, than light. If main is first (when input is absence) it exposes it as "other" device. If "main" is second (when output is present) it ignores it but makes "input" its first "device" and "switch" the second?

Anyway it does not explain, why it does not show up two "remotes" since the device has two inputs! Maybe it combines them into one (but does not tell me anything about tho buttons yet, needs more investigations) or just ignores the second. Two switches as in a ShellyPlus2PM get presented as two devices (if the device is configured that way and not as a shutter device).

[Luligu]

Hi,
will be released soon but if you have time, check shelly plugin 2.0.0 in the dev.

There the default for new setups creates a very simple device suitable for Alexa.

Also introduced the expert mode in the config and refactored the config removing the duplicated list/select options as we said.

So will be a major release.

[IvoGruber]

Hi,
simple config mode seems to be a better/good starting point for newbies. nice! do not know if whitelist would be better than blacklist in simple config?! also expert mode is nicely cleaned up. Thx.

but simple config still triggers the same configuration needs in alexa to get things running.

The colorbulbs expose two light components now in simple mode? pls. check those again. do not know if this was just some dirt on alexa or caused by the new version of the plugin.

[Luligu]

Hi,
I choose blacklist cause I will add to Devices page the selection soon...

The simple mode triggers a few automatic behaviors that with default configuration create very simple devices suitable for Alexa and SmartThings.

Will check again colorbulb but I guess is an Alexa issue caused by the major upgrade. The endpoint is actually different.