Perte des sensors après plusieurs read #6

Nico0084 · 2016-02-04T23:14:55Z

Salut,
Je n'ai pas de onewire mais en debugant celui de tikismoke je suis tombé sur la perte des sensors progressive après plusieurs read.

2016-02-04 23:28:13,112 domogik-onewired INFO ==> Reading sensor '/28.551F2C030000/temperature'
2016-02-04 23:28:13,112 domogik-onewired INFO ==> Reading sensor '/28.9CEB2B030000/temperature'
2016-02-04 23:28:13,313 domogik-onewired ERROR ### Sensor '28.551F2C030000' NOT FOUND.
2016-02-04 23:28:13,314 domogik-onewired ERROR ### Sensor '28.9CEB2B030000' NOT FOUND.
2016-02-04 23:28:13,314 domogik-onewired ERROR Traceback (most recent call last):
File "/var/lib/domogik/domogik_packages/plugin_onewired/lib/onewired.py", line 93, in readSensor
value = ow.owfs_get(str(sensor)).strip() # Ex.: ow.owfs_get('/26.D050E7000000/B1-R1-A/pressure')
File "/usr/lib/python2.7/dist-packages/ow/init.py", line 159, in _get
raise exUnknownSensor(path)
exUnknownSensor: '/28.551F2C030000/temperature'
2016-02-04 23:28:13,315 domogik-onewired DEBUG => 'Couloir premier étage' : wait for 60.0 seconds
2016-02-04 23:28:13,315 domogik-onewired ERROR Traceback (most recent call last):
File "/var/lib/domogik/domogik_packages/plugin_onewired/lib/onewired.py", line 93, in readSensor
value = ow.owfs_get(str(sensor)).strip() # Ex.: ow.owfs_get('/26.D050E7000000/B1-R1-A/pressure')
File "/usr/lib/python2.7/dist-packages/ow/init.py", line 159, in _get
raise exUnknownSensor(path)
exUnknownSensor: '/28.9CEB2B030000/temperature'

Il semblerait que cela provienne de la config de certains GPIO, voir la discution suivante : ow Python makes sensors disappear surtout la fin.

vdomos · 2016-02-05T08:57:07Z

Pas tout compris à la discussion du lien donné, ils parlent de GPIO et i2C.
Pas sur que cela soit lié, Tiki utilise un dongle USB pour le 1-wire.

Faudra que je refasse des tests lors de perte de "sensor" car je n'ai pas constaté ce problème Pourtant avec un sensor débranché pendant plusieurs jours, l'erreur "exUnknownSensor" est bien "catchée"

vdomos · 2016-02-05T14:26:42Z

Tiki peux tu me donner ta configuration owfs ?

As tu un daemon owserver qui tourne ?

# netstat -anp|grep ows
tcp        0      0 192.168.0.39:4304       0.0.0.0:*               LISTEN      31869/owserver

Peux tu me donner la conf dans /etc/owfs.conf pour une install. Debian.

J'ai fais un test.
Je ne sais pas si cela peut être lié avec ton problème

Si le plugin est configuré avec 'u' et owserver configuré avec le dongle cela génère pleins d'erreurs exUnknownSensor car le plugin et le server accédent tous les 2 au dongle.

Configure le plugin avec "localhost:4304" pour que cela fonctionne correctement.

J'ai du redémarré owserver pour que cela remarche correctement aprés le test.

Nico0084 · 2016-02-05T15:08:00Z

Pour info, sur le PC de tiki, j'ai rajouté un timeout dans le process Read parcequ'il y avait beaucoup de requete en cascade. Le décalage de 5 sec au démarrage n'est pas fiable. iIl ne peut pas être tenu par un système dont ne connait pas le temps d'execution. le self._readStep sur 5 sec.

