Page 2 sur 3
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 24 sept. 2020, 10:11
par Flying Domotic
Bonjour,
Faut-il vraiment déconnecter le RFLINK pour que Domoticz le voit ? Est-il possible qu'après un boot, le simple redémarrage de Domoticz ne suffise pas ?
Dans le log de Domoticz, juste après le boot, qu'est ce qu'on voit au sujet RFLINK ?
Juste après le boot, qu'est ce que raconte un lsusb ? Voit-on le RFLINK ?
Sur quel nom de port RFLINK est-il définit dans la partie "Hardware" de Domoticz ? Est-ce qu'un port persistant a été défini ?
Il est possible que Domoticz démarre trop tôt dans la séquence de boot.
Est-il possible de vérifier que le fichier /etc/init.d/domoticz.sh contient bien la ligne :
Vérifier également les conditions de démarrage de la clef 4G dans /etc/init.d/, et ajouter dans domoticz.sh celles qui n'y figureraient pas déjà.
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 24 sept. 2020, 10:43
par micky1183
Bonjour,
Merci à toi tout d'abord de prendre du temps pour essayer de débloquer mon problème
Flying Domotic a écrit : 24 sept. 2020, 10:11
Bonjour,
Faut-il vraiment déconnecter le RFLINK pour que Domoticz le voit ? Est-il possible qu'après un boot, le simple redémarrage de Domoticz ne suffise pas ?
[*]domoticz voit bien mon rflink lors du redémarrage, c'est mon script pour envoi de sms dans domoticz qui ne fonctionne plus. sinon gammu fonctionne bien lors du test en ssh. Quand je fais la manip précédente, c'est à dire redémarrage du pi en débranchant le rflink, un stop domoticz...rebranchement du rflink un start domoticz, tout fonctionne. La mon script d'envoi de sms fonctionne bien. Comme si il y avait un conflit entre gammu et le rflink.
Dans le log de Domoticz, juste après le boot, qu'est ce qu'on voit au sujet RFLINK ?
[*]Status: RFLink: Using serial port: /dev/ttyUSB12
2020-09-24 10:28:28.908 Status: RFLink: Controller Initialized!...
2020-09-24 10:28:28.983 Status: RFLink Detected, Version: 1.1 Revision: 48 Build: 4
2020-09-24 10:29:11.298 (Rflink) Rain (Pluviométrie)
Juste après le boot, qu'est ce que raconte un lsusb ? Voit-on le RFLINK ?
[*]pi@raspberrypi:~ $ lsusb
Bus 001 Device 008: ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 001 Device 005: ID 0463:ffff MGE UPS Systems UPS
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
oui on le voit en 2eme position
Sur quel nom de port RFLINK est-il définit dans la partie "Hardware" de Domoticz ? Est-ce qu'un port persistant a été défini ?
oui le port persistant à été défini
[*]/dev/ttyusb12
Il est possible que Domoticz démarre trop tôt dans la séquence de boot.
Est-il possible de vérifier que le fichier /etc/init.d/domoticz.sh contient bien la ligne :
[*]dans /etc/init.d/domoticz.sh j'ai
# Required-Start: $network $remote_fs $syslog $time
Vérifier également les conditions de démarrage de la clef 4G dans /etc/init.d/, et ajouter dans domoticz.sh celles qui n'y figureraient pas déjà.
[*]Dans /etc/init.d/, je n'ai rien du tout, je ne comprends d'ailleurs pas les conditions de démarrage qui tu me décrits?
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 25 sept. 2020, 00:28
par Flying Domotic
Oups, j'avais compris que c'était le RFLINK qui avait un souci. C'est la clef 4G donc.
Est-ce qu'elle a un service (au sens systemctl) associé (pour préciser sur le fichier dans init.d) ?
Ceci dit, avoir un port persistant avec une terminaison numérique n'est pas forcement une bonne idée ... Il serait plus habile de l’appeler
ttyUSB-RFLINK plutôt que ttyUSB12.
Sinon, ça ressemble quand même assez fort à un souci d'alim. As-tu une autre alim plus musclée ? Le Rpi a besoin de 2A, ne reste qu'un Ampère pour le RFLINK et la clef 4G, ce qui peut être un peu ras des pâquerettes. J'ai eu plein d'ennuis avec une carte A6 qui ont disparues quand j'ai changé d'alim ET que j'ai alimenté la carte 4G en direct.
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 25 sept. 2020, 11:29
par micky1183
Effectivement le titre n'est plus adapté du coup...
ok, ce qui est bizarre, c'est que quand je teste en ssh avec la commande echo "Test tutoandco" | gammu --sendsms TEXT 06**********, ca fonctionne quand même. Mais quand je lance le script via domoticz, gammu ne répond pas.
- pour l'alim, je viens d'essayer une de 5A
- pour le nom, j'ai mis comme tu m'as dit ttyUSB-RFLINK
-pour le service systemctl, je pense qu'il ne fonctionne pas en tout cas ca me dit rien donc je n'ai pas fait de manip de ce coté.
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 26 sept. 2020, 22:23
par Flying Domotic
Est-ce que ça s'arrange avec avec l'alim 5A ?
Comment Domiticz appelle t'il gammu ? Script ? Python ? Autre ?
Est-ce que le daemon de réception est utilisé ?
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 27 sept. 2020, 11:01
par micky1183
Mon alim est une alim de tel portable récent, elle fait "5v 2A ou 5v 4,5A", Elle a du s'adapter et donc envoyer 4,5A.
Mon problème est le même.
Le script qui appelle gammu, c'est celui-ci en lua dans event domoticz:
commandArray = {}
if (devicechanged['SMS test'] == 'On') then
os.execute ('echo "test SMS raspberry" | gammu --sendsms TEXT 06***********')
end
C'est ce script la qui ne fonctionne plus après redémarrage de mon raspberry si je redémarre sans le rflink, il refonctionne.
Et non le daemon de réception n'a jamais été utilisé.
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 27 sept. 2020, 18:55
par Flying Domotic
Du coup, c'est peut être un souci de définition du port du GSM dans gammu. Comment est fait l'interfaçage entre gammu et le smartphone/module GSM ?
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 27 sept. 2020, 20:31
par micky1183
Je pense que tu veux parler de ca avec la commande
gammu-config -c /home/pi/.gammurc ?
Current Gammu configuration │
│ │
│ P Port (/dev/ttyUSB-3G) │
│ C Connection (at19200) │
│ M Model () │
│ D Synchronize time (yes) │
│ F Log file () │
│ O Log format (text) │
│ L Use locking () │
│ G Gammu localisation () │
│ H Help │
│ S Save │
│ │
│ │
│ <Ok> <Annuler> │
│ │
└───────────────────────────────────────────┘
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 28 sept. 2020, 10:50
par Flying Domotic
C'est ça. On est bien d'accord sur le fait que ttyUSB-3G et ttyUSB_RFLINK pointent bien sur les bons ports et sont différents ?
Re: données oregon/owl ne remonte pas après un redémarrage du pi
Publié : 28 sept. 2020, 21:06
par micky1183
tu dois me parler de ca si je comprends bien?
pi@raspberrypi:~ $ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 sept. 28 20:41 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 sept. 27 07:53 /dev/ttyUSB1
crw-rw---- 1 root dialout 188, 2 sept. 27 07:53 /dev/ttyUSB2
crw-rw---- 1 root dialout 188, 3 sept. 27 07:53 /dev/ttyUSB3
lrwxrwxrwx 1 root root 7 sept. 27 07:53 /dev/ttyUSB-3G -> ttyUSB3
lrwxrwxrwx 1 root root 7 sept. 27 07:51 /dev/ttyUSB-RFLINK -> ttyUSB0