Diferencias entre "esperar" y utilizar variables en una tarea

[rabeliyo]

Muy buenas pues os comento a llevo unos dias metiendo horas en el tasker y viendo perfiles de los que pueda sacar ideas y me ha llamado la atencion en los perfiles de bluetooth de coche en concreto un caso.

Yo uso lo siguiente en la tarea de salida por si bajo a respostar y vuelvo:

Tarea: Apagar Bluetooth Coche

1. Esperar 10 min (se supone que he salido de el coche por cualquier cosa)
2.Bluetooth Establecer apagado

y en el caso de la tarea de entrada tengo puesto al principio

1.Detener. Tarea Apagar bluetooth coche


El caso es que en algunos ejemplos veo que se hace asi:

Tengo un perfil cuyo contexto es "bluetooth conectado" que establece una variable %BTCON a 1 cuando se conecta y la tarea de salida (cuando se desconecta) es un poco más compleja:

1. Establece %BTCON a 0
2. Establece una variable local %cont a 0
3. Esperar 2 minutos; Etiqueta: "Comienzo"
4. Parar si %BTCON = 1 (si se ha vuelto a conectar durante estos 2 minutos)
5. Sumar 1 a %cont
6. Ir a etiqueta "Comienzo" si %cont < 5
7. Apagar bluetooth si %BTCON = 0


Pues ahi viene mi pregunta me gustaria saber que ventajas o inconvenientes tiene el usar un tipo u otro ya que entiendo que en los dos se detiene la tarea cuando se vuelve a conectar el bluetooth si entra dentro del rango de los 10 min en los que puedo volver a subir al coche

Un saludo

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

me gustaria saber que ventajas o inconvenientes tiene el usar un tipo u otro ya que entiendo que en los dos se detiene la tarea cuando se vuelve a conectar el bluetooth

Creo que en la práctica ambos sistemas dan un resultado similar, y el primer método tiene ventajas evidentes:
- Es mucho más sencillo de programar y de entender, y por tanto tiene menos posibilidades de fallo o de que te equivoques al construirlo.
- No necesitas utilizar una variable global como %BTCON.
- La tarea de salida se interrumpe de forma instantánea en el momento en que el perfil vuelve a activarse y así se zanja el tema definitivamente, si flecos. Con el otro sistema la tarea de salida puede seguir viva durante uno o dos minutos más, lo cual no tiene ninguna ventaja.

[rabeliyo]

Perfecto entonces, me ha quedado muy claro, es que como la veia tan elaborada la segunda pues pensaba que tendria algun tipo de ventaja

Muchisimas gracias

[rabeliyo]

Reabro el hilo ya que me he puesto a mejorar mis perfiles y no acabo de conseguir que funcionen.
Bien,como he puesto arriba tenia una accion "esperar" para cuando bajo del coche y una accion "detener" para cuando reconecta el bluetooth si hemos bajado y vuelto a subir.
La accion de entrada no funciona hasta que la accion esperar ha concluido una vez se ha iniciado la espera y acabado la tarea de salida.

Pues bien, me he decantado por utilizar el segundo metodo de espera, que me checkea cada pocos minutos si la conexion se ha vuelto a realizar para no tener asi que tener la tarea en espera si he vuelto antes de 10 min, pero me pasa lo mismo, que no me cambia el valor de la variable %BTCON ya que se sigue ejecutando la tarea de salida.
¿Como lo habeis conseguido vosotros?

Si no me equivoco tenia entendido que una tarea de entrada no puede detener una de salida en el mismo perfil (que es lo habitual) pero pensaba que con el tema del cambio de valores en la variable en forma de interruptor funcionaria.

EDITO: Acabo de hacer que funcione creando otro perfil con estado de bluetooth que cambial el valor de la variable, y funciona, pero me gustaria saber como lo teneis vosotros.

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

