Ammené à travailler avec le terminal, à travers des connexions série, on constate un problème d’ajustement de la taille après l’utilisation de certaines commandes telles que vi etc…

J’utilise généralement la commande suivante pour me connecter sur le port série /dev/ttyUSB0

screen /dev/ttyUSB0 115200

Le problème est que certains logiciels comme l’éditeur vi considèrent que le la fenêtre de terminal n’est que de 24 lignes.

Cela reste ainsi ensuite même après être sorti de l’éditeur, ce qui laisse une bande vide en bas empêchant d’utiliser toute la hauteur du terminal.

serialProblemeLignesVides

Le problème, expliqué par Akkana Peck sur son blog est que screen n’a pas de possibilité d’envoyer par le port série, la taille originale de la fenêtre du terminal, (alors que c’est ce qui se passe en SSH par exemple).

Il ne semble pas non plus y avoir une commande qui permet de demander au terminal sa taille.

Cela n’a pas l’air simple à résoudre, heureusement pour nous, Akkana partage un petit script en python qui ruse en allant déplacer le curseur pour trouver la bonne taille etc.. et permet de résoudre le problème.

TerminalSerialResolution

On peut également le mettre par exemple dans le fichier .bash_profile pour qu’il se lance à l’ouverture de la session.

Je ne sais pas s’il quelqu’un connait une meilleure solution à ce problème ? Mais en tout cas cela fonctionne parfaitement pour moi depuis plusieurs mois… et je me suis dit qu’il pouvait être utile de partager l’astuce.

Voici comment j’ai branché un minitel avec un Raspberry.
Ou autrement dit, branché un minitel sur Internet ;)

minitelRasp

J’ai trouvé plusieurs liens qui expliquent différentes manières de procéder, mais toutes imposent de créer un petit circuit électronique… et aucune ne propose d’utiliser le PL2303… Comme cette méthode me semble plus simple, j’écris ce billet.

Il vous faudra principalement:

  • Un minitel avec prise DIN et touche Fonction (Recup ou ~ 5€)
  • Un adaptateur USB/Serial PL2303 avec niveaux 5V (~ 1€)
  • Une prise DIN (~ 1€)

Tous les minitels n’ont pas de port DIN. Il faut donc bien choisir.
Le minitel doit avoit cette prise au dos.. ainsi que la touche Fonction.

priseDIN

toucheFonction

L’adaptateur USB/Serial PL2303 existe avec, soit des niveaux de 3V3, soit des niveaux de 5V.
Pour l’utilisation avec le Minitel il faut utiliser un PL2303 avec les niveaux 5V.

Comme on n’est jamais vraiment certain, il vaux mieux vérifier.

pl2303Multimetre

La prise DIN comporte 5 connecteurs.

docMinitel

DINSoude

1: RX : à connecter sur TX du PL2303
2: Masse: à connecter sur la masse du PL2303
3: TX : à connecter sur RX du PL2303
4 et 5 se sont pas utilisés ici.

PL2303Soude

On branche ensuite simplement le PL2303 sur un port USB du Rasp, et la prise DIN sur le Minitel.

Coté OS, il est maintenant nécessaire de dire à Raspbian “d’envoyer une console” sur notre PL2303 qui est reconnu par défaut en /dev/ttyUSB0

Comme expliqué entre autres sur Pila’s blog, on ajoute donc au fichier /etc/inittab la ligne:

T1:23:respawn:/sbin/getty -L -i -I "\033\143" ttyUSB0 4800 minitel1b-80

puis on exécute un sudo init q ou reboot pour appliquer la modification.

Coté Minitel, il faut lui dire d’utiliser la prise DIN, donc une fois allumé on fait:

Fnct + T, puis A (ou F) : passage en mode péri-informatique (80 colonnes).
Fnct + T, puis E : désactivation de l’écho local.
Fnct + P, puis 4 : réglage de la vitesse de transmission à 4800 bauds.

Avec cette méthode, le prompt de login ne s’affiche pas parfaitement, mais après avoir tapé quelques caractères, tout rentre dans l’ordre.

MinitelEtRasp

ScreenMinitel

MinitelPing

A quoi ca sert ?
A rien.. ok.. ;) Mais il faut bien recycler nos vieux Rasp modèles B !

Quelques autres liens sur le sujet:
Pila’s blog ici et ici / x0r ici et ici / xavier / Yip / ForumRaspberry / alphak / furrtek / Labomedia / Aplu

J’utilise généralement Shutter pour prendre des screenshots.

J’évite de stoquer ces screenshots sur les sites publics, donc jusqu’à présent, quand je voulais ensuite partager ce screenshot, en gros:

  • je l’enregistrais localement
  • je faisais un scp du fichier dans le répertoire qui va bien sur un serveur web
  • Je faisais des copier/coller de l’URL avec le nom du fichier pour communiquer l’URL.

On peut faire des variantes avec sshfs, scripter quelques trucs.. etc.. mais c’est pas forcément l’idéal.

Mais ce coup ci, j’en avais plusieurs à faire et j’ai donc cherché un truc “propre” pour simplifier le process.

