Time based events failing?

My time based routines haven’t worked in 2 days…

1 Like

My time based (clock time AND sunset based) routines have been consistently failing for weeks. Lights don’t turn on at sunset, lights don’t turn off at clock time. Sweeper backups don’t turn off the lights in the house mid morning, etc.

Seriously – basically I have a remote control where I turn lights on at night using my cell phone, and off in the morning. There are no reliable time based events working and have not worked for several weeks.

My wife goes around in the morning and turns off the lights manually by pressing the button on the modules/ switches… She’s not amused they burn all night when they are supposed to go off. And if she didn’t turn it off manually, they burn all day…

Face it, Smartthings is losing the competition with electromechanical “clock” timers in her eyes.

2 Likes

There’s always, hope, my friend, … there’s always hope.

In my personal opinion, SmartThings has a much greater chance of stabilizing the product / platform than they do of sustaining the business. There’s no ongoing revenue and tremendous marketing and consumer education challenges. The “smart home / consumer IoT” market will either fizzle (enter a long trough), or become highly competitive (SmartThings has yet to face Nest, Apple, etc., head-on).

1 Like

Which would be fine, except that it doesn’t advertise itself that way.

1 Like

It is pretty outrageous.

I am sure they convince themselves these are “minor problems” that they will iron out “soon”.

Business Intelligence believes (and I agree with their conclusion) that the smart home market is stuck in the ‘chasm’ of the technology adoption curve, in which it is struggling to surpass the early-adopter phase and move to the mass-market phase of adoption.

The key point is this:

The largest barrier is technological fragmentation within the connected home ecosystem. Currently, there are many networks, standards, and devices being used to connect the smart home, creating interoperability problems and making it confusing for the consumer to set up and control multiple devices. Until interoperability is solved, consumers will have difficulty choosing smart home devices and systems.

SmartThings (and others) try to solve this problem by claiming to support all protocols - Zigbee, Z-Wave, BLE, TCP/IP and what not. This is clearly not working. It just creates more confusion for a non-technical customer, which leads to frustration and dissatisfaction.

There’s like 90% overlap in functionality between Zigbee and Z-Wave. Why would an average Joe Consumer care for one over the other is beyond me. The sad thing is, in their quest to support all protocols, SmartThings (and others) have to settle for a bare minimum feature set, effectively offering customers castrated versions of all “supported” protocols.

1 Like

We’re drifting off of the “Time Based Events” Topic, but I think that multi-protocol support is a valuable feature – except that it really has to be “all or one”. The lack of BLE (and Homekit, for that matter) is making a larger and larger subset of devices incompatible with SmartThings.

A key advantage of SmartThings (now copied by some other vendors) is compatibility with lots of third-party hardware and services; some more successfully integrated than others. Because the market is still small, this isn’t like iPhone vs. Android which both have large app stores with, dunno, probably 90% overlap in the most demanded Apps? Heck, some folks are still willing to use Windows Mobile with its tiny store.

As I see new connected / smart devices hit the market (Kickstarter, etc.), I’m always pleased to see Z-Wave or ZigBee, and not happy with those that are BLE, 6wLoPAN, Thread … or even WiFi. The two Z’s integrate well, especially if the Community pitches in for a custom DTH and if protocol specific functions aren’t required (direct association?). Bluetooth BLE will be a quite a feature jump.

In summary; I have far fewer concerns about SmartThings’s compatibility than stability / reliability. Their model for extensibility may not be optimal, but it seems to be pretty resilient except for some notable edge cases (Lutron? Nest? proprietary ZigBee?).

SmartThings’s official stance on the scheduler problems is that it is not a minor problem, but that they are optimistic about the solution paths they are exploring and testing. I take that as meaning there has been tremendous progress, but the problem is so complex that it is not possible to implement solutions incrementally (though there may be incremental band-aids).

Definitely hard to believe this hasn’t been addressed in the 1.25+ years that it is has been known to exist. So either the problem was ignored / deferred, assumed it would be handled by Hub V2, or, not just hard, but really, really, really hard. Or trapped from resolution in the bureaucracy of a dysfunctional organization. We’ve seen plenty of evidence of the latter when there have been problems that are easy to solve, and yet solutions never appeared, appeared with flaws, or repeatedly deferred (e.g., shake for Tile labels, if anyone remembers that from the first 2 years of ST App).

It only looks good on paper. In reality, SmartThings’ Z-Wave implementation sucks. Other “multiprotocol” hubs (Wink, Iris, Staples) suck as much, to be fair. Their TCP/IP support sucks even more. I don’t know about their Zigbee implementation, as I try to stay as far away from it as I can, but I suspect it’s mediocre at best. And something tells me when (and if) they enable BLE, it will be pretty lousy too. So what’s the point? Yes, there’s lots of stuff to play with for the early adopters, but this monster has no chance of crossing the “chasm”.

