Firmata FRM_INs werden regelmäßig taub

Begonnen von Zen@homE, 05 Dezember 2013, 18:08:10

Vorheriges Thema - Nächstes Thema

Zen@homE

Hallo zusammen,

ich betreibe einen Arduino Mega ADK über Firmata an FHEM. Dabei verwende ich die Pins zwischen 22 und 49 um ca. 20 drahtgebundene Melder abzufragen. Leider stellt sich nach ein paar Stunden im ein Zustand absoluter Taubheit ein. Die Ausgänge funktionieren weiterhin, alle Eingänge bleiben auf dem letzten Stand. Laut LED sendet der Arduino fröhlich weiter, im Log ist nix zu finden. Mittlerweile habe ich einige Versionen von Firmata ausprobiert (´momentan StandardFirmata V_2_05). Nach einem "set FIRMATE reset" läuft alles wieder für ein paar Stunden. Die Verkabelung hab ich gecheckt. Mit einem Watchdog kann ich den Zustand zwar sauber erkennen, aber für den eigentlichen Einsatzzweck als Alarmanlage finde ich das unbefriedigend.
Zwar verdiene ich meine Brötchen mit Software, aber was Linux und vor allem Perl angeht, habe ich in den letzten Wochen gerade erst mein Seepferdchen gemacht. Für sachdienliche Tips zum Debugging wäre ich echt dankbar.

Bitte nicht Böse sein, dass ich so ohne Vorstellung mit der Tür ins Haus Falle...

Gruß

Thomas

P.S.: Ich weiß, daß ihr mehr Infos braucht, also fragt. ;-)

ntruchsess

sorry dass ich mich noch nicht gerührt habe, hab den Thread erst grade gesehen.

