SmartThings Community

Fibaro parameters not saving (April 2019)

Hey @ian_black

Your details are not showing up! Also, please PM me the details.

1 Like

Hi there, I’m not sure what PM means?

Is this what you require?

Kianoosh: I Deleted the info provided due to security reasons, I started a private message with you to discuss the issue in detail

1 Like

PM as in Private Message, sorry for not communicating better in my earlier post.

1 Like

OK, You are using a custom DTH, and your DTH was hitting Null Exceptions because the DTH in use did not assign default values to variables for settings variable, specifically settings.configLoggingLevelIDE was null because the there is no default value assigned to it (commented out in your preference sections).

I generally avoid troubleshooting custom DTHs, but figured this might be useful for others. I would like to encourage users to check and see if the issue reported also occurs with SmartThings approved DTHs before reporting them. Thanks

So, are you saying, there was a problem with DTH ( is that the downloaded device handler?) . If so, I only tried that as the one supported by Smarthings didnt seem to work either and reading forums, it was supposed to work. I happy to go back to the standard
one.

I’m totally confused by the whole of this. I appreciate your help, but can you just inform me how I go about changing the parameters for my Fibaro devices.

Thanks

Ian

OK, @ian_black, even SmartThings DTHs is broken when attempting to set the configuration because the Fibaro Device is set to run locally but the DTH is using the runIn() without using forceForLocallyExecuting: true. So the problem is that runIn() will be ignored for locally running devices if forceForLocallyExecuting is not set to true.

The two affected DTHs are

  1. fibaro-dimmer-2-zw5.groovy - Fibaro Dimmer 2 ZW5 https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/fibargroup/fibaro-dimmer-2-zw5.src/fibaro-dimmer-2-zw5.groovy
  2. fibaro-motion-sensor-zw5.groovy - Fibaro Motion Sensor ZW5
    https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/master/devicetypes/fibargroup/fibaro-dimmer-2-zw5.src/fibaro-dimmer-2-zw5.groovy

A fix for this issue would be for the user to publish the SmartThings DTHs themselves which will cause the two impacted device to no longer run locally, this will then circumvent the runIn issue described above. After the user is done configuring their device, then can either choose to run devices in the cloud or remove their locally published DTHs, and that will cause the devices to be run locally again. I know it is not ideal, but it is a quick workaround for time being until we fix the issue in the prod.

We are working on a fix as we speak now, no timetable when these issues are fixed, but should not be longer than a week.

Thanks for reporting this issue and your patience.

2 Likes

@DanielSiegel See my post above ^, This is most likely what you are experiencing, Thanks for your patience.

I have no idea what all that is about…

I think the everyday user of Smartthings and associated devices want a quick and easy solution and not have to go into this depth of understanding. I for one don’t understand!

Please could you inform me of when this “fix” is in place and how I go about executing it.

Thanks

Ian

1 Like

Blockquote

1 Like

I think I understand. I will probably just wait a week for the fix since I can use Zwave Tweaker in the interim (sounds just as easy - since I have had some experience with Zwave Tweaker).

By the way, I just added some Fibaro switches this morning, and noticed that the Single Switch 2 does not experience this problem (despite my earlier mistaken assumption) – just the Dimmer 2.

Thanks for the detailed explanation and the progress update.

One minor question. One residual UI effect of this problem is the “dashes” instead of the energy usage reporting in one section of the interface (see my original post in this section, or the attached picture below). I assume this is related to the same issue. Will this go away once your fix is implemented? Will I need to remove and re-add the affected Dimmer 2 switches?

The fix for this issue has been released, please let me know you are still having issues saving the configuration to the two mentioned devices.

1 Like

I just installed 2 Fibaro Dimmer 2 switches about an hour ago (on my test bench) - roughly 5PM PST.
It does appear that something has changed.

In both cases, the parameters now do appear to sync correctly. When changing/saving the parameters, the UI (in the area I marked in the picture above with a red arrow) now cycles thru the parameters and indicates “Sync OK” - as it did before.

But, this Sync OK message stays there (unlike the old energy info - see my picture above).
Not a big deal, as this info seems somewhat redundant. Just wondering why this changed.

Also, while both of these switches function correctly, one of them is not properly updating in the UI.
Appears to be very inconsistent. The attached load turns on/off correctly (both from an attached physical switch and remotely via the classic app). But the UI does not always update, even after waiting for multiple minutes.

Not sure yet why this is occurring, or how it might relate to the fix.
I have another 5 switches to install (after testing first), and will report more later tonight.

Appreciate any info as to exactly what changed to implement this fix.

1 Like

Just finished adding/testing another 7 Fibaro Dimmer 2 switches (7PM PST).
All looks good with the fix. The config parameters change as they did before this sync problem arose.

The only odd change is the UI feature I mentioned above (says “Sync OK” permanently instead of showing the energy usage, except during an actual sync, when it correctly displays the cycling thru the parameters until the sync completes). Not sure why this change occurred. Just curious.

Anyway, thanks for the fix. Appreciate any detailed info you can provide as to what exactly was fixed/changed.

See this post for detailed on what was wrong and what was changed Fibaro parameters not saving (April 2019)

Hi @Kianoosh_Karami, just a heads up, I’m not getting the parameters to sync fully, they hang at parameter 38 then time out. Thanks to @RobinWinbourne, I now know that parameter 38 was added only recently to the Fibaro firmware, so those of us with older devices will eternally have “Sync incomplete! Open settings and tap Done to try again.” Is there anything that can be done? Drop parameter 38 if it’s not crucial? Or implement Z-Wave over-the-air updates? :wink:

2 Likes

I personally am not familiar with Fibaro parameters, but if this is something missing from the DTH, we can reach out to the Fibaro team and ask them to update the DTH.

1 Like

It’s not so much that something is missing, more that too much is included, without and checks against firmware numbers.

Parameter 38 never used to exist, but it was added at some point with a firmware update, so for older devices running the old firmware, parameter sync fails due to that number not reporting a successful update.

I’ll take a look at the DTH this weekend and If i can figure out a way for it to work for new and old firmware, I’ll suggest the necessary revisions. It’s certainly possible to get Fibaro modules to report firmware version, so I just need to write some code around that.

Are zwave OTA updates ever likely to happen?

2 Likes

I’m not sure I understand. You pointed me to this same thread.
I saw your point re the RunIn issue (before the fix), but didnt see any info about what precisely was done to implement the fix.

For example, I am assuming you did not change the standard Fibaro DTH (“Fibaro Dimmer 2 ZW5”), and made changes only to your back-end cloud server code. Is that correct, or am I missing something?

If that is the case, I was wondering why there was a slight change in the UI (see my picture above).
It now says “Sync OK” (except during the actual sync) instead of reporting energy usage.

This is not a big deal, particularly given that you fixed the “sync problem” and my Fibaro Dimmer 2 switches are now syncing as I add them to the hub. By the way, as I suspected, I did need to remove the prior ones (that were added after this sync problem occurred, but before the fix) and re-add them to the hub. This worked fine.

Just wanted a little more detail to understand why the UI has changed slightly.

Gotcha. Sorry, I was under impression about the change to fix the configuration syncing issue.

I am not sure what has changed so that UI look different. I will run that by other folks and see if they can weigh in on the matter.

Why or how the UI changed is of minor importance compared to knowing if SmartThings are thinking/have thought/are in the process of introducing Z-Wave OTA updates which would benefit ALL ST users and be of gargantuan importance.