Open Nico0084 opened 8 years ago
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"
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.
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........
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
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 notifications@github.com:
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 https://github.com/vdomos/domogik-plugin-onewired/issues/6#issuecomment-180393770 .
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 notifications@github.com 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 notifications@github.com:
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 < https://github.com/vdomos/domogik-plugin-onewired/issues/6#issuecomment-180393770
.
— Reply to this email directly or view it on GitHub https://github.com/vdomos/domogik-plugin-onewired/issues/6#issuecomment-180436455 .
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.
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 notifications@github.com 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 https://github.com/vdomos/domogik-plugin-onewired/issues/6#issuecomment-180448705 .
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
Salut,
Des nouvelles de ce problème ?
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" notifications@github.com a écrit :
Salut,
Des nouvelles de ce problème ?
— Reply to this email directly or view it on GitHub https://github.com/vdomos/domogik-plugin-onewired/issues/6#issuecomment-182777686 .
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 ;)
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.
C'est déjà une fausse vm (un conteneur lxc).
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.
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 ?
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à ;)
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.
Il semblerait que cela provienne de la config de certains GPIO, voir la discution suivante : ow Python makes sensors disappear surtout la fin.