Teste mal die ConfigurableFirmata wie hier im wiki beschrieben.
mit aktuellem FHEM-code kannst Du am FRM device per 'attr verbose 5' die Kommunikation zwischen Arduino und FRM_IN mitloggen (nicht am FRM_IN-device anstellen, die Kommunikation wird vom FRM-device gebündelt abgewickelt). Jedes mal, wenn sich der Zustand eines Eingangs ändert solltest Du die passende Nachricht sehen können (Details sind auf http://firmata.org dokumentiert). Wenn da im Zustand 'taub' keine Digital-I/O-messages bei Zustandsänderung mehr kommen, dann liegt's am Arduino.

- Norbert
while (!asleep()) {sheep++};

Zen@homE

Hallo Norbert,

verbose am FRM device habe ich auf 5. Im Zustand 'Taub' erscheinen keine '<' Meldungen im Log. Das es am Arduino liegt bezweifle ich jedoch, da:
1. Die TX-Led am Arduino brav bei jeder Zustandsänderung der Melder aufflackert.
2. Die FRM_OUTs auf dem Arduino noch normal funktionieren.

Mit der ConfigurableFirmata hatte ich genau die selben Symptome.

Gruß

Thomas

justme1968

ich habe bei zwei arduino nanno den gleichen effekt. auch bei einem eigenen test sketch und bei verbindung über terminal programm.

ich habe den verdacht das der uart so durcheinander kommt das zwar sie led noch leuchtet er aber nichts mehr sendet.

ich wollte eigentlich den brenner meiner heizung überwachen. zuerst mit einem normalen trennrelais aber das scheint beim schalten zu viele störungen zu erzeugen. die störungen sind trotz entstör modul so groß das es reicht wenn das relais in der nähe mehrfach geschalten wird. ohne mit dem arduino verbunden zu sein.

ein solidstate relais ist besser aber immer noch nicht gut genug.

ich werde als nächstes statt den relais einen kleinen traffo/netzteil versuchen und die kleinspannunf per a/d pin messen. mal sehen ob das besser geht.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

ntruchsess

Optokoppler wären vieleicht auch eine Option.
while (!asleep()) {sheep++};

justme1968

wie gesagt reicht es schon wenn das relais in der nähe ist. zum manchmal schon unter einem meter. das entkoppeln des eingangs ist es also nicht.

zum störungsfrei abgreifen sollte es aber eigentlich mit dem solidstate relais vergleichbar sein oder? das ist leider auch nicht wirklich gut.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Zen@homE

Hallo Andre,

das Du den Effekt auch mit einem Terminalprog hast ist ja interessant. Empfängt der Nano bei dir den noch was, wenn er verwirrt ist?
Das der ATMEL selbst sich aus der Ruhe bringen lässt, glaube ich eigentlich nicht. Da hätte ich eigentlich eher den FTDI (USART->USB) in Verdacht. Würde auch die TX-Led erklären.

Leider hatte ich bisher noch nicht genug Zeit um den Sourcecode mal genauer anzusehen. Wie sieht da die Signalkette aus?

Gruß

Thomas

justme1968

ich hatte den sketch nur den status eines digital pin ausgeben und die on board led entsrpechen schalten lassen. die ausgabe hört auf sobald das problem da ist, die tx led geht noch und auch die led dich ich schalte geht noch. d.h. der sketch ist noch aktiv und arbeitet korrekt.

was mir gerade noch einfällt ist das ein redet nicht hilft sondern nur das abziehen und wieder an stecken. das würde auch für die ftdi theorie sprechen. es kann sogar sein das es geholfen hat nur das terminal prgramm neu zu starten. da bin ich mir aber nicht mehr sicher.

wie gesagt macht der das ding sogar probleme wenn ich das relais nur daneben liegt und schaltet ohne das es verbunden ist und den den pin von hand gegen masse oder vcc schalte.

ob der noch empfangen würde kann ich nicht sagen. das kann ich aber mal probieren.

//#include <Bounce.h>

#define LED_PIN    13

void setup()
{
  pinMode(LED_PIN, OUTPUT);
  digitalWrite(LED_PIN, HIGH);

  pinMode(3, INPUT);
  //digitalWrite(3, HIGH);

  Serial.begin(57600);

  digitalWrite(LED_PIN, LOW);
}

//Bounce bounce(3, 100);

void loop()
{
  //bounce.update();

  static byte b = 0;
  //byte r = bounce.read();
  byte r = digitalRead(3);
  if( b != r ) {
    b = r;
    Serial.println(b);
    digitalWrite(LED_PIN, !digitalRead(LED_PIN));
  }
}
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Zen@homE

das würde mich interessieren. Ich arbeite gerade an Plan B: BBB mit 30 x GPIO. Die Device Tree Overlays haben mich Nerven gekostet (Vieleicht hätte ich als Linux Unwissender besser doch nicht Wheezy statt Angsdingens genommen?!) Aber den Arduino wieder aus dem Technikschrank schrauben ist auch blöd.

Mal sehen

Thomas

Zen@homE

Einen geruhsamen Abend zusammen,

nachdem ich der Zeit in den letzten Tagen ein paar Stunden abringen konnte, um mich meinem Problem mit Firmata nochmal annehmen zu können, wollte ich mal eine Statusmeldung abgeben.

1) Plan B:  BBB mit 30 x GPIO ist grundsätzlich machbar, aber meine konkreten Ansprüche an die Lösung übersteigen leider meine momentanen Möglichkeiten. Gpio über debugfs finde ich uncool und die Kommunikation zwischen IoDevice und Client in FHEM hab ich noch nicht so richtig durchschaut.

Da ich aber den BBB nun schon mal mit Debian und FHEM versorgt hatte, habe ich da mal ein Testsetup mit FHEM, Firmata, USB-Hub und Arduino Leonardo zusammengestöpselt. Lustig, auf dieser Kombi läuft mein kleiner Hörtest seit mehr als 24 Stunden ohne Fehler...

Lieft das Problem hier? =>http://hardware.slashdot.org/story/12/08/24/2228251/serious-problems-with-usb-and-ethernet-on-the-raspberry-pi?

Gruß

Thomas