def readSensor(self, saddress, sprop):
"""
        ow.Sensor don't work with sensor directory be replace by ow.owfs_get
        """
        while self._lastRead + self._readStep > time.time() and not self._stop.isSet():
            time.sleep(0.1)
        self._lastRead = time.time()
        try:
            sensor = self._root + saddress + "/" + sprop
            self.log.info(u"==> Reading sensor '%s'" % sensor)
            value = ow.owfs_get(str(sensor)).strip()                # Ex.: ow.owfs_get('/26.D050E7000000/B1-R1-A/pressure')
            if ("temperature" in sprop) and value == '85':          # Error reading thermometer return 85 !
                self.log.error(u"### Sensor '%s', BAD read temperature (85°)" % saddress)
                return "failed"
            return value
........

Après 4 heures toujours pas d'exUnknownSensor mais il faut plus de temps de test pour valider si ça change quelque chose........

vdomos · 2016-02-05T16:51:18Z

il y a combien de sondes sur le bus ?
Je ne sais plus si Tiiki utilise ou non le mode parasite pour son cablage.

Ma config. actuelle, un dongle 1-wire USB sur une RPI 2 avec 10 chips
1-wire.
Sur ce RPI, j'ai

3 process python xpl (Domogik 0.3) qui lisent les senseurs sur le bus
avec le module ow
un Jeedom qui lit aussi les mêmes à intervalle régulier.
Et 2 VMs Domogik avec le plugin onewired qui lisent ces même senseurs.
ils passent tous par le même daemon 1-wire owserver du RPI2 et je n'ai pas
de problème de exUnknownSensor"
.Je pense qu'au niveau requetes le dameon est servi.

Les seul cas ou c'est apparu chez moi, c'est du à un problème sur le bus
cablage ou autre comme le week-end dernier

J'ai rajouté un module avec 2 chips dont un en mode parasite et cela a
suffit à me pourrir le bus et générer ces erreurs (cable long jusqu'au
module).
Par contre, comprends pas pourquoi dans la log de Tiki, il y a eu des
"Traceback ..." alors que je n'ai pas rencontré ce problème même avec
pleins d'erreurs exUnknownSensor génèrées à cause de mon module pourri !

2016-02-05 16:08 GMT+01:00 Nico0084 [email protected]:

Pour info, sur le PC de tiki, j'ai rajouté un timeout dans le process Read
parcequ'il y avait beaucoup de requete en cascade. Le décalage de 5 sec au
démarrage n'est pas fiable. iIl ne peut pas être tenu par un système dont
ne connait pas le temps d'execution. le _self.readStep sur 5 sec.

def readSensor(self, saddress, sprop):
"""
ow.Sensor don't work with sensor directory be replace by ow.owfs_get
"""
while self._lastRead + self._readStep > time.time() and not self._stop.isSet():
time.sleep(0.1)
self._lastRead = time.time()
try:
sensor = self._root + saddress + "/" + sprop
self.log.info(u"==> Reading sensor '%s'" % sensor)
value = ow.owfs_get(str(sensor)).strip() # Ex.: ow.owfs_get('/26.D050E7000000/B1-R1-A/pressure')
if ("temperature" in sprop) and value == '85': # Error reading thermometer return 85 !
self.log.error(u"### Sensor '%s', BAD read temperature (85°)" % saddress)
return "failed"
return value
........

Après 4 heures toujours pas d'exUnknownSensor mais il faut plus de
temps de test pour valider si ça change quelque chose........

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

Nico0084 · 2016-02-05T17:00:57Z

Je dirais 9 sondes, le detail du cablage je sais pas.
Les "Traceback ..." c'est moi qui les ait rajouter en log sur le raise
exUnknownSensor , mais au final ça n'apporte pas grand chose.

Le 5 février 2016 à 17:51, vdomos [email protected] a écrit :

il y a combien de sondes sur le bus ?
Je ne sais plus si Tiiki utilise ou non le mode parasite pour son cablage.

Ma config. actuelle, un dongle 1-wire USB sur une RPI 2 avec 10 chips
1-wire.
Sur ce RPI, j'ai

3 process python xpl (Domogik 0.3) qui lisent les senseurs sur le bus
avec le module ow

