Интеграция Google Cloud IoT в мобильное IoT-приложение
Google Cloud IoT Core был официально выведен из эксплуатации 16 августа 2023 года. Если вы пришли сюда с вопросом «как интегрировать GCP IoT Core» — важно знать это прямо сейчас. Проекты, которые на него полагались, должны были мигрировать на альтернативы.
Что вместо Google Cloud IoT Core
Google рекомендует несколько путей миграции:
1. MQTT-мост через Cloud Pub/Sub напрямую. Устройства публикуют в Cloud Pub/Sub через собственный MQTT-брокер (например, HiveMQ, EMQX или Mosquitto), а не через управляемый GCP IoT Core. Мобильное приложение подписывается на Pub/Sub топики через gRPC API.
2. Партнёрские платформы. Google официально отсылает к Clearblade IoT Core и Cognite, которые предлагают совместимый API. Миграция с Cloud IoT Core на Clearblade — минимальные изменения в клиентском коде.
3. Переход на другой облачный IoT-провайдер — AWS IoT Core или Azure IoT Hub, если привязки к GCP нет.
Мы чаще всего рекомендуем связку Cloud Pub/Sub + собственный MQTT-брокер для клиентов, которые хотят остаться в GCP-экосистеме.
Архитектура мобильного приложения на базе GCP
Для мобильного клиента прямое подключение к Cloud Pub/Sub через gRPC требует Google Cloud credentials. Встраивать Service Account key в приложение — нельзя. Используем Firebase Authentication + Cloud Firestore/Realtime Database как transport-слой для IoT-состояний.
Схема работает так: IoT-устройства публикуют телеметрию → MQTT-брокер → Cloud Pub/Sub → Cloud Function → Firestore. Мобильное приложение читает состояния из Firestore через реалтайм-подписки и пишет команды туда же. Отдельная Cloud Function слушает изменения в Firestore и публикует команды обратно в MQTT-брокер к устройству.
На Flutter это реализуется через cloud_firestore пакет:
FirebaseFirestore.instance
.collection('devices')
.doc(deviceId)
.snapshots()
.listen((snapshot) {
final state = DeviceState.fromJson(snapshot.data()!);
// обновляем UI
});
На React Native — @react-native-firebase/firestore с аналогичным API.
Cloud Run + MQTT для IoT
Более правильная архитектура для production: EMQX или HiveMQ на Cloud Run / GKE → Cloud Pub/Sub → Cloud Functions → Firestore. EMQX поддерживает Rule Engine (аналог AWS IoT Rules): можно прямо из брокера публиковать в Pub/Sub по условиям без отдельных Lambda/Functions.
Мобильный клиент подключается к EMQX через MQTT over WebSocket с JWT-аутентификацией (выдаётся Firebase Auth). EMQX проверяет токен через HTTP Authentication hook — запрос к вашему бэкенду при каждом подключении.
Firebase Cloud Messaging для IoT-событий
Push-уведомления по IoT-событиям — нативная сильная сторона GCP-стека. Cloud Function триггерится по Pub/Sub сообщению, отправляет FCM notification через Admin SDK:
await admin.messaging().send({
token: userFcmToken,
notification: { title: 'Датчик движения', body: 'Движение обнаружено в прихожей' },
data: { deviceId: '...', eventType: 'motion' }
});
На Flutter firebase_messaging обрабатывает уведомления в background через onBackgroundMessage handler. Важно: на Android обработчик должен быть top-level функцией, не методом класса — иначе крэш при получении уведомления в killed state.
Сроки
Базовая архитектура (MQTT-брокер + Pub/Sub + Firestore + мобильный клиент) — 3–4 недели. Push-уведомления, Cloud Functions для автоматизации — ещё 1–2 недели. Стоимость рассчитывается индивидуально, GCP-инфраструктура тарифицируется по объёму сообщений и compute.