Tag: Windows

Neurtura – O cómo sobrevivir en el mundo de la Monitorización Industrial

Ha costado que llegue el segundo invitado a Mascando Bits, pero nunca es tarde si la dicha es buena, y en este caso lo es. Hoy Xabier, compañero de fatigas en el trabajo, nos trae una retrospectiva con aplicación práctica de ingeniería de hardware y software al estilo open source que tanto ha marcado los inicios de Ingran Engineering, empresa de la que me siento orgulloso de pertenecer. Xabier ha sido y será siempre un MacGyver de la electrónica y la mecánica. Esperemos que esta sea la primera de otras muchas entradas.


Actualmente vivimos en un mundo complicado, luchando entre el software y hardware abierto y sistemas propietarios. En la confrontación entre la solución basada en ArduinoESP8266 de 5€ y el Siemens S7 de 500€. En el dilema de dar servicio a un precio adecuado y cumplir las directivas y el marcaje CE. Puede que aquí encontréis algo intermedio, o no. Pero por lo menos, fue nuestra solución durante un tiempo.

 

Introducción

La verdad que empecé a escribir esta entrada hace bastante tiempo, puede que hace más de uno año. Pero por fin lo he completado. A falta de que todavía monte un blog, quisiera agradecer a Rubén que me deje espacio en su blog para publicar.

Este va a ser la primera de varias entradas, comentando la funcionalidad de un sistema que en su día desarrollamos en Ingran Engineering, que actualmente ha quedado en desuso, al migrar a sistemas de adquisición de datos basados en Modbus-TCP, y también porque el módulo central del sistema, el Industruino que usamos en sus primeras versiones, nos dio bastantes problemas para los niveles de calidad y servicio que buscábamos. No obstante el fabricante ha sacado una revisión del Industruino que soluciona los problemas del primero y que además añade nuevas capacidades al dispositivo.

El las siguientes fotos os muestro la versión básica del Neurtura (nombre comercial del dispositivo de monitorización), en la primera podéis ver el aspecto exterior con los conectores:

 

En esta podéis ver los componentes internos:

Podéis observar de izquierda a derecha: Un magnetotérmico, un analizador de energía eléctrica, el Industruino D21G IND I/O (la versión más reciente) con su módulo ethernet al lado, una fuente de alimentación de 24 Voltios y un router Teltonika RUT230.

El la parte exterior tenemos conectores Harting, para la alimentación, para la conexión de las pinzas amperimétricas, para el analizador de energía, y para las conexiones de los sensores, actuadores y Modbus-485.

Si alguien no tiene demasiadas ganas de leer, que vaya al final, al apartado “Compilando“.

 

Contexto

¿Cómo narices se puede monitorizar un proceso industrial, en este caso concreto, una bomba de agua para regadío, de manera efectiva, eficaz y barata? Esa pregunta nos la hicimos en Ingran Engineering hace bastante tiempo, con la certeza de que tenía que haber una solución que tuviese las tres Bs (Bueno, Bonito y Barato). Esto era lo que necesitábamos:

  • Medida de parámetros eléctricos de una bomba: Potencia, Voltaje, Factor de Potencia…
  • Medidas de parámetros del acuífero: Conductividad eléctrica (salinidad), Nivel del agua bajo tierra…
  • Medida de parámetros del agua extraída: Caudal, Presión…
  • Registro de datos cada 10 segundos, y mostrarlos vía Web y en el móvil

Además, por si no fuera poco, teníamos las siguientes restricciones:

  • Necesidad de utilizar GSM/GPRS/3G para la comunicación.
  • Necesitaba tener marcaje CE y cumplirlo.
  • Tenía que ser compatible con lo que había ya montado: diversos tipos de caudalímtros/contadores, medidores de nivel de acuífero…

Aqualogy tenía una solución llamada IdroSmartWell que hacía todo eso, y más, a un precio que casi nos dio un infarto al escucharlo. La solución de software vino de la mano del proyecto EmonCMS de Open Energy Monitor y la de hardware tuvimos que apañárnosla.

 

Especificaciones técnicas

