[Interface Température] Configuration des paramètres wifi par l'utilisateur

[Devdevdavid]

Dans le but de rendre l'utilisation de LightKit plus accessible à l'utilisateur, on souhaite que les configurations wifi (SSID, mot de passe, IP, Gateway, Masque) soient configurables.

La procédure serait la suivante :

• [x] A-t-on une configuration valide enregistrée en mémoire flash ?

• si Oui:

  • [x] on essaie de se connecter au réseau indiqué dans la configuration

• si Non:

  • [x] On démarre en mode Access Point
  • [x] L'utilisateur peut se connecter au module à travers l'interface web (IP par défaut à définir)
  • [x] Il peut choisir de configurer le module pour se connecter à un réseau wifi existant
  • [x] Il saisi les paramètres dans un formulaire HTML
  • [x] Note: il serait intéressant d'afficher les réseaux alentours détectés avec une indication de la force du signal
  • [x] Après validation du formulaire, les paramètres sont stockés en mémoire flash
  • [x] Une séquence de reboot est enclenchée

Les objectifs secondaires:

1. [x] La configuration lue au moment du boot doit être affichée dans le terminal
2. [x] On utilisera un checksum ou un CRC pour valider la configuration flash
3. [x] La sauvegarde des paramètres doit être évolutive et doit supporter l'ajout de nouveaux paramètres
4. [x] La led de status, s'il y en a, doit indiquer si le module est en mode connecté ou AP

D'autres propositions ?

[Devdevdavid]

Sur l'ESP32, j'obtiens désormais des crashs en mode AP lors d'une tentative de connexion. Ce problème est évoqué ici

[Devdevdavid]

Le problème venait finalement du fait que l'on doit attendre un peu entre l'appel de WiFi.softAP()et de WiFi.softAPConfig() Le même problème est évoqué ici ✅ Résolu avec 84174b598c02ce7f536e9145e25cc92958a20d7f

[Devdevdavid]

📸 Voici un aperçu de la page de configuration Wifi :

• Lightkit.pdf
• Lightkit 2.pdf

[GilDev]

Pas mal ! Ça ressemble à Tasmota, peut-être la source d’inspiration. 🙂

[Devdevdavid]

Non je ne connaissais pas ^^

[Devdevdavid]

📸 Voici une première ébauche de l'interface des réseaux wifi découverts avec le SSID et RSSI affiché sous forme de logo :

[Devdevdavid]

Scan des réseaux alentours fonctionnel. Il suffit de cliquer sur un scan pour pré-remplir le champ SSID. Lors du scan, le module se déconnecte du réseau, lance un scan, puis se reconnecte. Idem lorsqu'il est en mode AP. Lors du scan, il n'est donc plus possible d'interagir avec le module. Cela crée des latences si l'on clique sur un bouton de la page web en même temps. Le scan est relativement rapide (3-5s) donc ça passe. On prend le soin d'enregistrer en RAM le canal wifi et l'adresse MAC de la box avant la déconnexion pour une re-connexion plus rapide.

Ajout d'une icône de chargement pour savoir quand-est-ce que le scan est en cours :

[Devdevdavid]

Déconnexion de l'utilisateur lors du scan

Lors des tests avec Pascal, nous avons remarqué que les téléphones Android se déconnectent du module en point d'accès lors du scan wifi des réseaux environnants. Cette déconnexion empêche la validation du formulaire HTML et donc la configuration du module.

Pour éviter cela, nous avons choisi d'effectuer un scan peu après le démarrage et de conserver les résultats pour 24h. Au delà, le chargement de la page web impliquera une demande de rafraichissement des scans qui déconnectera les utilisateurs Android. Pas de soucis pour leur 2nd tentative car les résultats seront de nouveau disponibles pour 24h.

En pratique, l'utilisateur va brancher son module puis tenter une configuration wifi. Ce problème ne sera apparent que pour un faible nombre d'utilisateur et n'est pas bloquant.

Note: Pas de problème pour un module en mode client, l'utilisateur reste connecté à sa box

Commit : dcb2b8313c1d36dd5e3f334903decc24e4c74b55

[Devdevdavid]

Tester le point sur la LED de statut avec la carte board_temp_telegram_relay qui dispose d'une led de status de type Néopixel

[Pascal-Tours]

Fonction validée !