- Dû passer à une mesure toutes les 3 minutes afin
d'économiser l'utilisation du quota du GSM
- Dû passer à 60 secondes la connection à socat
aussi à cause du quota GSM
- Dû passer à python 2.7 dans luatool.py à cause que
mon mac n'a plus de lien symbolique sur python2
Je pense avoir trouvé la solution.
J'arrive maintenant à détecter si un ap wifi existe ou non grace
à la fonction print(wifi.sta.status()).
J'essaie en premier de me connecter sur le 2e ssid (celui du smartphone)
et continue mon boot normalement.
Si non, j'essaie de me connecter sur mon 1er ssid (celui de la maison)
et continue mon boot normalement.
Si non, j'essaie de me connecter sur le wifi qui se trouve dans eus_params.lua
et continue mon boot normalement.
Si non, je passe en mode setup gadget pour trouver une nouvelle configuration
Maintenant quand il voit qu'il a le ssid1, il se connecte sur
Internet pour mettre à jour l'horloge.
Mais s'il voit ssid2, il redémarre et s'arrête pour la maintenance.
Reste encore à modifier le wifi_init qui soit capable de se connecter
aussi sur le ssid2, car actuellement c'est seulement le ssid1.
Maintenant les *secrets* sont chargés au moment de l'init.lua et
l'aiguillage du boot *dsleep* se fait en fonction de la variable
node_mode. Ainsi c'est le même iniz.lua et wifi_init.lua pour les
différents projets NodeMCU.
Reste encore à faire de pouvoir sauver deux possibilités de connexions
WIFI dans les secrets_wifi afin de pouvoir se connecter sur le
WIFI du smartphone en cas de dépannage sur le terrain
Bien qu'il n'a pas de connexion réseau au moment du power boot, il peut
retrouver une ancienne heure sauvegardée dans la flash et continuer à
enregistrer.
Il faut maintenant qu'il voit que quand il a un wifi connu qu'il se
connecte sur Internet pour se resynchroniser avec la bonne heure
Comme il peut démarrer maintenant tout seul depuis un power off,
il n'a plus moyen d'aller chercher la date sur Internet.
Il faut donc régulièrement quand on est connecté sur Internet, sauver
la date dans la flash afin qu'il puisse au moins partir d'une date pas
trop fausse quand il démarre sans nternet
J'affiche maintenant la trace du pet tracker sur un mymaps de Google, je suis assez content.
Mais pour l'instant c'est encore un peu de la théorie, car c'est le même fichier pet tracker
qui a servi pour l'étalonnage des paternes que celui que j'affiche, donc les paternes sont
toujours bien résolues, cela va être différents quand le pet tracker va se balader dans
des endroits inconnus de la cartographie des points GPS du quartier.
Faut donc maintenant aller faire un tour dans le quartier avec le pet tracker et voir
comment cela va fonctioner en pratique
Le problème était que pour les tests de fonctionalité de la dernière partie du code,
j'ai limité aux 5 premières paternes et que c'est seulement à partir de la 16e paterne
que les coordonnées GPS *bougent*, car je n'avais pas encore bougé lors de la 1ère minute ;-)
à avoir un bon résultat pour les très petites paternes grâce au calcul
de la déviation de rssi entre le pet tracker et la calibration.
Faudra juste tester s'il y a des doublons pour tout simplement ne pas
en tenir compte lors de l'affichage dans de rares cas
En utilisation la technique des votations j'arrive à trouver la
corélation des paternes en triant le tableau de votes et prenant
le premier élément.
Me reste encore à récupérer la coordonée GPS de la paterne et
surtout le faire pour toutes les paternes du pet tracker ;-)
pour les paternes comptant moins que 3x ap wifi, il y a trop de doublons et
la levée de doute avec le calcul des erreurs (rssi) ne fonctionne pas pour là
où il n'y a qu'un seul ap wifi dans la paterne.
Il faudra donc éliminer les mesures qui sont trop fausses
Je n'avais pas pris le bon index pour remplir le tableau de votes.
Mais je m'aperçois que j'ai des fois une paterne avec qu'un seul ap wifi
et cela me crée pas mal de doublons au niveau votes.
Je dois donc encore chercher pourquoi et comment lever le doute avec le
coefficient error de distance
J'ai bien des votations, mais le résultat des patternes gagantes se trouvent
toujours dans les moins de 20, donc proche de la maison bien que j'ai pris une
patterne à 150. Je ne sais pas pourquoi
J'arrive maintenant à parser toute la table ap wifi à la recherche d'une mac adresse.
Me reste encore à faire le voting pour savoir dans quelle paterne elle se trouve
Et après de parser toute la table pet tracker
Je commence à charger le fichier pet tracker dans un tableau que je vais après parser
pour rechercher des corespondances dans les patternes ap wifi du quartier afin de pouvoir
trouver les coordonnées GPS de chaque lieu de passage
Et là où j'ai fait fort, c'est que j'ai pris à chaque fois où j'avais le
maximum de signal, et on peut bien voir la disposition de mes ap wifi perso
tout autour de la maison. Je suis vraiment très content que mon principe
fonctionne enfin
d'ap wifi *vu* par le NodeMCU
Maintenant il faut que j'extrais les coordonnées GPS de chaque
ap wifi les plus proches afin de pouvoir afficher dans un google
mymap tous les ap wifi du quartier
J'ai vu que j'avais beaucoup trop de doublons au niveau des noms
des ap wifi comme par exemple *upc free*, j'enregistre donc
maintenant l'adresse mac de l'ap wifi aussi, ainsi j'arrive à
les différentier
Je change de méthode pour trouver les positions GPS, plus avec
Wigle car il y avait trop de bruit, mais maintenant en
enregistrement // du NodeMCU et du OSMand+ pour avoir la
corrélation GPS avec les timestamps d'enregistrement.
Reste encore maintenant à faire le calcul post traitement
pour pouvoir *coller* le positions GPS aux ap wifi *vu* par
le NodeMCU
Les données de géolocalisation des ap wifi de Wigle sont pourries !
Je dois m'y prendre autrement pour pouvoir *étalonner* la
géolocalisation du trajet de mes ap wifi :-(
L'ancien cat.lua, faisait sauter le buffer RAM de socat.
Le nouveau attend entre chaque ligne 50mS afin que le socat ait le
temps de vider le buffer de la trame réseau
Ajouté aussi, pour des tests de post traitements, le tout premier
fichier de logs des ap wifi quand j'ai fait le tour du quartier à
pied avec mon NodeMCU dans une boîte
Mon socat ne fonctionne plus avec les nouvelles version du firmeware
et mon pet tracker utilisait le module rtc-mem qui ne se trouvait pas
dans la version de dec 19.
J'ai donc dû modifier la procédure de boot afin de ne plus devoir
utiliser le module rtc-mem et de pouvoir revenir au firmeware de
dec 19 et pouvoir utiliser à nouveau mon socat qui est indispensable
afin de pouvoir récupérer les logs des ap wifi scannés lors de la sortie du chat
