I decided to replace my Dimmer2 with Wallis because I have scary little space behind the switches to keep it long term like that.
According to the manual, the Walli Dimmer relies on ZWave association groups in order to support multiple switches (i.e no support of an existing wired connection any longer).
It seems however, that any attempt to edit association groups in Homey is failing with error message:
MULTI_CHANNEL_ASSOCIATION_REMOVE is not a function.
Is there a workaround or do I have to disassemble everything again?
Cheers,
Aron
@Athom: What is this weird thing with “Title seems unclear. Is it a sentence”. An Error message code can be considered as clear. The title:
Walli Switch: MULTI_CHANNEL_ASSOCIATION_REMOVE is not a function
is in my eyer super clear.
If there was an algorithm which can really judge whether something is clear or not, it should be sold to make you rich!
Hm, that welcome message doesn’t state that they don’t respond here. Actually prior my post I tried to contact them first, ask before complain ;), but on no page I visited I could find a contact link.
It could be so simple: navigate to the app page, click on the link for the project/ vendor and get in touch.
Anyway, I can hardly imagine that editing associations (for Fibaro) devices is so rare that this error remained unobserved. I am therefore wondering whether I did a stupid mistake…
I tried to work around the issue with flows, but its sort of hell; for instance the flow cannot be hooked on “Walli switch turned on”, but only on “Power meter changed”. The second doesnt work because on this kind of switch one doesnt have any direct load (as the lamp is only connected to the dimmer).
If these flow cards are not available, then the device didn’t include properly, as those flow cards are default there when the device has an on/off capability, which I assume it does?
as for the error MULTI_CHANNEL_ASSOCIATION_REMOVE is not a function. that is the same, usually happens if a device failed to include properly, and misses a few capabilities/command classes it has.
associations are taken care of by Homey’s z-wave core, the app can’t touch this part except for adding a bit of explanation text to what an association group can do, but that is it.
Thanks for the hints. I have meanwhile tried to include another Walli Switch - this time in double switch mode:
I can edit and assign association groups. They in fact work (apart from the problem that the two buttons are not synchronized)
I still cannot create any flow with on/off capability. Would be a strange second inclusion error.
The Walli Switch is included anyway in a strange way:
The Fibaro Double switch gets imported as 2 devices, so basically you can configure them separately
The Fibaro Walli Switch gets always imported as 1 device with 2 buttons. It is my (bold) assumption that one on/off capability cannot be linked to 2 buttons, i.e. which button(s) would it control?
I have raised a support request around the error and as for your hint, I will exclude and include the switch-in-single-mode again and again, just to see whether its behavior improves.
For other readers:
With the Walli switch in 2-button-mode, I succeeded to link it to the dimmer; Walli Switch (ID:131) Walli Dimmer (ID:141) by
The Double Switch has 5 groups:
Assign value 141 to group 2 (this is for the upper button)
Assign value 141 to group 4 (this is for the lower button)
The Walli Dimmer
Assign value 131.1 to group 2 (this is for the upper button on/off)
Assign value 131.1 to group 3 (this is for the upper button dim)
(I didn’t manage to address the second button as well)
i’m not sure why Athom implemented it this way,
usually the rule that we keep was that it was related to the amount of outputs is the amount of devices that gets added, so:
2 outputs 2 inputs = 2 devices
2 outputs 1 input = 2 devices
1 output 2 inputs = 1 device (2 buttons)
1 output 1 input = 1 device
But if you want a real answer, you’ll have to ask that to Athom.
As for the on/off capability, i’ve checked the code, and they just forgot to implement the on/off triggers into the code, usually that is there by default, but the walli switch is kinda a weird device for implementation into Homey, so they probably overlooked that part (feature request thingy!).
There should be “Button scenes” triggers as flow cards, that will do pretty much the same, but with more options.
Is the Fibaro code open source? Could you point me to it?
What you mention behind the device by output strategy makes a lot of sense to me. I have placed that question to Athom because this single device has always the problem that it cannot have a proper name (i.e. you always have to refer to button1/ button2/ output 1/ output2 which makes your flows hard to read). I do suspect though that they made it a single device since some options, like the LED ring cannot be on both devices (they could contradict).
The scene button is operational, but it is very hard to get the thing right to get the thing right with the flows. For instance, you have no way to check whether the Switch is actually on/off since it has no load, this means you have to rely to trigger on/off on the dimmer in the flow -but this leaves you with wrong LED indicators (LED is on while light is off).
As a z-wave guru, do you happen to know whether self-associations in z-wave are supposed to work? I have tried to trick the Walli 2-switch to behave like 1-switch through associations, but it had only a weird effect.
Athom can disable the settings on the 2nd device/relais just fine like they (should?) do when you include it as the double switch, as indeed only the main device know what to do with parameters.
well, you could switch a “logic yes/no value” and have that as state for on/off, but i agree it is not how it supposed to be.
i’ve never worked much with associations as I would loose a lot of control of what is going on between the 2 associated devices, making it kinda hard to debug certain situations just for a few milliseconds of faster responds time.
but it should work like this:
association group 2: Node_ID.4
association group 4: Node_ID.2
For me, associations are quite useful to “link” devices together, rather than “automate”. Good example here are indeed the walli switches: 2 switches, each with an LED should behave symmetrical depending on the state of the ligth. Then however, only one can switch the light.
With associations, I should be able to link the two devices together, as you mention with node id and group (where as the UI could be MUUCH more helpful by allowing me to select the device by and the group by function).
With flows; I am less worried by the little timing difference, more about the number of flows I need:
1 flow per switch to change the LED state of the master and the slave switches to ‘on’
1 flow per switch to change the LED state of the master and the slave switches to ‘off’
(toggle doesnt work since then the LED could remain ‘on’ while the switch is off)
Another aspect is security, esspecially fire alarms: since the associations do not require the hub, an interrupted connection to the hub doesn’t impact the behavior, i.e. the blinds move up on fire alarm, even if the hub is not reachable (or cannot reach all the devices)
