Firmata+Arduino

[Achim]

Hallo,

Ibin mit Sicherheit nicht der Softwarespezialist und möchte hiermit niemand auf die "Füsse treten".

Beim "Herumsurfen" bin ich auf folgenden Artikel gestossen (http://www.freetronics.com/pages/usb-power-and-reset])

The Reset IC connected to the Wiznet W5100 Ethernet IC is the very common STM811 or many compatible parts.

This reset IC performs two functions: Firstly it holds the W5100 in reset if the VCC rail is less than 4.38V. Secondly, it holds the W5100 in reset for 140-280 milliseconds after the board is powered up.

Ethernet Reset IC Delay
If your W5100 Ethernet IC is not 'awake' after your board is powered up or reset, the most likely issue is that your Arduino microcontroller has come out of reset sooner than the W5100 IC, and the sketch has sent the W5100's ethernet configuration out before the W5100 140-280ms reset period has expired.
This is because the Arduino microcontroller has a 65 millisecond powerup/reset delay, the longest available to be set by the fuses and bootloader, and the STM811 Reset IC controlling the W5100 Ethernet IC has a longer reset delay of 140-280 milliseconds.

The fix:

Insert this line as the very first line in the void setup() { function in your project:

delay( 50 );   // allow some time (50 ms) after powerup and sketch start, for the Wiznet W5100 Reset IC to release and come out of reset.

Ist das nicht vielleicht eine Ursache der Verbindungsprobleme wenn der Arduino neu gestartet wird.

Achim

[ntruchsess]

...niemand auf die "Füsse treten".

Hallo Achim,

keine Angst, mit solchem Input trittst Du hier niemandem (jedenfalls ganz sicher nicht mir) auf die Füße. Ich schau mir mal an, ob so ein Delay in der Ethernet-library berücksichtigt wird und was eigentlich bei einem Ethernet.begin() so alles passiert. Wäre echt nicht schlecht, wenn das vieleicht mit so einem trivialen Delay in den Griff zu kriegen wäre.

Danke Dir für den Input!

Gruß,

Norbert

[kaizo]

Hallo AchimU,

guter Tipp, hat bei mir leider zu keiner Änderung geführt. Habe direkt nach der setup{.... ein delay (100); eingefügt, leider stürzt der gesamte fhem-Prozess immer noch ab.
Werde mal noch ein bisschen testen und größere Zeiten probieren, ob sich hier eine Änderung ergibt.

Leider stürzt der Prozess immer noch ab, und der Grund kann aus den Log's nicht ergründet werden.
Mal läuft alles ganze 15h, mal aber auch nur 10min.

Nicht gerade zufriedenstellend....


Gruß
Kai

[kaizo]

Hallo Norbert,

hast Du auch ein DS2423 am Arduino/Firmata einmal ausprobiert?
Ich habe hier zwei DS2423-Alternativen aus dem Forum im Einsatz, bei der Abfrage der Zählerstände kommt ein Fehler:

OWCOUNT: Could not get values from device Counter3, reason: invalid data length, 3 instead of 45 bytes in three stepsinvalid data length, 3 instead of 45 bytes in three steps

Erkannt werden die Counter einwandfrei...

OWX: 1-Wire devices found on bus OWio
10.A08098010800      DS18S20/DS1920 OWX_10_A08098010800
28.395507040000      DS18B20        OWX_28_395507040000
28.95212D040000      DS18B20        Aussentemperatur
1D.A2D988000002      DS2423         Counter3
1D.A2D988000003      DS2423         OWX_1D_A2D988000003


PS: das Delay nach "void setupEthernetClient(){" habe ich nun mal auf 300ms gesetzt, dann sollte der Chip ja spätestens einsatzbereit sein. Mal sehen, ob das hilft.

Gruß
Kai

[Wzut]

Der asynchrone OWX-kern ist Prinzip schon fertig, Leider muss ich noch alle Sensor-module an den umgekehrten Informationsfluss (zwischen OWX und Sensormodul) anpassen.

Bedeutet das OWTHERM mit deinen neuen OWX Dateien noch nicht zusammen arbeitet ?
Ich habe die gestern mal getestet :
Positiv : es gibt beim fhem start kein Gemecker mehr über die OWX defines
Negativ : meine drei DS1820 sind zwar alle im Status "initialized" aber Temperatur Abfrage schlägt leider fehl,
Bsp ; "OWTHERM: Could not get values from device OWX_10_EEAC4D020800, return was invalid data length, 1 instead of 10 bytes"

[ntruchsess]

Bedeutet das OWTHERM mit deinen neuen OWX Dateien noch nicht zusammen arbeitet ?

nein, das bezieht sich auf meinen noch nicht veröffendlichten Arbeitsstand. Der hier im Thread vorab veröffendlichte Stand arbeitet noch synchron. Der wird ins SVN committed, sobald Peter Henning die Implementierung für CUNO erfolgreich getestet hat.

Ich habe die gestern mal getestet :
Positiv : es gibt beim fhem start kein Gemecker mehr über die OWX defines
Negativ : meine drei DS1820 sind zwar alle im Status "initialized" aber Temperatur Abfrage schlägt leider fehl,
Bsp ; "OWTHERM: Could not get values from device OWX_10_EEAC4D020800, return was invalid data length, 1 instead of 10 bytes"

Du hast die hier im Thread veröffendlichte OWX+OWX_FRM-Version getestet? Über USB oder Ethernet? Funktioniert es, wenn Du die OWTHERM-devices vor dem Neustart aus der fhem.cfg entfernst (die sollten vom OWX automatisch wieder angelegt werden)?

Gruß,

Norbert

[ntruchsess]

hast Du auch ein DS2423 am Arduino/Firmata einmal ausprobiert?
Ich habe hier zwei DS2423-Alternativen aus dem Forum im Einsatz, bei der Abfrage der Zählerstände kommt ein Fehler:

Nein, einen DS2423 oder den hier im Forum veröffendlichten Nachbau habe ich leider nicht, bei mir werkeln nur DS18B20. Wenn Du mir einen schicken würdest, könnte ich mich aber drum kümmern. Wenn Du es selber untersuchen willst, solltest Du erst mal testen, ob die Arduino-OneWire-library mit dem DS2423-Nachbau klar kommt. Dazu müsstest Du einen Arduino-sketch schreiben, der unter Verwendung der mit Firmata ausgelieferten OneWire-library direkt mit dem Teil kommuniziert (ohne die Fernsteuerung über Firmata und Fhem).

Gruß,

Norbert

[ntruchsess]

The fix:
Insert this line as the very first line in the void setup() { function in your project:
delay( 50 );   // allow some time (50 ms) after powerup and sketch start, for the Wiznet W5100 Reset IC to release and

Hab grade mal einen Blick in die Ethernet-library geworfen. Ein Aufruf von Ethernet.begin ruft erst mal W5100.init() auf. Und da steht als erste Zeile ein 'delay(300)' drin.

Ein weiteres Delay im Setup sollte damit überflüssig sein. (Schade... so ein simpler fix wäre auch zu schön gewesen...)

Gruß,

Norbert

[kaizo]

Hallo zusammen,

Negativ : meine drei DS1820 sind zwar alle im Status "initialized" aber Temperatur Abfrage schlägt leider fehl,
Bsp ; "OWTHERM: Could not get values from device OWX_10_EEAC4D020800, return was invalid data length, 1 instead of 10 bytes"

Das habe ich auch so. Ich lasse die Definition von FRM in der cfg-Datei und muß immer den OWX "von Hand" definieren nach einem Neustart, dann geht die Abfrage auch. Lasse ich alles in der cfg-Datei dann bekomme ich die gleiche Meldung und die Werte werden nicht ermittelt. Lösche doch mit "delete ..." einfach mal die OWX-Definition, definiere das dann neu und Du wirst sehen, die Werte werden wieder angezeigt.

Interessant ist bei mir auch, bei einem rereadcfg stürzt FHEM ab. Es reicht bei mir, wenn FRM definiert ist, dann geht das rereadcfg schon nicht mehr. Fehlermeldung Console:
Can't use string ("2") as a HASH ref while "strict refs" in use at ./FHEM/10_FRM                                                              .pm line 88.

Nein, einen DS2423 oder den hier im Forum veröffendlichten Nachbau habe ich leider nicht, bei mir werkeln nur DS18B20. Wenn Du mir einen schicken würdest, könnte ich mich aber drum kümmern. Wenn Du es selber untersuchen willst, solltest Du erst mal testen, ob die Arduino-OneWire-library mit dem DS2423-Nachbau klar kommt. Dazu müsstest Du einen Arduino-sketch schreiben, der unter Verwendung der mit Firmata ausgelieferten OneWire-library direkt mit dem Teil kommuniziert (ohne die Fernsteuerung über Firmata und Fhem).

Ich hatte auch schon überlegt, die Counter mal am Ardunio mit einem eigenen Standanlone-Sketch abzufragen. Das wird der nächste Weg sein. Wenn ich nicht weiterkomme würde ich Dir einen ATTiny25 mit drei Drähten zusenden, den könntest Du dann an den Arduino anklemmen und testen. Wir bleiben hierzu in Kontakt...

Das Einfügen der Delay-Anweisung 300 hat leider nicht gereicht, und es stimmt, ich hätte ja eigentlich einfach mal in die Ethernet-Lib sehen müssen, dann hätte ich die Delay-Anweisung sicherlich auch entdeckt. Wirklich schade das es nicht so einfach zu lösen ist....



Gruß
Kai

[kaizo]

Hallo Norbert,

habe das mit den DS2423 nun mal getestet. Ob die mit dem Standard-OneWire.h abfragbar sind weiß ich nicht, habs nicht probiert. Da allerdings ein Prom abfragbar ist (DS250x) sollte darüber auch der Zählerstand abfragbar sein, da es sich ja "nur" um eine Speicherzelle in dem DS2423 handelt.

Ich habe eine DS2423.h im Netz gefunden, mit welcher ich die Zählerstände einwandfrei auslesen konnte. Es liegt als nicht an dem DS2423. Hänge ich hier mal an.

Leider sind zur Zeit die ständigen Abstürze des FHEM-Servers viel ärgerlicher, ich kann das Ding bald alle 5 Minuten neu starten. Die Abstürze sind nicht nachvollziehbar. Am Wochenende werde ich mal auf einen Rasberry Pi umsteigen und hoffen, dass der ganze Prozess dort etwas stabiler läuft. So ist Heimautomatisierung nicht mehr sinnvoll möglich.

Gruß
Kai

[ntruchsess]

Dein DS2423.h verwendet ja auch die 'OneWire.h'. Hast Du da die genommen, die mit der Firmata gebundelt kommt? (Das ist im Prinzip die OneWire-library von Paul Stoffregens Site mit ein paar kleinen Erweiterungen.

Wenn es damit funktioniert und 'remote' über OWX->FRM->Firmata->OneWire.h nicht, dann ist der DS2423-Nachbau vieleicht vom Timing her zu empfindlich. So wie OWX aktuell implementiert ist wird der Bus-reset und die eigentliche Schreib-/Lese-aktion auf dem OneWire-bus in zwei getrennten Aufrufen gemacht. Der zeitliche Abstand zwischen Reset und eigentlicher Kommunikation kann wegen des dazwischenliegenden Netzwerks nicht mit definiertem Timing durchgeführt werden (Die Aufrufkette OWCOUNT->OWX->FRM->TCPIP->Firmata->OneWire.h ist nur für jeweils ein Firmata-kommando in sich zeitlich garantiert. Firmata an sich kann zwar die Aufruffolge 'Reset->Select->Write->Read' in einem Aufruf durchführen, dazu muss das von OWX aber auch so aufgerufen werden.... Eine entsprechende OWX-Version, die das so bündelt habe ich in Arbeit

Ich würde so einen gefakten DS2423 ja gerne mal direkt mit der PerlFirmata (ohne FHEM/OWX) testen um dazu was sicheres sagen zu können...

An der Stabilität der Netzverbindung zwischen Arduino und FHEM habe ich letztes Wochenende mal gearbeitet und versucht das systematisch anzugehen. Mit meinem EthernetShield läuft das auch nicht so toll, liegt bei mir aber eher an der Hardware (die Ethernetbuchse meines Shields neigt zum Wacketkontakt mit den Patchkabeln, die ich habe...) Naja - einen Patch, der einen FHEM-absturz bei ständig abbrechender Verbindung zum Arduino behebt habe ich ins SVN committet, der Sketch selbst ist noch nicht wirklich final (ich konnte aber herausfinden, das es - funktionierende Hardware vorrausgesetzt - recht zuverlässig wiederverbinden kann, wenn man nach dem Erkennen eines Verbindungsabbruchs am EthernetClient-object die stop()-methode aufruft. Ohne das Stop bleibt die Verbindung im WIZ5100-chip offenbar logisch erhalten und der neue connect-versuch führt nicht zu einem neuen Verbindungsaufbau). Der Nachteil ist, dass - wenn der Arduino dauernd erfolglos 'connect'->'stop' aufruft beim Wiederverbinden die ganzen Pakete im Puffer des Wiz5100 erst mal rausgehen und in FHEM erst mal ein Schwung sofort wieder abbrechender Verbindungsveruche ankommt. Naja - ist halt noch 'Work in Progress'...

Gruß,

Norbert

[kaizo]

Ich habe die modifizierte OneWire.h aus /utility/ genommen, so wird die ja eingebunden.

Ich glaube nicht, dass es an den nachgemachten DS2423 liegt. Ich habe gerade einen original DS2423 angeschlossen, und hier ist es die gleiche Fehlermeldung.
Meine Vorgehensweise:

define FRM FRM 3030 global
define OWio OWX 2  // Pin 2 am Arduino
get OWio devices

Meldung:
OWX: 1-Wire devices found on bus OWio
10.A08098010800      DS18S20/DS1920 OWX_10_A08098010800
28.395507040000      DS18B20        OWX_28_395507040000
28.95212D040000      DS18B20        OWX_28_95212D040000
1D.A2D988000003      DS2423         OWX_1D_A2D988000003   // hier ist der ATTINY 25
1D.9EC30D000000      DS2423         OWX_1D_9EC30D000000   //hier ist der Original-DS2423

dann
get OWX_1D_9EC30D000000 counters

MELDUNG:
OWCOUNT: Could not get values from device OWX_1D_9EC30D000000, reason: device 1D.9EC30D000000.90 returns invalid datainvalid data length, 3 instead of 45 bytes in three steps  

get OWX_1D_9EC30D000000 present

MELDUNG:
OWX_1D_9EC30D000000.present => 0    // Hier müsste ja eine "1" stehen

(Das gleiche auf einen DS1820 ergibt auch eine "0")

Ich könnte Dir einen FAKE-DS2423 zur Verfügung stellen, schick mir doch mal eine PN mit Deiner Adresse, dann sende ich Dir den zu. Vorher löte ich noch ein paar Drähte dran, dann kannst den besser an deinen Arduino hängen.

Das Du an der gesamten Geschichte weiterentwicklest freut mich sehr, denn, auch wenn ich mich hier wiederhole, die Lösung mit Firmata und Arduino ist eine gute Geschichte (wenn sie dann mal durchgängig laufen wird)

...Naja - einen Patch, der einen FHEM-absturz bei ständig abbrechender Verbindung zum Arduino behebt habe ich ins SVN committet...

Auch wenn das noch nicht Final ist, schick doch mal eine beta ;-) oder sag, in welchem SVN. Ich finde den nicht.
Bestimmt schon besser, als die ganzen Abstürze.

Gruß
Kai

[det.]

Hallo Norbert,

bitte sende mir eine pm mit Deiner Adresse und ich schick Dir am Freitag einen meiner 2 fertig aufgebauten dougie Zähler raus. Habe die z.Z. eh noch nicht fest eingebaut, aber getestet sind die und funktionieren. Kannst Du gern so lange behalten wie Du willst.

[woody]

Hallo Leute,
habe mich jetzt auch mal an dieses Them gewagt. Leider habe auch ich Abstürze von fhem nach eintragen von der frm konfiguration. Auch beim bearbeiten der fhem.cfg stürzt fhem permanent ab. Selbst das rereadcfg bewirkt einen Absturz von fhem.

Gibt es hier schon neue Erfahrungen oder workarounds?

Das reconnecten mit Ethernet funktioniert übrigens ganz gut. Habe die aktuelle configurableethernetclient V_2_04 auf einem Uno mit wiznetshield.

Konnte jemand das mit dem "return was invalid data length, 1 instead of 10 bytes " lösen?

Viele Grüße

woody

[ntruchsess]

Das Du an der gesamten Geschichte weiterentwicklest freut mich sehr, denn, auch wenn ich mich hier wiederhole, die Lösung mit Firmata und Arduino ist eine gute Geschichte (wenn sie dann mal durchgängig laufen wird)

danke für die Blumen. Im Moment hätte ich gerne etwas mehr Zeit mich da wieder richtig reinkieen zu können. Hausautomation ist halt irgendwie etwas für die langen Winterabende ;-)

...oder sag, in welchem SVN. Ich finde den nicht.

das findest Du im fhem-svn:
siehe Changelog, Revision r3150

Danke für das Angebot mit dem Fake-2423 - ich habe grade 'det' angeschrieben, der mir auch einen angeboten hat. Falls das nichts wird komme ich gerne auf Dein Angebot zurück. Einer sollte ja reichen um das zum Laufen zu kriegen.

Gruß,

Norbert