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. ;-)
sorry dass ich mich noch nicht gerührt habe, hab den Thread erst grade gesehen.
Teste mal die ConfigurableFirmata wie hier im wiki (http://www.fhemwiki.de/wiki/Arduino_Firmata) 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
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
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
Optokoppler wären vieleicht auch eine Option.
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
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
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));
}
}
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
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 (http://hardware.slashdot.org/story/12/08/24/2228251/serious-problems-with-usb-and-ethernet-on-the-raspberry-pi)?
Gruß
Thomas