Dudilla sobre perfil conectado wifi

[rabeliyo]

Buenas! Pues os cuento he hecho un perfil para un amigo dentista para que cuando el movil se conecta a la wifi de la clinica hace un wake on lan a todos los pcs y enciende las luces,el agua y los aparatos mediante vera (sistema domotico).

Pues bien hasta ahi la primera parte, todo eso esta en la tarea de entrada y funciona perfectamente. En la tarea de salida lo contrario,se apaga todo.
Pues el caso es que la conexion wifi a veces se pierde, no tengo ni idea de porque, si el movil,si en router pero vamos que a mi me pasa tambien en mi casa y bares con wifi.Por lo que se apaga todo porque piensa que te has ido.

Actualmente lo tengo de la siguiente manera para cuando se ancla al wifi:

Entrada:
Detener tarea salida
Levantar todo el sistema

Salida:
Esperar 4 min (lo he puesto para dar tiempo a que se vuelva a conectar si se pierte)
Apagar todo el sistema - if %WIFII !~ *CONNECT*
Apagar wifi - if %WIFII !~ *CONNECT*

La cosa es que me imagino que porque son del mismo perfil,la entrada no puede parar la tarea de salida si se vuelve a piyar la señal despues de una perdida de señal.Espera a que termine la salida para hacer la entrada y claro me vuelve a ejecutar todo el levantamiento del sistema,que no me importa porque si ya esta encendido todo no hace nada pero me parece algo que si se puede evitar pues mejor.

¿Alguna sugerencia o mejora para solucionar esto?
Estoy abierto a sugerencias.

Un saludo

[xuspitin]

Y si la salida la haces por otro lado adjuntandole el intervalo de hora?

[rabeliyo]

Te refieres a crear otro perfil de conectado a wifi + unas horas determinadas con solo una tarea de salida no?
El problema es que no sale siempre a la misma hora y si amplio mucho el rango de horas estaria en las mismas durante ese periodo.

[Caravantes]

Entrada:
Detener tarea salida
Levantar todo el sistema

Salida:
Esperar 4 min (lo he puesto para dar tiempo a que se vuelva a conectar si se pierte)
Apagar todo el sistema - if %WIFII !~ *CONNECT*
Apagar wifi - if %WIFII !~ *CONNECT*

Ese planteamiento me parece correcto y debería de funcionar bien.
Si no funciona probablemente sea por algún pequeño error. Quizá podríamos verlo si copias aquí la descripción exportada, que muestra todos los detalles y evita errores en la transcripción.

Otra idea: Yo insertaría varias notificaciones para conocer con detalle cómo se ejecutan los procesos, y así podría ver qué es lo que no está funcionando bien.


Entrada:
Notificación: Tarea de entrada iniciada a las %TIME
Detener tarea salida
Levantar todo el sistema
Notificación: Tarea de entrada acabada a las %TIME

Salida:
Notificación: Tarea de salida iniciada a las %TIME
Esperar 4 min
Notificación: Tarea de salida tras la espera, a las %TIME
Apagar todo el sistema - if %WIFII !~ *CONNECT*
Apagar wifi - if %WIFII !~ *CONNECT*
Notificación: Tarea de salida acabada a las %TIME con Wifi if %WIFII ~ *CONNECT*
Notificación: Tarea de salida acabada a las %TIME sin Wifi if %WIFII !~ *CONNECT*

[rabeliyo]

Caravantes el perfil lo tengo en el movil de mi amigo pero los las tareas por separado funcionan perfectamente, he estao haciendo unas pruebas asi por encima con el mio y poniendo en vez de %TIME un "decir" y confirmo que no se puede detener, en un mismo perfil una tarea de salida con una de entrada, se ejecutan pero uno detras de otro, la tarea detener queda inservible.
Pero si se crea otro perfil tambien de concetado a wifi y se usa uno para la entrada y otro para la salida si que el de entrada detiene la salida .