Pues bien, me he decantado por utilizar el segundo metodo de espera, que me checkea cada pocos minutos si la conexion se ha vuelto a realizar para no tener asi que tener la tarea en espera si he vuelto antes de 10 min, pero me pasa lo mismo, que no me cambia el valor de la variable %BTCON ya que se sigue ejecutando la tarea de salida.

Creo que hay un método que puede resolver tu problema. Se trata de que la propia tarea de salida establezca un periodo de demora, dentro del cual comprueba cada poco tiempo si el perfil vuelve a estar activo (porque se ha recuperado el contexto) y en caso afirmativo la tarea se "autodestruye". Si se agota el periodo de demora es porque no se ha recuperado el contexto y entonces procede ejecutar lo que corresponda como tarea de salida "definitiva". Así no necesitas utilizar ninguna variable Global de tipo %BTCON y tampoco necesitas un segundo perfil.

Supondré que el perfil se llama COCHE. Como ejemplo, vamos a establecer una demora de 10 minutos y haremos comprobaciones cada 10 segundos. La tarea de salida sería del tipo siguiente:

- Establecer variable %tiempoespera a 600 (son 600 segundos; son 10 minutos).
- Establecer variable %comprobacion a 10 (cada 10 segundos se comprueba el perfil)
- UnaEspera (Etiqueta o destino de Goto)
- Esperar %comprobacion segundos. (es una espera de 10 segundos)
- Detener tarea, si %PACTIVE ~ *COCHE* (Si el perfil se ha reactivado, detiene la propia tarea de salida. Se puede indicar el nombre de la tarea a detener, pero si no se pone nada se detiene la propia tarea).
- Restar de variable %tiempoespera, restar %comprobacion.
- Ir a UnaEspera, si %tiempoespera > 0
- A partir de aquí puedes añadir aquí el resto de acciones que deben ejecutarse cuando ha pasado el tiempo establecido y no se ha recuperado el contexto.

Creo que no necesita más explicación.

[rabeliyo]

Eso era justo lo que buscaba, una variable externa para modificar la salida sin depender de la entrada por el problema que se producia, muchas gracias Caravantes.
Por cierto, ¿sabeis si se tiene pensado implementar la variable de info de bluetooth al estilo %WIFII para poder evitar estos problemas y poder definir variables de "connected" o nombres de aparatos de bluetooth en proximas versiones?

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

Por cierto, ¿sabeis si se tiene pensado implementar la variable de info de bluetooth al estilo %WIFII para poder evitar estos problemas y poder definir variables de "connected" o nombres de aparatos de bluetooth

Es una propuesta interesante pero no tengo ni idea sobre lo que está previsto implementar en el futuro.

De nuevo creo que puedes solucionar eso con la variable %PACTIVE, que recoge los nombres de los perfiles activos (separados por comas), siempre que utilices perfiles y contextos adecuados, porque los contextos de BT sí pueden diferenciar los nombres de los aparatos.
Por ejemplo yo tengo un perfil que se llama BtAuric (abreviatura de BlueTooth Auricular) asociado a un contexto Bluetooth-conectado en el que he especificado el nombre del auricular, un Sennheiser VMX 200-II (usando la lupa es fácil elegirlo sin necesidad de escribirlo). Del mismo modo tengo otros perfiles BtAltavoz, Coche, etc asociados a contextos Bluetooth-conectado con los respectivos nombres de los aparatos. Así, en cualquier tarea puedo poner condiciones de tipo
- Si %PACTIVE ~ *BtAuric*
o bien
- Si %PACTIVE ~ *BtAuric*/*BtAltavoz*/*Coche*
o incluso
- Si %PACTIVE ~ *,Bt* (cualquier perfil que comience por las letras Bt indicativas de BlueTooth).
Supongo que esa estrategia te sirve para resolver el problema.

[rabeliyo]

Perfectamente explicado Caravantes, lo voy a implementar en todos mis perfiles y estoy pensando en crear una unica tarea de cuenta atras para no tener que repetirla en cada perfil.

[oscarptx]