Au bout de quelques secondes de recherche, je suis tombé sur le bien nommé shutter-scp (voir aussi ici. Et c’est exactement ce que je voulais.

Pour l’installation, il suffit de copier un fichier dans le bon répertoire de Shutter (voir le README).
Pour la configuration, il suffit de renseigner où faire le scp (Serveur:Répertoire) ainsi que l’URL qui sera communiquée (à saisir dans le champs “Mot de Passe”).

Une fois le screenshot réalisé dans Shutter, un clic pour exporter, un autre pour valider le scp, puis un dernier pour copier l’URL complète.
Avec ma clé SSH chargée en mémoire, pas besoin de mot de passe, en 3 secondes, tout est fait.

ShutterScp1_m

ShutterScp2_m

J’avais testé Screencloud qui supporte le SFTP.. Mais il ne supporte pas (encore) l’authentification par clé publique… donc pas possible pour moi.

Introduction

Mon but était de pouvoir allumer le chauffage (chaudière) d’une maison secondaire à distance.

La chaudière est équipée d’un thermostat qui peut maintenir une température programmée automatiquement, mais le besoin est de pouvoir passer, à la demande, et à distance, du mode “Hors gel” au mode “JeVeux18°C”.

Par exemple X semaines sans rien chauffer du tout.. puis du jour au lendemain décider de vouloir 18°C. (Si vous pensez que ce n’est pas grave d’arriver dans une maison à 2°C, vous n’avez probablement pas encore d’enfants ;) )