Well, I am happy to report that all my time-based events have been running flawlessly for the last 2 weeks. Without fail, lights come on and off when they should, phases/modes change as scheduled, sunset/rise is dead on each day and//// Well I can go on and on… Oh… Did I mention I gave up on ST scheduling and have moved all time based routines to Eventghost? Didnt? Sorry, didnt want to get your hopes up that ST was actually improving. :smiling_imp:

2 Likes

All of my time based events are also working. I’ve also got fully local processing working, my data is not being sent out to a cloud at all. Response times are instant. I don’t have to worry about proprietary services going dark or bricking my hub in the future based on someone else’s business needs. If I want a new feature in the front end, back end, or anywhere in between, I can create it.

$30 z-wave stick and home-assistant.io.

2 Likes

So how do you handle your zigbee devices? Do you have to exclude the devices from ST hub before you connect them to the z-wave stick???

Same boat here except mine is through Tasker and Sharptools :slight_smile:

1 Like

I solved that problem by not having any.

But the system is capable of working with zigbee. https://home-assistant.io/components/zigbee/

And yes, z-wave devices have to be moved over: exclude from ST, then include on the stick. I consider it a liberation.

2 Likes

Yep, there’s hardly any Zigbee devices that cannot be replaced with Z-Wave. “Arrival” sensors are the only ones I can think of, but they are notoriously unreliable, so not a big loss.

I’ve solved the time based events problem by making every time based event do nothing more than activate a simulated switch. I have time of day switches (morning, day, evening, night) and a sun-up switch. All my time based needs are triggered off the state or change of these simulated switches.

I trigger the time based events for these simulated switch with a redundant set-up. For grins I start with Smartthings time based events. For confidence, I use IFTTT. Since I’ve done this, I’ve had much more reliability. When I get a chance, I’m going to work on a logger to see how often either system fires or fails.

There are pluses and minuses with both protocols. ZigBee is somewhat better through water, making it better suited for outdoor deployment and in some places where there are water pipes in the walls. ZigBee devices are also generally smaller with better battery life than Zwave. And ZigBee networks are way easier to repair address tables for.

If you’re going to run lights, the 232 device limit on a zwave network can be a real issue for many buildings, while ZigBee allows for both more devices and more hops. For a large house with a couple of outbuildings, ZigBee is likely to be a better fit.

I like both Zwave and ZigBee, and it’s always good to have choices. For some people, all zwave will be better, for others all ZigBee, for many people being able to use both is ideal. :slightly_smiling:

1 Like

Most of my time based events fall into a sunrise/sunset class since I’m using them to adjust lighting downstairs, so I’ve taken to using an outside lux sensor and it’s been working marvelously for those specific uses. Even the ones I used to have set with a time offset from sunset work well just by figuring out what lux level I want the lights to come on at and using that. My time based stuff is just shutting off some outside lights, so I’m not all twisted up about exact minutes. For those I use IFTTT. The combination of the two seems to work well.

The ones I can’t force into those two categories I run through Rule Machine and have the rules updated twice a day to keep the schedules fresh. Seems to be working great there too!

Sorry, but this is totally incorrect. 2.4 GHz is absorbed by water molecules. It’s the physics behind the microwave oven. It’s also a reason why this band was allocated for civilian use worldwide. It’s the most useless wave band for outdoor communications.

http://www.schoolphysics.co.uk/age16-19/Wave%20properties/Wave%20properties/text/Microwave_ovens/index.html

2 Likes

Read the linked article carefully. It specifically says that if the microwaves were completely absorbed by water, they wouldn’t be able to penetrate the food and it wouldn’t cook inside.

And the microwave oven environment is very different from a sensor transmitting outdoors.

Zigbee is used for low-power sensors in many outdoor applications such as agricultural soil sensors and outdoor lighting. It’s also used in some underwater applications and for sensors inside fluid pipes. None of this would be possible if the radio waves were completely absorbed by water.

Yes, they are definitely affected by water, and range is reduced. But zigbee devices are cheap, and it remains the protocol of choice for many outdoor applications. Not the most physically efficient, but often the best budget choice.

There are also many factors that affect real life deployment of outdoor RF equipment, not just wavelength. The Zigbee protocol is very good at dealing with transmission obstacles, so it can pick up some advantages that way.

Still, if someone says they’re getting better results using Zwave sensors outdoors at their house, I don’t doubt it. “All home automation is local.” If you have a solution you’re happy with, that’s great. :sunglasses: