Presentación del proyecto

Soy José Olmos, un aficionado a la programación que en sus ratos libres se dedica a desarrollar aplicaciones sobretodo en java.

 Tengo otro blog dedicado al proyecto ProyectGR en http://proyectgr.blogspot.com.es/. En ProyectGR se busca el análisis gramatical del lenguaje castellano. Conseguí crear un motor robusto de autómatas dinámico que era capaz de introducir y generar expresiones regulares en tiempo real y a reconocer sus tokens y funciones.

Según fue creciendo el programa, me vi en la necesidad de repartir el trabajo y memoria entre varias máquinas. Empecé a descomponer la aplicación que llevaba hasta entonces, en distintos módulos independientes para convertirlos posteriormente en servicios y clientes especializados. Ello me llevó a utilizar la tecnología de RMI para la programación distribuida.

Por otra parte, en mi entorno, me vi en la necesidad de intentar desarrollar una aplicación de seguridad. En principio muy sencilla: dada una cámara web normal y corriente, enviar un vídeo al usuario en el caso de que detectase movimiento.

Realicé un primer lanzamiento. Para la grabación del vídeo y la detección del movimiento, no tenía que hacer prácticamente nada, la aplicación motion sobre linux ya lo hace todo. Por lo tanto, mi aplicación lanzaría un hilo que controlase a motion para parar, iniciar, reiniciar o cambiar la configuración por un lado, y otro para comprobar que en una ruta determinada hubiera algún vídeo que motion generó al detectar el movimiento.

Para enviar el vídeo me compliqué la vida con la api de whatsapp, digo compliqué porque por un lado estaba el problema de que hace falta un número de teléfono con su registro correspondiente, para poderlo usar. Una vez solucionado esto (nada trivial) me puse a trabajar con la api y esta se desconectaba continuamente del servidor de whatsapp, con lo que programé un hilo exclusivamente para estar atento y reconectar si fuera necesario.

Con el whatsapp no sólo envío información al usuario, sino que este puede interactuar con el programa. Ahora el usuario puede ejecutar comandos sobre la aplicación como la de reiniciar el motion, saber la temperatura del aparato, apagado e incluso comandos de linux directamente.

Usando el autómata del proyecto ProyectGR conseguí que esta aplicación pudiese interpretar expresiones regulares para que el usuario pudiese trabajar con la aplicación, por ejemplo: motion rate 30, reconoce sus tokens actúa en consecuencia.

Llegó a funcionar perfectamente en el portátil sobre Fedora, pero al pasarlo a Pidora para la Raspberry Pi, todo se fue al garete. Problemas con motion, con la wifi, con el sensor de la temperatura y cómo, con whatsapp.

Desistí después de muchos intentos de Pidora y pasé a la versión de Debian para Raspberry Pi y llegó a medio funcionar (faltó reconfigurar motion).

Por los exámenes tuve que parar y cuando retomé el proyecto, para mi sorpresa, la api de whatsapp ya no fucionaba. Los mensajes de error me decían versión obsoleta y por más que intenté actualizar, no conseguí que volviera a funcionar.

Se me ocurrió entonces usar otro medio de comunicación, Telegram y sus bots. Aún no lo he hecho, pero en principio no hace falta número de teléfono y tiene ciertas limitaciones, pero para mi proyecto creo que me es suficiente.

Viéndome en la necesidad de reprogramar gran parte de la aplicación decidí comenzar de cero pero esta vez usando lo aprendido de RMI.

Mi idea es hacer un sistema de seguridad distribuido sin la necesidad de ningún servidor central o grabador. Normalmente las cámaras están conectadas a un grabador. A parte de que son carísimos, ¿qué ocurre si el grabador cae? se pierden todas las cámaras y vídeos.

Lo que pretendo es que la información se distribuya entre todos los computadores conectados (Raspberry Pi) de forma que cada computador tenga conectada una o dos cámaras a lo sumo, un detector infrarrojo por ejemplo, etc. Si un computador se pierde sólo se perdería la visión de sus cámaras pero el resto del sistema estaría funcionando y sus grabaciones serian accesibles ya que estarían distribuidas (a trocitos) entre el resto de los componentes.

Un computador tendría el servicio de Telegram lanzado para interactuar con el usuario, donde el resto de los computadores enviarían sus vídeos. Si el computador que tiene el Telegram cae, otro computador asumirá el papel y lo lanzará él, comunicándolo al resto para que ahora se les envíen los vídeos a éste.

En los siguientes post se irá comentando el desarrollo de cada servicio distribuido y viendo el progreso general.