Bonjour,
en effet c’est l’une des seules fonctions qui n’est pas completement multi. C’est un choix que j’ai fait lié à des limitations de la dépendance utilisée pour la geoloc/geofence ainsi que l’OS.
Pour faire simple, avec cette dépendance, j’avais 2 choix pour renvoyer les events:
- laisser le « daemon »/service natif de la dépendance, gérer l’envoi des events au serveur (jeedom). La dépendance n’accepte qu’une seule url.
- que ce soit l’app jeemate (mon code) qui envoie les events au serveur. mon code donc je fais ce que je veux.
Dans la doc, il est conseillé de laisser la dépendance gérer cela car elle met les events en cache de son coté, gère les envois au serveur, retry, service background etc
Si je l’avais fait (solution 2), alors j’aurais du gérer cela moi-meme via le code de l’app jeemate. Ce qui implique que le code de l’app fonctionne tjs (meme app kill) et donc activer obligatoirement le service background jeemate (+notif permanente). Ne jamais rater une interception d’un event de la dépendance pour ensuite l’envoyer au serveur etc
Tandis qu’avec la solution 1, en mode geofence seulement, on n’est pas obligé d’avoir un service background actif.
Donc j’ai choisi la solution 1) car
- fiabilité grace au daemon de la dépendance qui a été battle-testé par son dev.
- consommation batterie
- ça m’évite de réinventer la roue et d’avoir du code à debugger supplémentaire
En contournement, je pensais que l’on pouvait forwarder depuis un jeedom vers un autre jeedom une commande info
Pour l’instant c’est comme ça, peut etre que mon avis évoluera, mais je préfère la jouer safe pour la majeure partie des users 
Eventuellement, j’aurais une idée coté jeedom pour automatiser cela depuis le plugin jeemate, faudra qu’on voit cela apres la release de la v3
Infos complémentaires provenant de la doc de la dépendance geoloc:
« WARNING:
The BackgroundGeolocation SDK hosts its own flexible and robust native HTTP & SQLite persistence services.
It is highly recommended to let the plugin manage uploading locations to your server, particularly for Android when configured with stopOnTerminate: false, since your App Component will terminate — only the plugin’s native Android background service will continue to operate, recording locations and uploading to your server. The plugin’s native HTTP service is better at this task than your own http requests, since the SDK will automatically retry on server failure. »
