I thought too it works this way. But sometimes it turns Bluetooth off at the end time. Sometimes I believe it doesn't. Which confuses me.
And the problem is if "OFF" sub-event fires BEFORE the end time. What will happen next? Would main event turn Bluetooth "ON" again? You see, the time range for event is confusing. It should be exact time only and corresponding "OFF" event somewhere. The time range assumes constant re-firing of an event to me...
Is it possible for llama to sense when we are driving to then turn on bluetooth?
Thanks,OK. Here is what I would try: create an event for BT on in the specified time window, and an alternate event all around it. So, if you want BT on between 8pm and 9pm, create a BT on event, and another, separate event for 9pm to 8pm that keeps BT off. This is essentially how I've set up sound profiles, and it works just fine.
If location fires BEFORE time expired - would time turn BT ON again ?
If time expired earlier, would BT still be ON until location reached?
Is it possible to have Llama refer to events as actions? I'm thinking of a scenario like this:
Add condition: active app--Music Player
Add action: switch profile to silent
Queued event
Add condition: active app is not the Music Player
Add action: switch profile to predefined event
I have sound profile events created for different times within a day. So if the active app is not the Music Player, I'd want Llama to switch to whatever event is covering that part of my day. Is this possible to do?
Then, in each of your profiles switcher events, you should add the condition, when llama variable "Silent" has the value 'yes'
Finally, Thanks for your question, it helped me to optimize some of my events.
to which I added,
Condition: Llama variable when "silent" has a value of "Yes"
Sorry, here i meant : when Llama variable "silent" doesn't has the value of "Yes"
Hmmm...I see what you mean. I have limited experience with conflicting events--the only experience being sound profiles.
I'm not sure. For this to be true, Llama would have to be periodically checking if conditions still hold and then acting accordingly.
From my experience with Llama, things don't turn off unless you create an event to turn them off. So if as part of your time event BT turns off at a certain time, off by location becomes redundant a redundant event. However, if you are creating an open ended time event ("turn BT on at 8PM," or something like that with no end time) then I think BT stays on until the location event turns it off.
Thanks,
Now the last question - how to create event with no end time (to turn it OFF later by another event)? Event always has start and end times (with "time" condition) ...
Time frame is confusing to me in general - e.g. if event fires on Monday, can I turn it off? would it re-fire later on again (assuming it's still Monday)? If so, how often it re-fires? :-\
Thanks,In light of new knowledge, maybe it's something that could be something that can be accomplished by the use of Llama variables.Your event could be something like:
Condition: Between time X and Y (I'd probably make X and Y cover a full 24 hours,)
Action: Turn/keep BT off
And the variable to add as a condition here would be location. So BT would stay off the whole time, except when you're in the variable-specified location. That's how I'm picturing it, maybe kurokirasama can confirm if this would be possible, and if so, what variable/variable values should be used.
Thanks,
But it becoming complicated. :-\
Simple task : Turn BT ON at 8:00 and turn it OFF arriving to work (on weekdays) (similar on the way back) becoming complicated because of no single time event (only time range)...:'(
Hi.
Llama triggers an event when all conditions are true and when there is a change in them. That's means that when conditions of an event become true, the event triggers, and as long as any of its conditions doesn't change to false and then all to true again, the event should not trigger again. We have to consider this when creating queued event, because if it's conditions are already true, it won't trigger until some of the conditions became false and then all true again.
Nevertheless, what I do to avoid missbehaviors is to add a llama variable. For instance in your case, I would do something like this:
Conditions:
- time range
- when llama variable "bluetooth" has the value of 'off'
Actions:
- turn bluetooth on
- set llama variable "bluetooth" to 'on'
And the other event:
Conditions:
- at work
- when llama variable "bluetooth" has the value of 'on'
Actions:
- turn bluetooth off
- set llama variable "bluetooth" to 'off'
hope this helps.
Beat regards,
Enviado desde mi GT-N7000 mediante Tapatalk
Hi.
Llama triggers an event when all conditions are true and when there is a change in them. That's means that when conditions of an event become true, the event triggers, and as long as any of its conditions doesn't change to false and then all to true again, the event should not trigger again. We have to consider this when creating queued event, because if it's conditions are already true, it won't trigger until some of the conditions became false and then all true again.
Nevertheless, what I do to avoid missbehaviors is to add a llama variable. For instance in your case, I would do something like this:
Conditions:
- time range
- when llama variable "bluetooth" has the value of 'off'
Actions:
- turn bluetooth on
- set llama variable "bluetooth" to 'on'
And the other event:
Conditions:
- at work
- when llama variable "bluetooth" has the value of 'on'
Actions:
- turn bluetooth off
- set llama variable "bluetooth" to 'off'
hope this helps.
Beat regards,
Enviado desde mi GT-N7000 mediante Tapatalk
Thanks, kurokirasama.
But I can see a few flaws in suggested algorithm
Conditions:
- time range
- when llama variable "bluetooth" has the value of 'off'
Actions:
- turn bluetooth on
- set llama variable "bluetooth" to 'on'
When time range is still in effect (e.g. you reach the "work" location and reset variable to "OFF" before time expired, should it fire again because of time range (end time still did not expire)?
Actually, all this can be done without variables with the same result (and same flaws). I think. :-\
What I try to say, I need not a range, but one (fixed) time event. E.g. turn blue tooth ON at 8:00. Then I can turn it OFF when location becomes "work".
When I try select time rage (e.g. 8:00 to 8:01 or 8:00 to 9:00 I'm not sure if BT turns OFF at 8:01 before reaching "work" or BT turns ON again before 9:00 but after reaching "work". :-\
May be I need to try if range 8:00 to 8:00 works...
Thanks,What I usually do for that is to put between 8 and 8:10, less than that doesn't seems to work all the time. And as long as you don't tell llama to do anything, it won't do anything, so when it's out of time range, it won't turn bluetooth off unless you tell it by another event.
Enviado desde mi GT-N7000 mediante Tapatalk