Etat Alarme Ajax

Bonsoir à tous.
Je rencontre depuis ce jour des problèmes de remonter sur l’état de mon alarme Ajax.
Les commandes sembles fonctionnelles, mais l’état ne se met plus a jour.
Je n’ai volontairement pas rajouter de log, car on y voit dans ceux ci des infos de type apikey, mais j’en ai a disposition pour transmettre avec un ticket si je suis un cas isolé.
La question est plus de savoir si vous rencontrer également ce problème de fonctionnement.

Merci pour vos retour.

1 « J'aime »

Bonjour
Je n’ai pas de soucis de mon côté, es tu sur de ton URL d’accès externe ? N’as tu pas des soucis de ce côté là ? Dans 99% des soucis sur ce plugin ça vient de la.

Ca semble revenu. Les état sont remontés avec une heure de décalage environ declanchant les scénarios associés… Pour le côté waf on repassera madame s’est retrouvé dans le noir plusieurs fois :rofl:.
Mais oui ca fonctionnait partiellement dans le sens ou les commandes d’armements fonctionnait. Seul le statut ne voulait pas s’actualiser.
Merci pour ta réponse en tt cas.
A surveiller.

je ne sais pas si c’est récurrent mais à de nombreuses reprises j’ai observé la même chose ces derniers temps. il me restait un scénario lié au statut de la centrale via le plugin. je précise que mon accès internet est parfaitement fonctionnel, je suis en pack power (donc dns jeedom).

En fait, pour éviter les A/R via jeedom et ajax systems sur le cloud, j’utilise le plugin SIA PRO qui coûte presque rien. lui marche 100% du temps depuis le début et renvoie sans faillir dans la seconde suivante le code SIA de l’opération. tous mes scénarios sont donc déclenchés et drivés par des listes de codes. c’est pas aussi convivial mais la liaison est intra-lan ip locale ajax à ip locale jeedom. le niveau de panne est donc quasi nul.

pour analyser les états, j’ai créé un bout de code php qui décode complètement les états et les classifient. avec ce résultat pas de souci pour détecter les éléments principaux (armé, désarmé, mode nuit, dysfonctionnement, fin de dysfonctionnement et bien sûr intrusion).

je trouve que tout ça se complète fort bien. le plugin officiel est convivial et remonte plutôt bien les ouvertures/fermetures de portes/fenêtres. mais pour le reste c’est très aléatoire pour une raison que je n’ai pas eu le temps d’investiguer. du coup la solution sia pro est toute indiquée.

1 « J'aime »

Merci pour ton retour. Il faut que je regarde de plus près cela.

Effectivement le SIA étant 100% local ca sera forcement plus fiable.

Après perso j’ai une connexion internet vraiment pas top (multiple coupure par jour) et pourtant je n’ai aucun raté donc c’est vraiment bizarre. Le plus simple pour savoir si c’est un soucis jeedom ou ajax c’est de regarder les logs jeedom le moindre message venant d’ajax est ecris dans les logs

J’y ai jeter un oeil, sur la phase ou ca semblait ne pas marcher pour moi , je ne voyais pas me semble il ( je ne suis pas expert pour lire ce genre de données) remonter correctement le statut de l’alarme. Par contre je pouvais passer les commandes d’activation et désactivation de l’alarme pas le plugin via le dashboard.(d’ou pour moi le liens avec le compte ajax ok).
Je peux tjrs essayer de les envoyer en mp si tu le souhaites, je ne voulais pas les mettres ici car on voit des infos de token que je ne voulais pas diffuser.

De mon côté j’ai zéro choses dans les logs quand ça « rame ». juste un grand vide de communication et ça se resynchronise plus tard tout seul sans rien faire. genre 1h plus tard.

ça arrive chez moi souvent le soir à l’armement. une fois, c’est arrivé au désarmement, le matin, j’ai donc rebooté le serveur jeedom et pareil, pas de mise à jour.

j’ai même pressé le bouton de synchro pour recharger tous les objets et rien, pas de mise à jour de l’état.

