@ArstenA I don’t know if you can see this on Android, but the text size for the Battery in IOS is way to big. Here is a screen shot.
[OBSOLETE] Original & Aqara Xiaomi Zigbee Sensors (contact, temp, motion, button, outlet, leak, etc)
When using the bspranger device handler I have a button that shows as being pressed in the Smartthings app but won’t turn on a light for example. However if I switch the device handler done by a4refillpad the light will turn on. Is there some adjustment I need to make? Thanks
Are you using an iPhone? If yes he knows about it. I also switched DTH until Brian fixes it.
No I,m using Android.
Which device are you having issues with?
If it is a button, I added some configuration parameters. Please check those.
Yes it is a button. I’ll check the configuration. Thanks
I changed in the configuration both to Toggle and then Momentary but it still didn’t work. The button presses are registering in the app but it just won’t control a device.
Just read this.
I hadn’t configured for momentary or toggle and the button works fine.
When I select any of the 2 it stops working.
Deselect so nothing is selected and it works again.
I also tried not selecting either but it still won’t work
Hi,
Big thanks to everybody who contributed to these DHs over the years…
I’ve been using the BSpranger DHs since start of the year (before this i’d used catchall and A4refill, which also worked pretty well, but i thought clear slate for new year)…
bspranger : Xiaomi Aqara Door/Window Sensor
bspranger : Xiaomi Aqara Temperature Humidity Sensor
No pairing issues or dropouts to report since start of the year. I guess i have about 12 of these cumulatively with another 5 on the way and 3 of the Xiaomi Aqara Button on the way too.
Reason i’ve been using these, i guess like everybody here is the affordability/disposablility of these. I just saw over on the main page that Samsung are giving us a major update in 2018 Q1 (SmartThings app will receive a major overhaul in Q1 2018)
At SDC, SmartThings made it very clear that “SmartApps” (as we know them) are being deprecated. I didn’t catch exactly what will happen to DTHs, but since they are currently also written in Groovy like current SmartApps, you can bet those will also be deprecated.
SmartThings also insisted (a bit too emphatically and often…) that existing SmartApps will continue to run indefinitely. This is one case where I would say it is safe to “hold your breath”… they’ll be gone before you turn blue.
has anybody here tested the new platform (https://smartthings.developer.samsung.com/) / can confirm if these sensors are still going to be viable?
1 Like
You can’t create code for z-wave and zigbee device on the new platform yet,
Ok thanks, just wait and see for now then.
Felt like i was stuck in a loop going round the new sites not finding anything so posted here… i guess its normal i can’t see an option thats not there… makes sense.
@ArstenA Something happened with the Original Temp / Humidity battery reporting. It went from 100% to 0% over night. I had done the Github update yesterday.
UPDATE: Went back to the last version of the Temperature / Humidity Sensor DTH and battery went back to reporting. I believe you broke it with the last update. At least on IOS.
@ArstenA my two aqara motion sensors are showing -450% on battery status… It’s that normal on first battery report?
I’ve been reading through ST community threads and doing some research looking through the official ZigBee sensor DHs in the SmartThingsPublic repository on GitHub.
First off, most of the Xiaomi device DHs include IAS Zone enrollment commands. IAS stands for Intruder Alarm Systems, and the types of ZigBee devices that can have IAS support include motion sensors, contact switches, fire sensors, water sensors, gas sensors, personal emergency devices, vibration movement sensors, and panic button devices.
When connected to a CIE (Control and Indicating Equipment) coordinator (i.e., hub, like the ST hub), devices that support IAS can provide special reporting on two different alarm types, tampering status, low-battery status, test mode, and other aspects of the device.
IAS Zone support requires ZigBee Cluster ID 0x0500 as the interface. The following Xiaomi devices do not support Cluster 0x0500 which means they are not IAS devices:
“Original” Xiaomi series: Button, Door/Window Sensor, Motion Detector, Temperature/Humidity Sensor
Aqara series: Button, Door/Window Sensor, Leak Sensor*, Motion Detector, Temperature/Humidity Sensor
*Note: The Aqara Leak sensor does produce “zone status” messages, so some more testing is needed to determine if it actually supports IAS Zone reports even though it does not report Cluster 0x0500 as available.
So, all DH code relating to IAS Zone enrollment is unnecessary and can be removed.
Second, I notice that some of the Xiaomi device DHs use “direct” ZigBee commands in their configure and refresh functions, such as zcl global write, zcl global send-me-a-report, zdo bind, etc. These commands are not something that can just be copied and pasted from other DHs, because all of the parameters are device specific.
If you look at the most recently updated official SmartThings Device Handlers, all of those zcl / zdo commands have been replaced with much simpler and more standardized ZigBee functions that have been added to the SmartThings groovy library.
For example, here’s the refresh & configure code section from the SmartSense Open/Close sensor DH:
Code (click triangle to view)
/**
* PING is used by Device-Watch in attempt to reach the Device
* */
def ping() {
return zigbee.readAttribute(0x001, 0x0020) // Read the Battery Level
}
def refresh() {
log.debug "Refreshing Temperature and Battery"
def refreshCmds = zigbee.readAttribute(zigbee.TEMPERATURE_MEASUREMENT_CLUSTER, 0x0000) +
zigbee.readAttribute(zigbee.POWER_CONFIGURATION_CLUSTER, 0x0020)
return refreshCmds + zigbee.enrollResponse() //
}
def configure() {
// Device-Watch allows 2 check-in misses from device + ping (plus 1 min lag time)
// enrolls with default periodic reporting until newer 5 min interval is confirmed
sendEvent(name: "checkInterval", value: 2 * 60 * 60 + 1 * 60, displayed: false, data: [protocol: "zigbee", hubHardwareId: device.hub.hardwareID])
log.debug "Configuring Reporting, IAS CIE, and Bindings."
// temperature minReportTime 30 seconds, maxReportTime 5 min. Reporting interval if no activity
// battery minReport 30 seconds, maxReportTime 6 hrs by default
return refresh() + zigbee.batteryConfig() + zigbee.temperatureConfig(30, 300) // send refresh cmds as part of config
}
It is still not a good idea to just copy and paste that code into any of the Xiaomi DHs, especially because the Xiaomi devices use a _non-standard method of battery reportin_g, but I think it’s worth a look at re-working the refresh and configure code, especially since it relates to reporting and device check-in time intervals. Considering a number of users have had issues with sensors dropping their connection, and also with reporting intervals, it’s possible that improvements to the refresh and configure code may help.
8 Likes
In a post by SmartThings Software Engineer @jody.albritton on that same thread you linked to:
Custom smartapps and devices are not going away. Check out the new developer portal (very beta)
I’ve poked around the new developer website and looked at documentation. It appears that they are moving away from runtime-compiled groovy on ST’s servers as the specific SmartApp / Device Handler platform, and over to Amazon Web Services (AWS) Lambda functions / web services applications with a RESTful API interface.
Officially supported languages on AWS Lambda are Node.js, Python, Java and C# through .NET Core. I am not a programmer by any stretch of the imagination, but since Groovy is a language for the Java platform and compiled into Java Virtual Machine bytecode, I’d have to guess that moving current SmartApps and Device Handlers over will be a matter of porting with minor modifications rather than complete re-writes. It really depends on how much of the currently available APIs and functions are moved over to the new platform. Also, SmartThings’ Groovy code runs in a restricted sandboxed environment, and I haven’t read anything in the new developer documentation that explains whether that will be the case with code running on AWS Lambda.
One thing for sure is that cost structuring will change. AWS Lambda does have a free tier usage level, but when you go past limits, you are charged. As to who gets charged, it depends on whether the code is hosted on SmartThings / Samsung’s AWS-L account, the SmartApp / Device developer’s account, or the end-user’s account (assuming the new ST infrastructure will allow for end-user’s to host custom code on AWS-L).
Also, I read things like this page about Rate Limits on the new developer documentation site, and I really want someone to explain how this will affect me as an end-user. Will I have to worry about how many devices I can have connected to my hub or interfacing with a SmartApp?
3 Likes
Don’t they know the mercury bulb is at the bottom of the thermometer?
I’m not a developer, so I don’t know the nuts and bolts, but I’ve been using the Aqara button device handler from therkilt/SmartThingsPublic (master). It seems to be working well. Single press works. No long press.
Just thought I’d post to see if it helps to take a peek at the code.
It seems my last two batteries are draining rather quickly, though. I’m not sure if it’s the actual batteries or the reporting from the device handler.
I looked at the code, and yes, the author tried to get push and hold (long press) to work, and wasn’t able to, so that functionality was removed. Also, battery reporting was removed because it wasn’t working. In the code, it would always display as 100%.
I don’t see anything in the code that sets up reporting time intervals. So if your batteries are draining quickly, I’d have to assume it’s based on the button’s default reporting and how often you use it.
I looked at the DH and it doesn’t make much sense to me how it is reporting presses.
I see it does use a switch type vs a button type. Maybe I should try that…