Yo implementé hace tiempo todo mi Tasker a la idea de Caravantes de usar la variable %PACTIVE y funciona siempre genial...

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

estoy pensando en crear una unica tarea de cuenta atras para no tener que repetirla en cada perfil.

Pues no se me había ocurrido, pero creo que has tenido una buena idea. A ver si podemos hacerlo funcionar. Se trata de hacer una subtarea que llamaremos DEMORA y que tiene que recibir los siguientes parámetros:
1- Tiempo máximo de espera, en segundos.
2- Tiempo entre comprobaciones, en segundos.
3- Nombre del perfil a chequear.
4- Tarea de Entrada o de Salida (E/S).
A su vez, esta subtarea devolverá un texto que puede ser Abortar o Seguir (A/S).

El problema es que a una subtarea solo se le pueden pasar DOS parámetros, y aquí nosotros necesitamos pasarle CUATRO. La solución está en concatenar esos cuatro elementos, separándolos por el carácter almohadilla (por ejemplo) y de esa forma los podemos transmitir a la subtarea como un único parámetro; luego la subtarea se encargará de volver a separarlos.

Veamos cómo se hace en la práctica. Supongamos que estamos en la tarea de SALIDA del perfil COCHE, tal como hemos comentado anteriormente en este hilo, y queremos establecer una demora de 10 minutos, con comprobaciones cada 10 segundos. Para más claridad voy a poner en negrita los datos transmitidos de la tarea a la subtarea, y viceversa. En esa tarea de salida del perfil Coche... habría que comenzar con las siguientes acciones:
- Ejecutar tarea Demora, Prioridad 10, Parametro1: 600#10#Coche#Salida , Devolver variable %respuesta
- Detener tarea, si %respuesta ~ A*
- A partir de aquí se añaden el resto de acciones que deben ejecutarse cuando ha pasado el tiempo establecido y no ha cambiado el contexto.

Subtarea Demora
- Separar variable %par1, separador: #
- Establecer variable %tiempoespera a %par11, calcular encendido.
- Establecer variable %comprobacion a %par12, calcular encendido.
- Establecer variable %perfil a %par13, calcular apagado.
- Establecer variable %tarea a %par14, calcular apagado.
- UnaEspera (Etiqueta o destino de Goto)
- Esperar %comprobacion segundos.
- Si %tarea ~ E* (Entrada)
- .. Devolver "Abortar", Parar encendido, si %PACTIVE !~ *%perfil* (si no coincide)
- Else (Salida)
- .. Devolver "Abortar", Parar encendido, si %PACTIVE ~ *%perfil* (si coincide)
- Fin si
- Restar de variable %tiempoespera, restar %comprobacion.
- Ir a UnaEspera, si %tiempoespera > 0
- Devolver "Seguir", Parar encendido

¿Se os ocurre alguna idea para mejorarlo?

[oscarptx]

Pues no se me ocurre cómo mejorarlo no, yo lo había creado haciendo %par1 la tarea y %par2 el perfil, con unos segundos de espera y comprobación genéricos, pero ya que estamos vamos a mejorarlo usando 4 parámetros...

[rabeliyo]

Yo tambien iva por los tiros de hacerla generica pero como bien dice oscarptx asi es mas completa y mejor.
Lo unico que no entiendo es el Si tarea "coincide" E. en teoria sin ese paso y con un solo devolver "abortar sin no coincide" tambien funcionaria pero no acabo de ver es porque lo pones (seguro que es una tonteria y se me escapa )

Me viene de lujo porque asi luego implemento un if en la tarea principal, que si me devuelve un "seguir" pueda en este caso desactivar bluetooth, activar el perfil de vuelta a la ubicacion del coche etc...
Lo unico que supongo que ¿tendria que asignar un valor a la variable "seguir" para poder usar el if en la tarea principal no?

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

Lo unico que no entiendo es el Si tarea "coincide" E. en teoria sin ese paso y con un solo devolver "abortar sin no coincide" tambien funcionaria

