Google Cloud IoT Core


En post anteriores hemos visto la potencia de Microsft Azure en torno al Universo del Edge Iot Computing  mostrando de una forma clara como es posible con una Raspeberry Pi 3 o un ESP8266   empezar a utilizar con muy buenos resultados dicha plataforma, pues bien como no podía ser de otra forma Google también ha desarrollado su propia plataforma denominada Google Cloud Iot Core

 

Cloud IoT Core es un servicio completamente administrado que le permite conectar, administrar e ingerir datos de manera fácil y segura desde millones de dispositivos dispersos a nivel mundial. Cloud IoT Core, en combinación con otros servicios en la plataforma Google Cloud IoT, proporciona una solución completa para recopilar, procesar, analizar y visualizar datos de IoT en tiempo real para admitir una mejor eficiencia operativa.

loud IoT Core, que utiliza Cloud Pub / Sub debajo, puede agregar datos de dispositivos dispersos en un solo sistema global que se integra perfectamente con los servicios de análisis de datos de Google Cloud. Por ejemplo puede usarse el  flujo de datos de IoT para análisis avanzados, visualizaciones, aprendizaje automático y más para ayudarlo a mejorar la eficiencia operativa, anticipar problemas y crear modelos completos que describan y optimicen mejor su negocio.

Cloud IoT Core es compatible con los protocolos estándar MQTT y HTTP, por lo que se pueden usar dispositivos existentes con mínimos cambios de firmware.Asimismo Google Cloud IoT Core se ejecuta en la infraestructura sin servidores de Google, que se amplía automáticamente en respuesta a los cambios en tiempo real y se adhiere a los estrictos protocolos de seguridad estándar de la industria que protegen los datos de su empresa

 

En este post  veremos  Google Cloud Platform Console para crear un registro de dispositivos Cloud IoT Core y registrar un dispositivo. También veremos  cómo conectar un dispositivo y publicar eventos de telemetría del dispositivo.

Como siempre antes de empezar se requiere cumplir ciertos requisitos:

  • Inicie sesión en su cuenta de Google. (si aún no tiene uno, regístrese para obtener una cuenta nueva) .
  • En la consola de GCP, vaya a la página Administrar recursos y seleccione o cree un nuevo proyecto.Vaya a la página Administrar recursos
  • Asegúrese de que la facturación esté habilitada para su proyecto.Desde aqui se puede  habilitar la facturación
  • Habilite las API Cloud IoT Core y Cloud Pub / Sub.Habilita las API

Configure Google Cloud SDK y gcloud

  1. Instale Google Cloud SDK . Cloud IoT Core requiere la versión 173.0.0 o superior del SDK.
  2. Ejecute el siguiente comando para actualizar la CLI de gcloud que se incluye en el SDK:
    gcloud components update
    

    Si está utilizando una máquina virtual de Compute Engine con la instalación predeterminada de gcloud, no podrá actualizar los componentes. Para habilitar Cloud IoT Core en una máquina virtual de Compute Engine, reinstale gcloud ejecutando los siguientes comandos:

    sudo apt-get remove google-cloud-sdk
        curl https://sdk.cloud.google.com | bash
        exec -l $SHELL
        gcloud init
    

Para obtener más detalles, consulte la documentación de referencia de los comandos de gcloud iot .

Introducción al Cloud IoT Core

Registro del dispositivo

Para que un dispositivo se conecte, primero debe registrarse con Cloud IoT Core. El registro consiste en agregar un dispositivo a una colección (el registro) y definir algunas propiedades esenciales. Puede registrar un dispositivo con Cloud Platform Console, comandos gcloud o la API REST-style.  En conjunto, las funciones que le permiten registrar, monitorear y configurar dispositivos se llaman administrador de dispositivos.

Protocolos (MQTT y HTTP)

Cloud IoT Core admite dos protocolos para la conexión y comunicación del dispositivo: MQTT y HTTP. Los dispositivos se comunican con Cloud IoT Core a través de un «puente», ya sea el puente MQTT o el puente HTTP. Cuando crea un registro de dispositivo, selecciona protocolos para habilitar: MQTT, HTTP o ambos.

MQTT es un protocolo de publicación / suscripción estándar que los dispositivos integrados usan y soportan con frecuencia, y también es común en las interacciones máquina a máquina.

HTTP es un protocolo «sin conexión»: con el puente HTTP, los dispositivos no mantienen una conexión con el Núcleo Cloud IoT. En cambio, envían solicitudes y reciben respuestas.

