hahaha, I am considering indeed…
This would be something I would love to see.
I made it almost exactly one year with mine. Lottery ticket.
Yes, I spent 1 year home. My wife with her arrival in her bag at office for let’s say 9 to 10hs a day, mine home. The difference of behavior was very very visible. So I am not sure the ping is no dynamic so that when the device is in the range of the hub, it might decrease the numbers of pings till the timeout we discussed the other day in another post.
So is there a tool or something to measure strength of mesh or a tool to see what all connected devices are routing through within the mesh at any given time? That would be something that I think everyone would love to have.
As far as your open/close sensors, to maximize battery life you should set it so that the “normal” (non-reporting) position is whatever position the sensor is usually in. If you have a sensor intended for normally closed and you leave that door open all the time, then, yes, it’s going to be reporting all day long and that’s going to run the battery life down. If it checks to see if it needs to report every three minutes and you leave it open for 10 hours, it’s going to report 200 times a day or more, which will not be the engineered specifications.
With regard to the strength of the mesh, unfortunately smartthings does not give us any tools for this. you can add an additional device and then use its tools But that’s a lot more work and cost.
For zwave, it’s the same thing: you have to add an additional device and then use its mapping tools
It might, but it doesn’t, Unless something has changed in the last year. I spent literally 4 months working with smartthings support trying to solve an arrival sensor problem and was assured many times, including by senior engineering staff, that the behavior of the arrival sensor itself did not change depending on whether it was within range of the hub or not. But maybe it’s different now.
That’s interesting, but there is something I foresee here: the mesh is dynamic so if you audit it this week, nothing prevents the mesh to adjust in a different way few hours/days later and stay in this state for a while before another event causes a change. Unlike fixed IP assignment, I don’t understand there is a way to lock the mesh in a given patern. And if so, that would anyway be a problem when a mesh adjustment is needed du to a long term perturbation.
That’s not quite how zigbee works. Each zigbee end device chooses a parent based on a number of factors including signal strength and then it will always try that parent first even if other things have changed in the mesh. But the device will also identify a couple of alternate routes and then use those if the parent is not available. So the pattern is stable enough for minor changes, but can readjust over time if a long-term change is needed. But the main thing you want to identify is what parent each end device has chosen, that’s typically what tells you if a heal is necessary to update the routes.
A binary Sensor should only send a report when it’s State changes, regardless of the “normal” state; unless it also supports Polling and/or minimum reporting (usually battery level, temperature…).
I have a Contact Sensor (Centralite ZigBee) on a propped open door, and it isn’t eating batteries.
I have a Z-Wave sensor on a door and the LED flashes once when the door opens and once when it closes. I presume that is 2 and only 2 messages, regardless of how long the door stays open or closed.
It varies from model to model. I know you’re familiar with the issues with people who have tried to convert flood sensors to Monitor when something is dry and find that it runs through the batteries for some models and works fine with others.
Some devices report a state change, some report on a specific state. You make a good point that this can vary, so it’s something to look into for each device.
This is why I would, if doing a new build or major renovation, seek some method of hardwiring as many sensors as possible. The upfront cost is more than offset by the battery expenditure, let alone having to constantly monitor/change those batteries.
Unfortunately, that is not my scenario today. So battery hell it is. lol
All my SmartThings Motion sensor batteries CR2450 show low in weeks. I think it is the DTH provided by ST. As my batteries still check good with my tester. ST has to work out a better method of checking battery health, as their formulae is way off.
A perfect example of this is a project I will be resurrecting from last year which repurposes a Utilitech leak sensor as a water sensor for a Christmas tree. To identify when the water level in the tree stand gets dangerously low I invert the readings from the sensor, making wet the normal state and dry the alert state. The battery life is noticeably reduced on the Utilitech sensor when left continuously in the wet state, although t still managed to outlast the holidays.
@SteveWhite What does invert state mean? I have the same device and use it for the same reason.
For notifications I created a custom smart app, but this should not affect the device?
What is a normal state versus an alert state? How do you switch the states?
@tgauchat I would think it works like you state, send notification when state changes.
Also if # of flashy lights are accurate in my experience some devices when placed in iffy network range ( my garage) may need to send 2 messages for the smart things hub to get message.
Yes but the explanation from ST when I checked with them last year was: but you test it without a load attached to the battery so you are reading an optimistic voltage.
however my observation is that in the recent months, I got longer duration for the motions sensors than last year.
Bedroom is a room being used every day in term of sensing
Playroom is a room barely used 2 or 4 times a week.
Entry door was a sensor under our outside porch. I stopped using this sensor after the many false motion detections. (PIR are not really suitable for outside usage)
For all of these charts, when the level goes back up (not always 100%!!!), it means the battery was changed because the sensor wasn’t responding anymore (no led when inserting the old battery, no reset possible).
great battery record. It would be a little more descriptive to include battery type and sensor make and model.
Your general lifetime with coincells is similar to mine, poor (anything less than 6 months is a hassle). I try to apply devices without coincells. Arrival/presence sensors were dead within 3 months, almost useless until hardwired.
What are you using to log and chart?
The battery type influence is not really making a big difference versus the frequent changes. I tried both genuine Panasonic and other brands, that doesn’t drive to significant difference in my case.
Regarding the sensors,
For the data collection, I use a homemade MySQL dump. I published my smartapp and associated php script/sql information on https://github.com/philippeportesppo/Dump_Temperature_Battery_Level_SmartThings
You can have a try. I record every 3 hours the state of sensors with temperature capabilities as originally, this was for a temperature recording purpose that I developed the scripts but I then added the battery monitoring later when I started having issues with the sensors to collect facts. You can add other capabilities if you want to monitor other type of devices (water leaking, etc).
In my opinion the way ST gauges battery health is wrong. It was better two years ago. Smae model sensor the battery lasted months not a month.
Staff have acknowledged in the forum that one of the recent zigbee updates fried battery reporting. They are aware of the issue and are expecting to correct it in the future, but no specific timeline.