The internal clock of the ST hub is, unfortunately, very inaccurate unless permanently connected to the internet. As - for reasons - my hub isn’t always connected to the internet and runs basically all of my home automations locally, time-based routines are getting out of sync with “real” time quite quickly. I am thus looking for a clock - in the broadest sense - that I can pair with ST to reliably provide accurate time. Maybe some Zigbee device that can locally provide time? It doesn’t matter if the device also has other features, as long as the time can locally be “seen” by the ST hub. Does anyone have a suggestion?
ST hubs do not function without the internet. If your hub time is incorrect contact support. In the App, menu, contact us.
I honestly can’t think of anything for your use case, other than to say keep it connected.
How are you managing hub firmware updates given that ST only gives large date ranges when the firmware updates? Ditto for certain devices.
are you referring to Routines that depend on Sunset/Sunrise? ST needs an internet connection to update those.
Of course the ST hub works without constant internet access - what doesn’t work is to access it from the app. Everything else works locally, except for time-based routines that get out of sync over time (they are reasonably ok for two to three days, but then drift). What do you think support can do about that?
Thanks a lot, I will keep searching for a solution and post it when I come up with something. Of course I would keep the hub connected if I could, but with shaky internet connection this isn’t under my control, unfortunately.
Any firmware can happen when the hub is connected, which often is two months in a row (and then not for two weeks or so). Never had a problem with firmware updates. That doesn’t mean the hub needs to be connected 24/7 to the internet.
No, I am talking about real time-based routines. For example to react differently to detected motion in the evening (switch on light 1) or late at night (switch on light 2). I would like this to change at, say, 23:00 every day. Without internet connection, the hub executes the routine ok-ish for the first days, then drifts and does not react properly afterwards. I have “kind of” solved the problem with a light detector, that sets a virtual “evening hour” switch to on when the light goes lower than 200, and switch off 6 hours later. Using this switch as a precondition in a routine works to do what I want. As I said, this “kind of” solves the problem, but on gloomy days the light detector triggers “evening” already at 15:00, so the evening is over at 21:00.
It would all be much easier if the clock in the hub worked properly, or if I had an external clock that can communicate with the hub to set the correct time (I guess once or twice a day would be sufficient).
can you post a screenshot for some of them so we can see them? also post a short line for each in how they are failing.
Nothing fancy at all. A simple example is “if 23:00 every day” “then turn on LED light”.
It triggers at a reasonable time for the first few days without internet connection, then drifts to trigger later and later every day (by quite a lot).
Edge Drivers can’t access the RTC:
good to know - although I don’t know whether RTC is used for triggering routines, or a “normal” system clock. I would have assumed the latter. Is there any kind of documentation on how the ST hub clock works, to satisfy my curiosity?
So, if the RTC clock is used and there is no way of setting it from an Edge driver, my question simplifies to “Does anyone know of a Zigbee clock that can be connected to the ST hub and used to trigger a routine?” - leaving the unreliable onboard-clock of the hub aside. As an example: “if CLOCK1 says it is 23:00” “then switch LED light on”.
The hub is just a Linux system, where a simple user can’t just set the time.
“Does anyone know of a Zigbee clock that can be connected to the ST hub and used to trigger a routine?” - leaving the unreliable onboard-clock of the hub aside. As an example: “if CLOCK1 says it is 23:00” “then switch LED light on”.
That’s an interesting idea and might work. Check if there’s a standard Zigbee cluster in the specifications.
Page 3-86:
Even though there’s a Time spec, the device still needs to be built/designed to incorporate that cluster.
A dumb and overly complicated workaround for this would be to set up a plugin timer that would be active during the hours you want the extra light. Then plug in one of the devices that will notify ST when it switches to battery power, like a Zooz range extender. Instead of time, in your automations, you would use “If switch DumbTimer is on” in place of "time is between 23:00 and 5:00.
That’s not complicated enough. Plug in a lamp, point a surveillance camera at it, if it detects motion, switch on a virtual switch in ST and use that in routines.
Edit: needs the cloud though…
Hi, @frayer
I’ll ask the engineering team about this to know the expected behavior in this case and I’ll let you know their feedback.
yes, of course the device would need to support the cluster - maybe I wasn’t clear from the beginning, but that was the whole point of my original question: Is there a device that can give real time to Smartthings, either to set the clock of the hub, or if that isn’t possible, at least to have an (additional) clock in the setup that Smartthings routines can use? Or do I have to use a potentially unstable silly workaround?
thanks a lot, I would greatly appreciate any help the engineering team can give!
The idea is not really overly complicated - unfortunately we have to resort to these kinds of workarounds to get the home automations going.
I have a “dumb” digital plug timer that works very reliably, so I can plug in a smart plug (I have plenty of those lying around anyway) that will go “on” when it receives power from the plug timer. This can then trigger a routine in Smartthings. The important thing is only that everything runs locally. I cannot predict how reliable such a setup will be, but as I do not make anything “mission critical” dependent on it, it should be ok - better than the internal clock of the hub for sure. I’ll try and report!