JE rajoute que sur le probleme semble etre que le ftdi ne semble pas maintenir le port ouvert ce qui fait crasher le teleinfo_2_cpt.py avec le retour suivant :
Traceback (most recent call last):
File "teleinfo_2_cpt.py", line 541, in <module>
main()
File "teleinfo_2_cpt.py", line 534, in main
teleinfo.readMeter(gDeviceName, gExternalIP, gCleAPI, gDebug, gRealPath)
File "teleinfo_2_cpt.py", line 387, in readMeter
self.__selectMeter(_CompteurNum)
File "teleinfo_2_cpt.py", line 262, in __selectMeter
raise FtdiError("Can't set bitmode (%d, %s)" % (err, ftdi.get_error_string(self.context)))
__main__.FtdiError: Can't set bitmode (-2, USB device unavailable)
le modem est pourtant bel et bien visible via lsusb.
root@jeedom:/var/www/html/plugins/teleinfo/ressources# lsusb
Bus 001 Device 004: ID 051d:0002 American Power Conversion Uninterruptible Power Supply
Bus 001 Device 008: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC
Bus 001 Device 002: ID 05e3:0610 Genesys Logic, Inc. 4-port hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
et dmesg
[ 8745.601582] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[ 8745.605354] ftdi_sio 1-1.3:1.0: device disconnected
Le modem est donc bien toujours en prise avec FTDI1
Note que si je tente en version 1 compteur, le FTDI prend la main, et la garde correctement. Les leds sont vertes sur la durée mais les données sont inexploitable (frame corrupted).
Je soupconne donc que teleinfo_2_cpt.py ne gere pas le ftdi de la meme facon que teleinfo.py
d'ailleurs avec un
root@jeedom:/# picocom -b 1200 -d 7 -f n -p e /dev/ttyUSB0
picocom v1.7
port is : /dev/ttyUSB0
flowcontrol : none
baudrate is : 1200
parity is : even
databits are : 7
escape is : C-a
local echo is : no
noinit is : no
noreset is : no
nolock is : no
send_cmd is : sz -vv
receive_cmd is : rz -vv
imap is :
omap is :
emap is : crcrlf,delbs,
Terminal ready
JjSTuG*]&&LL B
ADCO xxx:
OPTARIF BASE 0
ISOUSC 45 ?
BASE 005732345 (
PTEC TH.. $
IINST 017 _
IMAX 032 D
PAPP 03950 2
MOTDETAT 000000 B
ADCO xxx:
OPTATAT 000000 B
ADCO xxx:
OPTARIF BASE 0
ISOUSC 45 ?
BASE 005732348 +
PTEC TH.. $
IINST 017 _
IMAX 032 D
PAPP 03940 1
MOTDETAT 000000 B
ADCO xxx:
OPTARIF BASE 0
ISOUSC 45 ?
BASE 005732349 ,
PTEC TH.. $
IINST 017 _
IMAX 032 D
PAPP 03950 2
MOTDETAT 000000 B
ADCO xxx:
OPTARIF BASE 0
ISOUSC 45 ?
BASE 005732351 %
PTEC TH.. $
IINST 017 _
IMAX 032
IINST 017 _
IMAX 032 D
PAPP 03920 /
MOTDETAT 000000 B
ADCO xxx:
OPTARIF BASE 0
IX 032 D
PAPP 03960 3
MOTDETAT 000000 B
etc...
J'ai bien des lignes qui crachent les trames.... du coup je me pose la question : pourquoi s'appuyer sur le FTDI plutot que d'utiliser le mode Serie de base en tappant directement sur le port avec le parsing du 2 cpt ?
En gros dans un cas, on a une connection qui marche mais un parsing qui ne marche pas,
Dans l'autre cas, un parsing qui marche mais une connection qui plante apres quelques trames.
Enfin je ne suis pas dev et je ne connais pas forcement la portée de ma question ou meme si elle a un sens.
Merci.