Autenticación de dispositivo

Cloud IoT Core utiliza autenticación de clave pública (o asimétrica):

  • El dispositivo usa una clave privada para firmar un JSON Web Token (JWT) . El token se pasa al Cloud IoT Core como prueba de la identidad del dispositivo.
  • El servicio utiliza la clave pública del dispositivo (cargada antes de que se envíe el JWT) para verificar la identidad del dispositivo.

Control del dispositivo desde la nube

Con Cloud IoT Core, puede controlar un dispositivo modificando su configuración. Una configuración de dispositivo es una acumulación arbitraria de datos definidos por el usuario que pueden estructurarse o no. Si sus dispositivos usan MQTT, las configuraciones se propagan automáticamente a ellos. Si sus dispositivos se conectan a través de HTTP, deben solicitar configuraciones explícitamente.

Configurando dispositivos

Con Cloud IoT Core, puede controlar un dispositivo modificando su configuración. La configuración de un dispositivo es una burbuja de datos arbitraria y definida por el usuario. Después de que se haya aplicado una configuración a un dispositivo, el dispositivo puede informar su estado a Cloud IoT Core.

La configuración del dispositivo funciona de manera diferente en los puentes MQTT y HTTP. Ver abajo para más detalles.

Límites

Las actualizaciones de configuración están limitadas a 1 actualización por segundo, por dispositivo. Sin embargo, para obtener los mejores resultados, la configuración del dispositivo debe actualizarse con mucha menos frecuencia, como máximo, una vez cada 10 segundos.

La tasa de actualización se calcula como el tiempo entre el acuse de recibo más reciente del servidor y la próxima solicitud de actualización.

Diferencias de protocolo

MQTT

Los dispositivos que usan MQTT pueden suscribirse a un tema especial de MQTT para actualizaciones de configuración:

 / devices / {device-id} / config

Cuando un dispositivo se suscribe al tema de configuración, el puente MQTT responde con un mensaje SUBACK MQTT, que contiene la QoS concedida para el tema de configuración (0 o 1) o 128 si se produce un error.

Después de suscribirse inicialmente, el dispositivo recibe la configuración más reciente en la carga útil de un mensaje y recibirá actualizaciones de configuración adicionales a medida que se envíen a Cloud IoT Core.

Las siguientes muestras ilustran cómo recuperar las actualizaciones de configuración en un dispositivo a través de MQTT usando Python:

def get_client(
project_id
, cloud_region, registry_id, device_id, private_key_file,
algorithm
, ca_certs, mqtt_bridge_hostname, mqtt_bridge_port):
«»»Create our MQTT client. The client_id is a unique string that identifies
this device. For Google Cloud IoT Core, it must be in the format below.»»»

client
= mqtt.Client(
client_id
=(‘projects/{}/locations/{}/registries/{}/devices/{}’
.format(
project_id
,
cloud_region
,
registry_id
,
device_id
)))

# With Google Cloud IoT Core, the username field is ignored, and the
# password field is used to transmit a JWT to authorize the device.
client
.username_pw_set(
username
=‘unused’,
password
=create_jwt(
project_id
, private_key_file, algorithm))

# Enable SSL/TLS support.
client
.tls_set(ca_certs=ca_certs, tls_version=ssl.PROTOCOL_TLSv1_2)

# Register message callbacks. https://eclipse.org/paho/clients/python/docs/
# describes additional callbacks that Paho supports. In this example, the
# callbacks just print to standard out.
client
.on_connect = on_connect
client
.on_publish = on_publish
client
.on_disconnect = on_disconnect
client
.on_message = on_message

# Connect to the Google MQTT bridge.
client
.connect(mqtt_bridge_hostname, mqtt_bridge_port)

    # This is the topic that the device will receive configuration updates on.
    mqtt_config_topic = ‘/devices/{}/config’.format(device_id)

    # Subscribe to the config topic.
    client.subscribe(mqtt_config_topic, qos=1)

return client

HTTP

Si está utilizando el puente HTTP , los dispositivos deben solicitar explícitamente nuevas configuraciones .

El  siguiente ejemplo en python ilustran cómo recuperar las actualizaciones de configuración en un dispositivo a través de HTTP:

def get_config(
version
, message_type, base_url, project_id, cloud_region, registry_id,
device_id
, jwt_token):
headers
= {
‘authorization’: ‘Bearer {}’.format(jwt_token),
‘content-type’: ‘application/json’,
‘cache-control’: ‘no-cache’
}