Las especificaciones técnicas de Neurtura que habéis visto en las fotos anteriores son las siguientes:

  • Analizador de energía eléctrica trifásica: Conexión a pinzas amperimétricas externas de 5A o 1A. Medida de V, I, P, PF, THD y más cosas…
  • 4 Entradas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 18 bits.
  • 2 Salidas analógicas de 0-20mA o 0-10 Voltios: Resolución máxima de 12 bits.
  • 8 Entradas/Salidas digitales: Opción de usarlas como contadores de pulsos.
  • Conexión de Modbus-485 para conectar mas dispositivos.
  • Opción de postear (enviar) a EmonCMS directamente.
  • Guardado de datos en la SD local.
  • Guardado de parámetros de configuración en la EEPROM.
  • Guardado de datos de contadores y demás datos cambiantes en la FRAM propia.
  • RTC local.
  • Actualización del firmware remota: Utilizando el RUT230.

 

Compilando y cargando el firmware

El Industruino se programa utilizando el IDE de Arduino por USB, aunque también se puede programar por Ethernet utilizando TFTP, cosa que ya comentaré explicaré mas adelante en otra entrada.

En la Organización de Ingran Engineering de Github podéis encontrar el firmware y las librerías necesarias:

Para compilarlo y subirlo al Industruino, seguid estos pasos:

  1. Decargar el IDE portable de Arduino, versión 1.8.5
  2. Extraer arduino-1.8.5-windows.zip
  3. Dentro de la carpeta de arduino-1.8.5 crear una carpeta llamada “portable
  4. Abrir el programa arduino.exe
  5. Instalar la placa del industruino -> clicando Tools -> Boards Manager y buscando “industruino” -> Insalar “Industruino SAMD Boards 1.01
  6. Cerrar el entorno de programación de Arduino
  7. Descargar el proyecto Ikusi-Makusi de GitHub y extraerlo en donde se quiera
  8. Descargar el proyecto Ikusi-Makusi-libraries de GitHub y copiar las librerías en la carpeta arduino-1.8.5\libraries
  9. Abrir el programa arduino.exe de nuevo, en Herramienta->Placa seleccionar Industruino D21G y en Herramientas->Puerto el puerto de series correspondiente.
  10. Abrir el archivo Industruino_ethernet.ino del proyecto Ikusi-Makusi con el IDE de Arduino.
  11. Compilarlo y subirlo al Industruino.
  12. Conectad el Industruino a una red con DHCP y encenderlo.
  13. Con los botones navegar hasta la pantalla RED y mirad la IP asignada.
  14. Meter la IP en cualquier navegador web y empezar a experimentar.

Continuará…

 

Problemas de acceso a una IP o dominio público desde una red LAN

En ocasiones más de uno se habrá encontrado con el problema de que tiene una dirección IP pública (fija o dinámica) o un dominio público (mediante DNS fijo o dinámico) que apunta al router que tenemos dispuesto, permitiendo acceder a un servicio de una máquina que corre en nuestra red de área local (LAN) desde fuera de ella, pero desde la red local es imposible acceder con dicha dirección o dominio. Si alguna vez te ha pasado esto, te explico las causas y las posible soluciones.

La causa de este comportamiento está sujeta habitualmente a medidas de seguridad que evitan las conexiones loopback como característica de seguridad. La dirección lookback es una dirección especial que los host utilizan para dirigir el tráfico hacia ellos mismos. Esta característica suele ser una extensión de la NAT llamada NAT loopback.

NAT loopback es una extensión de NAT que te permite acceder a tu dirección pública de Internet (WAN) desde dentro de tu propia red (LAN). Esto es práctico cuando tenemos algún servidor dentro de nuestra propia red, ya que nos permite acceder a ese servidor usando la misma IP pública (y por lo tanto también dominio) tanto desde dentro de la LAN, como desde el exterior.

Esta característica desgraciadamente no está presente en la mayoría de los routers que nos proporcionan nuestros proveedores de Internet. Con lo cual lo único que puedes hacer es comprobar si es posible activar esta característica en la zona de administración del router o contactando a tu proveedor de acceso a Internet para que te lo solucione.