Lo que no me gusta nada es que queda por duplicado el perfil para hacer una cosa relativamente simple por unos puñeteros microcortes de vez en cuando.
¿lguna idea para poder mejorarlo o que si hay un microcorte no me vueva a ejecutar todo el levantamiento?
¿Vosotros tambien teneis de vez en cuando cortes de esos?

[mlesir]

Puedes usar una tarea independiente en la salida. Es decir la tarea de salida quedaria reducida a una accion: realizar tarea. Luego en esa tarea si que metes el resto de acciones. No es exactamente lo q quieres pero....es lo que hay. A mi tambien me jode lo q comentas de tener q usar dos perfiles.

[darkopro]

Pues no tiene nada que ver pero, si la conexión Wi-Fi se pierde en el móvil puedes mirar a ver si es en ti dispositivo en ajustes WiFi no tuvieras activada la mantener wifi activo siempre o tuvieras activado el cambio de red automático (depende del dispositivo) o probar a cambiar la frecuencia al router.

[rabeliyo]

Puedes usar una tarea independiente en la salida. Es decir la tarea de salida quedaria reducida a una accion: realizar tarea. Luego en esa tarea si que metes el resto de acciones. No es exactamente lo q quieres pero....es lo que hay. A mi tambien me jode lo q comentas de tener q usar dos perfiles.


Acabo de probarlo y tampoco funciona :enfadadisimo:me veo utilizando 2 perfiles

[rabeliyo]

Pues no tiene nada que ver pero, si la conexión Wi-Fi se pierde en el móvil puedes mirar a ver si es en ti dispositivo en ajustes WiFi no tuvieras activada la mantener wifi activo siempre o tuvieras activado el cambio de red automático (depende del dispositivo) o probar a cambiar la frecuencia al router.

Lo tengo desactivado pero probare lo que comentas del router a ver porque por lo que veo ¿no es normal que se corte no?

[mlesir]

Se me olvido mencionarte que le deberias poner una prioridad mas baja a la tarea en la accion realizar tareaq a la tarea del contexto (en propiadades del perfil, pulsando largo en el nombre del perfil).

[Caravantes]

Caravantes el perfil lo tengo en el movil de mi amigo pero los las tareas por separado funcionan perfectamente, he estao haciendo unas pruebas asi por encima con el mio y poniendo en vez de %TIME un "decir" y confirmo que no se puede detener, en un mismo perfil una tarea de salida con una de entrada

Gracias, por insistir y contradecirme.
Acabo de probarlo con un perfil real y tienes razón.

Perfil: PruebaDemora (146)
Estado: Cargando [ Origen:Cualquiera ]
Entrada: PruebasEntrada (145)
A1: Detener [ Con error:Apagado Tarea:PruebasSalida ]
A2: Decir [ Texto:Encendido Motor: Voz:default:default Stream:3 Tono:5 Velocidad:5 Respect Audio Focus:Encendido Continuar tarea inmediatamente:Apagado ]

Salida: PruebasSalida (144)
A1: Esperar [ MS:0 Segundos:10 Minutos:0 Horas:0 Días:0 ]
A2: Decir [ Texto:Apagado Motor: Voz:default:default Stream:3 Tono:5 Velocidad:5 Respect Audio Focus:Encendido Continuar tarea inmediatamente:Apagado ]


Para ser exactos, lo que ocurre es lo siguiente: mientras está en ejecución la tarea de salida, aunque se restablezca el contexto... la tarea de entrada no se inicia, permanece "en cola" hasta que finalice la ejecución de la tarea de salida. Una vez que la tarea de salida ha finalizado, entonces se inicia la tarea de entrada, y eso ocurre aunque en ese momento el contexto ya no se cumpla. Todo lo cual me resulta muy sorprendente. Y claro, si la tarea de entrada se inicia cuando la tarea de salida ya ha finalizado, la acción DETENER TAREA DE SALIDA no funciona.

Puede que esto sea una característica de las nuevas versiones de Tasker (4+), porque creo recordar que con la versión 3 sí era posible que las tareas de entrada y salida se solapasen en el tiempo, y por lo tanto la tarea de entrada podía detener a la tarea de salida.

La experiencia de hoy tira por tierra algunas de mis creencias básicas en relación al tema de las tareas con demora. Dichas creencias estaban basadas en lo que dice el maestro Andreas Odegard, autor de la GUIA PARA PRINCIPIANTES DE TASKER, en su Lección 5: trucos y consejos (este documento fue escrito con la versión 3 de Tasker):

Let’s assume you want to create a profile that is active when connected to a WiFi network, but you want to make it so that the profile doesn’t deactivate until the device has been disconnected for 5 minutes without having reconnected in the mean while.

To do this, you want to make the actual trigger for the profile its own profile, with both an enter task and a named exit task. The enter task does a Set Variable %Wifiactive to 1, as well as a Stop action with the exit task’s name. The Exit task first does a Wait for 5 minutes, and then a Set Variable %Wifiactive to 0. You then create your original profile and use the Variable Value state context for %Wifiactive equals 1.

What this does is to make your original profile triggered indirectly, by a variable set by another profile. That other profile contains the original context, but it’s that profile’s tasks that control the other profile. That way you can use the standard Wait action to actually delay the deactivation of the main profile by 5 minutes. If the device reconnects in those 5 minutes, the enter task’s Stop action will stop the exit task, which is important to avoid the Exit task completing and disabling the other profile despite the reconnection.


El artículo original en inglés está aquí: http://www.pocketables.com/2012/09/beginners-guide-to-tasker-part-5-tips-tricks.html

También es posible que yo haya interpretado mal ese texto, pues mi nivel de inglés es muy poco solvente. Ahí va mi traducción, sobre la que agradeceré cualquier corrección o mejor traducción:

Supongamos que desea crear un perfil que se activa cuando se conecta a una red WiFi, pero quiere hacerlo de modo que el perfil no se desactiva hasta que el dispositivo se ha desconectado durante 5 minutos sin haber vuelto a conectar en ese tiempo.

Para ello, el verdadero desencadenante para el perfil debe ser otro perfil propio, ambos con sus respectivas tareas de entrada y salida. La tarea de entrada utiliza una acción Establecer-variable %Wifiactive a 1, y luego añade una acción Detener-tarea con el nombre de la tarea de salida. La tarea de salida primero usa la acción Esperar 5 minutos, y a continuación Establecer-variable %Wifiactive a 0. Tras eso ya puede crear su perfil original utilizanado el contexto de estado Valor-de-variable con la variable %Wifiactive igual a 1.

Así resulta que su perfil original está comandado por una variable del otro perfil. Ese otro perfil contiene el contexto original pero sus tareas controlan al primer perfil. De esa manera usted puede utilizar la acción Esperar para retrasar realmente la desactivación del perfil principal en 5 minutos. Si el dispositivo se vuelve a conectar durante esos 5 minutos, la tarea de entrada contiene una acción acción Detener-tarea que aborta la tarea de salida para evitar que se desactive el otro perfil.

Aunque este fragmento utiliza una acción DETENER-TAREA-DE-SALIDA (que hoy no funcionaría) Andreas también reconoce la necesidad de utilizar DOS perfiles para resolver este problema.

[darkopro]

Lo tengo desactivado pero probare lo que comentas del router a ver porque por lo que veo ¿no es normal que se corte no?

Yo tuve problemas de desconexiones y cambie la frecuencia y me fue de fabula. También podría ser por solapamiento de canales e incluso por el modo de ahorro de energía del móvil, no descartes nada. Por ponerte un ejemplo, tengo un programa para hacer deporte que me enciende el Bluetooth automáticamente y lo conecta al cinturón pectoral. En ese momento tengo una desconexión del WiFi y no sabría decirte si es fallo del programa o del móvil al conectar el Bluetooth.
En mi gimnasio por ejemplo, la red está formada por varios routers, hay uno que me tira de la red con la señal a tope y no hay manera de que me pueda conectar. Como no es mi red pues me toca aguantarme.
Al cambiar a 4.3 tuve problemas con lo del cambio de red automático, es una opción que venía nueva con la rom y venía activada y claro, cuando perdía un poco de señal me pasada al 3G, hasta que me metí en opciones y vi que habían puesto esa opción nueva...

