I see, thanks.
By the way, I would like to ask how can I change the main tile to display lux rather than the battery level?
I see, thanks.
Oh now that’s interesting. In the new app, I don’t see that. I just get “Checking status” instead of what you see. I may need to switch DTH’s and then back to get that to work right. I pretty much use the Classic app, so that never bothered me. To get that to change, the DTH’s metadata needs to recognize ocfDeviceType: “oic.r.sensor.illuminance”. That’s actually already documented within ST’s documentation, but it’s not working.
I thought you’d find this interesting regarding how the new app inconsistently displays this device (heck, almost any device for that matter):
I have 2 of these sensors, and here’s how they look on 2 different devices:
Same DTH, different results. There’s nothing I can do to fix that.
I used the Smartthings new app and could connect the light sensors easily, but they showed 0% battery and didn’t update automatically on the lux readings.
Then I installed the Smartthings Classic app, followed your advice (press sensor button + tap on Configure) and everything worked fine in both the new ST and older ST Classic apps.
Then I deleted the ST Classic app…and everything is still working fine in the new app.
So for those who are using the new ST app, the above might be a workaround to get these sensors working with the new app.
johncontantelo: thanks for your efforts in creating this awesome DTH!
No problem! I installed another one last night using the new app though, and it showed up ok. It could have been that your device didn’t get configured correctly, which wouldn’t surprise me. I may end up adding a setting you can get to via the new app that would force a configuration like the Classic app does. That’s something I should be able to work on this weekend.
All changes are noted in the code’s change log.
Most recent change (5-30-2020) was to add a preference that shows up for the new app that a user can toggle in either direction ONCE to force device configuration instead of having to use the Classic app.
NOTE: This is a workaround until the new app can address having a Configure tile.
I have looked everywhere in the documentation on how to prioritize any particular tile (i.e. illuminance vs. battery) but found nothing. I have tried tweaking the order of the code to see if it can be forced, but nothing has worked. It has to be the way the platform addresses the DH code, I cannot find out how a developer can prioritize which tile they want to be shown on the home page tiles. The only pattern I can find is that the first tile in the device details shows on the home page tile.
I’d love to figure out how this can become a developer choice, maybe I’m just a newbie coder and can’t figure it out.
Actually nobody can figure it out. I have many devices besides this sensor that show up differently across all my devices, just like what I showed in post #43 above for this sensor.
I’ve tried experimenting with all sorts of known vid variations, ocfResourceType variations (including ST documented one called oic.r.sensor.illuminance), as well as not even providing any vid or ofc value and letting just the capabilities determine the order. Nothing works as you’d expect in terms of tile arrangements.
Thanks John! Appreciate the great work on this DH. I’ve been looking for something like this for a long time. Maybe we’ll find a way or at least request a way to prioritize the tiles in the future
Thanks John. I used the updated code and the lux is showing correct!
Is there any reason why the checkInterval is set to 7320 sec? I assume these are seconds, right?
Can we change that for ie. every 10 minutes ?
Appreciate your effort;
I was playing with this sort of thing for a couple of weeks, a few months back. There does seem to have been some long overdue work done on the Developer Workspace since. It was clear that for other types of devices you could create a device profile in the Developer Workspace and it all presumably tied nicely together. There you could choose from a very limited range of device types (the equivalent of choosing the ocfDeviceType) and specify a unique Vendor ID to name the profile (as far as I can tell this the same as the Visualization Identifier). You chose which of your capabilities would appear as the dashboard tile status and action icon, and it all got wrapped up with the into a UI Manifest which you could replace if you wishes. The UI Manifest will look remarkably familiar if you have looked at the Presentation Resources via the VID Selector tool. You could also delve into Device Plugins.
I wanted to see if this could be applied to Groovy DTHs. I seemed to have some success with accessing this device profile using my organisation id as the ‘mnmn’ and using the ‘vid’ (I felt the ocfDeviceType was largely irrelevant with a vid selected) but it seemed could only get it to change the device details page and not the dashboard tile. I say ‘seemed’ because the app is nothing but unpredictable (or it is when you don’t know how it is supposed to work). Ultimately I decided to concede defeat and wait for more information.
It seems to me that all the basics exist, but they were created in a way that was focused on organisations creating published devices, and they are taking a bit of reworking to apply to the world of custom device handlers.
Great, glad to hear!
checkInterval is not used for how often LUX values are sent, but instead for “health check” events. Basically if the device doesn’t “check in” within that time frame it will be considered offline.
This device reports LUX immediately by default, and there have been attempts to configure it to some custom value, but the device isn’t honoring the commands to change it. I tried several methods with no success. I even found other HA platforms having the same issue.
Oh I see. Thanks for the tip. It is, what it is then!
How are you all making use of the lux meter?
I find that it keeps sending a continuous stream of lux values.
If i use smart lighting to fire rules based on > X lux values, it will simply keep firing the smart rules over a extended period of time. That wont be too good for the zigbee network health.
How can me make effective use of this lux meter with a configurable re-arm interval to only allow re-firing rules after N interval has passed.
I’m using the classic app.
I use these to turn on LED night lights (LED rings built into my smoke detectors) when LUX values are below 1 and between sunset and sunrise.
Correct. The device sends values as soon as they change. As for impact on your Zigbee mesh, that’s nothing. I have hundreds of Zigbee devices on my mesh that constantly report power, temp, humidity and many other things. Your Zigbee mesh is way more tolerant of chatty devices vs. Zwave.
This could be done with webCore, and/or some custom SMartApps, and maybe even SHM custom rules (Classic only).
I use it to switch on my living room lights and open the curtains, at sunset. I run both and new and old app in parallel.
In the new app’s automation, under the IF section, under TIME, there is an option to limit the running to only once a day.
I don’t see any option to fire the automation every N intervals though (except for N = once per day).
I use this DTH and the sensor to make my halo smoke detectors behave like nest smoke detectors with regards to the light. Simple and effective.
Thanks @orangebucket. I guess the platform announcement answers some of the questions and opens up a lot more about Xiaomi device support without Groovy. Will Samsung support these devices in their new development platform?
@johnconstantelo this device handler has worked perfectly, love it!
I just got the ones I ordered from AliExpress exactly 2 months ago. All of them paired perfectly with the DTH and at the moment are all reporting the same values (+/- 3 lux). I’ll be adding them into automations later this week. Thanks for the DTH!