@alciol, j’ai demandé à Domotique-Store s’ils avaient des retours avec leur clef GSM Wizelec, et ils m’ont répondu ne pas avoir de retours négatifs de leurs clients.
Il m’ont dit autre chose d’interessant:
Selon eux, la clef wizelec qu’ils vendent est reconnue comme une Huawei E220 par Jeedom.
Il me semble que c’est la Wizelec en question que tu possèdes.
Est-ce le cas de ton côté ?
Par ailleurs, j’ai avancé et trouvé une clef Huawei E220 officielle d’occasion sur le forum, je ferai un test dès que je la reçois et te donnerai mon retour.
Je ne sais pas comment voir comment est interprété la clef gsm par jeedom et oui j’ai acheté le clef GSM sur domotique-store.
Le problème changé de hardware avec une clef hyper difficile à se procurer n’est pas une solution pour moi
Je suis arrivé à garder une connexion stable sur le pi4 avec la clef gsm, faudrait comprendre pourquoi maintenant. J’avais le pi + hub sur une alim vairable, j’ai sous alimé le pi (juqu’au point que la led rouge « power » était éteinte), et la sa marché nickel.
Pour moi c’est pas une solution car le pi est sous alimenter donc perte de puissant, fiabilité, durabilité… c’était vraiment pour une phase de test.
J’ai un pi 4piB rev1.2, un carte d’extension X828 (fait prise sata + hub USB), une alimentation 5V 5A ajustable. L’alimentation est branche sur la carte x828 puis repiqué sur le pi. J’ai remarqué que la duré avant plantage de la GSM varier avec la tension que j’envoiyer. Jusqu’au moment de ras-de-bole ou j’ai tourner la vise ajustable à la rache, la led rouge du pi « power » c’est éteinte, et la pendant 4 jour la gsm n’a pas planté. Malheureusment j’ai pas pris la mesure de tension, faudrait que je refasse des teste mais je pense pas que le pie aime beaucoup sa…
J’ai regardé les forums et j’ai trouvé cette clef, quelqu’un la installé sur home assistant et un pi4b, peut-être que sa fonctionnerai aussi avec jeedom… a tester je pense non ?
Salut ! Je suis entrin de réaliser un test et depuis 1 jours j’ai pas eu de perte de la clef GSM ! YOUHOU !!!
Si tu veux essayer la même configuration que moi pour valider la chose, je laisse tourner et je te tiendrais au courant s’il retombe en echec.
Alors premièrement, la clef GSM était bien avec un chipset de la E220, je l’ai flashé j’ai mis le dernier soft du E3372h-153 Firmware 22.180.05.00.00 avec la procédure suivante.
J’ai utilisé la procédure de @akenad pour paramétrer l’usb switch pour que jeedom puisse la reconnaitre comme clef GSM.
J’ai installé la dernier version stable de l’eeprom du 16/01/2021 (j’ai essayer la dernière version critical, il tomber en echec après quelque heure)
J’ai branché le hub en USB2 (en usb3.0 tombé en echec après quelque heure).
bleuthoo désactivé
wifi est opérationnel
raspberry pi4b rev1.2
hub usb3.0 + 2 prise sata (carte extension x829 du pi)
tourne sur carte SD
J’ai remarqué que les démons c’est relancé de lui même mais la clef GSM n’est pas tombé en erreur. affaire à suivre je vous tiendrais au courant si sa retombe en échec ou si le système devient stable.
Une fois le test validé, je vais basculer mon system sur le SSD de la carte x829 branché sur la prise usb3.0 du pi, puis j’ai acheter le zero4u pour faire le hub usb2.0 branché sur la prise usb2.0 du pi.
De mon côté j’ai reçu la clef e220 et ça ne marche pas du tout.
Du coup, j’ai rebranché la e3372h-153 en la déplaçant pour capter mieux, j’ai une moyenne de 13/30 plutôt stable, cette fois le démon tient, j’en déduis que la force du signal y est pour bcp dans la stabilité de l’ensemble…
J’attends un peu pour voir combien de temps il tient !
J’essaie de simuler un signale faible pour voir si le démon devient instable comme toi, j’ai enrouler la clef GSM dans de l’aluminium relier à la masse et je capte 5/30…
Sa me parrait bizarre que la stabilité dépendrais de la force du signal.
Je ne sais pas exactement comment cela fonctionne, mais j’avais des chutes à 2-3/30 régulièrement qui duraient longtemps, au point que la clef se remettait à clignoter vert (quand tout va bien et que la synchro. est bonne la LED clignote en bleue chez moi).
2021-02-04 06:50:03][DEBUG] : Client disconnected from [127.0.0.1:35260]
[2021-02-04 11:45:14][DEBUG] : Client connected to [127.0.0.1:41522]
[2021-02-04 11:45:14][DEBUG] : Message read from socket: XXXX
[2021-02-04 11:45:14][DEBUG] : Client disconnected from [127.0.0.1:41522]
[2021-02-04 11:45:48][DEBUG] : Client connected to [127.0.0.1:41542]
[2021-02-04 11:45:48][DEBUG] : Message read from socket: XXXX
[2021-02-04 11:45:48][DEBUG] : Client disconnected from [127.0.0.1:41542]
[2021-02-04 12:16:30][DEBUG] : Client connected to [127.0.0.1:42016]
[2021-02-04 12:16:30][DEBUG] : Message read from socket: XXXX
[2021-02-04 12:16:30][DEBUG] : Client disconnected from [127.0.0.1:42016]
[2021-02-04 17:30:47][DEBUG] : Client connected to [127.0.0.1:48666]
[2021-02-04 17:30:47][DEBUG] : Message read from socket: XXXX
[2021-02-04 17:30:47][DEBUG] : Client disconnected from [127.0.0.1:48666]
[2021-02-04 18:10:36][DEBUG] : Client connected to [127.0.0.1:49422]
[2021-02-04 18:10:36][DEBUG] : Message read from socket: XXXX
[2021-02-04 18:10:36][DEBUG] : Client disconnected from [127.0.0.1:49422]
[2021-02-04 18:25:56][DEBUG] : Client connected to [127.0.0.1:49754]
Je en comprends pas la numérotation des ports après les « 127.0.0.1: » par exemple ?
On dirait qu’il essaye de se connecter en changeant de port à chaque fois…
Salut @Domatizer, merci pour ton intérêt.
Je te confirme être sur Rpi4.
Oui j’ai fait un gros travail déjà en suivant a la lettre les tutos d’Akenad.
Pour les ports, je ne parle pas des ports USB mais des ports « virtuels » au sens de ce que je vois dans le log. Je ne comprends pas bien le fait de passer de 127.0.0.1:49422 à 127.0.0.1:42016 à 127.0.0.1:48666, etc.
Salut,
Je suis tombé sur quelqu’un sur un autre forum facebook qui fesais tourner une clef GSM E220 sur deux pi4b sans aucun problème. Je n’ai pas pu beaucoup échanger avec lui pour connaitre la configuration exacte de sont hardware malheureusement, mais cela confirme bien qu’il est possible de rendre ce système stable !
D’après ce que j’ai compris son installation dâte un peu, donc plus sa vient plus je pense que le problème viens de la version de l’eeprom.
D’après mes test, il faut absolument un hub 2.0 alimenté branché sur un port usb2.0 du pi. Ensuite il faut changé la version de l’eeprome, je suis sur la dernière version stable, cela fait exactement 25H que mon installation est mis en route pour l’instant sa tient (c’est la première fois que mon installation est stable aussi longtemp).
@alexcrp essaie de basculer sur la version eeprom de @akenad, je te tiens au courant si mon installation tombe en échec.
Comme dis au dessus à un moment sa doit planter niveau communication entre le pi et la clef gsm, un timeout, problème de tension ou je ne sais quoi, et le port se déconnecte d’où l’erreur « GSM : None » cela fait planter la clef car même un redémarage du pi ne suffit pas a relancer le service, il faut rebooter la clef. Je pense que d’après tes logs, vu que le raspberry pense toujours que la clef GSM est disponible mais n’arrive pas a communiqué avec, il essait différent port.