J’en ai déduit que le souci était peut être en amont ailleurs.

Si ça arrive une heure plus tard c’est côté ajax alors, je viens de regarder on retransmets les évènements en moins de 100ms…

Bonjour à tous,

Je rencontre également le problème depuis quelques jours.
Après quelques tests je me suis aperçu que c’était surtout le retour d’état qui aléatoirement long, les commandes "armement, désarmement " depuis Jeedom quant a elles passent bien en instantané.

Exemple: désarmement à 14h58 via l’application AJAX

Log du plugin ajaxSystem

 : Impossible de lancer le démon ajaxSystemd, vérifiez le log
[2023-03-20 15:33:17]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"HOME_SIREN","id":"AAAAAA","updates":{"temperature":25},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:33:32]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"HOME_SIREN","id":"AAAAAA","updates":{"temperature":24},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:34:11]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"HUB","id":"ZZZZZZZ","updates":{"state":0},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:34:19]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"DOOR_PROTECT","id":"BBBBBB","updates":{"reedClosed":0},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:34:22]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"DOOR_PROTECT","id":"BBBBBB","updates":{"reedClosed":1},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:36:38]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"MOTION_PROTECT","id":"CCCCCC","updates":{"temperature":23},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:37:18]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"HUB","id":"ZZZZZZZ","updates":{"gsmTrafficRx":147733},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}
[2023-03-20 15:37:51]DEBUG : Received : {"apikey":"XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX","data":[{"type":"MOTION_PROTECT","id":"CCCCCC","updates":{"temperature":22},"userId":"MOIMOI","hubId":"ZZZZZZZ"}]}

Je n’ai pas d’erreur dans les logs
Je ne sais pas si ça peut aider mais c’est un exemple de ce qui se produit chez moi.

Version plugin ajaxSystem : 2022-08-24
Hardware HUB Ajax: 7.0.3.1.1.2.1.0
Firmware HUB: EU 2.14.1

URL accès externe Jeedom: OK

Bonne soirée

Bonjour,
A mon avis c’est chez ajax le soucis, il faut savoir que nous envoyer les event ca leur coute de l’argent et nous sommes loin d’etre prioritaire…

1 « J'aime »

Juste pour ma culture vous avez utilisé l’entreprise API pour faire le plugin ?
Merci
Bonne soirée

Bonjour
Oui

1 « J'aime »

De mon coté j’ai des problèmes de remontées d’état d’ouverture de capteur, même alarme désarmée…
l’état du reedclose est complètement incohérent et change n’importe quand aléatoirement.
Ca aussi ça passe par ajax ? ou ça reste full local ?
Effectivement il y a l’air d’avoir un décallage très important

C’est ajax cloud, il n’y a quasiment rien de local avec ajax malheureusement si ce n’est l’état de l’alarme et si ya une alerte.

J’ai fait pas mal de test et je confirme c’est coté ajax le soucis, sur des truc comme l’activation désactivation d’une prise j’ai le retour immédiatement, par contre effectivement sur les fenêtres j’ai pas de tout de suite… Je suppose qu’ils ont en fonction de la priorité de l’événement un traitement différent d’ou le soucis.

Ok merci.
Du coup c’est pas vraiment exploitable en l’etat.
As tu ouvert un ticket chez eux ?
Avant on n’avait pas ce problème…
Merci

J’aimerais mais je n’ai aucun contact ou page pour ouvrir des tickets chez ajax… Et oui je confirme c’est inutilisable.

Ils ont une hotline assez reactive sur telegram. On peut directement leur parler.
J’avais eu besoin d’eux l’été dernier quand j’etais en vacances pour activer l’alarme suite à un bug.
En 1h c’ete réglé.
Peut etre fait il les contacter de cette façon au sujet des API ?

Sinon les etats des capteurs sont dispos en SIA local alarme desarmée ?

Je pense pas me faudrait le support pro mais je sais pas comment y acceder…

Pour les état des capteurs dis dans la doc (et ici aussi) tu n’as rien si l’alarme est inactive.

1 « J'aime »