J’ai remarqué que mon plugin Ajax ne remonte plus jamais les infos Ethernet, Alimentation secteur et GSM.
Même quand j’excite mon hub volontairement, par exemple en déconnectant la prise ethernet ou en coupant le courant, y a aucune mise à jour de statut.
J’historise ces commandes, et en regardant ce matin, je vois que sur deux ans de temps, les valeurs n’ont plus jamais été mises à jour.
Je me demande si c’est ma config ou bien si c’est le plugin en lui même.
Dans l’équipement j’ai ça actuellement pour les commandes, je me demande si dans l’avant dernière colonne les valeurs sont encore justes.
OK j’ai déjà un élément de réponse en analysant les logs.
La partie GSM chez moi, quand l’équipement a été créé disait : gsm:gprsEnabled. Ce n’est plus bon, il faut a la place utiliser gsmNetworkStatus
@Loic : possible que les commandes aient évolué avec le temps au fil des mises à jour du plugin mais que les commandes n’aient pas été modifiées après les updates ?
Pour la partie alimentation secteur il y a deux indicateurs :
Un qui vient du SIA : externallyPowered
SIA [Maison][XXXXXXXX] externallyPowered => 1
Un autre qui vient des updates cloud de Ajax : hubPowered
« data »:[{« type »:« HUB »,« id »:« XXXXXXXXX »,« updates »:{« hubPowered »:1}
On pourrait avoir une commande avec le statut SIA et une autre avec le statut du cloud ?
A savoir que quand l’ethernet est perdu, forcément il ne reste que les messages en provenance du cloud.
Autre possibilité : coder une logique qui affiche le statut en fonction du fait que la connection SIA est active ou non.
Dans le message périodique avec le statut général, donc en gros le gros message qu’envoie le cloud tous les X temps, on a également l’information suivante :
Pour la partie Communication on a deux choses intéressantes :
« ethernet »:{« enabled »:true,« dns »:« INFO NETTOYEE »,« ip »:« INFO NETTOYEE »,« gate »:« INFO NETTOYEE »,« dhcp »:false,« mask »:« 255.255.255.0 »},
Et juste ensuite :
« activeChannels »:[« ETHERNET »,« GSM »]
Qui indique quels sont les canaux de communication disponibles, ici j’ai mon ethernet qui est connecté et la carte SIM GSM.
Le niveau de batterie du hub :
« battery »:{« chargeLevelPercentage »:100,« state »:« CHARGED »}
Ce serait cool de le mettre à disposition.
Utiliser le contenu de ces messages périodes permet de maintenir la synchronisation des états, même si on a loupé un message de type « Update » en provenance du cloud.
Ce qui fait que tôt ou tard, on récupère un statut plus ou moins synchro.
Soit via les messages d’updates si ils arrivent avant, soit via le périodique.
Tu saurais m’indiquer les valeurs actuelles de commandes, afin que je regarde pour mettre à jour les miennes ? Peut-être prévoir aussi pour la prochaine version du plugin que quand on fait « synchroniser » ou bien via un post update, qu’il remette les valeurs correctes pour les commandes ? Parce que du coup quand il y a un breaking change, on se retrouve sans le savoir avec des commandes qui ne sont plus jamais rafraichies. Et pour un truc qui se veut être de « sécurité » c’est un peu moyen
Oui, le SIA est intéressant, mais les valeurs des commandes du plugin doivent quand meme encore être rafraichies, sinon comment moi je peux savoir qu’elles ne sont plus raccordées à rien d’une version à l’autre du plugin ?
Bonjour
Non la comme ça je saurais pas te dire c’est dans les json mais ça bouge pas beaucoup. Une commande rafraîchir j’aimerais mais c’est techniquement pas possible ou alors faut je vous interdisent de changer le nom des commandes.
Pour le Sia je comprends pas ce que tu veux désolé.
Pour le SIA je veux rien, ça fonctionne
Tout ce que je demande c’est que d’une version à l’autre du plugin on tente de trouver une solution pour que les commandes non SIA soient mises à jour.
Je viens de supprimer l’objet Hub et le recréer via une synchro, et de toute évidence depuis deux ans j’en ai loupé des trucs … y plein de commandes supplémentaires …
Adapter les commandes existantes je comprends pourquoi ça peut être embêtant, créer celles qui n’existent pas, je pige pas le soucis
J’ai regardé pour la partie « techniquement pas possible » pour rafraichir les commandes, et en faisant un petit test avec un plugin que j’écris j’ai ceci a proposer :
Attribuer un numéro d’ID unique sur la commande (un Guid, ou autre peu importe) qui soit différent du nom de commande, et le tour est joué, après si les gens renomment, tu sais toujours retomber sur tes pattes sur base de cet ID caché qui fait partie de la commande en elle même.
De primabord, ça serait un breaking change, mais qui règlerait le soucis pour tous ceux qui partent d’un setup neuf
Bonjour
Les commandes non Sia peuvent être mise à jour par Sia cest déjà en place depuis le début du Sia ça. Le soucis c’est de trouver toute les conversions si tu les as n’hésites pas à me les passer j’ai fait celle que je pouvez.
Pour les commandes avec un guid à c’est possible mais c’est lourd à mettre en place et malheureusement j’ai pas du temps pour faire ça dans les 6 à 12 mois à venir.
Actuellement je ne prends quasiment plus de demande d’évolution par manque de temps et je ne fais que de la correction de bugs désolé. En plus ce genre de fonction demande à être remonté au niveau du core et donc impacterait tous les plugins. En fonction des impacts y’en aura pour plusieurs mois avant de pouvoir la voir arriver.
Je pige pas ce que tu me dis quand tu dis « Les commandes non SIA peuvent être mise à jour par SIA » … le niveau de batterie, par exemple, tu vas pas mettre ça a jour via SIA … y a aucune correspondance, c’est une particularité de Ajax dans ce cas ci.
Pour exploiter l’info, je t’ai donné l’information ici plus haut ou dans mon autre rapport de bug (j’ai splitté en plusieurs topics, donc je sais plus), j’ai regardé le contenu des trames renvoyées par le cloud, et c’est simplement un mauvais mapping. J’ai mis le screenshot du log avec la bonne valeur. J’ai regardé le code source du plugin Ajax et je vois bien ce qu’il faut adapter …
Mais c’est un plugin payant dont je trouve pas le code source sur le github de Jeedom.
Si tu me donnes accès au code source, je veux bien te fixer tout ce que tu veux
La partie Ethernet, elle remonte aussi très clairement dans les trames cloud (non SIA) … evidemment pas via SIA, vu que ça n’est pas prévu pour ça. La portée du réseau GSM, etc non plus … C’est logique, SIA c’est juste des codes … c’est très années 80 comme protocole
Comme je dis, suffit de me donner accès au code, je peux fixer ça … c’est rien de compliqué, c’est juste stimuler l’alarme avec différentes conditions, analyser les trames dans les logs débug, et aller pécher l’info au bon endroit dans les trames qui rentrent, qu’elles soit full data, ou juste les update frames
Bonjour
Je demande dès demain matin à Domadoo l’autorisation d’ouvrir le répo GitHub pour que tu puisses faire un pr car je comprends absolument rien à ce que tu me remontes. Je dis pas que toute les commandes cloud sont mise a jour aussi en Sia c’est pas possible je dis juste que quand c’est possible j’ai essayé de le faire. Mais malheureusement je n’ai pas le luxe de pouvoir passer des heures à faire des tests donc j’ai fait ce que j’ai pu avec le temps que j’avais sur ce plugin. Il y’a donc sûrement des dizaines voir des centaines de bug ou manquement dans le plugin. Si j’avais des jours devant je pourrais sûrement complètement le transformer mais c’est pas le cas.
Et ça, ça vient avec les grosses trames c’est correct.
Mais ces grosses trames elles remontent, de ce que je vois ici une fois toutes les lunes ou pendant une synchro.
Quand le device est en train de tourner, et qu’on chipote a rien, les infos elles remontent via des trames qui contiennent un tableau « updates » et dans ce tableau, on retrouve l’info de la batterie, mais ce n’est pas la même façon d’aller repêcher l’info, du coup l’info j’ai l’impression qu’elle est ignorée, et de fait, elle remonte pas, ou bien sérieusement, montre moi comment, car j’ai mon hub débranché depuis 45 minutes, je vois le pourcentage de batterie descendre dans l’appli AJAX et il se passe littéralement rien sur jeedom.
Je comprends que c’est pas facile à expliquer, mais je te dis ce que je vois dans les logs, je vois bien l’information passer, je la vois avec l’ID du device, user ID, et tout le bazar, et de l’autre coté, je vois que ça remonte pas dans jeedom.
Sans vouloir etre casse bonbon, avant de poster j’ai même pris la peine d’essayer d’aller voir dans le code d’où ça pourrait venir
Par contre pour clarifier le bazar : je ne suis pas en train de parler de SIA. Stop penser SIA LOL … je parle des messages spécifiques AJAX, que tu reçois même si le SIA est totalement désactivé
À oui ça cest Pas géré par le plugin. Globalement ce qui est géré c’est ce que j’ai pu testé il y a quelques années et c’est tout. Ajax ne documente pas l’api update car en vrai on est quelques dizaines à y avoir le droit dans le monde (je crois même que c’est une erreur qu’on y ait accès).
Donc effectivement la batterie n’est pas géré en update temps réel.
Bah c’est justement la partie que j’essaie de t’expliquer en te montrer des logs de production ici pour voir pour l’implémenter.
D’autres messages tu les as déjà implémentés, car je vois bien que par exemple tu gères le message d’update du statutGsm … et je vois que pour gérer la partie batterie, suffit de faire pareil, mais avec une autre clé pour aller chercher dans le tableau.
En vrai pour des choses dynamiques comme le niveau de batterie, la qualité du signal GSM etc, il faudrait implémenter de la même manière : via les trames updates.
Les trames sont simples, si tu veux je te les poste ici ou je te donne les clés des champs comme tu veux … ou bien je veux bien le faire, je suis jamais contre de contribuer quand je peux
Donne moi un peu de temps, car pour chaque truc je dois le stimuler, et par exemple, pour la batterie, je dois attendre que la valeur change, donc que ça se décharge, car comme tu sais, AJAX n’envoie les updates que quand t’as un truc qui change.
De ce que je vois dans l’API de l’application Android décompilée :
0 - Interface GSM désactivée:
1 - Interface GSM activée mais pas de connexion au réseau GSM
2 - Interface GSM activée et enregistrée sur le réseau GSM
Trame d’exemple :
[2023-10-01 20:55:57][DEBUG] : Received : {« apikey »:« aaaRCt3Lw55OnEQTy1DvQnqNV0iEcvOe »,« data »:[{« type »:« HUB »,« id »:« XXXXXX »,« updates »:{« gsmNetworkStatus »:0},« userId »:« XXXXXX »,« hubId »:« XXXXXX »}]}
Pour la partie batterie voici une trame d’update en exemple :
[2023-10-01 21:00:35][DEBUG] : Received : {« apikey »:« aaaRCt3Lw55OnEQTy1DvQnqNV0iEcvOe »,« data »:[{« type »:« HUB »,« id »:« 000AA0A5 »,« updates »:{« batteryCharge »:85},« userId »:« 3B5B80DF »,« hubId »:« 000AA0A5 »}]}
Donc la clé que tu cherches c’est batteryCharge.
J’ai pas encore le moyen aujourd’hui de faire le test sur un capteur, faut que je ressorte mon alimentation de labo pour simuler une pile en batterie faible.
Si je ne dis pas de connerie, pour les équipements qui vont sur secteur c’est cette trame là tout le temps. Donc, du matos que j’ai en ma possession, c’est valable pour le Hubs et les répéteurs.
Y a une autre trame plus générale pendant le « gros synchro » qui envoie d’autres infos, je tente de te générer ça
