Well.... I guess each to their own. I would definitely call that "surviving a reboot".
But yes, it won't run if its scheduled time is in the past.
1 Like
Absolutely, no.
As discussed, if the event is missed.. for whatever reason, reboot being the most obvious, it doesn't recover. There is a recover option BUT it recovers ALL missed and thus can have multiple running on top of each other.
How can you say that an event doesn't survive a reboot. It does. There's no arguing that. It does not unschedule all scheduled events. It doesn't catch up with any missed events. But events schedule for further in the future are still scheduled, right? So, that is surviving a reboot.
RunIn isn't restarting. The event is scheduled for the future. That schedule persists after a reboot unless specifically unscheduled.
I guess we'll agree to disagree. Saying it "doesn't survive a reboot" (to me) means it will NEVER run if you reboot - which simply is not true. If it is not in the past, it will run. I'm only being pedantic because that distinction can be very important in how you handle initialization of devices and apps after a reboot. So it's important to understand what it actually does.
Yes, missed scheduled events do not catch-up or recover after a reboot. I think we can all agree on that.
Anyway. Enough said on my part. As long as we agree in what it does/doesn't do - call it whatever you want. 
I know I cannot put runin() into what amounts to an infinite loop.. as in an alternate to runEvery5Minutes()
runEvery(x)Minutes() has very specific values. If you want a runEvery8Minutes() you can't..
I had this in wx-ApiXU-Driver for those people that wanted Lux to poll less often at night. After about a week, the loop would fail.
I agree 100% that it CAN survive.. but I cannot agree that it always will survive. Which is the 'absolute' word that I'm tripping over. 
1 Like
We aren't talking about runEvery....we're talking about runIn. And runIn is only once. So, the method of runIn doesn't survive....the event it schedules does.
runEvery is a very different story and not what was asked here. We can certainly discuss that too if you want but that's not what we are talking about.
You said it doesn't survive at all. Which is absolutely incorrect. 
Might I interest anybody in the "Reply as Linked Topic" option in Discourse that you can access here?
Now you can continue your own discussions in the Debate Chamber without making staff move them there anyway.
(Edited to correct my typo in the name of the link. FWIW, I find the description of the behavior clear, regardless of what you call it. My suggestion would be to continue discussions of how to phrase this there since all is clear here.)
1 Like
You thought we weren't staying on topic so you posted something that is completely off-topic? Hmm...okay. I guess I should just let people be wrong next time. Got it.
Using any of the following (the value is a string, but comes from a list) does stop the logs, but doesn't update the UI nor does it update the value shown in State Variables:
device.updateSetting("logLevel",[value:"0",type:"string"])
-or-
device.updateSetting("logLevel",[value:"0",type:"list"])
Running the below updates the UI:
// Not sure which ones are needed, so doing all... This works!
device.clearSetting("logLevel")
device.removeSetting("logLevel")
state.settings.remove("logLevel")
So what is the correct way here? My way "works", but is there a "better" way?
Here's how Hubitat does it in their stock drivers:
device.updateSetting("logEnable",[value:"false",type:"bool"])
(see, for example: HubitatPublic/GenericZigbeeRGBWBulb.groovy at master · hubitat/HubitatPublic · GitHub)
This assumes a boolean setting named logEnable. It looks like you might be trying to use a string or an enum for some reason. I wouldn't do that unless you have a good reason--I'd try to make it look like the native drivers so users have a more consistent experience between the two. That being said, if your data types match up (is the key really a string? or are you using a key or just the "value" in the list?), I'm not sure why at least one of those wouldn't work, but enums are tricky in the UI...
I believe @djgutheinz released an update to the TP-Link drivers within the last couple weeks that fixes this.
Ok, I will look at this some more then.
Yes, the key really is a string, so the question is, since the type is a list with string keys, what is the type that should be passed with updateSetting? I would assume string, right?
As for doing it like the stock drivers, at the moment I'd say no, at the moment I need more levels to filter logs with. Though I will revise this as they've been tested by more users and I can remove more log messages or possibly add a special, hidden, developer-level debug. It is a valid point though, will keep it in mind, thank you.
EDIT: It is probably more a matter of restructuring the debug messages, since most of my driver-code is automatically reused and auto-generated, this should not be too much work. Still new here and need to learn more about best practices.
If you simply want to see if a device is turned on or off, go to the device's event page. I will look at the logging again; however, I think the case will be to eliminate logging status (attributes) when the status has not changed.