Hemos hecho una subtarea que sirve para comprobar el periodo de demora y queremos que sea genérica, o sea que debe servir para una demora en tareas de entrada y también para una demora en tareas de salida.
En el caso de que la tarea sea de Entrada... hay que abortar en el caso de que el perfil haya dejado de estar activo (%PACTIVE !~ *%perfil*). En el caso contrario (tarea de salida) hay que abortar en el caso inverso, en caso de que el perfil se haya reactivado (%PACTIVE !~ *%perfil*).

 Cita: Originalmente Escrito por rabeliyo

Lo unico que supongo que ¿tendria que asignar un valor a la variable "seguir" para poder usar el if en la tarea principal no?

No hay ninguna variable "seguir" (ni tampoco "Abortar"). Eso son textos-fijos devueltos por la subtarea; la tarea principal sí recoge esa información en una variable. Para explicar cómo se utilizaría en la tarea principal, he puesto el ejemplo de la tarea de SALIDA del perfil COCHE, con una demora de 10 minutos y haciendo comprobaciones cada 10 segundos. He puesto las dos acciones concretas que deben ir al comienzo de esa tarea. Creo que no te has leído bien mi mensaje anterior. Vuelve a mirarlo con calma, creo que está todo explicado.
Si luego todavía hay algo que no entiendes, vuelves a preguntar.
Hay otro post específico que explica cómo se comunican las tareas y subtareas: http://www.htcmania.com/showthread.php?t=744076

[rabeliyo]

Vale, me he puesto a mirarlo desde el ordenador detenidamente y ya lo veo claro, es qu eel otro dia desde el movil me lie porque en Si tarea coincide E le falta el % delante, ¿seria asi no?

Si %tarea coincide *E*

Y lo otro no me acordaba de que el el abortar o seguir, son textos dentro de la variable a devolver en este caso %respuesta

Creo que es asi, si no corregidme.
Como siempre Caravantes un perfil curradisimo

[Caravantes]

 Cita: Originalmente Escrito por rabeliyo

en Si tarea coincide E le falta el % delante

Gracias por el aviso, ya lo he corregido.

[Jusss]

 Cita: Originalmente Escrito por Caravantes

r apagado.
- UnaEspera (Etiqueta o destino de Goto)
- Esperar %comprobacion segundos.

Como estas Caravantes estoy intentando copiar esta sub tarea pero me quede trabada en el punto de espera, que accion de tasker seria donde pones "- Esperar %comprobacion segundos"? Porque "tarea" "esperar" no se puede poner una variable

[Caravantes]

 Cita: Originalmente Escrito por Jusss

Porque "tarea" "esperar" no se puede poner una variable

Sí se puede, del siguiente modo. Abres la acción ESPERAR del modo normal. Verás que tienes varias líneas para especificar milisegundos, segundos, minutos y horas. A la derecha de la palabra SEGUNDOS hay un icono con dos flechas entrecruzadas. Al tocar ese icono te aparecerá un cuadro de texto para escribir un número o una variable, e incluso te permitirá elegir la variable de la lista que aparece al tocar en el icono de la etiqueta. Si vuelves a tocar el icono de las dos flechas desaparece el cuadro de texto y vuelves a tener un regulador de 0 a 59 segundos.

[Jusss]

[quote=Caravantes;12666009- Ir a UnaEspera, si %tiempoespera > 0[/QUOTE]

Otra pregunta Caravantes tengo un problema en esta accion, no entiendo bien que accion de Tasker seria "Ir a UnaEspera" es "ir a accion"?, o "Ir a UnaEspera" es solo información y hay que poner solo un "if"-

[oscarptx]

Es ir a acción, ahí le marcas que retroceda hasta esa acción

[Jusss]

 Cita: Originalmente Escrito por oscarptx

Es ir a acción, ahí le marcas que retroceda hasta esa acción

Seria en tipo: " etiqueta de accion" y debajo en etiqueta pongo " UnaEspera"?