Error when using two Blue 2-in-1s together in a Z2M group (rampRateOffToOnRemote)

Hi all,

I’m receiving the following error for 2 separate Blue 2-in-1s that are setup in the Z2M group called “Basement Main Lights”.

2023-09-15 22:28:13 Publish 'set' 'state' to 'Basement Main Lights' failed: 'TypeError: Cannot read properties of undefined (reading 'rampRateOffToOnRemote')'

If I turn on/off each of the single pole lights individually I don’t get the error. It’s only when I turn on the group that has both switches in it that I receive this error. The good news is that it’s still working but I’d like to understand what is going on so I can fix it.

A little more background for context:
I have a room at home with a Blue 2-in-1 switch at each end. The room has a bulk head that splits the room in half. On each side of the bulk head, I have 4 LED downlights controlled by the nearest Inovelli blue switch. The wiring was done so that each of the groups of downlights are connected as a single pole so that the nearest switch can turn on/off/dim the nearest set of 4 downlights. I have an automation that when double pressing up on either switch will turn both lights on to 20% brightness and then holding up or down will brighten/dim both groups of lights. To do this, I have both “front” and “back” dimmers in a Z2M group titled “Basement Main Lights”. The setup works but as mentioned above I am getting the called out error I’d like to correct.

1 Like

I submitted this issue a few days ago with the intention of looking into it further. It seems like some of the device-specific parameters aren’t being populated in the group, and I can “fix” the issue in Z2M by accommodating the “undefined” return value when it looks for rampRateOffToOnRemote in zigbee-herdsman-converters/src/devices/inovelli.ts and just return a default value. As I mentioned in the issue, I’m also seeing some weird group behavior where sometimes non-Inovelli devices in a group don’t turn on in response to a group command sent by Z2M, and it’s always accompanied by this error. I haven’t conclusively determined if guarding against the error fixes it, but it does make the error message go away.

I also see that the author did some refactoring a few days ago (move all devices to TypeScript) and there’s now an annotation there, so perhaps the latest dev version changed the behavior.