Etat Alarme Ajax

Hello,

Pareil de mon côté ça faisait quelques temps que ça ne le faisait plus mais ça recommence. En SIA la MES et la MHS est bien remontée en temps réel et avec le plugin tout ce qui est commande action (commande MES,MHS, prise) fonctionne en instantané.
Du coup je rassemble les 2 infos pour vérifier la bonne mise en/hors service.
Mais pour les capteurs c’est chaud…

1 « J'aime »

J’ai également le problème de temps entends, c’est quand même assez gênant

Bonjour à tous,
Pareil, je rencontre le même souci.
Les remontées d’état se font aléatoirement.

Du coup, comme il y’a ce délai, et parce que j’ai un script à la con mal fichu qui fait de la synchro entre jeedom et HA, je me suis retrouvé à 4h du matin avec l’alarme activée.
Bien sur je ne l’ai su que tôt ce matin, quand j’ai tout fait sonner.

J’ai tout désactivé pour le moment, jusqu’à un retour normal des choses.

ça marche pas non plus chez moi depuis quelques jours. de toute façon ça n’a jamais marché de manière stable. ça plante sans crier gare, le jour, la nuit…

je ne l’ai jamais utilisé pour la partie alarme cela dit, j’ai tout codé en local via SIA et on utilise que l’app ajax avec la géolocalisation intégrée. on a jamais observé aucun raté de notre côté sur cette implémentation.

pour les états des portes et fenêtres, et bien j’ai bien peur aussi comme loic qu’il n’y ait pas de solution, vu le contexte en ukraine, comme c’est une solution de là bas, les coûts de leur api cloud sont certainement optimisés pour aller à l’essentiel.

Salut, j’ai également des soucis de remontée d’information. Particulièrement depuis hier.
Petite question : si on configure le SIA en local via Démon, la remontée des informations (par exemple capteur ouverture etc.) se fait en local du coup ? et on ne dépend plus du cloud ???

Par avance merci pour vos réponses :slight_smile:

Bonjour,
Comme dit plusieurs fois et aussi précisé dans la documentation : non il n’y a quasiment rien de local avec ajax hormis si l’alarme se declenche.

Hello, SIA protocol is local (in ajax setup I have internal IP address for Jeedom).
Since last update if I try to start SIA Daemon I get a 500 internal server error.
Logs (in debug mode) shows nothing…

Any help?

1 « J'aime »

Tiens, amusant, j’ai également l’erreur 500 quand je fais start demon.
Quand je l’ai stoppé il n’y a qu’une façon que je connais de le remettre en route : reboot jeedom

Bah j’ai activé SIA, au moins j’ai déjà la remontée d’info pour savoir si l’alarme est armée ou non, ce qui débloque déjà pas mal de mes scenarios.
Par contre mes scenarios basés sur ouverture / fermeture, je vais les desactiver pour le moment, alexa arrête pas de gueuler que les portes sont ouvertes ahaha :smiley:

Question : on saurait détecter qu’il y a des perturbations côté ajax ? et exposer le status du cloud ajax / webservices relais jeedom ? Avec cette commande on pourrait au moins avoir une notif qu’il y a un stud et eventuellement désactiver des scenarios à la volée pour mieux gérer les perturbations.
C’est juste une question :slight_smile:

Je pense qu’il y a un vrai probleme soit chez ajax soit entre jeedom et ajax.
Avant il n’y avait pas toute cette latence.
Je pense que ca vaudrait le coup de les contacter pour au moins connaitre les raisons.
Peut etrr qu’il y a aussi un problème chez eux sur leurs API ou sur un serveur et qu’ils ne sont pas au courant…

Bonjour Loïc, vous Avez des logs côté serveur des données qui arrivent ? Car c’est quand même bizarre qu’elles arrivent par paquet d’un coup… ( Le capteur de la porte peut s’activer 4 fois d’un coup en pleine journée, surement les évènements qui ne sont pas arrivée en temps réel) alors que sur leur application c’est en temps réel

Oui sur l’appli c’est en temps réel même quand on est connecté à distance.
Je pense qu’il y a un vrai souci quelque part…
D’autant que ca m’etonne de la part d’ajax de laisser des problemes de cet ordre.
Sauf si ils ne sont pas au courant d’ou la nécessité de les appeler.
A un moment donné je pense qu’il y a eu un acvord commercial pour l’implémentation d’ajax au sein de jeedom donc forcément qu’ils assurent un support sur leurs API quoi qu’il arrive

Bonjour
Oui bien évidemment j’ai passé ma soirée a faire des tests en direct en lisant directement la sqs et je confirme j’ouvre la fenêtre j’ai rien qui arrive je la ferme non plus et bouffe d’un coup j’ai tout qui arrive. J’ai même dans le doute doublé le nombre de worker de notre côté pour être sûr que le soucis ne venait pas de la et changé le batch (tout est en parallèle maintenant au lieu de 10 par 10).

J’ai aussi confirmé en pilotant une prise ou là le retour est immédiat et dès que je change l’état arrive tout de suite ce qui exclus donc un soucis de notre côté.

Sûrement honnêtement je peux pas trop te dire je m’occupe pas de ça mais je demande à la prochaine réunion que j’ai avec jeedom sas.

Hello,

Déjà lors de la mise en/hors service en comparant l’état entre le plugin SIA et le plugin AJAX, si incohérence alors soit tu envoie un message ou exécute l’action que tu veux faire ensuite.
Par contre si pas d’action particulière je ne pense pas qu’il y ait un moyen…

Je confirme le même problème sur les états des ouvrants ici. Sur l’appli c’est ok, sur Jeedom c’est visiblement HS sur l’ensemble des ouvrants armé comme désarmé.

2 « J'aime »

Ouais c’est une possibilité effectivement … après, ce que je demandais d’avoir un status de service, c’est pas si exotique que ça :stuck_out_tongue:

Je vais tenter de bricoler un truc autour de ce que tu proposes, ce sera déjà ça :stuck_out_tongue:
Merci à toi !

Un status je vois pas comment c’est possible, comment peut on savoir que le cloud Ajax nous envoi pas tout tout de suite ? Clairement c’est impossible

Le cloud ajax, effectivement j’ai pas d’idée la comme ca.

Par contre le serveur relais jeedom ce serait déjà un début :slight_smile:
J’avais eu la même pensée avec la partie skill AWS alexa.
C’est juste une idée hein.

1 « J'aime »

Si tous le monde envoi un mail ça bougra peut être ^^

contact@alarmeajax.fr