Sobre el problema en cuestión, también puedes cambiar el perfil para que se active mediante la opción WiFi cercana o mediante pegatinas NFC para que encienda las luces, el agua, etc. Si por algo necesitas que el teléfono este conectado a la red WiFi puedes añadir en la tarea de entrada la opción: Esperar hasta WIFI ~ *CONNECT* de esta manera el perfil no estaría sujeto a las pérdidas de conexión. En «esperar hasta» el tiempo que ponemos es para que tasker compruebe que se da la condición (si ponemos 30 segundos cada 30 segundos hará la comprobación). Con algunas variables se da la condición en cuanto se cumplen, no realiza la espera ;)

También se me ocurre que hagas una doble comprobación en la tarea de salida:
Esperar 30 segundos
- Si (if) wifi !~ *CONNECT*
- Realizar tarea: apagar casa
- Fin si (end if)
Así esperaría 30 segundos y si sigue desconectado del WiFi realizaría la tarea de salida.

[Caravantes]

Lo que no me gusta nada es que queda por duplicado el perfil para hacer una cosa relativamente simple por unos puñeteros microcortes de vez en cuando.

La solución primera es la que has propuesto tú mismo: dos perfiles, ambos con el mismo contexto, uno con la tarea de entrada y el otro con la tarea de salida. Como ya has dicho, en esa situación la tarea de entrada sí puede interrumpir a la tarea de salida y todo funciona bien. Sería más "elegante y simple" que eso funcionara en un solo perfil, pero que haya dos perfiles tampoco es un gran inconveniente, yo diría que el problema es casi de carácter estético o conceptual.

De todas formas, quizá pueda resolverse con un solo perfil, del modo siguiente. La tarea de entrada no puede detener la tarea de salida, pero la tarea de salida sí puede detenerse a sí misma si se ha recuperado la conexión. La tarea de salida puede comprobar cada pocos segundos si hay conexión, y en tal caso se auto-aborta a sí misma antes de apagar todo.

Entrada:
Levantar todo el sistema

Salida:
Establecer variable %demora a 15*20, matemáticas sí (comprobaremos cada 15 segundos, 20 veces; 15*20=5 minutos)
InicioBucle
Esperar 15 segundos
Detener tarea si %WIFII ~ *CONNECT*
Establecer variable %demora a %demora-15
Ir a InicioBucle si %demora>0
Apagar todo el sistema
Apagar wifi

¿Vosotros tambien teneis de vez en cuando cortes de esos?

Creo que no, pero piensa que para la mayoría de nosotros el microcorte seguramente pasaría desapercibido o tendría unas consecuencias menos evidentes y por eso puede incluso que no nos percatemos de ello. De todas formas, en este tipo de perfiles yo no uso el contexto de CONECTADO A WIFI sino el de WIFI CERCANA, y tal vez este contexto sea menos inmediato, menos sensible a los microcortes.

[rabeliyo]

Pues voy a probar las opciones que me habeis propuesto, el NFC tambien me parece una opcion muy buena, pero ya sabeis, la gente cuanto menos tenga que hacer mejor jajaja.

Aparte voy a cambiarle el canal del router y probar con wifi cercana, es muy raro porque pasa incluso en la misma habitacion del router.

Os voy comentando a ver que tal, que esta tarde me pondre con ello

Muchas gracias a todos!!!!! como siempre

EDITO: Los dos metodos que proponeis, el del bucle y el de detener tarea con la condicion en la propia salida funcionan perfectamente :ok:

[JulioVillamizar]

Hola estuve buscando por Internet y encontré la solución la comparto con todos ustedes. me dicen si le funciono.

Como poder Detener una tarea de salida en una tarea de entrada y viceversa Detener una tarea de entrada en una tarea de salida:

Solo tiene que entrar en la propiedades del perfil y desactivar la opcion Fuerza Orden Tareas

Y listo con eso les debe funcionar.

[Caravantes]

.
[Nota: este tema también está tratado en otro hilo, de forma casi idéntica: http://www.htcmania.com/showthread.php?p=14151444#post14151444 ]

Como poder Detener una tarea de salida en una tarea de entrada y viceversa Detener una tarea de entrada en una tarea de salida: Solo tiene que entrar en la propiedades del perfil y desactivar la opcion Fuerza Orden Tareas

Genial, muchísimas gracias. Era un tema con el que estabamos bloqueados desde hace meses y por fin lo has resuelto.

Acabo de construir un pequeño perfil para comprobarlo.

Contexto de estado-orientación Plantado
Tarea de entrada llamada "PruebasPlantado"
- Detener tarea (de salida) "PruebasPlantadoNo"
- Decir "Plantado uno"
- Esperar 6 segundos
- Decir "Plantado dos"
Tarea de salida llamada "PruebasPlantadoNo"
- Detener tarea (de entrada) "PruebasPlantado"
- Decir "Plantado NO uno"
- Esperar 6 segundos
- Decir "Plantado NO dos"

Efectivamente funciona como has dicho: Si desactivo la casilla Fuerza Orden Tareas (en las propiedades de un perfil de estado), en la tarea de entrada ya funciona la acción DETENER "tarea de salida" y en la tarea de salida ya funciona la acción DETENER "tarea de entrada". Con esa casilla marcada (opción por defecto) las acciones de tipo DETENER-la-tarea-contraria no tenían efecto alguno.

Hay algo más, relativo al órden en que se ejecutan las tareas y sus acciones. He quitado las acciones DETENER TAREA para observar lo que ocurre con las tareas si no se producen esas interrupciones.

Teniendo activada la opción Fuerza Orden Tareas ocurre lo siguiente:
Al activarse el contexto se inicia la tarea de entrada y dicha tarea se continúa normalmente hasta su finalización. Si el contexto deja de cumplirse mientras se ejecuta la tarea de entrada, esa tarea continuará ejecutándose hasta terminar; entretando, la tarea de salida habrá sido puesta en cola para ejecutarse cuando termine la tarea de entrada. Igualmente, si se está ejecutando la tarea de salida y de nuevo el contexto vuelve a activarse, la tarea de entrada vuelve a ponerse en cola, y así sucesivamente... pero con un límite: Por las pruebas que he hecho, si el contexto cambia dos veces, la tarea que se está ejecutando no vuelve a ponerse en cola tras la tarea contraria, solo puede haber una tarea ejecutándose y la opuesta en espera, la cola no admite más tareas pendientes de ejecución. Esto explica por qué no funciona la acción de tipo DETENER-la-tarea-contraria: la explicación es que nunca se ejecutaban ambas tareas al mismo tiempo; cuando le llega el turno a esa acción la tarea contraria no se está ejecutando, y por tanto no hay nada que detener.

Ahora bien, si desactivamos la casilla Fuerza Orden Tareas , ocurrirá lo siguiente:
Al activarse el contexto se inicia la tarea de entrada y dicha tarea se continúa normalmente hasta su finalización. Si el contexto deja de cumplirse mientras se ejecuta la tarea de entrada, la tarea de salida no se pone en cola sino que también comienza a ejecutarse aunque no haya finalizado la tarea de entrada: ambas tareas se ejecutan por turnos: una acción de cada una. Del mismo modo, si la tarea de salida está en ejecución y se reactiva el contexto ocurrirá que la tarea de entrada comenzará a ejecutarse (en paralelo) aunque la tarea de salida no haya finalizado. Esta ejecución en paralelo es la que posibilita que una acción de tipo DETENER-la-tarea-contraria pueda funcionar.

Más información (en inglés: Enforce Task Order) en el siguiente hilo: https://groups.google.com/forum/#!topic/tasker/qInYbV1L2Jo

Julio, nuevamente gracias por ayudarnos con este importante tema.