docs: état des lieux localisation capteurs OpenRemote

- Documentation des découvertes et corrections appliquées
- Problèmes restants identifiés (connexion MQTT, topics, déconnexion)
- Prochaines étapes recommandées

LOCALISATION-CAPTEURS-STATUS.md

@@ -0,0 +1,65 @@
+# État des lieux - Localisation des capteurs sur les maps OpenRemote
+
+## Problème initial
+Les capteurs du simulateur n'apparaissent pas sur les maps OpenRemote (realm master et smart city martinique).
+
+## Découvertes
+
+### 1. Deux sets d'assets en BDD
+- **Anciens assets** (avec suffixe `(traffic)`, `(airquality)`, etc.) : ont `agentLink` MQTT + `location` GeoJSON → ce sont les bons
+- **Nouveaux assets** (sans suffixe, créés par le simulateur via REST) : sans `agentLink`, sans `location`
+
+### 2. Format de la location
+L'attribut `location` dans OpenRemote utilise le format GeoJSON Point :
+```json
+{"type": "GeoJSONPoint", "value": {"type": "Point", "coordinates": [lat, lon]}}
+```
+
+### 3. Compteur SENSORS global
+Le compteur utilisé pour générer les clés SENSORS est **global** (pas par type) :
+- traffic: 0-9, airquality: 10-19, parking: 20-29, noise: 30-39, weather: 40-49, light: 50-59
+
+### 4. API REST refuse les PUT sur assets avec agentLink
+L'API REST d'OpenRemote refuse les mises à jour (HTTP 403) sur les assets qui ont un `agentLink` actif. C'est une protection pour éviter les conflits avec l'agent MQTT.
+
+### 5. Connexion MQTT au broker Artemis
+Le broker Artemis d'OpenRemote nécessite un **"Service user"** avec username/password pour l'authentification MQTT (rc=5 = Not Authorized sans credentials). La documentation mentionne ce mécanisme mais ne détaille pas comment créer le service user.
+
+### 6. Topics MQTT pour l'API interne
+La documentation indique que les topics pour publier des valeurs d'attributs sont :
+- `{realm}/{clientId}/writeattributevalue/{attributeName}/{assetId}` - Payload: JSON de la valeur
+- `{realm}/{clientId}/writeattribute/{attributeName}/{assetId}` - Payload: `{"value": <VALUE>, "timestamp": <TIMESTAMP>}`
+
+Le format `smartcity/{type}/{id}` utilisé par le simulateur est pour les agents MQTT externes, pas pour l'API MQTT interne.
+
+## Corrections appliquées au simulateur
+
+1. **ASSET_MAP mis à jour** avec les bons asset IDs (ceux avec agentLink + location)
+2. **Location ajoutée dans le payload REST** (GeoJSONPoint)
+3. **Topics MQTT corrigés** (index basé sur position du capteur, pas compteur global)
+4. **REST désactivé** pour les assets avec agentLink (403)
+5. **Connexion MQTT anonyme** au broker Artemis (rc=5 persistant)
+
+## Problèmes restants
+
+### Connexion MQTT au broker Artemis
+Le broker refuse les connexions anonymes (rc=5). Il faut un "Service user" dont la création n'est pas documentée. Solutions possibles :
+1. Créer un service user via l'UI OpenRemote (Manager UI → Users)
+2. Modifier la configuration Artemis pour accepter les connexions anonymes
+3. Utiliser un broker MQTT externe (EMQX) et configurer un agent MQTT dans OpenRemote
+
+### Topics MQTT
+Le simulateur publie sur `smartcity/{type}/{index}` mais l'API MQTT d'OpenRemote attend `{realm}/{clientId}/writeattributevalue/{attributeName}/{assetId}`. Il faut soit :
+1. Changer le format des topics dans le simulateur
+2. Configurer un agent MQTT dans OpenRemote qui écoute sur `smartcity/#`
+
+### Déconnexion cyclique
+Le broker Artemis déconnecte le client MQTT du simulateur de manière cyclique. Cause possible : keepalive trop court ou configuration du broker.
+
+## Prochaines étapes recommandées
+
+1. **Créer un service user** dans OpenRemote pour l'authentification MQTT
+2. **Configurer un agent MQTT** dans OpenRemote qui écoute sur `smartcity/#` et mappe les topics vers les attributs des assets
+3. **Corriger le format des topics** dans le simulateur pour utiliser le format de l'API MQTT d'OpenRemote
+4. **Tester la connexion MQTT** avec les bons credentials
+5. **Vérifier la localisation** sur les maps OpenRemote une fois que les agents MQTT reçoivent les données