Données Mobile Alerts (Lacrosse)

[thrymartin]

pourquoi 30' : parce que je me base sur les limitations de l'API : pas plus de 3 appels / heure je crois
donc restons en dessous, 30' semble bien, 2 appels par heure, 24 / jour
(le but étant d'éviter: le blacklistage, de saturer le serveur, d'enerver le staf mobile alerts)
donc le script propose un cache de 30' et je vous propose de régler la fréquence de vos http-capteurs sur la valeur par défaut, soit aussi 30' : n'oubliez pas qu'il n'y aura qu'un seul appel pour tous, inutile d'en mettre un a 30' et les autres a 1h... ça ferait toujours 2 appels par heure

pour étaler les acquisitions, je n'ai pas trouvé d'autre truc que celui la :

invalider tous les http-capteurs
puis un par un, les revalider en les étalant sur 30'

exemple sur 6 capteurs : toutes les 5 minutes

comme ça, quoiqu'il arrive, en cas de couac d'une acquisition, chaque capteur peut devenir celui qui fera l'acquisition sur le serveur mobile alerts et les autres prendront leur tour de la même manière pour aller récupérer les données dans le cache : c'est circulaire quoi

la mauvaise idée qui pourrait vous trotter dans la tête:
validez (le départ du décompte) tous les capteurs sur une période de 1 minute par exemple et vérifiez que le premier aille bien sur le serveur chercher les infos et actualiser le cache
vous avez tout, tout de suite, c'est bien, vous êtes content ...
mais si vous avez un couac de lecture (et on a vu que parfois, quelques nuits, on a quelques heures ou le serveur mobile alerts était difficilement accessible) et que ce soit le dernier (de la minute) qui aille finalement récupérer les données et remplir le cache : les autres arriveront à la soupe que 30' plus tard... vous aurez globalement des données plus vieilles que de les répartir sur les 30'
sauf si vous resynchronisez tout à chaque couac... c'est vous qui voyez

[ARTNOW]

Salut THYMARTIN , dis-moi , au bout de 30'' on est bien supposé récupérer toutes les valeurs des capteurs qui ont été mesurées dans ce laps de temps ?

[ARTNOW]

J'ai mis en place le nouveau script depuis 1h30 mais je n'ai pas toutes les valeurs :

[img]

Annotation%202020-02-24%20104312.png

[/img]

[ARTNOW]

Voici le résultat après plus d' 1h30 :

[thrymartin]

heu... tu as bien des valeurs toutes les 30' ou est le blème ?
pour les 30', j'ai expliqué pourquoi plus haut.

(NB : quand on vérifie les requetes réussies, il ne faut pas laisse sur "fusionner")

