Arduino DINo Relaisboard + Configurable Firmata = hängt sich auf

[rico5588]

Jens das ist der Wahnsinn....

deine Firmata 2.8.2 geht super, bin dir sehr Dankbar.

Ich hoffe es hilft auch noch anderen.
Ursache des eigentlichen Problems war die zu große Spannung.
Laut Hersteller (KMtrinoc) sollen es 12V sein. Hier wird er aber scheinbar so heiß das er sich aufhängt.
Bei nur noch 10 V wird er zwar immer noch sehr warm aber stürzt aber nicht mehr ab.

auf zum nächsten Projekt:
Ich habe gelesen das man über den P1 Header auch 1 Wire nutzen kann (theoretisch)
Könntest du mir einen Tipp geben a. mit welchem Sensor und b. was man dazu an der Config anpassen muss?

MFG Rico

[jensb]

Hallo Rico,

freut mich sehr, dass Firmata bei dir jetzt läuft.

Mit P1 Header meinst du wahrscheinlich den RPi. Es geht auch mit ConfigurableFirmata - da hast du die Wahl. Habe schon über 1Wire nachgedacht, aber noch keine Erfahrung. Mach ein neues Thema auf und viel Erfolg!

Grüße,
Jens

[jensb]

P.S.:

Da du jetzt ConfigurableFirmata 2.8.2 verwendest, bist du auf die aktualisierten Firmata-Komponenten von FHEM angewiesen. Wenn du in FHEM "update" aufrufst, werden die manuell eingespielten Versionen mit den jeweils offiziellen Versionen ersetzt. Es kann u.U. noch etwas dauern, bis Norbert die neuen Versionen freigibt. Bis dahin müsstest du nach einem FHEM-Update prüfen, ob die Unterstützung für 2.8.X vorhanden ist und wenn nicht, die Dateien noch einmal installieren (z.B. aus dem Unterverzeichnis restoreDir kopieren). Wenn du das vermeiden willst, solltest du noch einmal einen Anlauf mit Firmata bis 2.6.X machen.

Jens

[Uef]

Hallo zusammen,
auch wenn das Thema schon etwas älter und gelöst ist, passt mein Problem doch genau hier rein.

Kurz zum Hintergrund: eigentlich will ich die ConfigurableFirmata (CF) nur für 1Wire nutzen und habe dafür mit einem Arduino Nano mit einem ENC28J60 Ethernet-Shield gestartet.
Nach den ersten Problemen bin ich dann auf einen UNO mit w5100-Shield (wegen des kleineren Codes) und der ConfigurableFirmata vom 20.4 2015 (wegen der besseren Kompatibilität) gewechselt. FHEM ist aktuell.

In der CF hatte ich nur 1wire und FirmataExt aktiviert, und bekam auch immer den "Unhandled sysex command" Fehler.
Erst wenn man, wie Jens empfohlen hat, AnalogInput mit hinzu nimmt, werden im FRM-Device in FHEM auch die Pins angezeigt.

Danach könnte man vermuten, dass das Problem in der CF liegt (und eventuell ist da auch noch eins, ggf. in der Pin-Definition), aber ich habe mir auch den Ablauf der Kommunikation zwischen FRM und der CF angeschaut und verstehe da einen Punkt nicht.

Genau wie bei Rico seinerzeit ist der Ablauf bei mir wie folgt (Jens hat das damals ja auch gut verständlich beschrieben)

• Es gibt von FRM einen Resetbefehl ff --> Connection accepted
• Dann wird die Version mit f079f7 abgefragt --> die CF antwortet (wenn man die Antwort decodiert, kommt auch der Versionstext raus)
• Dann aber sendet FRM ein "f069f7"  --> das ist eine ANALOG_MAPPING_QUERY
• Direkt im Anschluss schickt FRM noch mit "f06bf7" die CAPABILITY_QUERY
• Dann schickt die CF die Fehlermeldung mit dem "Unhandled sysex command"

Hier der Log-Auszug dazu (die Schritte habe ich dort nochmal dazugeschrieben):

Code Auswählen Erweitern