un Jeedom qui lit aussi les mêmes à intervalle régulier.
Et 2 VMs Domogik avec le plugin onewired qui lisent ces même senseurs.
ils passent tous par le même daemon 1-wire owserver du RPI2 et je n'ai pas
de problème de

exUnknownSensor.Je pense qu'au niveau requetes le dameon est servi.

Les seul cas ou c'est apparu chez moi, c'est du à un problème sur le bus
cablage ou autre comme le week-end dernier

J'ai rajouté un module avec 2 chips dont un en mode parasite et cela a
suffit à me pourrir le bus et générer ces erreurs (cable long jusqu'au
module).
Par contre, comprends pas pourquoi dans la log de Tiki, il y a eu des
"Traceback ..." alors que je n'ai pas rencontré ce problème même avec
pleins d'erreurs

exUnknownSensor génèrées à cause de mon module pourri !*

2016-02-05 16:08 GMT+01:00 Nico0084 [email protected]:

Pour info, sur le PC de tiki, j'ai rajouté un timeout dans le process
Read
parcequ'il y avait beaucoup de requete en cascade. Le décalage de 5 sec
au
démarrage n'est pas fiable. iIl ne peut pas être tenu par un système dont
ne connait pas le temps d'execution. le _self.readStep sur 5 sec.

def readSensor(self, saddress, sprop):
"""
ow.Sensor don't work with sensor directory be replace by ow.owfs_get
"""
while self._lastRead + self._readStep > time.time() and not
self._stop.isSet():
time.sleep(0.1)
self._lastRead = time.time()
try:
sensor = self._root + saddress + "/" + sprop
self.log.info(u"==> Reading sensor '%s'" % sensor)
value = ow.owfs_get(str(sensor)).strip() # Ex.:
ow.owfs_get('/26.D050E7000000/B1-R1-A/pressure')
if ("temperature" in sprop) and value == '85': # Error reading
thermometer return 85 !
self.log.error(u"### Sensor '%s', BAD read temperature (85°)" % saddress)
return "failed"
return value
........

Après 4 heures toujours pas d'exUnknownSensor mais il faut plus de
temps de test pour valider si ça change quelque chose........

—
Reply to this email directly or view it on GitHub
<
#6 (comment)

.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

vdomos · 2016-02-05T17:17:39Z

Tu as peut-être raison concernant les requetes trop excessives si le plugin est configuré en accés direct sur le dongle USB.
En passant par le daemon avec sa gestion de cache, cela devrait mieux passé peut-être et ne pas faire planter le plugin.

même si il y a des problèmes de bus, cela ne devrait remonter que l'erreur "Sensor xx.yyyyyyyyyyyy NOT FOUND" à chaque lecture sans perturber le plugin.

Nico0084 · 2016-02-05T17:21:44Z

Mais ça ne perturbe pas le plugin vu que l'exception est gérée.
Mais les sensors ne reapparaissent jamais. il faut redémarrer le plugin
pour qu'ils remontent à nouveau. Un reinit de owserver pourrait peut-être
suffir ?

Le 5 février 2016 à 18:17, vdomos [email protected] a écrit :

Tu as peut-être raison concernant les requetes trop excessives si le
plugin est configuré en accés direct sur le dongle USB.
En passant par le daemon avec sa gestion de cache, cela devrait mieux
passé peut-être et ne pas faire planter le plugin.

même si il y a des problèmes de bus, cela ne devrait remonter que l'erreur
"Sensor xx.yyyyyyyyyyyy NOT FOUND" à chaque lecture sans perturber le
plugin.

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

vdomos · 2016-02-05T17:41:30Z

Ah, effectivement pas normal. même avec des erreurs NOT FOUND, la lecture peut se faire au prochain interval si la sonde revient.

Cela ressemble à mon test d'accés direct sur le dongle usb en même temps que le plugin.
obligé de relancer owserver pour revenir à la normal.

Aprés ton test si toujours le même probleme, pourrrais tu relancer le plugin avec la configuration dans le plugin:

 1-Wire Device (1-wire_device): localhost:4304