Trève de blabla.. en vrac:

  • La chaudière est équipée d’un “boitier/thermostat” filaire déporté, qui permet de contrôler la chaudière.
  • La première idée était de voir si le fabriquant ne proposait pas un module permettant de réaliser ceci. -> Oui, a priori c’est possible mon bon Monsieur, en échange d’un peu plus de 300€ HT.
  • Mmmm… j’achète 10 Rasp pour ce prix là moi
  • On va donc partir sur l’utilisation du Rasp, qui de toute façon est déjà sur place ;)
  • La seconde idée est de voir quel est le protocole utilisé entre le thermostat et la chaudière.. pour ensuite essayer de l’implémenter sur le Rasp.
  • Après investigations, il s’agit du protocole eBUS
  • A première vue, cela semblerais à peu près jouable de l’implémenter (UART etc.. ) même si le “projet” à l’air d’être complètement mort.
  • Mais très vite, cela semble quand même bien galère… Une partie du peu de doc est en Allemand.. Risque de péter la chaudière et le thermostat, beaucoup de temps à passer pour (essayer d') implémenter le protocole et trouver les bons menus..le tout sans être sûr d’y parvenir..et le tout pour un protocole déjà mort.
  • On en vient donc finalement rapidement à la 3ème idée: simuler la séquence d’appui sur les boutons du thermostat filaire existant, qui permet de passer du mode “HorsGel” au mode “JeVeux18°C”

Approche

  • Démontage du thermostat existant.
  • On trouve rapidement les contacts des 2 boutons utilisés pour aller dans les menus.
  • On soude les 4 fils, on les fait sortir sur le coté.. et on referme le tout.
  • Le thermostat pourra donc toujours être utilisé en “local” en appuyant sur les boutons.. mais ensuite en plus à distance par le Rasp.

chaudiere-filsSoudes

  • Maintenant il faut pouvoir faire “contact” entre les 2 fils de chaque bouton pour simuler l’appui.
  • On est en courant continu.. et avec un ampèremètre, on le mesure l’histoire de voir.
  • Plusieurs solutions sont envisageables pour créer le contact et donc simuler l’appui sur le bouton; transistor, relai “normal”, reed relay, circuit intégré, etc..
  • J’écarte l’idée du transistor, car je ne sais pas ce qu’il y a devant et derrière les boutons “interrupteurs” du thermostat.. n’étant pas spécialiste, je n’ai pas envie de cramer le tout… (qui coûte certainement le même prix que le module de commande à distance.
  • Après recherche sur le net.. le 74HCT4066 est censé faire l’affaire.
  • Je prends mon 74HCT4066, je n’ai aucun problème pour allumer/éteindre une LED par exemple.. mais cela ne marche pas sur les contacts de la chaudière.. Je ne sais pas pourquoi… (Trop faible intensité ? J’ai bien mis à la masse les entrées non utilisées, j’ai aussi testé avec une résistance de 50 Ohms.. bref..)
  • On passe à la solution de backup (c’est que l’hiver approchait .. des Reed Relay que j’avais en stock. (Commandés aussi pour un autre besoin).
  • Les miens (1.8€) sont en “5V” (3,7V minimum pour se fermer) et un “level shifter” est donc nécessaire pour “monter” les 3.3V de la GPIO du Rasp à 5V.
  • Je ne m’étend pas sur les Level Shifter dans ce billet. Cela pourra être l’objet d’un autre.
  • L’intensité est largement en dessous de la limite.. donc c’est ok.

Schémas

chaudiere

Je n’ai pas vraiment le temps de faire un beau schéma sous Fritzing.
Donc vous aurez la version “moche/papier”

chaudiere-schema

Mise en place

  • Test sur breadboard avec donc les level shifter et 2 reed relais.
  • Les entrées des relais sont donc commandées par 2 GPIOs du Rasp (17 et 18 dans mon cas).
  • J’installe wiringPi parce que c’est plus simple (et parce que je le vaux bien).
  • Je passe les 2 GPIOs en “sortie”
$ gpio mode 0 out  
$ gpio mode 1 out
  • Je créé les contacts en passant à 1 les GPIOs pendant 0.3 secondes.
  • Pour moi la séquence est assez simple (Bouton A / Bouton B / Bouton A):
gpio write 0 1 && sleep 0.3 && gpio write 0 0 && sleep 1 && gpio write 1 1 && sleep 0.3 && gpio write 1 0 && sleep 1 && gpio write 0 1 && sleep 0.3 && gpio write 0 0
  • Les tests sont concluants… \o/

chaudiere-breadboard

  • On dégaine le fer à souder
  • On soude le tout comme sur la breadboard de test..
  • On rajoute un DS18B20 (1€) et sa résistance pour pouvoir connaitre la température à distance. (Je ne détaille pas cette partie, voir par exemple ici ou .
  • On rajoute une LED pour montrer que le montage est sous tension. (Et pour impressionner Madame).
  • On force les GPIOs en mode “sortie” et à 0 dès le boot dans le /etc/rc.local
  • On refait un petit script plus propre.
  • On re-teste..
  • C’est OK, on peut aller boire une bière.

chaudiere-soude

Futur

  • Finaliser le boitier et les câbles vers le thermostat
  • Interface web (en plus de SSH) pour avoir la température et allumer la chaudière.
  • Voir si on veut commander la chaudière par SMS avec Gammu
  • Voir si on veut implémenter d’autres séquences (passage en HorsGel en cas d’oubli en partant)

Il n’y a pas difficulté particulière à réaliser ceci.. Et pas réellement d’intérêt à publier ces informations propres à une chaudière.. Le but est juste de montrer qu’avec un peu de motivation, un esprit un peu DIY et quelques Euros de composants, on peut facilement utiliser le Rasp pour domotiser plein de choses.. et j’espère que cela donnera des idées à certains pour mettre en place leurs propres projets domotiques.

J’ai un projet où le Rasp doit envoyer des informations par SMS.

J’ai acheté 10€ une clé 3G d’occasion pour l’utiliser avec Gammu

  • Informations sur la clé
 $ dmesg | grep tty | grep usb  
 [ 1014.053491] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB0  
 [ 1014.062066] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB1  
 [ 1014.069542] usb 1-1.3: GSM modem (1-port) converter now attached to ttyUSB2  
 $   
 $ lsusb | grep -i Huawei  
 Bus 001 Device 006: ID 12d1:1001 Huawei Technologies Co., Ltd. E169/E620/E800 HSDPA Modem 
 $
  • Installation de Gammu
sudo apt-get install gammu
  • Paramétrage
$ gammu-detect   
 ; Configuration file generated by gammu-detect.  
 ; Please check The Gammu Manual for more information.  

 [gammu]  
 device = /dev/ttyUSB0  
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile  
 connection = at  

 [gammu1]  
 device = /dev/ttyUSB1  
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile  
 connection = at

 [gammu2]  
 device = /dev/ttyUSB2  
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile  
 connection = at  
 $

Dans /etc/gammurc on met juste:

[gammu]  
 device = /dev/ttyUSB0  
 name = Phone on USB serial port HUAWEI_Technology HUAWEI_Mobile  
 connection = at
$ gammu identify  
 Périphérique : /dev/ttyUSB0  
 Fabricant : Huawei  
 Modèle : unknown (K3565)  
 Firmware : 11.111.11.11.11  
 IMEI : 222222222222222  

Si un code PIN est activé

 $ gammu getsecuritystatus  
 Waiting for PIN.  
 $ gammu entersecuritycode PIN 1234  
 $ gammu getsecuritystatus  
 Nothing to enter.  
 $
  • Envoi de SMS
 $ gammu sendsms TEXT 0612345678 -text "Test 1"  
 If you want break, press Ctrl+C...  
 Sending SMS 1/1....waiting for network answer..OK, message reference=1  
 $
 $ echo "Test 2" | gammu sendsms TEXT 0612345678  
 If you want break, press Ctrl+C...  
 Sending SMS 1/1....waiting for network answer..OK, message reference=2  
 $
  • Divers
 $ gammu getlocation  
 Latitude : 48.XXXXXX  
 Longitude : 2.XXXXXX  
 Range : 50000  
 Number of samples : 70  
 $

Gammu envoi la CellID sur le site web du projet open source OpenCellID (GET HTTP).
(Il faut un accès Internet dans ce cas, donc je ne pourrais l’utiliser)

  • Conclusion

Nous avons donc pour 10€ de clé, et 2€ (voir 0€ ) de forfait mensuel une solution d’envoi de SMS illimité.

Pour toutes les infos, voir la doc .