basepath = ‘{}/projects/{}/locations/{}/registries/{}/devices/{}/’
template
= basepath + ‘config?local_version={}’
config_url
= template.format(
base_url
, project_id, cloud_region, registry_id, device_id, version)

resp = requests.get(config_url, headers=headers)

if (resp.status_code != 200):
print(‘Error getting config: {}, retrying’.format(resp.status_code))
raise AssertionError(‘Not OK response: {}’.format(resp.status_code))

return resp

Actualización de la configuración del dispositivo

Puede actualizar la configuración del dispositivo utilizando Cloud Platform Console, Cloud IoT Core API o gcloud.

Por Consola

  1. Vaya a la página Registros del dispositivo en la Consola GCP.
  2. Haga clic en el ID del registro que contiene el dispositivo.
  3. En la página de detalles del registro , haga clic en el ID del dispositivo cuya configuración desea actualizar.
  4. En la parte superior de la página, haz clic en Actualizar config.
  5. Seleccione un formato para la configuración y pegue los datos en el cuadro Configuración .
  6. Haga clic en Enviar al dispositivo .

Usando gcloud

Para actualizar la configuración de un dispositivo, ejecute el gcloud iot devices configs update :

 gcloud iot dispositivos configs update \
   (--config-data = CONFIG_DATA | --config-file = CONFIG_FILE ) \
   --device = DEVICE_ID \
   --registry = REGISY_ID \
   --region = REGION \
   [--version-to-update = VERSION_TO_UPDATE ]

Los dispositivos se actualizarán de acuerdo con el protocolo que usan .

Usando Cloud iot Core API

Para actualizar la configuración del dispositivo a través de la API, use el método Device modifyCloudToDeviceConfig , especificando la nueva configuración en el campo config . También puede especificar una configuración al crear un dispositivo y luego usar modifyCloudToDeviceConfig para cambiarla más tarde.

El siguiente ejemplo en Pythoon  ilustran cómo actualizar la configuración de un dispositivo:

def set_config(
service_account_json
, project_id, cloud_region, registry_id, device_id,
version
, config):
print(‘Set device configuration’)
client
= get_client(service_account_json)
device_path
= ‘projects/{}/locations/{}/registries/{}/devices/{}’.format(
project_id
, cloud_region, registry_id, device_id)

config_body = {
‘versionToUpdate’: version,
‘binaryData’: base64.urlsafe_b64encode(
config
.encode(‘utf-8’)).decode(‘ascii’)
}

return client.projects(
).locations().registries(
).devices().modifyCloudToDeviceConfig(
name
=device_path, body=config_body).execute()

Revisando la configuración del dispositivo

Por ultimo  tambien uede revisar las últimas 10 versiones de la configuración de un dispositivo mediante Cloud Platform Console, la API o gcloud.

Consola

  1. Vaya a la página Registros del dispositivo en la Consola GCP.
  2. Haga clic en el ID del registro que contiene el dispositivo cuya configuración desea actualizar.
  3. En la página de detalles del registro , haga clic en el ID del dispositivo cuya configuración desea actualizar.
  4. Haga clic en Configuración e historial de estado.

Utilice las casillas de verificación para controlar si se muestra el historial de configuración o el historial de estado, o ambos. Haga clic en Comparar para ver si la configuración y el estado coinciden como espera.

gcloud

Para obtener configuraciones recientes, ejecute la gcloud iot devices configs list y describe comandos:

 Configuración de dispositivos de gcloud iot list DEVICE_ID \
   --registry = REGISY_ID \
   --region = REGION \
   [--filter = EXPRESIÓN ]
   [--limit = LIMIT ]
   [--sort-by = [ CAMPO , ...]]
 Las configuraciones de dispositivos gcloud iot describen DEVICE_ID \
   --registry = REGISY_ID \
   --region = REGION

Fuentes:   https://cloud.google.com/iot/docs/how-tos/getting-started y  https://cloud.google.com/iot/docs/how-tos/config/configuring-devices

Pasos para migrar aplicaciones en Google Cloud


Tras el aviso de Google a los usuarios de la plataforma de Google Cloud ,es decir  la  plataforma PaaS( Plataforma como Servicio ) conocida  como  GAE  (Google App Engine)    para que migren sus viejas  aplicaciones maestro/esclavo  construidas en  Python,Java PHP o  Go  hacia  el   nuevo entorno HRD que sustituirá definitivamente al veterano sistema basado en el almacén  de datos maestro/esclavo, vamos a ver como es realmente sencillo migrar nuestras aplicaciones para no perderlas definitivamente el plazo tope de este verano.

  

 

