Le démon ne démarre pas malgré dépendances OK et service OK

rwaesely · Juin 4, 2024, 10:00

Bonjour,
J’ai installé les dépendances, cliqué sur le bouton de réinstallation du service, même redémarré la box, rien à faire. Le bouton du démon n’apparait même pas.

Je suis preneur de vos lumières

ddelec24 · Juin 4, 2024, 7:16

Bonsoir @rwaesely
comme l’indique la documentation.
1: installer les dépendances
2: installer le service (bouton orange) ça met en route un autre équipement du plugin officiel docker
3: ajouter votre équipement dans le plugin signal
4: vous pouvez activer le mode de réception en temps réel, et relancer l’installation du service. Là et seulement là, vous verrez le démon se lancer.

bref, suivez bien la documentation, que ça soit la stable ou la beta du plugin, je mets à jour chaque fois que j’ai une nouveauté ou une remonté utilisateur

si ça échoue toujours, une copie de votre page santé jeedom, les logs du plugin signal en « debug » en haut à droite, et fournissez les logs svp

Bonne soirée

rwaesely · Juin 5, 2024, 7:34

Merci beaucoup pour ta réponse. J’avais parcouru la doc et au passage, elle est super soignée, ça fait plaisir.
J’ai ajouté un équipement, et j’ai des erreurs qui remontent :

Mais il s’enregistre !
En suivant le lien pour le Qrcode affiche une pastille rouge, mais ça reste conforme à la doc : et lorsque je clique dessus, je constate qu’il renvoie vers une IP locale (j’accède à ma domotique via un DNS depuis Internet, donc bon…)
http://192.168.XXXX:8099/v1/qrcodelink?device_name=signal-api424
J’essaierai ce soir sur mon wifi, donc en LAN. Dommage que cela ne fonctionne pas en utilisant le DNS « courant ». Je te tiens au jus !

rwaesely · Juin 7, 2024, 9:11

Bon, j’ai pu accéder à la page chez moi, qui a bien affiché un QRCode, que j’ai scanné, ça m’a ouvert une activité android de Signal pour scanner le qrcode à nouveau (pour ma sécurité, qu’il disait)… J’arrive sur une page « Appareils associés » avec un bouton bleu « Associer l’appareil » et lorsque je clique dessus, échec ! Il mouline sur « Liaison de l’appareil », puis et j’ai un Toast « Erreur réseau ». Là, je sèche. La doc préconise de recharger la page de l’équipement, mais bien sûr la pastille est restée en croix rouge…

ddelec24 · Juin 8, 2024, 10:32

pouvez vous aller dans l’administration jeedom et me montre la configuration réseau svp? interne et externe.

Merci

ddelec24 · Juin 9, 2024, 4:07

tout parait ok à ce niveau, pourriez vous retenter en ayant mis les logs en « debug » svp et me les fournir?

rwaesely · Juin 9, 2024, 5:14

Alors c’est en cours, cette fois-ci, miracle, l’appairage sur signal a fonctionné. j’ai enregistré de nouveau l’équipement pour que la pastille passe au vert mais ça charge depuis bien 5 minutes

rwaesely · Juin 9, 2024, 5:19

la pastille reste rouge et le log en cours :

[2024-06-09 19:10:03] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:11:03] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:12:04] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:12:10] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:13:05] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:13:09] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:14:11] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:14:11] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:15:16] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:15:16] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'

rwaesely · Juin 9, 2024, 5:20

haaaaa ça y est la pastille est passé au vert. Bon bah le passage en debug semble avoir solutionné le truc… ou alors c’est une coincidence

ddelec24 · Juin 9, 2024, 5:22

suivant votre matériel, peut etre que tout n’était pas prêt ça prend du temps la première fois sur des raspberry ou autre, ou alors les serveurs d’authentification signal étaient dérangés.

Mais javais jamais vu cette erreur
n’hésitez pas à continuer la procédure pour activer la réception temps réel si vous avez besoin

bonne soirée

rwaesely · Juin 9, 2024, 5:25

