I’m using a galaxy S7, even with the commenting out, it’s not working for me. It’s not opening, it’s crashing the whole ST app as I said above.
At line 131. For the fault tile, the backgroundColor is missing the “#” This causes the color not to load, at least on android 
1 Like
Good find! Fixed.
Rendering of tiles is horrible on Android (nothing to do with your handler) especially if there is icons involved. Take a look at the current and accumulated power
I’ve commented out the icons as a temporary solution on all the four small tiles. The icons on these never load on my phone anyway, at least now the text is aligned.
Can I just ask what ‘defaultValues’ is - so that I can determine whether to uncomment them from the code? (I use iOS) In addition, to uncomment, i just remove the // at the beginning of the line, right?
Yes, I found this too. I doubt I need a bypass as there are two 42W Halogen bulbs in the light unit.
My devices was also unresponsive. I looked at the live log and after the configuration sync was all done the device became responsive again.
Could you give an example on what you comment out?
Hi David, thank you for this handler. I’m using iOS, and have found an issue in that whenever I go into the preferences #13 is always set to number 2. Therefore when I exit it’s always followed by the auto calibration. I understand that the calibration is supposed to set this to 0 once it has run?
If I change #13 to 0 and exit the lights then stop working, which I can only assume means it’s taking all the default settings, and not the settings it determined from the previous calibration. I can’t see what the settings were auto determined, because they don’t appear to get saved?
I hope that makes sense?
All this is covered in the usage instructions, see here: https://github.com/codersaur/SmartThings/tree/master/devices/fibaro-dimmer-2#auto-calibration
If parameter #13 is used to force auto-calibration of the device, any values that are specified for parameters #1, #2, and #30 will be ignored. Monitor the Live Logging tab in the IDE to discover what the new auto-calibrated values are.
Next time the parameters are updated, remember to set parameter #13 back to 0: Readout if you do not want auto-calibration to be forced again. Additionally, review parameters #1, #2, and #30, as any values specified will over-write the auto-calibrated values.
2 Likes
Thanks, I really should have read the manual!
I’m definitely out of my comfort zone with this stuff. It didn’t help that I hadn’t wired up the switches correctly so that in certain positions the dimmer wouldn’t work at all! In my defense it was a 3 switch setup with an intermediary switch involved.
I have given this a go and it does seem to offer good potential, so thank you for putting so much time into it.
I have tested this with a few different Fibaro 212’s in my house - some were working fine before and two are brand new that I installed today. Afraid I have a few issues with it:
-
The dimming does not work on the new devices, when using SmartThings. Even if the percentage is set to ~40% (or whatever), the lighting does not change, and if I exit the device and reopen the device page in the app then it reports 100% again. I have tried setting all settings but it still does not make it work. Reverting to the original ST device handler makes it work. Strangely this problem does not appear on the devices which were already installed.
-
Resetting the energy counter with a single accidental click is quite annoying, I would suggest this is turned off, or at least made a little bit harder.
For issue 1 I see this in live logger:
5590115c-a87d-4241-a5f0-bd10d34ea650 22:17:25: info New sensor reading: Name: power, Value: 10.1, Unit: W
5590115c-a87d-4241-a5f0-bd10d34ea650 22:17:19: info Setting dimmer to 40%
(but I dont get any change in light level)
I’ve found this happens when the auto-calibration mode has decided that the load is non-dimmable (this sometimes happens even when the load really is dimmable). Check what the device reports for parameter #31. You can over-ride it by setting parameter #32 to 0. If the device is dimmable from the physical switch, check that you have not enabled RF protection.
Good point. I am planning to make the reset require a double-tap in the next release.
1 Like
Right you are, forcing it to allow dimming does seem to have worked on the new bulbs. I have no idea why it decided these particular bulbs were not dimmable!! Will have to play with another auto-calibration to see if that fixes things, but can wait until tomorrow I think.
Double click would be good, but Id rather there was some overriding setting to prevent a pocket fumble deleting data. Ive disabled the reset command in my copy of your handler so its no biggie any more!
Thanks again, look forward to playing with it a bit more over the next few days.
When Nightmode is enabled, the DTH makes a note of the current value of parameter #19.
When Nightmode is disabled the original value of parameter #19 is restored.
This preserves a forced switch-on level when Nightmode is not in operation (DayMode if you will).
It sounds like you have configured parameter #19 while Nightmode was disabled, and this is getting restored when Nightmode is disabled. It should tell you in the IDE log, e.g.
info sync(): Syncing parameter #19 [Forced Switch-on Brightness Level]: New Value: 50
info sync(): Syncing configuration with the physical device.
info disableNightmode()
...
info enableNightmode(): Saved previous param19: 50
info enableNightmode(): Saved previous active level: 5
info enableNightmode(1)
The solution is to set parameter #19 to zero, while Nightmode is off. 
HTH
Nightmore remembers the value of Parameter #19 that has been reported by the device. If a configuration report for parameter #19 has never been received, then it is assumed to be zero.
The value you have set (or not set) on the settings screen is irrelevant at that point.
Check parameter #39 (Power limit), as well as parameters #45-49 (which dictate which kind of alarms are raised). I think parameter #49 can turn off voltage drop alarms. However, if you are getting genuine voltage drop alarms, maybe check with an electrician in case you have some wiring or load issues.
If the problem only occurs when you set Param #13 back to zero, this suggests that the problem is being caused by one of the parameters that is set by auto-calibration, which you must be overwriting again when you set P#13 back to zero.
After auto-calibration, the device will send configuration reports for all the parameters it changes. You can see these in the IDE Log. Make sure you update these values back into the settings screen, or leave the inputs empty so they don’t get over-written again. I think it’s probably going to be Parameter #1, #2, or #30.
Put the IDE Logging Level up to debug and pm me the whole sequence… I’ll take a look.
Are you going to upgrade this to the new ST color scheme?
Does this or any other DH support use of input S2? And in that case does it support double and triple click?