En  efecto,  el  veterano almacén de datos Maestro / Esclavo  que hemos usado desde que GAE se puso en servicio pronto se cerrará, para dar paso a la nueva plataforma  HRD.Como nota importante aunque las  aplicaciones desplegadas en GAE que no almacenen  datos en el almacén de datos  Master / Slave , todavía se configuran para utilizar el almacén de datos Master / Slave ,así que esta nueva directiva todavía les es de aplicación .

Tras el desmantelamiento de la infaestructura del almacen de datos master/slave, van a proporcionar un período de gracia de un mes durante el cual los usuarios pueden volver a habilitar sus aplicaciones con el fin de migrar a HRD. Esto significa que después de 10 de agosto 2015 estas aplicaciones dejarán de atender las solicitudes y que ya no tendrán acceso programático a los datos. Obviamente  si ya no necesitan las aplicaciones maestro / esclavo y datos asociados, no se requiere ninguna acción ( se borrarian ) pero si se necesitan  animan a que migremos a HRD inmediatamente.

Cuando el equipo de Google lanzó    el almacén de datos Google  App Engine, Master / Slave era el único servicio de base de datos que las aplicaciones podían utilizar para almacenar datos. Se daba la circunstancia de que el almacén de datos Master / Slave tenía problemas para escalar con el tamaño y era  complejo mantener  las aplicaciones que se ejecutaban en App Engine  usando ese sistemas , así que se lanzó su sucesor, el almacén de datos  de alta replicación (HRD), en 2011. Desde ese lanzamiento HRD ha demostrado  escalar sin problemas.

Uno de los objetivos principales con Google Cloud Platform era proporcionar a los clientes las mejores tecnologías para construir su negocio, así que cuando vieron que HRD era una tecnología más robusta, finalmente han decidido hacer HRD el servicio de base de datos por defecto.

El 4 de abril 2012 Google  anunció  la desaprobación de almacén de datos del maestro / esclavo – , lo cual  ya era una señal de que en tres años a partir de esa fecha se cerraría formalmente el servicio.

Como ya han pasado  tres años desde que se anunció, van a  forzar el apagado de todo lo que  este en esa vieja infraestructura  del almacén de dato Master / Slave . De hecho,  si los usuarios  no tomasen ninguna acción en las  aplicaciones que esten desplegadas  en Master/Slave ,  las cerrarán el 6 de julio, 2015 y ya no garantizarán el tráfico de éstas (los usuarios verán respuestas HTTP 404 ).

 

Una nota importante: Es necesario seguir los pasos anteriores, incluso si la aplicación no almacena ningún dato, ya que tambien la  aplicación está configurada para utilizar el  almacén de datos maestro / esclavo.  Por ejemplo, incluso si se trata de una página web HTML estática. Cuando cierren el almacén de datos maestro / esclavo  de estas aplicaciones también cerraran  las que  no se migren.

 

Para asegurarse de que estas viejas aplicaciones que usen el almacén de dato Master / Slave sigan funcionando, los usuarios  tendrán que seguir estos pasos para cada aplicación:

 

1-Validarnos con nuestra cuenta de google

2-Iniciar sesión en la consola de administración del motor App   accediendo a la siguiente  url : https://appengine.google.com/

 

migracion0

3-Acceder  ahora   a  las aplicaciones que están bajo el esquema de almacenamiento  Master/Slave  pinchando sobre el link Migrate to High Replication

migracion1

 

4-Tras un proceso largo que dependerá del volumen de código de la aplicación, se  irán completando  las 8 fases  que constituyen el proceso (cath up, Copy,Waiting,Sync,Read-only,Catch up ,Sync,Copy)

 

5-Espere que  las  8 fases  que constituyen el proceso (cath up, Copy,Waiting,Sync,Read-only,Catch up ,Sync,Copy) estén concluidas  (la columna de Status pasara desde Waiting a Done).

Observaciones:

-En la fase Waiting habrá que confirmar  la activación   read-only bien seleccionando la copia incremental  o bien activado la activación de solo Lectura

migracion2

 

-En la ultima fase  Alias  tendremos que confirmar la creación del Alias

hrd migration

6-Observe que durante  el proceso hasta la ultima fase si  no ha ido satisfactorio o cambia de parecer , tiene la posibilidad de revertir el  proceso pulsando el botón   «Revert Migration«, pero una vez concluya el proceso  ya no podrá volver «marcha atrás»

 

migration-finish