ok merci. Pour l’instant le démon est toujours KO, mais je n’ai pas encore activé la réception des messages (car oui, j’ai lu la doc \o/). Je reviens poster mon avancement ici. J’ai beaucoup de contacts, ça peut expliquer que ça prenne du temps. Peut-être faudrait-il découper par paquet de 10-30 contacts pour éviter un overload ?

rwaesely · Juin 9, 2024, 5:38

Bon j’ai beau sauvegarder l’équipement rien ne s’affiche en contacts. Et l’équipement n’a aucune commande. Je pense que le souci persiste finalement.

rwaesely · Juin 9, 2024, 5:44

Je sauvegarde l’équipement, ça part en timeout. Le plugin fonctionne peut-être chez des gens avec peu de contacts ?

[2024-06-09 19:10:03] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:11:03] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:12:04] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:12:10] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:13:05] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:13:09] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:14:11] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:14:11] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:15:16] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:15:16] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'
[2024-06-09 19:16:16] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:17:22] DEBUG  : [RETOUR RECEIVE] {"error":"process killed as timeout reached"}
[2024-06-09 19:40:44] DEBUG  : [GROUPS] Envoi Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/groups/+42348756532'
[2024-06-09 19:40:55] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:41:53] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:42:53] DEBUG  : [GET CONTACTS] Requête:<br/>curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/identities/+42348756532'
[2024-06-09 19:42:55] DEBUG  : [GROUPS] Retour: {"error":"process killed as timeout reached"}
[2024-06-09 19:42:55]WARNING : [GROUPS] Error : process killed as timeout reached
[2024-06-09 19:42:55] DEBUG  : [RECEIVE] Requête: curl -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/receive/+42348756532'

ddelec24 · Juin 9, 2024, 5:53

y’a pas de raison, on dirait qu’il bloque sur les groupes.
pour avancer, j’irais voir dans le plugin « docker management », il y a un équipement signal, qui doit aussi générer des logs en haut à droite (logs conteneur)

et aussi je testerais une commande
Menu Réglages => Système => Configuration, aller sur l’onglet >_OS/DB puis le bouton _>Administration Système
saisir:

curl -v -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/groups/+42348756532'

ça devrait etre un peu plus verbeux qu’à travers mon plugin.

rwaesely · Juin 9, 2024, 6:06

Merci pour ton aide. Log du conteneur :

