SmartLighting ignoring time constraints? (Feb 1 2018)


(vlad) #42

Apologies for the late response - I am more familiar with the local side of things but may be able to help out. Could you submit a support request and also DM me your username?


#43

I’m fairly new to ST and home automation in general, but am very technical and haven’t had any issues setting all this up until now. I did a lot of research when choosing a hub and ST seemed to be way to go. I’m very disappointed that this thing still seems to be an issue (I can find people with this same issue going many years back).

In our kitchen, I have an Inovelli smart dimmer controlling eight Cree LED bulbs. I have a Zooz motion sensor setup to to trigger an automation that turns on the lights at 10% between the hours of 10pm and 6am. Originally, I had it set to sunrise. While the lights turn on at 10% like they should, neither setting stops the automation in the morning. Even after 8am, the lights still turn on at 10% when you walk into the kitchen, and will even override someone turning the lights up to 100% once motion is detected. There are no time zone settings I can see in the ST app, or in the Samsung API site that I can find, unless I just am not looking in the right place.

This should not be an issue after so many years of it not working. I don’t know what else to do on my end. The only thing I can think of is it has something to do with using custom handlers on the Inovelli switch or the Zooz (neither of which worked correctly with ST otherwise). If it is something in the device handler, maybe someone can point out what I’m doing wrong so I can edit the code before I upload it to the Samsung ST API site.


#44

I vaguely remember the timezone being set as a side effect of setting the hub location in the Classic app. You can see what it is by going to https://graph.api.smartthings.com/location/list and clicking on the location name but I’d have thought the times on the live logging would use the timezone so you’d notice if it were wrong. Maybe not though.

So does the motion triggering the automation start on time and does it ever stop?


#45

I just looked. It only shows the UTC time, so maybe I’m supposed to be using UTC time only in the app?

I’m not sure if it will stop, because we’re home in the morning and there is always someone home during the day. If I even use it now, I just shut off the automated lighting when we wake up. Lately though, we haven’t even been using it.

I have it set for start at 11pm and 6am. If I’m sitting in the kitchen at 11:30pm and enable automated lighting, it will usually start working (I say usually, because it didn’t work when I tried it last night). If I go into the kitchen at 8am (before yesterday), the lights will come on at 10% like the automation is still on. If I manually force them to 100%, the second the motion sensor detects movement, it’ll drop back down to 10%. At that point, we shut it off.

We live in Colorado, so we are -6:00 hrs UTC.

EDIT
I’ve been clicking around in both the app as well as IDE page. Still no reference to time, so you’re probably right about it being an issue with the Classic app, but I did notice on the logs page, it shows my exact, current time, offset to Denver, US (UTC -6:00). So I’m guessing this is not a time zone thing.


#46

Update on my situation… simply going in and “reseating” the location pin on the map seems to have done the trick for me. I would love to know what was going on in the backend, but am just happy it’s working now!


(Tristyn Russelo) #47

DUDE!! this f*cking fixed my time issues.
YOU ROCK!!!
I was just about to delete all my timed routines and re-create them.

Things all went south after an app update yesterday. the new ST app said my door lock was disconnected even though automatons and the button in the app still worked. Then today all zwave devices showed as disconnected, but automatons still worked. Toggled power or removed battery for all zwave devices and they showed as connected again. Everything seemed to be working until night came around and i noticed the wrong light levels were getting set…

The whole time everything worked and showed connected in ST Classic and in IDE online.
Smart lock still borked in new app… and can only add codes in ST Classic using a custom app.
But you fixed my time issue… so kudos to you!


#48

Glad it was a simple fix. So weird… I haven’t this simple fix listed anywhere, so hopefully this helps others, too.


#49

I am also have an issue having the app respect time constraints, but only when using sunrise/sunset. Setting a specific time works correctly. I tried re-setting the pin like described above with no success.

There is a build error when using sunrise/sunset, and an additional build error when using specific times (although in the end that seems the work)

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace timeOk = true

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace timeWindowStop = null

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace timeWindowStart = null

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace daysOk = true

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace modeOk = true

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:29:03 AM: trace modeChangeHandler(mode: Away)

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:28:43 AM: error Failed to build Behavior java.lang.NullPointerException @line 479 (buildTimeGuard)

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:28:43 AM: debug Updated with settings: [startTimeOffset:0, triggerModes:[Home], overrideLabel:true, startTimeType:sunset, endTimeType:sunrise, ending:2018-12-05T22:10:00.000-0800, presenceSensors:[Pixel 3 XL], starting:2018-12-05T16:10:00.000-0800, modeChangeFollowup:false, sceneIds:[cd7da898-c7b6-4a2b-973c-9e6fcadae9c2], presenceState:present, trigger:When Mode Changes, endTimeOffset:0, switchConditionState:on]



[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:36:35 AM: error Failed to build Behavior groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.util.ArrayList#addAll.
Cannot resolve which method to invoke for [null] due to overlapping prototypes between:
[interface java.util.Collection]
[interface java.lang.Iterable]
[interface java.util.Iterator] @line 380 (buildBehaviors)

[213082af-d32d-4dba-bc32-f6c32b9cdea3](https://graph-na04-useast2.api.smartthings.com/ide/logs#213082af-d32d-4dba-bc32-f6c32b9cdea3) 10:36:35 AM: debug Updated with settings: [startTimeOffset:0, triggerModes:[Home], overrideLabel:true, startTimeType:time, endTimeType:time, ending:2018-12-05T22:10:00.000-0800, presenceSensors:[Pixel 3 XL], starting:2018-12-05T16:10:00.000-0800, modeChangeFollowup:false, sceneIds:[cd7da898-c7b6-4a2b-973c-9e6fcadae9c2], presenceState:present, trigger:When Mode Changes, endTimeOffset:0, switchConditionState:on]