2016.10.28 09:47:24.116 5: FRM:>f07a6807f7
2016.10.28 09:47:24.172 5: FRM:<f07155006e00680061006e0064006c0065006400200073007900730065007800200063006f006d006d0061006e006400f7
2016.10.28 09:47:24.174 3: received String_data: Unhandled sysex command
2016.10.28 09:52:06.985 5: FRM:>ff                                                              <--- Schritt 1
2016.10.28 09:52:11.993 4: Connection accepted from ArduFirmata01_192.168.0.221_49154       
2016.10.28 09:52:12.001 5: FRM:>ff
2016.10.28 09:52:14.099 3: querying Firmata Firmware Version
2016.10.28 09:52:14.100 5: FRM:>f079f7                         <--- Schritt 2
2016.10.28 09:52:14.103 5: FRM:<f07902
2016.10.28 09:52:14.115 5: FRM:<064f006e006500770069007200650048006f00730074005f003000300033002e0069006e006f00f7
2016.10.28 09:52:14.118 3: Firmata Firmware Version: OnewireHost_003.ino V_2_06
2016.10.28 09:52:14.118 5: FRM:>f069f7                         <--- Schritt 3
2016.10.28 09:52:14.120 5: FRM:>f06bf7                         <--- Schritt 4
2016.10.28 09:52:14.122 5: FRM:<f07155006e006800                                       <--- Schritt 5 (geht bis in die nächste Zeile)
2016.10.28 09:52:14.134 5: FRM:<61006e0064006c0065006400200073007900730065007800200063006f006d006d0061006e006400f7
2016.10.28 09:52:14.137 3: received String_data: Unhandled sysex command
2016.10.28 09:52:14.206 5: FRM:<f06c7f7f00017f00017f7f00017f00017f00017f00017f00017f7f7f7f7f00017f00017f00017f00017f00017f00017ff7
2016.10.28 09:52:17.086 5: FRM:>f07a6807f7
2016.10.28 09:52:17.099 5: FRM:<f07155006e00680061006e0064006c0065006400200073
2016.10.28 09:52:17.185 5: FRM:<007900730065007800200063006f006d006d0061006e006400f7
2016.10.28 09:52:17.186 3: received String_data: Unhandled sysex command
2016.10.28 09:52:39.958 1: 3030 disconnected, waiting to reappear (ArduFirmata01)
2016.10.28 12:01:23.679 1: 3030 disconnected, waiting to reappear (ArduFirmata02)