2024-06-04T10:05:04.918483364Z + [ -z /home/.local/share/signal-cli ]
2024-06-04T10:05:04.919183159Z + grep -c www-data /etc/passwd
2024-06-04T10:05:04.932254307Z + exists=1
2024-06-04T10:05:04.932359151Z >>> Check if www-data exists : 1
2024-06-04T10:05:04.932541495Z + echo >>> Check if www-data exists : 1
2024-06-04T10:05:04.932710715Z + [ 1 -eq 1 ]
2024-06-04T10:05:04.932835090Z + userdel www-data
2024-06-04T10:05:13.923490312Z >>> Creating user signal-api
2024-06-04T10:05:13.923690365Z + echo >>> Creating user signal-api
2024-06-04T10:05:13.923947241Z + usermod -u 33 signal-api
2024-06-04T10:05:16.949809815Z + groupmod -g 33 signal-api
2024-06-04T10:05:18.720425527Z + set -e
2024-06-04T10:05:18.720810529Z + echo >>> Update signal-api UID/GID
2024-06-04T10:05:18.720952821Z + chown 33:33 -R /home/.local/share/signal-cli
2024-06-04T10:05:18.730282547Z >>> Update signal-api UID/GID
2024-06-04T10:05:19.014241847Z + cat
2024-06-04T10:05:19.021391356Z + cap_prefix=-cap_
2024-06-04T10:05:19.037529860Z + cat /proc/sys/kernel/cap_last_cap
2024-06-04T10:05:19.037701944Z + seq -s ,-cap_ 0 40
2024-06-04T10:05:19.039078460Z + caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40
2024-06-04T10:05:19.039306638Z + [ normal = json-rpc ]
2024-06-04T10:05:19.046536929Z + + hostnameawk {print $1} -I
2024-06-04T10:05:19.046823753Z
2024-06-04T10:05:19.058436978Z + export HOST_IP=172.18.0.3
2024-06-04T10:05:19.058680625Z + exec setpriv --reuid=33 --regid=33 --init-groups --inh-caps=-cap_0,-cap_1,-cap_2,-cap_3,-cap_4,-cap_5,-cap_6,-cap_7,-cap_8,-cap_9,-cap_10,-cap_11,-cap_12,-cap_13,-cap_14,-cap_15,-cap_16,-cap_17,-cap_18,-cap_19,-cap_20,-cap_21,-cap_22,-cap_23,-cap_24,-cap_25,-cap_26,-cap_27,-cap_28,-cap_29,-cap_30,-cap_31,-cap_32,-cap_33,-cap_34,-cap_35,-cap_36,-cap_37,-cap_38,-cap_39,-cap_40 signal-cli-rest-api -signal-cli-config=/home/.local/share/signal-cli
2024-06-04T10:05:19.271529735Z time="2024-06-04T11:05:19+01:00" level=info msg="Started Signal Messenger REST API"
2024-06-05T07:26:56.480365847Z [GIN] 2024/06/05 - 08:26:56 | 404 |       6.302µs |      172.18.0.1 | GET      "/v1/identities/"
2024-06-05T07:26:56.585246239Z [GIN] 2024/06/05 - 08:26:56 | 404 |       5.521µs |      172.18.0.1 | GET      "/v1/receive/"
2024-06-05T07:27:56.152813120Z [GIN] 2024/06/05 - 08:27:56 | 500 | 37.385779078s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-05T07:28:14.589629055Z [GIN] 2024/06/05 - 08:28:14 | 400 | 18.333299819s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-05T07:29:46.406648993Z [GIN] 2024/06/05 - 08:29:46 | 500 | 18.009111165s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-05T07:30:04.388722005Z [GIN] 2024/06/05 - 08:30:04 | 400 | 17.881285291s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-05T22:01:16.904154219Z [GIN] 2024/06/05 - 23:01:16 | 400 | 36.500550552s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-06T22:01:27.116833782Z [GIN] 2024/06/06 - 23:01:27 | 400 | 43.510149855s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-07T21:00:37.970607979Z [GIN] 2024/06/07 - 22:00:37 | 200 |          1m2s |    192.168.1.23 | GET      "/v1/qrcodelink?device_name=signal-api424"
2024-06-07T21:00:38.130243096Z [GIN] 2024/06/07 - 22:00:38 | 404 |       5.468µs |    192.168.1.23 | GET      "/favicon.ico"
2024-06-07T21:11:55.144958154Z [GIN] 2024/06/07 - 22:11:55 | 200 | 48.881567451s |    192.168.1.23 | GET      "/v1/qrcodelink?device_name=signal-api424"
2024-06-07T22:01:06.721876127Z [GIN] 2024/06/07 - 23:01:06 | 400 | 29.544581522s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-08T22:01:13.690507183Z [GIN] 2024/06/08 - 23:01:13 | 400 | 27.182069811s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:09:15.887240745Z [GIN] 2024/06/09 - 18:09:15 | 200 | 38.861629107s |    192.168.1.23 | GET      "/v1/qrcodelink?device_name=signal-api424"
2024-06-09T17:09:15.986766145Z [GIN] 2024/06/09 - 18:09:15 | 404 |        6.51µs |    192.168.1.23 | GET      "/favicon.ico"
2024-06-09T17:12:10.108569077Z [GIN] 2024/06/09 - 18:12:09 | 500 |          2m3s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:13:10.204624174Z [GIN] 2024/06/09 - 18:13:08 | 500 |          2m4s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:14:11.599524097Z [GIN] 2024/06/09 - 18:14:10 | 500 |          2m2s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:14:11.924058944Z [GIN] 2024/06/09 - 18:14:10 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:15:16.607075918Z [GIN] 2024/06/09 - 18:15:16 | 500 |          2m4s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:15:16.650970105Z [GIN] 2024/06/09 - 18:15:16 | 400 |          2m4s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:16:16.561573363Z [GIN] 2024/06/09 - 18:16:15 | 400 |          2m3s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:17:22.668301468Z [GIN] 2024/06/09 - 18:17:22 | 400 |          2m1s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:22:52.936137153Z time="2024-06-09T18:22:52+01:00" level=info msg="INFO  AccountHelper - The Signal protocol expects that incoming messages are regularly received."
2024-06-09T17:22:53.577479396Z [GIN] 2024/06/09 - 18:22:53 | 200 |         1m16s |      172.18.0.1 | GET      "/v1/groups/+42348756532"
2024-06-09T17:23:33.676328427Z time="2024-06-09T18:23:33+01:00" level=info msg="INFO  SignalAccount - Config file is in use by another instance, waiting…"
2024-06-09T17:23:33.677221191Z time="2024-06-09T18:23:33+01:00" level=info msg="INFO  SignalAccount - Config file lock acquired."
2024-06-09T17:23:33.677400671Z time="2024-06-09T18:23:33+01:00" level=info msg="INFO  AccountHelper - The Signal protocol expects that incoming messages are regularly received."
2024-06-09T17:23:33.688544829Z [GIN] 2024/06/09 - 18:23:33 | 200 |         1m47s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:24:33.486648724Z time="2024-06-09T18:24:33+01:00" level=info msg="INFO  SignalAccount - Config file is in use by another instance, waiting…"
2024-06-09T17:24:37.768519357Z [GIN] 2024/06/09 - 18:24:37 | 200 |         1m51s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:24:33.577081838Z time="2024-06-09T18:24:33+01:00" level=info msg="INFO  SignalAccount - Config file lock acquired."
2024-06-09T17:24:40.506261562Z time="2024-06-09T18:24:33+01:00" level=info msg="INFO  AccountHelper - The Signal protocol expects that incoming messages are regularly received."
2024-06-09T17:25:34.739198420Z [GIN] 2024/06/09 - 18:25:34 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:25:46.886356835Z [GIN] 2024/06/09 - 18:25:46 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:26:46.214393482Z [GIN] 2024/06/09 - 18:26:46 | 400 |          2m2s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:26:48.130888581Z [GIN] 2024/06/09 - 18:26:48 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:28:01.271597296Z [GIN] 2024/06/09 - 18:28:01 | 400 |          2m7s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:28:51.445900197Z [GIN] 2024/06/09 - 18:28:51 | 400 |          2m2s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:33:47.794063552Z [GIN] 2024/06/09 - 18:33:46 | 500 |         2m10s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:34:17.727176713Z [GIN] 2024/06/09 - 18:34:17 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:35:17.156225896Z [GIN] 2024/06/09 - 18:35:17 | 500 |          2m2s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:35:49.259702770Z [GIN] 2024/06/09 - 18:35:49 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:36:18.837045618Z [GIN] 2024/06/09 - 18:36:18 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:36:19.037360822Z [GIN] 2024/06/09 - 18:36:17 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:37:21.663132852Z [GIN] 2024/06/09 - 18:37:21 | 400 |          2m3s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:38:26.910975482Z [GIN] 2024/06/09 - 18:38:26 | 400 |          2m5s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:42:55.321133685Z [GIN] 2024/06/09 - 18:42:55 | 400 |         2m10s |      172.18.0.1 | GET      "/v1/groups/+42348756532"
2024-06-09T17:42:55.613105464Z [GIN] 2024/06/09 - 18:42:55 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:43:53.960742535Z [GIN] 2024/06/09 - 18:43:53 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:44:59.346871249Z [GIN] 2024/06/09 - 18:44:59 | 500 |          2m2s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:44:59.498593074Z [GIN] 2024/06/09 - 18:44:59 | 400 |          2m2s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:46:02.454853177Z [GIN] 2024/06/09 - 18:46:02 | 400 |          2m2s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:46:02.645116775Z [GIN] 2024/06/09 - 18:46:02 | 500 |          2m2s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:47:19.409688040Z [GIN] 2024/06/09 - 18:47:15 | 400 |          2m8s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:47:46.636284951Z [GIN] 2024/06/09 - 18:47:46 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/groups/+42348756532"
2024-06-09T17:48:08.835630276Z [GIN] 2024/06/09 - 18:48:08 | 400 |          2m2s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:48:34.013764231Z [GIN] 2024/06/09 - 18:48:34 | 200 |         2m39s |    192.168.1.23 | GET      "/v1/qrcodelink?device_name=signal-api424"
2024-06-09T17:52:19.564632996Z [GIN] 2024/06/09 - 18:52:19 | 500 |          2m3s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:53:12.732883833Z [GIN] 2024/06/09 - 18:53:12 | 500 |          2m0s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:54:19.045563385Z [GIN] 2024/06/09 - 18:54:18 | 500 |          2m2s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:54:20.274620225Z [GIN] 2024/06/09 - 18:54:20 | 400 |          2m0s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:55:15.044228687Z [GIN] 2024/06/09 - 18:55:14 | 500 |          2m1s |      172.18.0.1 | GET      "/v1/identities/+42348756532"
2024-06-09T17:55:15.209918349Z [GIN] 2024/06/09 - 18:55:14 | 400 |          2m1s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:56:28.393204216Z [GIN] 2024/06/09 - 18:56:27 | 400 |          2m7s |      172.18.0.1 | GET      "/v1/receive/+42348756532"
2024-06-09T17:57:23.558922868Z [GIN] 2024/06/09 - 18:57:23 | 400 |          2m1s |      172.18.0.1 | GET      "/v1/receive/+42348756532"

