Le mode Gardien de SignalPlate peut transmettre une détection à un équipement présent sur le même réseau local : serveur domotique, système de contrôle d’accès, tableau de bord ou outil de journalisation. Cette automatisation repose sur un webhook, c’est-à-dire une requête envoyée dès qu’un événement pertinent survient. Sur les versions Android récentes, une configuration correcte ne suffit toutefois plus toujours : l’application doit aussi être autorisée à communiquer avec les appareils du réseau local. Voici comment distinguer une erreur d’adresse, un refus de permission et une panne du destinataire afin de rendre les alertes SignalPlate plus fiables.
À quoi sert un webhook dans le mode Gardien ?
Un webhook agit comme une sonnette numérique. Au lieu d’attendre qu’un autre système interroge régulièrement SignalPlate, l’application lui envoie un message au moment où une plaque concernée est détectée. Le destinataire peut alors enregistrer l’événement, afficher une notification interne ou déclencher une action prévue par votre installation.
Ce mécanisme est particulièrement intéressant sur un site privé équipé d’un serveur local. Les échanges peuvent rester dans le réseau Wi-Fi du bâtiment, sans nécessairement traverser un service distant. Le webhook ne remplace cependant ni la détection ni l’OCR : SignalPlate doit d’abord repérer un véhicule, localiser sa plaque, lire les caractères et appliquer les règles actives avant de produire l’événement correspondant.
Dans une scène comportant plusieurs véhicules, il ne faut pas supposer que seule la plaque visuellement mise en avant peut être transmise. Le traitement du webhook est découplé du choix de la plaque affichée comme la plus proche ou la plus importante dans l’interface. Cette séparation évite qu’une présentation destinée à rester lisible limite artificiellement les événements envoyés à votre système.
Réseau local et Internet : deux accès différents
Une adresse locale désigne généralement un appareil joignable uniquement depuis votre Wi-Fi ou votre réseau Ethernet. Elle peut ressembler à une adresse numérique privée ou à un nom attribué par votre routeur. Une adresse Internet publique, à l’inverse, pointe vers un service accessible au-delà de votre installation.
Cette différence est essentielle pour le dépannage. Votre téléphone peut afficher une connexion Internet parfaitement fonctionnelle tout en étant incapable de joindre un serveur local. Il peut être connecté au mauvais Wi-Fi, placé sur un réseau invité isolé ou privé de l’autorisation Android nécessaire. Tester un site web ne prouve donc pas que le webhook local de SignalPlate peut atteindre sa destination.
Android renforce progressivement la protection de ces communications. SignalPlate prend en charge l’autorisation d’accès au réseau local prévue par les versions récentes du système. Lorsqu’elle est refusée, l’application peut afficher un état d’erreur dédié plutôt qu’un vague échec réseau. Vous savez ainsi que le problème ne vient pas forcément de l’OCR, du serveur ou de l’adresse configurée.
Préparer le destinataire avant de configurer SignalPlate
Commencez par vérifier le système qui doit recevoir les événements. Il doit être démarré, connecté au même réseau et à l’écoute sur l’adresse ainsi que le port prévus. Si ce destinataire change régulièrement d’adresse après un redémarrage du routeur, réservez-lui une adresse stable dans votre installation ou utilisez un nom local correctement résolu.
Testez ensuite son accessibilité depuis le téléphone Android. L’objectif n’est pas encore de valider la reconnaissance de plaques, mais uniquement le chemin réseau. Si aucun appareil mobile du même Wi-Fi ne peut joindre le service, modifier les réglages de détection dans SignalPlate ne résoudra rien.
Contrôlez également les règles d’isolation du routeur. De nombreux réseaux invités permettent d’accéder à Internet tout en interdisant les échanges entre appareils. Cette protection est utile dans un hôtel ou un commerce, mais incompatible avec un webhook devant atteindre un serveur situé à quelques mètres. Le téléphone et le destinataire doivent appartenir à un segment réseau autorisant leur communication mutuelle.
Configurer le webhook du mode Gardien étape par étape
- Connectez le téléphone au bon réseau. Vérifiez le nom du Wi-Fi et évitez le réseau invité si celui-ci isole les appareils.
- Ouvrez les paramètres liés au mode Gardien. Renseignez l’adresse complète du destinataire, en incluant le protocole, le port et le chemin attendus lorsqu’ils sont nécessaires.
- Accordez l’accès au réseau local. Si Android affiche une demande d’autorisation, acceptez-la pour permettre à SignalPlate de joindre les équipements présents sur le réseau privé.
- Enregistrez la configuration. Relisez attentivement l’adresse afin de repérer les espaces, chiffres inversés ou chemins incomplets.
- Effectuez un essai contrôlé. Utilisez une plaque de test et vérifiez à la fois son traitement dans SignalPlate et la réception de l’événement par le serveur.
- Contrôlez plusieurs passages. Un seul succès ne révèle pas toujours une adresse instable, une veille Wi-Fi ou un destinataire qui cesse de répondre après quelques minutes.
Pendant ce test, choisissez une scène simple et sûre. Un véhicule immobile ou un passage organisé sur une propriété privée facilite la comparaison entre ce que montre SignalPlate et ce que reçoit votre système. Ne manipulez jamais les réglages en conduisant.
Que faire si Android refuse définitivement la permission ?
Après plusieurs refus, Android peut ne plus présenter automatiquement la fenêtre d’autorisation. SignalPlate propose alors un accès aux réglages du système. Ouvrez la fiche de l’application, consultez les permissions disponibles et autorisez l’accès au réseau local si votre version d’Android l’exige.
Revenez ensuite dans SignalPlate et recommencez le test. Il n’est normalement pas nécessaire de recréer toutes vos règles de plaques pour corriger cette permission. Si le refus persiste, vérifiez aussi les restrictions appliquées par un profil professionnel, un contrôle parental, un pare-feu ou une politique de gestion du téléphone.
Ne confondez pas cette autorisation avec celle de la caméra. La caméra permet d’obtenir les images ; le réseau local permet de joindre le destinataire. Une détection peut donc apparaître correctement dans l’interface alors que le webhook échoue. À l’inverse, une connexion réseau parfaite ne produira aucun événement si la plaque n’est pas lisible ou ne correspond pas aux règles du mode Gardien.
Diagnostiquer une alerte qui ne parvient pas au serveur
La plaque apparaît, mais aucune requête n’arrive
Vérifiez d’abord le message d’état de SignalPlate. Une mention liée à la permission de réseau local oriente directement vers les réglages Android. Si l’accès est accordé, contrôlez l’adresse, le port et le chemin du webhook. Une simple erreur de port peut diriger la requête vers un service inexistant.
Le serveur répond depuis un ordinateur, mais pas depuis le téléphone
Les deux appareils ne sont peut-être pas sur le même réseau logique. Examinez le Wi-Fi utilisé par le téléphone, l’isolation des clients et les règles du pare-feu. Désactivez temporairement les données mobiles pendant le diagnostic si elles compliquent l’identification du chemin emprunté, puis réactivez-les après le test.
Certains événements seulement sont transmis
Comparez les plaques reçues avec les règles actives. Vérifiez le format accepté, les listes surveillées et le filtre par type de véhicule. Une moto exclue du filtre de détection n’entrera pas normalement dans la même chaîne de traitement qu’une catégorie autorisée. De même, une lecture encore instable ne doit pas être assimilée à une alerte confirmée.
Le fonctionnement devient irrégulier après plusieurs heures
Recherchez une mise en veille du serveur, un changement d’adresse locale ou une coupure Wi-Fi. SignalPlate dispose de mécanismes de surveillance et de reprises bornées pour ses services connectés, mais il ne peut pas maintenir éveillé un destinataire arrêté ni traverser une règle réseau qui bloque volontairement les échanges.
Sécuriser une automatisation locale
Un webhook peut contenir des données sensibles, notamment une plaque, une heure ou des informations liées à une détection. Limitez son accès aux équipements nécessaires et évitez d’exposer directement le serveur sur Internet uniquement pour simplifier un premier test. Une installation locale mal protégée peut devenir accessible à des appareils qui n’ont aucune raison de consulter ces événements.
Le destinataire doit également traiter les messages comme des signalements, non comme des certitudes absolues. L’OCR automatique peut se tromper dans des conditions difficiles. Pour une action sensible, prévoyez une validation supplémentaire : comparaison avec une liste précisément gérée, contrôle humain ou règle empêchant une décision irréversible à partir d’une seule lecture.
Enfin, documentez votre configuration : adresse du service, réseau utilisé, permission Android accordée et plaque de test. Cette courte fiche simplifie le diagnostic après un changement de routeur, de téléphone ou de serveur.
Une méthode de test qui sépare les causes
Pour fiabiliser le webhook SignalPlate, testez les couches dans le bon ordre : serveur actif, communication locale, permission Android, adresse configurée, puis détection réelle. Cette méthode évite de modifier l’OCR alors que le Wi-Fi est isolé, ou de réinstaller l’application alors qu’un port est fermé.
Une fois ces éléments validés, laissez le mode Gardien fonctionner pendant une durée représentative de votre usage. Vérifiez l’historique de SignalPlate et le journal du destinataire, puis comparez les heures et les plaques reçues. Vous obtenez ainsi une automatisation locale plus compréhensible, capable de signaler clairement un refus de permission et plus simple à maintenir lorsque votre installation évolue.
Laisser un commentaire