The logger functionality allows critical error and warning messages to be saved to the device’s logMessage attribute (not that there should be many ). This offers a way to store and review historical messages without having to keep the IDE Live Logging screen open.
Ah, good call! I propose to fix this by checking if P13 is > 0 (I think you meant P13, not P14 above), if it is, then it’ll nullify any target values of P1 and P2 (and also P13 after it’s sent). This will allow the device to sync. It’ll log a warning if the user has set values for P1 and P2 at the same time as forcing auto-calibration.
I don’t think there are any other read-write parameters that are changed during calibration. Can you confirm that it is just P1, P2, and presumably P13, that prevent syncing?
For the record, this is a great example of where it would be useful to be able to update the actual input values of preferences on the settings page. Unfortunately, due to ‘security restrictions’ this is not something that is currently possible on the SmartThings platform.
It’s absolutely crazy that SmartThings STILL haven’t fixed the issue of processing defaultValues on Android. Simply saying not to use defaultValue in the docs isn’t that helpful when the feature works and is very useful on iPhones.
In this version I have made it easier for Android users to comment out the defaultValue statements by isolating them on their own lines. Maybe, just maybe, I will finally have to capitulate and comment them out by default.
I just wish to thank you for this. I got this dimmer just over a week ago and have been having issues with it. I can confirm that this works extremely well.
I would like to mention, that after applying the device handler initially, it takes a while before the dimmer responds correctly - I set it to turn off and it would dim down to 1% and stay on, after a while this seems to subside. After ~5 minutes it started responding correctly and in a timely fashion.
Also worth mentioning, I am an android user, so I took off all of the ‘required’ and ‘defaultValue’ properties.
Sounds like you might need to be using the Fibaro Bypass module? Or, perhaps you have set relatively large values for the Dimming Step Time parameters #6 and #8, so it takes a really long time to transition between levels?
Thanks- my explanation was very poorly described. I have modified it so it is more concise. This issue was only temporary. As for the bypass module, I am extremely that in my house (in the UK) the ring main for the lights is in the switch back box, rather than up in the ceiling- it means that I can set it up using 3 wire mode.
By 3-wire mode, I assume you mean you have the dimmer wired to the neutral as well as live. Note, this eliminates one reason to use the bypass module, but some people may find they still need a bypass module if they have a small number of bulbs on the circuit (as even in 3-wire mode, the dimmer leaks a small amount of current to the load, meaning some bulbs flicker when the dimmer is off).
E.g. I have all my dimmers connected to Live and Neutral in the ceiling, but I still need to use bypass modules on circuits with only a handful of LEDs.
That’s fantastic that you’ve done this for us android users! As your device handler is great and not having access to any iOS devices it was extremely difficult to set up. I had the situation where because of some default values stuck in the ide on Android i couldnt even edit the device handler in the IDE, I get a weird server error from smartthings.
Also it meant that you can’t leave any values blank as the page won’t save, so instead of using the auto calibrated options you had to guess the values like start brightness and end max brightness. I managed to finally get around this by setting the value to perform an auto calibration everytime I saved the settings which overwrote the settings.
I raised another case with the Dev team and heard nothing back at all about the issue with default values on android.
I would like to say that once I was able to get the default value code removed with the previous handler it has worked flawlessly. I’ll test this new handler as soon as I can with solely android and let you know how I get on, but I assume there won’t be an issue
I have thought about it, but I am going to wait until the Android/iPhone differences are ironed out, and also for some of the missing capabilities to be standardised (i.e. it currently has non-standard capabilities for “Fault” and “Scene Controller”, plus another which I am thinking of adding is “Child Protection”).
I would really like someone from SmartThings to explain to me why they have a personal vendetta against android users. They must see posts here every week of new users complaining about “spinning wheels”, “you are not authorized” and ST app meltdowns, surely.
I updated one of dimmers to this new exciting DH, pressed edit then I get a blank screen and the whole ST app crashes and starts again from the main screen. I did this 3 times just to be sure. I went into the IDE and manually set the default parameters, from another dimmer, it’s still not working, there were some new parameters left blank, because I don’t know what to put in there. So I’ve got back to a previous working DH. Maybe it’s better to put all that default parameters back in, and let everyone with an Android just fend for themselves within the IDE.
Until SmartThings makes the platform equal for both Android and iPhone users.