Puis l’appel curl :

Eeeeet oui le curl ne renvoie rien ! en fait la page a chargé pendant bien 5 minutes. Puis ça a du faire un timeout.

ddelec24 · Juin 9, 2024, 6:12

ah ouai…

si tu as un accès ssh, tu pourrais tester la commande, tu auras le retour complet une fois le timeout arrivé

curl -v -X GET -H "Content-Type: application/json" 'http://localhost:8099/v1/groups/+42348756532?timeout=60'

je sais pas si ça va marcher l’option timeout en bout de ligne

tu as combien de contacts/groupes à synchroniser? j’avoue pour l’instant je dois avoir que des membres ayant des petites commu signal

rwaesely · Juin 9, 2024, 6:20

Techniquement j’ai pas non plsu 2000 contacts mais je dois bien en avoir une centaine au moins.
Marrant ta demande, j’avais justement lancé SolarPutty

Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 8099 (#0)
> GET /v1/groups/+42348756532?timeout=60 HTTP/1.1
> Host: localhost:8099
> User-Agent: curl/7.64.0
> Accept: */*
> Content-Type: application/json
>
< HTTP/1.1 400 Bad Request
< Content-Type: application/json; charset=utf-8
< Date: Sun, 09 Jun 2024 18:19:01 GMT
< Content-Length: 45
<
* Connection #0 to host localhost left intact
{"error":"process killed as timeout reached"}

donc le timeout n’a pas fonctionné

ddelec24 · Juin 9, 2024, 6:24

Et la premiere requete sans le ?timeout=60 ça te dit quoi? vraiment je vois pas. je vois erreur 500 dans les logs conteneur donc c’est coté signal et pas moi

rwaesely · Juin 9, 2024, 6:28

Je suis en train de la lancer sans le timeout. Question subsidiaire : le fait que toutes les requêtes passent avec du localhost au lieu du DNS « internet », ça pose pas de souci pour communiquer avec l’API de signal ? il a pas besoin d’avoir une URL accessible sur internet ?

ddelec24 · Juin 9, 2024, 6:35

pour faire simple, mon plugin interroge un script qui est dans un container docker (donc avec le plugin docker management de jeedom, qui est en local)
donc ça fait plugin signal => docker local => contact les serveurs

javais pris cette option pour éviter de faire des environnements python, mais c’est quand même plus gourmand en ressources c’est vrai