Same problem. As of the last few days very erratic response. Mostly my CREE bulbs not working.
My Hub is stuck at firmware 000.016.00009
How do I force the update?
Consider yourself lucky!
What update exactly? You are on the latest version.
1 Like
Didnāt notice the number lol.
Is that because 16.9 sucks or are you being sarcastic and 16.0000.9 is indeed 16.9?
Juan Felsmann
both of those statements. Allot of sensor issues dropping with this firmware update and also a battery reporting bug is present. It will show 67% on 1st party devices when in fact its 0% I have only seen it so far on the muilti purpose sensorsā¦
Ok, that explains why my thermostat stopped working
Uff!
Soā¦the random motion sensor eventsā¦like at 3 AMā¦and triggering the security rulesā¦is not a haunting event? What a reliefā¦ 
I never had issues until this upgrade. There are these random motion sensor event from all of my motion sensors throughout the day. Will tweaking the sensitivity help (if possible)?
Otherwise, I need to disable a bunch of stuff. Tired of being woken up in the middle of the night for no good reason.
you can disable OTA updates and that might stop the motion sensor problem.
I hate to argue, especially since Iām fairly new to the communityā¦ but measuring the voltage while the battery is under load doesnāt make any sense. The nature of these devices is that they will have pulsed loads with highly variable current. Also the battery internal resistance for a coin cell can range anywhere from 10-40ohms.
If you have 240mAh coin cell than lasts nominally 12 months it means you are drawing on average about 27uA of current. A fresh coin cell with 40 ohms IR will give a voltage reading of about 1mV less than one with 10 ohms IR and a constant current of 27uA. Thatās not much, but the reality is much worse due to pulsed loads. Letās say all of your power is spent sending Zigbee transmissions. Iām going to guess about 20bytes of data every second. At the fastest rate zigbee supports (250Kb/s) you can send that in about 6.4mS. If the average current over a year is 27uA and the TX time is the only load, the devices will draw 4.2mA during transmissions. The difference between a voltage reading while under 4.2mA load with a 10 ohm IR battery and a 40 ohm IR battery is 120mVā¦ thatās a significant difference on the voltage versus capacity curve.
I walked through that exercise with the battery IR because it demonstrates how tolerance beyond the designers control can impact the battery voltage reading. The reality is that batteries are not all created equal. You might be able to learn, or take a guess at the battery resistance based on an initial reading. However the battery IR changes over its life cycle and the real issue turns out to be creating a constant load. Above I surmised that Zigbee transmissions are the primary load. In reality the device will have a number of sensors adding load at various times; Zigbee, 3-axis accelerometer, reed switch, etc. To get a reliable/repeatable load that can be used to measure battery consumption, while not impossible, will be extremely tricky. The hardware may have no way of controlling the load for a given peripheral during the instant the voltage is being read.
A better approach would be to model the senors average power usage over time and use the un-loaded battery voltage as a ācorrectionā. Your designers can measure (in the lab) the average load per second for a given sensor, like the accelerometer, and adjust or subtract that value off the expected capacity of battery over time. This is tricky because you need to make a reasonable approximation of power usage for each sensor (in each mode it is used) and the code needs to keep track of how much time is spent in each mode. A reasonable approximation can be done by looking through the datasheets of each sensor. Then, as time passes, the code can model the battery level by subtracting the expected amount of usage from 100% total and slowly slewing toward the un-loaded battery reading in order to correct for tolerance, battery un-plug/re-plug, etc.
Note also: even if you had a coulomb counter in the hardware it wouldnāt help. Code that uses a Coulomb counter works by learning the total capacity of the battery over one or multiple charge cycles. Since you are using primary cells, you will never actually know the full capacity of a fresh battery. Fortunately the voltage versus capacity curves for lithium primaries are pretty reliable even though there isnāt a whole lot of granularity for the first 80% of battery life. If you moved to a model like I outlined above I expect you could get to within 1% usage reporting with fairly high reliability.
7 Likes
Wow!
ST or Centralite needs to do this!
1 Like
That was amazing. I need a cigarette now.
2 Likes
I have to chime in here. I would love to work for Smart things and fix the issues, if they pay me enough.
-
You guys had lengthy times of stability before this update? In 2 years I have never had more than 72 hours of stability, average is about 3 - 12 hours before an unexpected event occurs. Yes Iāve documented 1,000ās of unexpected behavior points for my smart things setup. And thatās just the stuff I witnessed, other random events when Iām not around go undocumented.
-
My hub also has the output āindicator status is when onā even though itās āwhen offā. The local device handler they pushed was updated. They likely didnāt comment out that debug code before bundling it into the firmware. Iām also not sure why they didnāt automatically trigger the āupdatedā subroutine when doing this to sync the local/cloud/device data. If you go into each device and manually save, it will trigger the āupdatedā routine and possibly resolve it for you. You should also notice an update interval field gets added to the device in the IDE.
-
I hope version 3 has bluetooth support, like we paid for in version 2. I have a dozen BT devices, hacked together with Apple TV HomeKit, iPhones and Homebridge software on my iMac. Which is actually way more reliable than Smart things I must point out. Iāll be purchasing a z-wave and zigbee dongle for home bridge, and may leave smart things in the trash.
-
For anyone looking for Apple HomeKit and Siri integration for Smart Things, the open source Homebridge with extension has been fairly reliable for me. Also to note, Apple HomeKit will support the video cameraās directly from home bridge IP camera extension. Homebridge can also use the cameraās motion detection api as a motion detector.
-
Tiered battery reporting is useless. Iāve had Aeon sensors die at 80%, and some live for weeks at 0%. Smartthings multisensors and motion sensors have the same issues. The problem with ST motion is that when power dips to 18%, it will send āmotion activeā events, then later send battery = 75%, repeatedly. Oh and the batteries supplied in the box are ancient. Every new ST branded device Iāve bought came with 3 year old batteries, when tested was already half the life gone.
-
I have noticed (using an Airspy, SDRSharp and Wireshark) that Z-wave beaming would kill batteries quick. Previous firmware would trigger this a lot. Some GE/Jasco switches would get stuck beaming (at Smart Things request) and interrupt z-wave reports from other devices.
-
I have noticed with this firmware the Z-wave radio crashes or hangs a lot more often. (confirmed with Airspy + SDRSharp) When the Z-wave radio of Smart things crashes, you will get a zwave restart event in Hub events. For hangs there will be no log event, it eventually recovers after a minute or so. During the crash or freeze, Smart things is deaf and mute to all events or triggers. Not all radio silence is a hang, some times itās waiting for an unresponsive device, then does a beam or discover.
-
I know ST support doesnāt want to hear this, but on channel 19 my devices dropped out, and lost battery life fast. On channel 20 battery life is way better, and the fake motion events have 90% ceased. Zigbee doesnāt appear to be affected by WiFi interference, as much as general microwave propagation issues. 2.4ghz is about a 4" wave. Changing a fraction of an inch in wave length can mean several decibels of reception indoors. Phillips Hue allows channel changes. Although support says they donāt have a way to change channels remotely. Magically after that āit canāt be doneā response from support, my hub switched from channel 19 to channel 20. The fake motion events were caused by higher draw on the sensor battery to below threshold and then it powering back up again.
-
I have told everyone in my extended family, friends, potential customers at Sears, Best Buy and Target to not purchase Smart Things unless you are a developer and tinkerer. Itās just not ready for prime time. The reliability as a security system is laughable.
2 Likes
I hate to argue, especially since Iām fairly new to the communityā¦ but measuring the voltage while the battery is under load doesnāt make any sense.
First off, your entire post is spot on and clearly worded. To accurately measure remaining capacity of coin cell batteries, which have a very flat region of discharge through the 10%-90% region of use, a usage-based/time-based component is required. We recognize that using only the voltage is insufficient for making an accurate estimation and are looking to improve.
The measuring battery voltage under load is specifically to address issues where devices will improperly report motion when the voltage drops below a certain point - a point that can be hit when the battery is under load. We know that improper motion events are extremely disruptive and want to minimize these as much as possible.
3 Likes
Interesting, this implies that the voltage dip isnāt enough to reset the microcontroller but is enough to drop the reference voltage? With a 3.0V nominal coin cell I would hope that the reference voltage for the ADC is in the 1.0V range meaning it would take a very significant dip get a bad reading. Software guys bainā¦ youāre stuck with the hardware you have.
Sounds like youāre stuck reading the battery voltage in order to validate the motion reading. Which is of course problematic for all the reasons mentioned above. Any chance the microcontroller has a brownout interrupt? Often micros can be programmed to brownout at different voltage set points. Iāve dealt with similar issues in the past by catching the brownout interrupt, setting a lock on the ADC readings, and waiting for the condition to disappear.
Why do you suppose one ST multiās would work with a battery down to tenths of a volt but some die at 2-2.8v? I canāt imagine thereād be that great a manufacturing variance. I think the lowest reading I got on a working battery was .06vā¦it had just died. Maybe shorted internal at that point and dropped that significantly? (not an EEā¦)
I see this frequently, some days it occurs many times. Itās predicatable with a z-wave device that has ghosted or anytime I use the repair option. I canāt believe this is considered normal behavior.
my orsam white show totaly diff versions
model: LIGHTIFY A19 Tunable White
application: 03
manufacturer: OSRAM
endpointId: 03
Raw Description 03 0104 0102 00 09 0000 0003 0004 0005 0006 0008 0300 0B04 FC0F 01 0019
Firmware
Current Version: 0x01020205
Target Version: 0x01020205
Last Updated: N/A
I have a half dozen that die there, a few that die around 2v, and a couple that go WAY downā¦unless the batteries are die spectacularly in those couple. Itās so random itās just ridiculousā¦
All my ST motion sensors die in the 2.9x range.