La ausencia de esta característica provoca que por ejemplo si te haces con un NAS, dispositivos de almacenamiento en la red que últimamente están teniendo una gran aceptación, no se pueda acceder desde el dominio a tu NAS si estás en la misma red local que el NAS. Es decir, terminas usando la IP local de la LAN (ejemplo: 192.168.1.177) cuando estás en la misma red y el dominio (mi_nas.com) para acceder desde fuera de la red LAN. Dos formas de acceder que vuelven complicado configurar aplicaciones, como por ejemplo un cliente de sincronización del estilo Dropbox, debido a que no tienes una única forma de acceder al NAS, la cual debería ser el dominio.

Si el equipo con el que accedes al NAS, es de sobremesa aún puedes solucionarlo editando el archivo “hosts” del sistema, pero en caso contrario tendrás que o bien cambiar el router o funcionar con IP local y dominio dependiendo si estás dentro o fuera de la red local del NAS.

Paso a explicar como solucionar la resolución de dominio tanto para Windows como para GNU/Linux mediante la edición del archivo “hosts” de tu ordenador.

 

Windows


  1. Abrir un editor de texto en “modo administrador
  2. Abrir el fichero ubicado en la siguiente ruta C:\Windows\System32\Drivers\etc\hosts
  3. Añadir el host mediante la adición de una línea al final del fichero. Usando el ejemplo anterior del NAS sería:
    192.168.1.177 mi_nas.com
  4. Guardar y a partir de ahora mi_nas.com resolverá directamente como 192.168.1.177

 

GNU/Linux


  1. Abrir un terminar y poner el siguiente comando en el terminal
    sudo nano /etc/hosts
  2. Añadir el host mediante la adición de una línea al final del fichero. Usando el ejemplo anterior del NAS sería:
    192.168.1.177 mi_nas.com
  3. Guardar y a partir de ahora mi_nas.com resolverá directamente como 192.168.1.177

 

Espero que este artículo sirva para arrojar un poco de luz en toda esta problemática.

Solucionar error “failed to create process” en herramientas instaladas de Python

Hoy me encontraba revisando dependencias de las herramientas, librerías y frameworks que tenía en Python y me he encontrado con la herramienta pipdeptree, una herramienta que nos permite enumerar las herramientas, librerías y frameworks al estilo del comando “pip freeze” pero mostrando además cada una de las dependencias que tiene con otras librerías.

Como suele ser la costumbre realicé las instalación con el clásico:

pip install pipdeptree

La instalación resultó satisfactoria pero al ejecutar la herramienta devuelve un error:

$ pipdeptree

failed to create process.

El error “failed to create process” se produce por un problema de la ruta en el script de ejecución. Concretamente por culpa de espacios en la ruta donde tenemos instalados Python y donde se instalan los paquetes mediante el comando “pip“. Si eres de los que tiene instalado Python en “Archivos de Programa” o “Program File”, vas a tener este problema si además estás usando una versión de “setuptools” anterior a la versión 24.3.1 del 23 de Julio del 2016.

Para ver la versión de “setuptools” que estás usando actualmente ejecuta el siguiente comando:

easy_install --version

Si tienes una versión anterior y no quieres actualizar, puedes corregir el error si vas a la carpeta “Scripts” dentro de tu instalación de Python y buscas el archivo “pipdeptree-script.py” que es el que ejecuta la herramienta gracias al binario “pipdeptree.exe” que lo invoca:

#!d:\program files (x86)\python35-32\python.exe
# EASY-INSTALL-ENTRY-SCRIPT: 'pipdeptree==0.10.1','console_scripts','pipdeptree'
__requires__ = 'pipdeptree==0.10.1'
import re
import sys
from pkg_resources import load_entry_point

if __name__ == '__main__':
    sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0])
    sys.exit(
        load_entry_point('pipdeptree==0.10.1', 'console_scripts', 'pipdeptree')()
    )

Para corregir el problema basta con añadir unas comillas a la ruta de la primera línea:

#!"d:\program files (x86)\python35-32\python.exe"

Si no tienes inconveniente alguno en actualizar “setuptools”, basta con que ejecutes el comando de actualización estándar de “pip“:

pip install --upgrade setuptools

Obviamente la segunda solución es la más recomendable, pero la explicación de la primera puede servir para solucionar errores similares en otras herramientas si se presentan, y si la actualización no funciona o no es una opción.

Solucionar problema de Autoridad de Certificación en los binarios .EXE generados con PY2EXE

Últimamente he empezado a utilizar la herramienta py2exe para poder mejorar la distribución de mis desarrollos en Python en sistemas Windows, mediante la generación de un ejecutable .exe autocontenido que evite tener que pedir al usuario que instale Python y las correspondientes librerías.

La herramienta py2exe puede ser instalada de manera sencilla con el comando:

pip install py2exe

Y puedes compilar rápidamente cualquier programa en Python realizando un fichero setup.py simple como este:

from distutils.core import setup
import py2exe

setup(console=['mi_programa.py'])

El cual deberemos ejecutar desde una consola de comandos de la siguiente forma:

python setup.py install

Al ejecutarlo nos resolverá todas las dependencias y dejará la versión autcontenida con el ejecutable mi_programa.exe en la carpeta dist.

Si trabajas con servicios o mínimamente con conexiones seguras haciendo peticiones, seguro que acabas usando la librería requests o puede que la librería con la que trabajes, la use como base para hacer conexiones seguras con SSL. Si intentas usar estas librerías que trabajan con certificados SSL te encontrarás con el siguiente error cuando ejecutas tu binario .exe:

requests.exceptions.SSLError: [Errno 2] No such file or directory

El cual viene dado porque cuando se empaqueta todo, el certificado de la Autoridad de Certificación no se incluye al ser un fichero que no es de Python. A causa de esto, cuando se empaquetan todas la librerías y se llama de manera relativa al certificado de la librería desde nuestro empaquetado con nuestro binario .exe de py2exe, éste no se encuentra porque ninguna parte.

Para solucionarlo es tan sencillo como proporcionar un certificado válido del tipo cacert.pem en la variable de entorno de Python REQUESTS_CA_BUNDLE de nuestro programa. Pero para resolverlo, vamos a hacerlo de manera elegante parcheando dicha variable sólo si es necesario, para poder seguir tirando de los certificados de las propias librería mientras desarrollamos.

Para ello vamos a instalar certifi, una librería que nos facilita una serie de Certificados Raíz que nos van a permitir validar la integridad de certificados, tanto de SSL, como de TSL de los servicios a los que nos conectemos.

pip install py2exe

Ahora vamos a modificar un poco nuestro setup.py:

from distutils.core import setup
import py2exe
import certifi

setup(console=['mi_programa.py'], data_files=[certifi.where()])

Hemos añadido únicamente el import de certifi y en los parámetros de setup hemos añadido el fichero de certificado que nos devuelve certifi gracias al método where. Este fichero se copiará en dist al mismo nivel que nuestro .exe.

Por último añadiremos en mi_programa.py al inicio de nuestro programa el siguiente código:

cacert_path = os.path.join(os.getcwd(), 'cacert.pem')
if os.path.exists(cacert_path):
    os.environ['REQUESTS_CA_BUNDLE'] = cacert_path

El código genera la ruta hasta certificado cacert.pem, usando el directorio de trabajo que será dist. Esa ruta se busca si existe entre las rutas que maneja Python para resolver las librerías y dependencias. Si se ejecuta desde el entorno de desarrollo, encontrará el de la propia librería que lo este usando, sino parcheará añadirá la ruta para que coja certificado que hemos copiado en dist.

De esta forma no sólo se soluciona el problema del certificado de la Autoridad de Certificación, sino que el parche se aplica selectivamente copiando fichero de certificado necesario. Esto es importante porque los certificados pueden cambiar y basta con volver a generar los binarios .exe con py2exe, teniendo las librerías actualizadas y con los certificados en regla, para que el ejecutable creado también los tenga.