Same happening for me too.
Seeing this in the logs for the child devices. (EP-1 & 2).
Tagging @ericm. 
Folks.
To resolve this go into the driver code and change all instances of multichannelv3 to multichannelv4.
This fix is courtesy of @christi999 .
5 Likes
Perfect thank you @bobbles for replying and thanks to @christi999.
Where did you find this solution please @bobbles?
Christi999 has re-released his driver for the Fibaro implant.
I decided to take a look at it and in his notes he mentioned it was updated to make it work with the last update.
I asked what he did, tried on the 222 and 223 drivers and it did the trick. 
1 Like
Worked for me, thanks.
1 Like
I am having issues with the update of the swich state when using the wall switch.
It works without problems from the device page, on and off, and the state updates in the dashboard accordingly.
However, if when the light is on, I switch it off from the wall switch, the light in the dashboard and the switch state remains ON. If I switch it off from the device page or the dashboard, the state updates to OFF and the light remains off.
EDIT: If switch on and off from the wall, it updates well in the dashboard, it only fails when switch on from the dashboard and off from the wall. The switch in the dashboard remains ON.
Hi,
After last system update 2.2.2.X All fibaro switches stopped working for me.
I took the latest version (15 Aug 20) but the new version
- has a bug that no handling multichannelv4, anyway - I fixed it.
- The activation is not working, so If I click in the driver on Turn Off it shes in the log the ChildOff, but it is not performed and nothing happens. the same occur if I click on the child in the dashboard.
Any assistance?
Are you on 2.2.2.xx or 2.2.3.xx which is the latest update.
On the latest I have found that Fibaro devices that use custom drivers no longer work correctly.
They either do nothing or do turn on and off but do not update status.
I have 5 which no longer work on the C7 but are ok on my C3.
@Cobra , I have the C3/C4 but it doesn't work. Using the latest driver. (and latest HE)
I analyzed the problem and here are my findings:
I've said it before and I'll say it again.... You're a legend, mate. The bug with the status not updating and dashboard switches bugging out has been driving me crazy for months. I finally got round to looking into the problem and this right here was the issue. Updated the code to "multichannelv4" and bam! fixed!
1 Like
Hi all
Over the weekend I updated the metering child device handler as @cjcharles0 has updated for home automation platforms.
I am assuming the simple changes to this are not the cause of the issues I am now experiencing.
I have a C5 running 2.2.4
Although the switches are working, there are debug messages appearing in the Live Log -
Also the state of the child devices is not updating, and can only be state synced using the Refresh button on the child device screen. This is having a side effect of the effective use of Groups...
Is anyone else experiencing these issues with Fibaro FGS-223s using @ericm device handlers ?
If youre talking about the child update so it is detected as a light then yes I did make that change, but that doesnt explain your issue.
I have a C7 hub and have been having a number of issues with my FGS222 and FGS224 devices (I skipped the FGS223 model for some reason, and had slightly different issues on each of the 2.2.4 firmware versions!).
I think Ive solved most of them now for my devices, and they might work with the 223 model if you can't get your device handler working. A fair few of the issues seem to be caused by the switch from multichannelv3 to multichannelv4 (driven mainly by Hubitat firmware I think) - have you changed all references in the device handler from v3 to v4 already?
@cjcharles I wasnt inferring at all that the change has caused. Just explaining why I updated.
I am looking at the fgs223 device handler and have changed as you suggest -
def zwaveEvent(hubitat.zwave.commands.meterv4.MeterReport cmd, ep=null) {
def zwaveEvent(hubitat.zwave.commands.multichannelv4.MultiChannelCapabilityReport cmd)
def zwaveEvent(hubitat.zwave.commands.multichannelv4.MultiChannelCmdEncap cmd) {
private encap(cmd, endpoint) {
if (endpoint) {
zwave.multiChannelV4.multiChannelCmdEncap(destinationEndPoint:endpoint).encapsulate(cmd)
} else {
cmd
}
}
and the state is still not being updated.
I see there are loads of other V1 & V2 commands in the device handler also.
Do these need to be updated?
Where is this all documented so I can debug issues more effectively in future?
Cool, no worries, I wasnt offended! Child devices shouldnt affect the parent handler much, but I do think the change from v3 to v4 will probably fix most of the problems you see. Probably the latest Hubitat firmware removes some of the options for v3 comms, hence there is less success.
Do you get a different error message now, since the v4 MultiChannelCmdEncap is the one that was missing and should now be present.
Its not really documented as Ive discovered, and the Fibaro devices have a hotch potch of handlers scattered over the forums without a good reference point for which ones to use and where to get them. I'd like to fix this in December if I have time, and perhaps host them all on Hubitat Package Manager aswell.
Yes getting an error message now -
so I have changed this method back and seems all working as before 
def zwaveEvent(hubitat.zwave.commands.meterv3.MeterReport cmd, ep=null) {
Yup, just change multichannelv3 to v4, that is used to encapsulate other commands, so should get most things working
And it has thanks@cjcharles
There was a delay in dwitching over the new handler I think and changing and Save Preferences seemed to force the issue.
I have never used GitHub (been over 20 years since I was programming) and was wondering if it is worth pushing the update to the device hander?
So its working now and I thought I would turn on the Debug messages and see if I can learn more about zwave commands and Hubitat Device Handlers.
I am seeing the following messages in the log when I turn off and on each of the 2 endpoints.
Should I investigate these further ?
What comment/log are you concerned about? Everything looks good to me.
I proposed a change to @ericm's device handler so its easier for other people in future, so if/when accepted then it will be public for everybody on the above link.