il se peut que parfois, eedomus saute une lecture, parceque lire dans le cache, ce n'est que du domaine de l'eedomus, pas de mobile alerts et parfois j'ai une valeur qui saute la 1/2 heure et qui ne se met a jour qu'apres 1h ... mais généralement c'est bon : j'ai toujours sur mes 9 données, provenant de 5 capteurs des X depuis (moins de 30')
chez moi c'est en test depuis 8 heures... et je contrôle avec l'appli android mobile alerts, en comparant les heures de relevés avec l'historique et c'est bon.

tu peux faire un test pour regarder le résultat du XML
il doit donner : (lecture du cache)
[CACHE][LACROSSE]
.... tout le reste
[/LACROSSE][/CACHE]
et la valeur demandée en XPATH doit apparaître en bas

pour qu'on ne puisse pas lire [CACHE], il faut arriver pile poil après 30' et avant qu'une valeur ne se mette à jour et faire le test pile poil a ce moment la : et ça ne vaut qu'une seule fois puisque ça va remplir le cache pour 30' : la ce sera un appel à mobile alerts avec la mise a jour du cache

[ARTNOW]

j'ai bien compris que le relevé se faisait toute les 30 min , mais je pensais que les valeurs qui avaient été mesurées dans cet intervalle nous parviendraient aussi ?

[thrymartin]

bien sur qu'elles parviennent, elles sont lues dans le cache
fais un test dans la page de config

ce qui te dérange, c'est que tu avais mis une frequence a 7mn (?) et maintenant c'est à 30
j'ai bon ?

va lire tes messages privés

[ARTNOW]

bien sur qu'elles parviennent, elles sont lues dans le cache
fais un test dans la page de config

ce qui te dérange, c'est que tu avais mis une frequence a 7mn (?) et maintenant c'est à 30
j'ai bon ?

va lire tes messages privés

OK pour les MP Merci

Oui je m’étais calé sur la fréquence de rafraîchissement native de lacross , je suis bien conscient que si on sature leurs site de requêtes ils risquent de fermer les portes
Ton travail m’intéresses beaucoup sur la récupération des infos toutes les 30 min mais chez moi cela ne marche pas il me donne une valeur toute les 30 min et de ce fait je perd des infos

[thrymartin]

Ben tu perds les infos qu'il y a entre les 30' : 3 sur 4, c'est si important que ça ? parce que ça ne bouge pas tant que ça en fait, et quand ça bouge, c'est dans un sens pendant un moment, ça ne fait pas le yoyo sur des durées très courtes et les graphes te donnent les intermédiaires : donc c'est moins "fin" certes, mais ça ne change pas grand chose.
que la température fasse en 4 heures, par exemple
2, 3, 4, 5, 6, 7, 8, 9
ou
2, 2.25, 2.5, 2.75, 3, 3.25, 3.5, 3.75, 4.... etc

ça fera le même graphe

relis mon MP, coupe la poire en 2

PS: le script n'est pas définitif, la condition d'erreur d'acquisition n'est pas la bonne (valeur non nulle), je vois avec merguez comment améliorer ça : il ne faut pas que le cache se mette à jour lors d'une erreur d'acquisition !
et ça va permettre, si comme c'est arrivé il ya 2 jours, vers minuit : pendant 3 heures, difficultés d'acces, mais avec des plages ou ça passait : bref un seul capteur un coup celui ci un coup celui la, se mettait à jour, et aucun des 8 autres !
avec le script à cache : tout aurait été à jour ! (une fois la condition d'erreur mise en place, ça va venir)

Donc, voula de quoi convaincre notre ami : un peu moins en frequences, mais TOUTES les mesures acquises, même quand monsieur Lacrosse décide de faire sa mauvaise tête.
(on ne sait toujours pas pourquoi il ya ces périodes ? c'est arrivé 4 fois, entre 2 et 9 heures d'affilé, et c'était toujours juste des temps d'acces au serveur : avec la page web et de la patience, ça finissait par arriver, mais avec le http-capteur, au dela de 40 secondes, ça passe en erreur, inutile donc de metre des temps d'attente de plus de 40 secondes dans le parametrage (30 par défaut, ça va très bien)

[thrymartin]

Bon, on va bien y arriver : V2.1
donc avec le correctif : si couac de lecture de la page html mobile alerts, donc si le $xml n'est pas généré, donc qu'il ne contient pas une chaîne de caractère qui se trouvera dans toutes les infos capteur ou centrale (balise de date/heure), alors le cache n'est pas mis à jour et le prochain appel par le prochain http-capteur va réessayer de récupérer les données.

toujours en TEST

Code : Tout sélectionner

<?php
// nom du script : lacross.php
// v2.1 : avec utilisation d'un cache / 30'

// fonction du script
    function sdk_makeKey($cle) {
        $o = array("@"," ","&#233;","&#232;","&#234;","&#235;","&#224;","&#225;","&#231;","&#250;");
        $r = array("_","_","e","e","e","e","a","a","c","u");
        return str_replace($o, $r, strtolower($cle));
    }

// cache
$cache_duration = 30;
$time_last_xml = loadVariable ( 'time_last_xml' );
if (( time () - $time_last_xml ) / 60 < $cache_duration )
{
$cached_xml = loadVariable ( 'cached_xml' );
echo $cached_xml ;
die ();
}

// script
    $phone_id    = getArg('phoneid');
    $url         = "https://measurements.mobile-alerts.eu/Home/SensorsOverview?phoneid=".$phone_id;
    $result      = httpQuery($url, 'GET');
    $result      = preg_replace("#<\!--((?:.|\n)*)-->#","",$result);
    $xml         = "<LACROSS>\n";   
   
    preg_match_all('/(?:(?:<h3>(?:\s*)<a href="(?:.*)">(.*)<\/a>(?:\s*)<\/h3>)|(?:<div class="sensor-component">(?:\s*)<h5>(.*)<\/h5>(?:\s*)<h4>(.*)<\/h4>(?:\s*)<\/div>))/', $result, $matches);

    if(!isset($matches[3])) {
        return;
    }
   
    $last_name = NULL;
   
    foreach($matches[3] as $k => $m) {
       
        if(($k != 0)&&($m == '')) {
            $xml .= "</" . $last_name . ">\n";
        }
       
        if($m == '') {
            $last_name = sdk_makeKey($matches[1][$k]);
         $last_name     = preg_replace("#^\d* *|\/|\(|\)#","_",$last_name);
            $xml .= "<" . $last_name . ">\n";
            continue;
        }
       
        $key = sdk_makeKey($matches[2][$k]);
       
        $o = array(" C","%"," mm"," km/h"," ppm","Nord- ","Sud- ","Est- ","Ouest- ",",");
        $r = array("","","","","","Nord-","Sud-","Est-","Ouest-",".");
       
        $xml .= "<" . $key . ">" . str_replace($o, $r, $m) . "</" . $key . ">\n";

    }
   
    if(count($matches[3]) > 0) {
        $xml .= "</" . $last_name . ">\n";
    }
   

    $xml .= "</LACROSS>";
    echo $xml;
     
// mise en cache
if (strpos ( $xml , "<releves_avec_date>" ))
{
$cached_xml = "<CACHE>";
$cached_xml .= $xml ;
$cached_xml .= "</CACHE>";
saveVariable ( 'cached_xml' , $cached_xml );
saveVariable ( 'time_last_xml' , time ());
}
?>

[thrymartin]

Bon, c'est testé, vérifié par merguez07 donc je l'ai mis en tête de discussion.
(édition du didacticiel)

Merci de jouer le jeu : encore cette nuit, une perturbation genre 20h - 1h
une seule donnée a été récupérée vers 21h30
au lieu d'avoir un trou de 5h pour tous les capteurs sauf 1
avec le cache, tous les capteurs ont été mis à jour au bout d' 1h30

je vous enjoins à rester avec une fréquence de 30' voila les chiffres que ça peut donner avec 10 capteurs :

sur 24 heures
sans cache et 10' = 1440 appels au serveur
cache et 30' = 48 appels au serveur

Si vous jouez le jeu, je pourrais essayer ensuite de contacter Mobile Alerts pour leur demander de lever ces difficultés d'accès (ou de régler le probleme) qui font au contraire augmenter le nombre de tentatives d'appel au serveur. Mais je ne peux pas faire ça si ce n'est pas la réalité...

[clarinette49]

Comme je l'ai dit je ne peux pour l'instant faire la modif, aussi je vais temporairement désactiver certains capteurs de façon à ne pas dépasser 50 requêtes par jour.

Je viens de faire la modif j'ai conservé 3 capteurs avec un appel toutes les heures.

Si tu contacte Lacrosse peux tu voir avec eux si il n'y aurait pas la possibilité de récupérer les données sans passer par leurs serveurs.

[thrymartin]

Ca a déjà été débattu sur Jeedom, apparemment en alternative, il n'ya que l'API mais ils semblent dire que ça ne fonctionne pas sur tous les capteurs (limité a 3 appels par minute, mais bon, on est loin d'une réelle limitation, récupérer 15 capteurs en 5 mn ce n'est pas la mort).

En plus, ça me semble compliqué : c'est du hackings : soit il faut intercepter le dialogue de la passerelle au serveur... soit intercepter carrément le 868 ... soit intercepter le dialogue entre la passerelle et les centrales / capteurs ... c'est peut être tout crypté ...
en theorie, c'est surement possible, il ya bien des softs sous linux pour intercepter les handshake wifi
Mais je me vois mal avoir une réponse la dessus : faut savoir que c'est une secretaire qui répond et qui fait "tampon" avec le staf technique...

c'est quand même plus simple d'être raisonnable et d'utiliser le cache... après s'ils voient que les appels ne sont pas les chutes du Niagara, ça va se lacher tout seul, a mon avis

PS : je ne sais pas et ne comprend pas le pourquoi de ces (heureusement rares et de toute façon quand je dors) perturbations, leur côté aléatoire mais régulier (de vers 20h à vers 2h, heure métropole, mais pas tous les jours, jamais la même heure) est assez étrange...
EDIT : le plus vraisemblable devait être un problème de serveur, qui semble réglé puisqu'il n'y a plus de perturbation depuis 2 semaines (à la date du 8/3/20)... enfin souhaitons le...

[thrymartin]

Pour le serveur Mobile Alerts, on a passé les 15 jours sans couac, donc le problème semble réglé

Par contre on m'a signalé une ID qui ne générait pas tous les capteurs dans le XML
(le problème c'est que les ID ont parfois des petites particularités dans le HTML généré, j'en ai même vu une avec un commentaire !?, bref, tant qu'on ne me signale pas une ID qui couac, je considère que le script fonctionne de manière universelle... bref, ce post ne vous concerne peut être pas)
Je regarde le problème, déjà quand j'aurai vraiment le temps, mais en attendant :

- SI pour vous tout marche, ça ne vous concerne pas (Lapalisse, bienvenue)
Sinon... ben attendez la mise à jour...

- Si vous aviez votre script a vous qui fonctionne et que vous vouliez juste rajouter le cache :
simple : vous insérez votre script entre

// script
ICI
// mise en cache

C'est tout si votre echo est la variable $xml

sinon, remplacez la dans la ligne (après // mise en cache)

$cached_xml .= $xml ;

$cached_xml .= $machintruchose ;

Vous pouvez aussi éventuellement virer la fonction (// fonction du script) au début de script si vous n'en avez pas besoin

en tout état de cause, je signalerai ici la mise à jour. (en nouveau message),

Je ne saurais trop insister sur cette nécessité de mise en cache ! rendez vous compte que certains ont plus de 10 capteurs et que la mise en cache, diminue le nombre d'appel au serveur Mobile Alerts de x fois le nombre de données à récupérer !

[thrymartin]

J'ai corrigé le script (première page)
V 2.2
Le probleme sur l'ID mentionné plus haut venait d'un commentaire, toujours le même et répété plusieurs fois.

<!-- Luftfeuchtigkeit -->
(il faisait déjà capoter le script sur une ID, celle du Hutzenberg, mais il était en un seul exemplaire... )

et une commande supprimait tout ce qu'il y avait entre <!-- et -->
eh bé non, ça ne marche que s'il n'y a qu'un seul commentaire :
avec plusieurs occurrences de ce commentaire, et il y a des ID qui ont ça (comme des ID qui n'ont rien) ben ça supprimait tout entre les commentaires, puisque ça prenait le "-->" par la fin ... d'ou COUAC

bref,

Donc j'ai supprimé la ligne fautive et mis a la place une commande pour supprimer toutes les occurrences de <!-- Luftfeuchtigkeit -->

et pis voila

PS, alternative universelle pour virer les commentaires :
// $result = preg_replace("/<!--.*?-->/s","",$result);

[thrymartin]

je disais donc sur le premier message :
Il a été demandé carrément un plugin, peut être un jour.../...

Bon, c'est le jour, je viens de demander son avis à maître merguez07
apparemment c'est bon,

c'est dans le store

[mimidelobbes]

Bonjour
Désolé de poser ma question ici mais je ne trouve pas d'autre endroits où la poser.
En lisant le forum il semble que la connexion de la passerelle Mobile-Alerts se passe bien pour vous. Malheureusement ce n'est pas le cas pour moi et je ne comprend pas pourquoi. J'espère que vous pourrez m'aider ou bien me rediriger vers qui le peu.
Quand je branche la passerelle sur mon switch, la led verte de la passerelle clignote une fois et rien d'autre. Quand je la branche sur la box, la led clignote deux fois et rien d'autre. Quand je vais sur la box avec le pc je constate qu'elle ne voit pas la passerelle. Impossible de changer quoi que ce soit avec l'appli du smartphone.
Je cherche désespérément une solution sur internet mais sans succès jusqu'ici.
Si vous avez une idée, je suis preneur.

Merci

Michel

[thrymartin]

Au fait, j'en profite pour dire que l'appli mobile a été mise à jour, juste zappez en faisant retour, le message qui s'affiche concernant l'amélioration du capteur de qualité d'air

==========

La passerelle ne sert qu'à communiquer les données à un Cloud
Le Cloud renvoi à l'appli mobile
et à une page Web d'ou sont tirées les données pour Eedomus

> vous êtes arrivé...
heu, tout le monde y est arrivé, super, vous êtes le number one

Donc, avant d'aller plus loin, au lieu de me parler de Led, dites moi si vous avez

éteint les capteurs (ou pas mis en service), lors de l'installation de la passerelle ?
(encore que moi, j'avais une station déjà active, ça n'a pas empêché l'install de la passerelle)
Il n'y a aucune raison de régler le DHCP avec l'appli, toutes les Box vont vous le faire
Et pas s'affoler si vous ne le voyez pas dans la box: dans ma Box Bouygues, je vois la passerelle dans les inactifs : la, de suite, en ce moment, pourtant ça marche, je reçois bien les infos correctement, dernier contact ya 3 mn
je l'avais mis en IP fixe, juste recherché Mobile-Alerts... et accepté l'IP deja attribuée (dans la liste proposée)

et avez vous :

- L'appli Mobile avec une ID - dans les réglages, vers la fin
- et si oui, Scanné ou entré le N° d'un capteur et s'il est affiché dans l'appli mobile ?

et si rien de rien, allez donc chez quelqu'un, donc un autre ordi, une autre connexion, ailleurs, lui brancher la passerelle et voir si il y a un changement - normalement effectivement au bout d'une 10aine de sec. elle doit être verte fixe
sans rien faire d'autre que de la brancher (secteur et LAN)
SI même ailleurs, ça fait la même, c'est peut être une malfonction, retour à l'envoyeur, voyez avec votre vendeur
Sinon, c'est à dire si ça fonctionne ailleurs, mais pas chez vous, revenez nous dire.

[mimidelobbes]

Merci pour votre réponse.
Oui les capteurs étaient éteints avant le branchement de la passerelle.
Comme proposé, je test ailleurs et reviens vers vous.

Michel

[mimidelobbes]

Bonjour
Voilà, j'ai testé sur une autre box et le résultat est le même, pas d'adresse IP assigné.
J'ai demandé le remplacement de la passerelle.
Merci de votre aide.

Michel