Llama - Who's Using It and Any Good Examples?

[skidmark]

Is it possible for llama to sense when we are driving to then turn on bluetooth?

 

[raino]

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...

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.

Is it possible for llama to sense when we are driving to then turn on bluetooth?

It might be possible to do this with NFC tagging, or the Car Mode condition. I don't know how docking in Car Mode works, though.

 

[raino]

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?

 

[gusar2000]

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.

Thanks,
Actually, the initial idea was to turn BT ON by TIME and turn it OFF by location. As far as I had to set up range of time (not initial time), this range not always played well with location. If location fires BEFORE time expired - would time turn BT ON again ? If time expired earlier, would BT still be ON until location reached?

 

[raino]

Hmmm...I see what you mean. I have limited experience with conflicting events--the only experience being sound profiles.

If location fires BEFORE time expired - would time turn BT ON again ?

I'm not sure. For this to be true, Llama would have to be periodically checking if conditions still hold and then acting accordingly.

If time expired earlier, would BT still be ON until location reached?

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.

 

[kurokirasama]

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?

Hi, I think ou could achieve that with Llama variables. First of cent should be like :

Add condition: active app--Music Player
Add action: switch profile to silent
Add action: set llama variable "Silent" to 'yes'

Queued event

Add condition: active app is not the Music Player
Add action: set llama variable "Silent" to 'no'

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.

Best regards,


Enviado desde mi GT-N7000 mediante Tapatalk

 

[raino]

Thank you for your reply. I've created the event and queued event, but don't understand this part:

Then, in each of your profiles switcher events, you should add the condition, when llama variable "Silent" has the value 'yes'

To test this out, I created the event+queued event you had suggested above, and added this condition to the whichever profile event was active. But I don't think it's working. The silent profile was not triggered when I launched the music player. Here are my events:

Add condition: active app--Music Player
Add action: switch profile to silent
Add action: set llama variable "Silent" to 'yes'

Queued event

Add condition: active app is not the Music Player
Add action: set llama variable "Silent" to 'no'

(^^as suggested by you)

Current Event
Condition: between time X and time Y
Action: change profile to Normal

to which I added,
Condition: Llama variable when "silent" has a value of "Yes"

My guess as to why it's not working is that when I create the variable "Silent," Llama doesn't recognize that I'm talking about the profile with the same name. In other words, "Silent" becomes just another string, not the profile I want it to refer to.

Finally, Thanks for your question, it helped me to optimize some of my events.

I'm glad I could help. Your posts have been very helpful to me.

 

[kurokirasama]

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"

 

[raino]

Sorry, here i meant : when Llama variable "silent" doesn't has the value of "Yes"

Great! It worked. Now to modify ten more events...

 

[gusar2000]

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? :-\

 

[raino]

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? :-\

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.

 

[gusar2000]

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)...:'(

 

[kurokirasama]

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

 

[kurokirasama]

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

You have to manually fire of the event so the variable get a value, otherwise the events will never trigger.


Enviado desde mi GT-N7000 mediante Tapatalk

 

[anon8164182]

Does anyone know how to stop Llama vibrating (vibrating llamas indeed!) every time profiles change?

 

[gusar2000]

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...

 

[BJozi]

So I had some time earlier to have a good look at kurokirasama's setting and thought I would translate some of the words/terms he uses but holy crap it's a bit complex! I thought I could adapt what he has but I think it would make more sense to start from scratch, I just have no idea how to properly go about it. I like how kurokirasama had events for a lot of conditions and rules, but how do you go about creating them in away that you can add to them? I had a few events setup previously but they were quite simple and after looking through kurokirasama's I was propable going about it the wrong way anyway.

 

[kurokirasama]

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...

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

 

[gusar2000]

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

Thanks,
will try.

 

[TehFonz1]

I'm hoping someone here will have an answer for this conundrum I'm facing with Llama.
I've recently started using the Nexus 5 and have a couple of wireless chargers. One of the wireless chargers is actually a car dock.
Now what I am trying to do is have the phone disable the keypad, disable pattern unlock, & open InDrive or set to car mode
Once undocked from the wireless car charger I want the reverse, so leave car mode or exit car mode. The pattern lock and keyguard should reset to the default depending on my location.

Just a couple of things: I am using Secure Settings for the keyguard & pattern lock switching.
What I am after is a way, whether it be with NFC tags or a condition inside Llama, to differentiate between a desk wireless charger, and a car dock wireless charger. I'm hoping someone here has done this or has an idea on which process I should use. Appreciate any help I get

Cheers
~Fonz