Ajouter des appareils push et pull

ProbeHarbor reçoit les mesures de deux façons : votre matériel envoie (push) du JSON vers une URL d’ingestion, ou nous récupérons (pull) du JSON en HTTPS depuis un flux public à intervalles réguliers. Les deux se configurent dans Dashboard → Devices. Les nouveaux nœuds ESP ou sur batterie devraient utiliser le push. Le pull s’adresse aux serveurs LAN toujours allumés ou aux relais qui exposent déjà du JSON en HTTPS.

Un compte gratuit (sans carte bancaire) associe votre clé d’ingestion à votre foyer, pour que l’historique et les alertes restent privés. Parcourez d’abord la démo en direct si vous voulez voir des mesures sans vous inscrire.

Choisir entre push et pull

Appareil push (recommandé)

1. Connectez-vous et ouvrez Devices.
2. Sous Push devices, cliquez sur Create push device (nommé Workshop probe par défaut : renommable à tout moment).
3. Dans l’encadré d’ingestion : scannez le QR, ou utilisez Download Arduino .ino / MicroPython .py / CircuitPython code.py / Zephyr main.c / CH32V main.c / AVR main.S / Teensy 4.1 .ino / PIC18 main.c / Particle Boron .ino / ESPHome snippet (URL ou chemin d’ingestion prérempli). La clé reste affichée 30 minutes et survit à un rechargement jusqu’à ce que vous la fermiez.
4. Clé perdue plus tard ? Sur la carte de l’appareil, utilisez Reveal ingest key (si la récupération des clés est activée sur le serveur) ou Rotate key pour en émettre une nouvelle. Les appareils créés avant l’activation de la récupération des clés doivent faire une rotation pour enregistrer une copie chiffrée récupérable.
5. Flashez un ESP32 (voir les options de flashage : Arduino IDE, PlatformIO, MicroPython ou l’esptool web d’Espressif), un Pico W (CircuitPython / MicroPython / Arduino-Pico), une STM32 Nucleo (Zephyr C + Ethernet), un CH32V307 (WCHNET C + Ethernet), un Uno en assembleur GNU AVR (ATmega328P + W5100), une Teensy 4.1 (QNEthernet), un PIC18F67J60 (MLA TCP/IP) ou une Particle Boron (webhook LTE). Il vous faut d’abord les pièces ? Nomenclature du kit antigel ESP32, Pico W, STM32 Zephyr, CH32V RISC-V, assembleur AVR, Teensy 4.1, PIC18 Ethernet ou cellulaire (DS18B20 étanche). Le moniteur série à 115200 doit afficher POST 200 (ou publish ok sur la Boron). Les clés des capteurs s’importent automatiquement (clés plates, objet temp, SenML ou Home Assistant REST). Renommez ensuite les capteurs sur la page Devices. Le mappage manuel sous Advanced est facultatif, pour mapper les clés à l’avance.
6. D’autres exemples (Uno Ethernet + DHT22, MAX31855, MAX6675, etc.) : sketches/. Le W5100 ne gère pas le TLS : envoyez un POST HTTP vers un relais sur le LAN (flux Python / push_https_forward.py).
7. Faites un test rapide avec curl, puis ouvrez Live en étant connecté. Après environ 30 minutes sans envoi, Live signale qu’une sonde est peut-être hors ligne.

Exemple curl (push)

Récupérez un corps d’exemple en direct depuis le flux d’ingestion d’exemple (basé sur la météo), puis envoyez-le en POST à votre clé d’appareil.

curl -X POST "https://probeharbor.dev/api/ingest/YOUR_DEVICE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"temp1": 42.5, "door1": false, "battery": 87, "rssi": -62}'

Formats de charge utile : clés plates, objet temp classique, sensors[] typé, SenML (RFC 8428) ou JSON state Home Assistant REST. Ils sont documentés dans ingestion et webhooks et dans la référence développeur ingestion push. Essayez des exemples en direct : natif, SenML, HA REST.