Meine Frage nun:
wieso findet Schritt 3 statt (erwartet hätte ich nach Jens' Beschreibung nur Schritt 4) ?
Und wieso so schnell danach auch Schritt 4, ohne dass eine Antwort von der CF kam ? (zumindest sieht das im Log so aus, kann in der Realität auch anders gelaufen sein)
Warum fragt FRM das analoge Mapping überhaupt ab, obwohl die Capability-Query noch gar nicht gelaufen ist ?

Darauf kann die CF meiner Meinung nach nur mit der genannten Fehlermeldung antworten, wenn im Sketch der CF einfach keine analogen Anschlüsse aktiviert (defined) wurden.

Kann es sein, dass hier noch ein kleiner Fehler in FRM steckt ?

Ich bin zugegebenermaßen nicht wirklich mit den Firmata-Protokoll vertraut (habe nur im Rahmen der Fehlersuche etwas gelesen) und vielleicht muß Schritt 3 auch sein, aber ich verstehe es nicht wirklich. AnalogInputs zu aktivieren ist natürlich ein Workaround, aber nicht so richtig schön.

Vielleicht hat Jens oder jemand der anderen Wissenden dazu eine Idee. Meine PERL-Skills reichen leider für eine Analyse der 10_FRM.pm nicht aus.

Danke und Gruß aus Aachen
Uef

P.S.: gibt es eigentlich irgendwo eine Doku, welche Version des Firmata-Protokolls die jeweils aktuelle FRM-Version unterstützt (im Code ? ich frage wegen, weil das bei einigen Usern (mir inklusive) zu Problemen bzw. Verwirrung geführt hat) ?

[jensb]

Hallo Uef,

deine Feststellung ist richtig, man könnte die ANALOG_MAPPING_QUERY weglassen, wenn man die CAPABILITY_QUERY auswerten würde - doch so ist das derzeit nicht umgesetzt. Alle Fragen an das Firmata-Device werden nach dem Verbindungsaufbau zunächst hintereinander auf die Reise geschickt und die Antworten werden asynchron verarbeitet, wenn sie eintreffen. Ein Umbau dieses Ablaufs ist möglich aber verhältnismäßig aufwendig, da man dann einen Zustandsautomaten für die Initialisierung braucht. Ein weiterer Vorteil wäre aber, dass FHEM beim Firmata-Verbindungsaufbau nicht mehr so lange blockiert ist. Die Änderung nur für diesen Anwendungsfall zu machen steht aber in einem schlechten Verhältnis zum Aufwand.

Vieles passiert auch im Firmata-Protokollhandler, der leider seit 2014 im FHEM-Repository nicht mehr aktualisiert wurde (siehe Unterverzeichnis FHEM/lib/Device/Firmata). Diesen Teil kann man aber über GitHub auf einen neueren Stand bringen. Hier finden sich auch die von dir gesuchten Kompatiblitätsinformationen:

• lib/Device/Firmata.pm: Versionnummer des Protokollhandlers (Zeile 22)
• lib/Device/Firmata/Constants.pm: die größte unterstützte Firmata-Version ist der letzte Eintrag mit V_XXX
  

Bitte auch beachten, dass es bei Firmata eine Anwendungs-Version und eine Protokoll-Version gibt. Die älteren Versionen von FRM und dem Firmata-Protokollhandler haben auf die Anwendungsversion geprüft, was zu einem Teil der heute auftretenden Problem geführt hat, da sich die Anwendungsversionen von Firmata und Configurable Firmata ganz unterschiedlich entwickelt haben. Erst mit dem Firmata-Protokollhandler 0.61 wird auf die Protokoll-Version geprüft, und die ist weitestgehend unverändert geblieben.

Grüße,
Jens

[Uef]

Hallo Jens,

vielen Dank für Deine ausführliche Antwort, die die Hintergründe gut erläutert.
Wenn Aufwand und Komplexität für die erforderlichen Anpassungen so hoch ist, dann ist die Aktivierung der analogen Pins sicher ein vernünftiger Workaround. Ist ja bzgl. der Ressourcen (Speicher) auch eher nicht so kritisch (zumindest besser als andere Funktionalitäten).

Ggf. sollte man einfach das Wiki an dieser Stelle ergänzen, das würde vermutlich schon mal helfen (kann ich gerne auch übernehmen; muss mir nur mal Zugriff besorgen).

Uwe

[seer]

Hallo zusammen.

Ob meine Frag wirklich hier her gehört weiß ich nicht genau, bitte verschieben wenn es der falsche platz ist.

Ich kämpfe nun schon seit Tagen an einem Arduino 1-Wire Busmaster herum und bekomme es einfach nicht zum laufen.
Möchte ihn nur per USB an einen RPI mit FHEM  hängen.

Es soll ja wohl die Version vom Mai 2015 mit OneWire gehen leider nicht bei mir oder ich bin zu blöde dazu.
Die Pins werden mir zwar angezeigt aber ich bekommen den DS18b20 nicht ans laufen, es werden keine Geräte gefunden.
Und die Log sagt mir leider nichts, hier mal alles was ich so an Log Eintagungen finden konnte.

Code Auswählen Erweitern


OWX_Set request Arduino_Temp_1Wire FF ?
2016.11.23 15:56:46 5 : FRM:>f0730104f7
2016.11.23 15:56:46 5 : SW: f0730104f7
2016.11.23 16:00:34 5 : FRM:>f0730104f7
2016.11.23 16:00:34 5 : SW: f0730104f7




FRM code

Code Auswählen Erweitern

defmod Arduino_Firmata FRM /dev/ttyUSB0@57600
attr Arduino_Firmata model nano
attr Arduino_Firmata room Arduino_1Wire
setstate Arduino_Firmata 2016-11-23 15:45:26 state opened


Device Code

Code Auswählen Erweitern

defmod Arduino_Temp_1Wire OWX 4
attr Arduino_Temp_1Wire IODev Arduino_Firmata
attr Arduino_Temp_1Wire buspower real
attr Arduino_Temp_1Wire room Arduino_1Wire
setstate Arduino_Temp_1Wire 2016-11-23 15:20:34 state defined

Ich weiß nicht mehr welchen Sketch und welche Libraries ich noch auf den Nano schieben soll.
Die Verzweiflung ist nahe bitte um Hilfe.

Gruß

[buec65]

Schau mal in die fhem.cfg
Da sollte wenn du Pin12 für 1-wire nutzt folgendes rein

#
#
define owxFRMPHZ OWX 12
attr owxFRMPHZ IODev PHZ
# definiert Arduino Pin 12 als 1-Wire Eingang
#

Pin Nr. musst du an deine Verkabelung anpassen

[Uef]

Hallo seer,

grundsätzlich wird der Arduino mit der Firmware ja wohl erkannt.

Auf die Schnelle erstmal zwei Ideen:

• mir fällt auf, dass Du für den Arduino-Sketch sehr viele Firmata-Features aktiviert hast. Ich weiß jetzt nicht genau, ob das auch ohne Ethernet zu Speicherengpässen im Arduino führen kann, aber bei mir läuft es in der gleichen Konstellation wie bei Dir, wenn ich nur DigitalInput, DigitalOutput, AnalogInput und natürlich OneWireFirmata und FirmataExt aktiviert habe.
• hast Du an den PullUp-Widerstand am 1Wire-Pin des Arduinos gedacht ?

Grüße aus Aachen
Uef

[seer]

Hallo.

Der Widerstand war das Problem.
Hatte einen 1M dran und jetzt einen 4.7K

Habe parallel noch einen ESP8266 NodeMCU M LAUFEN MIT 1-Wire und der läuft auch mit einem 1M  von daher habe ich einfach beim Arduino auch einen genommen war wohl de falsche Entscheidung.

Code Auswählen Erweitern

defmod OWX_28_FF575A051603 OWTHERM DS18B20 FF575A051603
attr OWX_28_FF575A051603 IODev Arduino_Temp_1Wire
attr OWX_28_FF575A051603 model DS18B20
attr OWX_28_FF575A051603 room OWX
attr OWX_28_FF575A051603 tempHigh 75
attr OWX_28_FF575A051603 tempLow 70

setstate OWX_28_FF575A051603 T: 17.75 °C ↓
setstate OWX_28_FF575A051603 2016-11-23 19:14:15 state T: 17.75 °C ↓
setstate OWX_28_FF575A051603 2016-11-23 19:14:15 temperature 17.75


Danke euch.

[Uef]

1M ist allerdings wirklich sehr groß ! Als Pullup geht das eigentlich nicht mehr durch
Ich staune, dass es am ESP8266 damit überhaupt funktioniert. Für parasitäre Versorgung und längere Busse sicher nicht geeignet.

Aber Hauptsache, es läuft.
Uef

[seer]

Vielen vielen Dank für den ausschlaggebend Hinweis.

Aber wenn wir gerade bei den Widerstände sind.
Ich weiß das ich einen einbauen muss.
Aber warum würden ich auch gerne wissen. Wieso benötige der data PIN noch mal +V

Bin einer der gerne alles versteht um den Fehler nicht noch einmal zu machen.

Gruß

Gesendet von meinem Nexus 5 mit Tapatalk

[Uef]

Der Pullup-Widerstand ist dafür da, die Datenleitung auf +5V (bzw High) zu ziehen; das können nämlich weder der Master noch die Slaves. Die können die Leitung über einen Transistor (o.ä) mit OpenCollector nur auf Low ziehen. High ist also der Ruhezustand.
Aber alle lauschen natürlich auf der Leitung.
Wenn die nun Low ist und der Slave (oder der Master) es nicht selbst war, ist ein anderer Busteilnehmer aktiv - und der Slave muss warten (z.B. mit seiner Antwort an den Master).
Ist die minimale elektrische Ausführung einer Collision-Detection.

Damit das Timing des 1Wire-Buses klappt, darf der Widerstand nicht zu lange brauchen, um die Leitung wieder auf High zu ziehen.
Für ganz lange Busse empfiehlt Maxim statt Widerständen sogar aktive PullUps mit höherer Stromkapazität, da dann sogar die 4.7K zum Engpass für das Timing werden können.

Uef

[seer]

Top vielen Dank.
Das ist doch mal ne Auskunft.