si tu as bien le dameon owserver sur la même machine et sur ce port ainsi que cette ligne

server: usb = all

dans owfs.conf

vdomos · 2016-02-11T09:18:40Z

Salut,

Des nouvelles de ce problème ?

Nico0084 · 2016-02-11T20:41:10Z

Salut
Avec un time wait de 5s ça semble ne pas bugger,
mais il y a eu plusieurs restart depuis et pas de période assez longue pas
valider quoi que ce soit :(
Il faudrait au moins une semaine pour valider un minimum.
@+
Nico
Le 11 févr. 2016 10:18, "vdomos" [email protected] a écrit :

Salut,

Des nouvelles de ce problème ?

—
Reply to this email directly or view it on GitHub
#6 (comment)
.

tikismoke · 2016-05-04T15:47:51Z

OUps j'avais loupé le sujet.

Alors oui mon bus est en mode parasite.
Il y a 9 sondes dessus.
Je n'utilise par le daemon owfs.
C'est bien un dongle USB.

Ca fait un petit moment que le plugin n'a pas planté, je sais pas si c'était vraiment lié au final.
OWFS n'est même pas installer sur la vm ni sur l'hote.

Voilà après comme j'ai pas mal de souci de MQ (du à priori a une surcharge des requetes lors de mes tests de domodroid) d'autres de xpl par moment, c'est vrai que domogik tourne rarement plus de 24h ;)

vdomos · 2016-05-04T16:34:26Z

Sur un rpi2 ou un Atom D525, le plugin s'arretait souvent comme le Manager, plus des problèmes de MQ comme toi.

Depuis retour sur une VM et plus ce problème.

tikismoke · 2016-05-04T16:36:14Z

C'est déjà une fausse vm (un conteneur lxc).

vdomos · 2016-05-04T16:45:04Z

Il tourne sur quoi ton conteneur ?
Je pense que Domogik est gourmand en ressources au fur et à mesure que l'on rajoute des plugins, et cela a du mal à suivre peut-être.

vdomos · 2016-05-12T15:57:24Z

J'ai denouveau constaté le problème du plugin qui s'arrete tout seul même sur ma vm

Mais à chaque fois, cela se produit lors de la rotation des logs.

La log ne contient que ces 3 lignes:

$ cat plugin_onewired.log
2016-05-06 06:59:54,669 domogik-onewired DEBUG Delete the file /var/run/domogik//onewired_return_code_13907
2016-05-06 06:59:54,928 domogik-onewired DEBUG __del__ Single client
2016-05-06 06:59:54,943 domogik-onewired DEBUG force_leave called

Peux tu me dire si c'est le cas pour toi ?

tikismoke · 2016-05-12T16:00:53Z

Nop ça l'a aussi fait en dehors des heures de rotation.

Côté hardware je détaille rapidos:
Processor information 2xIntel(R) Xeon(R) CPU E5345 @ 2.33GHz, 4 cores
Real memory 4.19 GB used, 15.71 GB total
Aucun souci de ce côté là ;)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Perte des sensors après plusieurs read #6

Perte des sensors après plusieurs read #6

Nico0084 commented Feb 4, 2016

vdomos commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

vdomos commented Feb 11, 2016

Nico0084 commented Feb 11, 2016

tikismoke commented May 4, 2016

vdomos commented May 4, 2016

tikismoke commented May 4, 2016

vdomos commented May 4, 2016

vdomos commented May 12, 2016

tikismoke commented May 12, 2016

Perte des sensors après plusieurs read #6

Perte des sensors après plusieurs read #6

Comments

Nico0084 commented Feb 4, 2016

vdomos commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

Nico0084 commented Feb 5, 2016

vdomos commented Feb 5, 2016

vdomos commented Feb 11, 2016

Nico0084 commented Feb 11, 2016

tikismoke commented May 4, 2016

vdomos commented May 4, 2016

tikismoke commented May 4, 2016

vdomos commented May 4, 2016

vdomos commented May 12, 2016

tikismoke commented May 12, 2016