Ah I see. So it sends from the root device but does it specify which switch has changed?
I have changed it to:
Switch outsideLight "Outside Light" <light> (LIGHTS) { zwave="6:command=switch_binary,respond_to_basic=true" }
Switch hallLight "HallLight" <light> (LIGHTS) { zwave="6:2:command=switch_binary,respond_to_basic=true" }
Now the status is updated however the status of outsideLight is modified no matter which switch is pressed. Is there anyway to update the status of hallLight as well?
Hmm - I thought from previous experience with these switches that endpoint 0 was the same as endpoint 1 (this is also how it is written in the zwave standard). What happens when you press switch 2 - does it send exactly the same thing as switch 1 or is it MC encapsulated?
If it always sends the same thing, then this switch might now be using the same strategy as the new Qubino switches. Is this a new switch?
It looks like when I press switch2 exactly the same thing is sent so endpoint 0 is always updated.
This is a FGS-223 which is new.
Ok, then I guess Fibaro has updated their code to use the same concept as Qubino are using. The bad news is that this isn’t supported in OH1 - probably, if it’s the same issue as Qubino, then it should work in OH2.
Ok I will give OH2 a go and report back.
Thanks for the help.
I just did it, BUT it remains the same problem (an by the way also with the Qubino devices), the issues are NOT resolved with the OH2 binding.
See also this thread
https://community.openhab.org/t/how-to-access-different-endpoints/5117/40?u=vossivossi
I can confirm the same problem on OH2. I can see the association is now using MULTI_INSTANCE_ASSOCIATION commands however the it has not fixed the problem.
Please provide a log of this - from the logs @vossivossi provided, it shows it was NOT using the multi channel association so if yours is I’d be interested to see what’s happening…
I have just checked and I am seeing the same as @vossivossi, it is only using it for the GET not the SET.
Ok- thanks - at least it’s consistent. I’ve had a look at the code - I need to think it through a little more but I’ll likely make a change to try at some stage - probably later tonight, but let’s see how it goes as I’ve been travelling for the past 24 hours so without much sleep…
I think I have spotted the bug in the code. If I can work out how to get the dev environment setup I will make a change and test it!
I know what is stopping it working - the question is how to solve it in a way that is compliant to the spec since there are some specific requirements on how this is used.
Please can you post the XML for the new FGS223 (@smee204), and also for the Qubino (@vossivossi). I want to check that the information ties in with the slightly complex conditions imposed on this in the standards.
I’ve made a change, but I’m not sure it will work for you yet. Since this only affects group 1, and there are other problems preventing you changing group 1, this change may not actually do anything. If you exclude the device and add it back it might work. Make sure you keep a log so we can see what happened during the initialisation if it didn’t work.
@chris
I recently got an FGS-213 to use to monitor my floor heating, I’ve noticed some stuff were missing.
For openhab2 I’ve updated the database for the Single switch 2 FGS-213 the same updates should probably be done for FGS-223 (if they are correct)
Added the Sensor_power command class and added the meter_reset, please review when you have the chance.
Regards, S
Are those issues above solved? @Lyve, @Woutch, @ossostborn?
I’m thinking about buying three of those devices and don’t like to burn my money 
Thx.
Hello @sihui,
I can confirm that the input for the scene value now works. But I’m not able to test it at the moment.
For the rest, I have no issue with my FGS223, but I have only one in use now driving 4 LED spots.
If you need more info, please ask!
Best regards,
Wouter
Thanks a lot!