Flux pull

1. Vérifiez que votre flux renvoie du JSON en HTTPS. Forme classique (clé racine par défaut temp) :

{
  "temp": {
    "0": { "c": 18.5, "f": 65.3, "h": 42 },
    "1": { "c": 19.0, "f": 66.2, "h": 40 },
    "avg": { "f": 65.75, "c": 18.75, "h": 41 }
  },
  "battery_pct": 87,
  "rssi": -62
}

2. Ouvrez Devices → Pull feeds.
3. Ajoutez un flux : nom, URL HTTPS et JSON root key (par défaut temp). Utilisez Test feed URL avant d’enregistrer.
4. Cliquez sur Save pull setup : les clés des sondes s’importent automatiquement depuis le flux en direct. Renommez les libellés sur la même page, ou cliquez sur Accept suggested names.
5. Cliquez sur Fetch now pour récupérer les mesures tout de suite, ou attendez la prochaine interrogation planifiée et vérifiez les cartes sur Live.

Par défaut, les flux pull attendent des objets de sonde imbriqués sous la racine configurée (pas des clés plates façon push). Les tableaux JSON SenML et les réponses Home Assistant REST sont détectés automatiquement quand cette racine est absente : collez l’URL telle quelle et mappez les clés de sonde exposées par SenML ou HA (par ex. 0, state). Si le microcontrôleur ne gère pas le TLS (Uno + shield Ethernet W5100), utilisez un relais HTTPS local (voir flux Python ou le redirecteur HTTP→HTTPS en bibliothèque standard pour l’ingestion push).

Déjà sur MQTT ?

Gardez Mosquitto ou le MQTT de Home Assistant sur votre LAN et répliquez les mesures en HTTPS. ProbeHarbor n’est pas un broker MQTT. Recette complète (curl, rest_command de HA, Node-RED) : guide du pont MQTT. Voir aussi ProbeHarbor face au MQTT fait maison.

Vérifier que tout fonctionne

• Live : les cartes se mettent à jour en direct ; les sondes en retard affichent un avertissement jaune « hors ligne » au bout d’environ 30 minutes.
• Devices → Status : dernière connexion, batterie et RSSI quand la charge utile les contient (après la première mesure en direct).
• L’essentiel antigel : réglez le seuil de gel et l’e-mail dans Devices après le premier POST, ou dans Alerts → When to alert, puis envoyez un test (débloque l’Overview complet après la première configuration).
• Overview : état de l’espace ; après l’essentiel, les indicateurs Status (heures de gel, marge la plus froide, ΔT intérieur−extérieur, écart entre sondes) et Insights (nuits à risque, porte/alimentation/mouvement, qualité de l’air). Les graphiques hebdomadaires peuvent superposer l’humidité et le point de rosée quand l’HR est disponible.

À lire aussi

• API d’ingestion et webhooks d’alerte
• Mise en service par QR du kit
• Configurer les flux de température (le pull en détail)
• Diagnostiquer des mesures figées
• Recette du pont MQTT · face au MQTT fait maison · docs MQTT développeur
• Développeurs : ingestion push · flux pull

FAQ

Push ou pull ?
Utilisez le push pour les nœuds ESP/Arduino capables d’envoyer un POST HTTPS sortant. Utilisez le pull si vous disposez déjà d’un flux JSON HTTPS public (ou d’un relais TLS) que ProbeHarbor peut récupérer à intervalles réguliers.

Pourquoi les relevés n’apparaissent-ils pas dans Home alors que l’ingestion réussit ?
Envoyez d’abord du JSON en POST : les clés des capteurs s’importent automatiquement dans Devices. Si Home reste vide, vérifiez que l’appareil a bien reçu un POST et consultez Devices → Device health. Flux pull : racine JSON correcte (temp par défaut), sauf si l’URL renvoie du SenML ou du JSON REST Home Assistant, détectés automatiquement.