[Edit]
Flasher la clef e3372h-153 en firmware “stick” num. 21.180.01.00.00 + gérer le multimode selon tuto LeCrabe on rendu la clef stable sur ma config (voir solution). Mille merci à @Alciol, @akenad, pour leurs aides à venir à bout du sujet. A dispo si besoin pour d’autres qui auraient des soucis similaires…
Bonjour à tous,
aujourd’hui un retour d’expérience sur un sujet qui m’a monopolisé beaucoup de temps, des heures et des heures de tests, en espérant que cela puisse être utile à d’autres.
J’ai d’énormes soucis à faire fonctionner une clef USB 4G - pourtant récente et quasi-omniprésente des tutos actuels sur le sujet - il s’agit du modèle Huawei e3372h-153. J’ai écumé toutes les procédures possibles (vider les sms de la carte sim, changer d’emplacement pour capter mieux, … ) plusieurs fois (dont les excellents tutos d’@akenad), discuté pas mal avec @alciol pour essayer de trouver une issue, cela a fonctionné pour lui, il a la version Wizelec commandée chez domotique store et reçu couleur noire avec un logo huawei, voir en détails le post concerné ici et au passage son excellent résultat de box DIY.
Dans mon cas, la clef est un modèle blanc acheté sur Amazon, qui a bien l’air d’être une originale fabricant (logos, packaging, etc).
Dans l’ordre les différents essais:
-
La clef a été achetée en Avril 2020, il s’agit d’un modèle Huawei e3372h-153, avec un firmware d’usine « Hi-Link » n° 22.328.62.00.1217, branchée en USB 2 sur hub (alimenté) au Pi. J’ai tout fais niveau branchements (avec ou sans le hub, USB2 ou USB3, etc): elle n’était pas reconnue en sortie de boite par le Pi dans le plugin SMS.
Ci-après les infos de DC Unlocker sur le modele sorti d’usine, sans bidouille:
-
Du coup recherches sur le forum Jeedom et tuto d’akenad avec le usb_modeswitch: cela a bien fait apparaitre la clef, a permis d’envoyer et de recevoir des sms, mais le démon plante au bout de +/- 10h, en restant affiché en vert. Les logs montrent différents types de messages d’erreur au moment du plantage. C’est à ce moment là que démarre ma longue série d’investigations…
(Je note au passage que la clef était reconnue en « 12d1:14dc » avec la commande lsusb avant la manip du fichier rajouté pour usb_modeswitch, exactement reconnue par defaut comme chez @oussama1984 dans son post ici ). -
Achat de 2 autres modèles + anciens de clefs USB GSM d’occasion: Huawei e220 et no-name HSDPA (reconnu tout de même comme hardware huawei avec lsusb…), aucune n’a fonctionné avec le plugin GSM.
J’en profite pour indiquer que la HSDPA était catastrophique = réception 4/30, opérateur affiché Orange (alors que Free normalement…), bref c’est du matos très obsolète à notre époque je pense…
J’avais aussi essayé de soliciter la communauté pour connaitre d’autres modèles de clefs compatibles, sans succès. -
Re-utilisation de la clef e3372h-153 avec installation du plugin GAMMU, en me résignant à utiliser un plugin non officiel si cela pouvait fonctionner: n’a pas fonctionné.
-
Remplacement du Pi 4B 4Go rev. 1.2 par un Pi 4B 8Go rev. 1.4:
suite au succès d’@alciol, l’idée était de miser sur la MAJ de la carte mère du Pi et d’éventuelles corrections de gestion des ports USB qui pourrait faire défaut (en me disant qu’au pire ça me ferait une config un peu plus véloce pour anticiper les futures évolutions de mon installation).
Avec au passage, installation de Pi OS Lite Buster 64 bits (au lieu de Pi OS Lite Buster 32 bits).
→ Cela n’a pas eu l’effet escompté, toujours les mêmes soucis de plantage de clef au bout de quelques heures. -
Flash du firmware de la clef de Hi-Link vers Stick:
ne trouvant pas d’issue et quitte à avoir une clef USB inutile, j’ai entrepris de la flasher, en suivant le tuto de haut vol récent ici, avec des infos prises là et d’un autre tuto là (c’était Impossible avec les méthodes via DC unlocker sous windows, la clef avait un firmware trop récent d’usine, qui empechait le modèle de clef d’être bien reconnu par DC unlocker qui la lisait bizarrement comme « AuthVer 4 modem (new) »).
→
ATTENTION: c’est de la bidouille de haut vol (= démontage de la clef + manip. avec un cable pour « shunter » un circuit en même temps qu’on la branche 
+ installation de repos. github russes 
…), c’est 100% linux en lignes de commandes (pas de softs à installer), mais ça marche: le firmware a bien été remplacé et la clef est bien en mode stick après coup.
Sans faire d’usb_modeswitch, la clef affiche 2 ports dans le plugin SMS et le premier fait le job. avec démon ok. et envoi + réception sms ok.
(Je note au passage que la clef « accroche » très très vite le réseau GSM (= passage du voyant vert au bleu) par rapport au firmware « hi-link » qui était + long…).
—> Même constat en Stick qu’en Hi-Link, arrêt de la clef au bout de quelques heures avec un démon toujours vert. Voilà ce que j’ai quand ça tombe ( ‹ Exception on GSM : None ›):
[2021-04-25 15:14:48][DEBUG] : Send to jeedom : {'message': '17', 'number': 'signal_strength'}
[2021-04-25 15:14:48][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2021-04-25 15:14:49][DEBUG] : http://127.0.0.1:80 "POST /plugins/sms/core/php/jeeSMS.php?apikey=43YYhiyX1QnXLVNseQLNfj3k47cOqE5u HTTP/1.1" 200 0
[2021-04-25 15:15:18][DEBUG] : write: AT+CREG?
[2021-04-25 15:15:18][DEBUG] : response: ['+CREG: 0,1', 'OK']
[2021-04-25 15:15:20][DEBUG] : write: AT+CSQ
[2021-04-25 15:15:20][DEBUG] : response: ['+CSQ: 16,99', 'OK']
[2021-04-25 15:15:20][DEBUG] : write: AT+CMGL=0
[2021-04-25 15:15:20][DEBUG] : response: ['OK']
[2021-04-25 15:15:20][DEBUG] : write: AT+CSQ
[2021-04-25 15:15:20][DEBUG] : response: ['+CSQ: 16,99', 'OK']
[2021-04-25 15:15:20][DEBUG] : write: AT+CSQ
[2021-04-25 15:15:20][DEBUG] : response: ['+CSQ: 16,99', 'OK']
[2021-04-25 15:15:20][DEBUG] : write: AT+CSQ
[2021-04-25 15:15:20][DEBUG] : response: ['+CSQ: 16,99', 'OK']
[2021-04-25 15:15:20][DEBUG] : Send to jeedom : {'message': '16', 'number': 'signal_strength'}
[2021-04-25 15:15:20][DEBUG] : Starting new HTTP connection (1): 127.0.0.1:80
[2021-04-25 15:15:20][DEBUG] : http://127.0.0.1:80 "POST /plugins/sms/core/php/jeeSMS.php?apikey=43YYhiyX1QnXLVNseQLNfj3k47cOqE5u HTTP/1.1" 200 0
[2021-04-25 15:15:50][DEBUG] : write: AT+CREG?
[2021-04-25 15:15:55][ERROR] : Exception on GSM : None
[2021-04-25 15:16:25][DEBUG] : write: AT+CREG?
[2021-04-25 15:16:30][ERROR] : Exception on GSM : None
[2021-04-25 15:17:00][DEBUG] : write: AT+CREG?
[2021-04-25 15:17:05][ERROR] : Exception on GSM : None
[2021-04-25 15:17:35][DEBUG] : write: AT+CREG?
[2021-04-25 15:17:40][ERROR] : Exception on GSM : None
[2021-04-25 15:18:10][DEBUG] : write: AT+CREG?
[2021-04-25 15:18:15][ERROR] : Exception on GSM
MES INTERROGATIONS EN COURS:
-
Les opérateurs arrivent-ils à détecter un usage « détourné » d’un petit forfait (2€ Free chez moi) pour de la domotique ou clef 4G et « brident » la SIM au bout de quelques heures ?
Ce serait curieux et j’ai lu d’autres personnes avec cette config sans soucis… -
Mon Hub USB accumule les clefs USB de passerelles: RFXcomXL, AEOTEC Z-wave, SENA Bluetooth et HUAWEI GSM, il est alimenté par son transfo d’origine 2,5A, peut-être est-ce trop léger pour alimenter ces x4 dongles en simultané ?
Il s’agit d’un hub USB2 ORICO préconisé par akenad ici, avec x10 ports USB de série… -
Mon Raspberry était alimenté par une alim. Meanwell format DIN 5V 2,4A, je l’ai récemment changée par une de même marque mais de 3A.
Le passage à une alim de 5A peut-il apporter une amélioration de stabilité de la clef GSM ?
(Elle est alimentée par le transfo du hub à priori, et non celui du Pi…)
Merci par avance pour vos aides, elles seront très préciseuses à ce stade 
Je posterai mes retours en fonction de mes prochaines recherches.
uniquement Android
