Right. Red light is on only few seconds - but how to avoid it? It is annoying when room is dark or just if I want it to be discreet.
It is a bright little bugger You could try putting some tape or something on the inside of the cap. Or even on the outside of it. Shouldn’t impede the magnet at all.
Did you ever get this to work right? I am having the same problem as you it stays open and never closes.
Hi guys - I love this little sensor but had a problem with the battery going bad and not getting any advance warning…
I installed this for the first time 6 months ago. The door opens and closes I’d say about 10 times a day. So each open and close is two state changes. So let’s say 20 state changes * 180 days = 3,600 state changes before the battery went bad. I guess when I look at it that way, the battery seemed to do a pretty good job.
The bigger issue is that I got no warning the battery had worn out. Instead one day I noticed that the sensor was always saying “closed” even when open, and upon a closer look there was no red light at all. SmartThings said the battery was at 64%. But clearly the battery was drained to the point where it was no longer working at all. I measured the battery and it was at about 2.35 volts.
I replaced the battery, which is a bit nerve racking because the circuit board sits very tight in the tube (a bit of a design flaw IMO). So the downside is that having to replace this battery every 6 months is a bit of a pain.
A few questions please:
Is there any way to disable the red light? Perhaps that will help the battery last a little longer.
Why didn’t SmartThings warn me that the battery level was low? Perhaps because it was only at 64% according to the app. But apparently 64% is enough to make it no longer function. So it seems the app needs to warn me at say 70%. Is there a way to set that threshold?
Or perhaps the battery level exposed to the app was incorrect?
I’m using the default device type that SmartThings hub v2 assigns - not a custom device type. Perhaps if there is one, it is better in this regard?
Sorry to awaken this zombie thread after no activity for so long, but I don’t believe this issue was ever fixed. I have 4 of these sensors and none report battery levels. They just stay stuck at 100% until the battery is dead without warning. No amount of pair/unpair has ever helped and I’ve tried both the default ST and @jabbera 's DTH but it just stays at 100%. If it is a configuration issue and this device is sleepy then how do we force a config value to it?
I figured out the issue! The configuration of the sensor has a parameter that tells it to send battery status. Parameter 101 is set by default to 0 (disabled). I hacked @jabbera’s DTH to force it to send a 1 for that parameter when the sensor notifies the hub it is awake. By pressing the only button it has for 6 seconds (until it starts blinking and no longer) you esentially speed things up by forcing it to wake up. As soon as you do that you should see an updated battery reading in the live logging for the sensor!
This worked on all 4 of my Aeon recessed door sensors.
Now I need some help from a programmer to fix this correctly… volunteers?
AEON Recessed Door Sensor
Where did you change this value?
can you post a link to the code? a gist or github?
I documented it here:
Please be advised NOT to use the DTH as modified by me for day to day use as it will likely eat your batteries up way more quickly. My hack was to find the issue and test it. @Jabbera has suggested a viable solution in the same issue if anyone here is a Groovy programmer willing to give it a stab.
Since I did not get any bites for help I figured I’d give it a stab… What I opted to do, following @Jabbera’s suggestion, is to check whether a ‘state’ indicating the parameter was configured is set to true - if not then I configure the parameter, it it is then I don’t. I do this just before the DTH reads the battery level. I did not do it upon join as I believe that section gets skipped if the DTH is not chosen by default. In order to help ST pick this DTH (once installed) by default I edited the fingerprint as well (I added the new one used in v2 hubs).
PLEASE NOTE: I am NOT a programmer so this code may be horribly hacked together… or it may be just fine - I do not know. If any of you want to help, I’d be really happy. I got tired of those sensors just dying on me so I want to fix this for good!
Below is my modified version (WORK IN PROGRESS!! NOT TESTED YET) of @Jabbera’s DTH:
Thanks, I’m going to try this out as I’m having that same issue. No reporting.
@Jrfarrar - Please let me know how it goes. I have one that is reporting 47% and 3 more that are still at 100% but they do have new 1 month old batteries… I don’t know whether there is an issue with the modified DTH or the batteries just last a long time. I guess I could swap batteries and see what happens to the percentage. My initial fix actually worked on all of them but I cleaned up the code a bit so I may have broken it again… Regardless, the fix is setting the appropriate parameter to send the battery value so if someone better at programming than I wants to take a stab at it, they can look at what I did for the solution.
I changed the DTH yesterday. I was getting “battery is 100%” notifications prior. But assuming that was wrong based on the setting you described? I’m still seeing 100% today.
How long ago did you install the battery? I may have to test my older code to see if any of the ones reporting 100% start reporting lower levels just by changing the DTH which would indicate that cleaning up the code I broke it.
Have you ever tried Zwave Tweaker? It helps see the parameters and it can also force them so you could use the default DTH and just force the parameter to enable the battery reporting. I’ll check my sensors reporting 100% to see what the parameter is set at and will report back.
I installed it 6 months ago. I got an installed zwave tweaker…going to have a look to see what the setting is. But not until I can put hands on it to get it to update.
Yeah, I have the same issue… Later tonight when I get home I will trigger it to wake up and query the setting. If not active then I broke the code and will figure out how to make it work again as I have a copy of my previous hack that forced the setting over and over (not ideal).
I guess I broke the code… the parameter is set to zero so it is not reporting the battery value. I’ll try to fix it.
Parameter #101: [id:101, scaledConfigurationValue:0, size:1]
Parameter #111: [id:111, scaledConfigurationValue:86640, size:4]
Parameter #121: [id:121, scaledConfigurationValue:256, size:4]
I made a minor change to the code and I then disabled the “do it once” condition…
if (state.batteryReportingEnabled != true)
To force it to keep enabling the parameter just change ‘true’ to ‘false’ for a few waking up cycles (pressing the only button for just over 6 seconds will wake it up) then set it back to ‘true’. I need to change that code so there is a better way to ensure the parameter is set properly but for now this should help you.
Also, in case it matters, please ensure your sensor paired in secure mode. Check the Raw Description of your device… it should look like this:
zw:Ss type:0701 mfr:0086 prod:0102 model:0059 ver:1.13 zwv:3.92 lib:03 cc:5E,86,72,98 ccOut:5A,82 sec:30,80,84,70,85,59,71,7A,73 role:06 ff:8C00 ui:8C00
When you awake the device, you should see the battery reading in the log right after it says it is awake.
DTH is here:
I have 5 Aeon recessed sensors and from time to time some report open in the middle of the night when there is no activity with the door. I have wired zwave wall switches all near the door sensors. Currently I just open and close the door and the sensor properly reports a closed condition. I saw comments from others that are having and open/close problems with other senors have started to add “reset the open/close status” on wakeup. If this is possible on Aeon sensors could you add this capability in the future? It would clear up the the false alarms I get possibly as well as the problems when I set my alarm Smartthings tells me after I have left that a door I know is closed is reporting open. Thanks for consideration.
Can these be made to work with STSamCon? they tend to act as if disconnected for STSC whereas Classic sees them fine. Same for the Zwave Plus default handler for them.