FRM_IN: state wird jetzt sofort nach define/connect/restart etc. gesetzt

[ntruchsess]

siehe Betreff. Damit es funktioniert muss man die ConfigurableFirmata vom 22.11.2013 oder neuer benutzen. Die sendet jetzt den Status eines digitalen Inputs direkt nach dem konfigurieren - bisher kam das erst rüber, wenn sich der Status das erste mal geändert hat. Hier der change in der Firmata.
Gleiches gilt für FRM_AD, nur fällt das nicht so auf, weil da der Status sowieso regelmäßig (nach attribut 'sampling-interval' übermittelt wird

- Norbert

[Achim]

Hallo Norbert,

das funktioniert bei mir nicht. Ich habe mir die neuste ConfigurableFirmata heruntergeladen und in die Firmata Library kopiert. Sketch neu compiliert und auf den Nano mit ENC28J60 Shield kopiert. IN/OUT/Analog_IN auf FHEM konfiguriert, funktioniert alles bestens. Nun habe ich den Eingang und den Ausgang gesetzt und danach den Nano ausgeschaltet. Dann den Eingang auf 0 gesetzt und den Nano wieder eingeschaltet. Der Ausgang wird nach kurzer Zeit wieder gesetzt, die Eingangsanzeige bleibt auch gesetzt, obwohl der Eingang auf 0 ist.

So wie ich das aber verstanden habe, sollte der Status nach einem Reconnect auch bei Eingängen wieder gesetzt werden.

MFG Achim

[Achim]

Hallo Norbert,

ich habe das Verhalten bei restart des Arduino mit den digitalen Eingängen (FRM_IN) weiter getestet. Folgendes kam dabei heraus:

Status Eingang                       Anzeige FHEM
vor Neustart     nach Ausschalten    vor Neustart    nach Neustart
0                1                   0               1
1                0                   1               1

Die Statusaktualisierung funktioniert nach meinen Tests nur beim Übergang von 0 auf 1 in der "Ausschaltphase".

Ich habe in der Funktion "reportDigital" die Werte auf die Console ausgegeben. Bei jedem Neustart (egal welche Statusänderung am Eingang) wurde folgendes ausgegeben (die Routine wurde dabei zweimal durchlaufen:

Code Auswählen Erweitern

Serial.print("port = ");
Serial.print(port);
Serial.print(" value = ");
Serial.println(value);

port = 0 value = 1
port = 1 value = 1

leider reichen meine C-Kenntnisse nicht, um in den Verschachtelungen der Funktionsaufrufe weiter dem Fehler auf den Grund zu gehen.

MfG Achim

[ntruchsess]

danke für's testen, ich kann mir das leider erst am Wochenende genauer anschauen.
Aber schau doch mal, wann die lätzte Änderung der perl-firmata libraries per update gekommen ist, der Fix ist nämlich nicht nur Arduino-seitig.

Gruß,

Norbert

[Achim]

Hallo Norbert,

ich mache vor jedem neuen Test ein "update" von FHEM. Der einzige Eintrag im fhem.log der auf Updates im LIB Verzeichnis hinweist ist:

2013.12.01 18:39:30 3: update get http://fhem.de/fhemupdate4/svn/FHEM/lib/Device/Firmata/Platform.pm

Die Grundinstallation von meinem TEST-FHEM ist das Image von Dirk mit seinem Display Support.

Ich habe die Dateien auf sourceforge (Download eines Snapshot) mit meiner in der FHEM Installation vergleichen. Sind beide identisch. Bis auf drei Dateien. Auf meiner Installation hat der Verzeichnis ../lib/Device/Firmata/IO gefehlt (NetIO.pm und SerialIO.pm). Habe ich dann aus dem Snapshot in die Installation kopiert. Bei mir war die Datei IO.pm im Firmata Verzeichnis vorhanden, die hat in dem Snapshot gefehlt. Lasse ich mal stehen und mache neue Tests.

[edit]
Ich habe das Problem weiter eingegrenzt. Folgende Definition habe ich bei meinen ersten Tests verwendet:

Code Auswählen Erweitern

define D5 FRM_IN 5
attr D5 verbose 0
attr D5 internal-pullup off
attr D5 room NANO

Wenn ich das internal-pullup Attribut weglasse:

Code Auswählen Erweitern

define D5 FRM_IN 5
attr D5 verbose 0
#attr D5 internal-pullup off
attr D5 room NANO
wird auch der Übergang von 1 auf 0 am Eingang während eines Neustarts des Arduinos nach dem Reconnect korrekt im FHEM angezeigt.

Mit einem externen Pullup/Pulldown Widerstand funktioniert auch alles korrekt. Es muss meiner Meinung nach irgendwo im Code bei der Definition des internen Pullups liegen.

Das Vorhandensein (oder auch nicht) des Verzeichnisses IO mit den beiden Dateien hat bei meinen Tests keinen Einfluss auf das Verhalten. Für was werden diese Dateien benötigt, bzw. welche der 3 Dateien (IO.pm, NetIO.pm und SerialIO.pm) werden benötigt?

MfG Achim

[ntruchsess]

ok, ganz ohne pullup ist der Zustand eines Eingangs praktisch komplett undefiniert - da brauchst Du dich über die Ergebnisse nicht wundern. Wenn man physikalische Schaltkontakte verwendet, die ja nur offen/geschlossen sein können, dann ist ein Pullup einfach Pflicht. Da braucht man nicht weiter nach einem Bug zu suchen, die Eingänge sind einfach ohne Pullup zu hochohmig.
SerialIO.pm und NetIO.pm gehören zum letzten Update das Ethernet-unterstützung schon in der perl-firmata selbst mitbringt. Vor dem Update gab es nur die IO.pm (für die Serielle Schnittstelle). Wird beides von FHEM nicht unmittelbar benutzt, deshalb schadet es jetzt auch nicht, dass das nicht mitkam - FRM bringt eine eigene Implementierung des perl-firmata IO-interfaces mit. Wundert mich aber, dass das beim Update nicht mitkommt, muss ich am Wochenende mal testen.
Wichtig ist die eine geänderte Zeile in der Plattform.pm und die ist ja offenbar bei Dir angekommen

- Norbert

[Achim]

Hallo Norbert,

da habe ich mir dann nicht richtig ausgedrückt. Ich habe bei meinen Versuchen an den Eingängen immer definierte Pegel angelegt. Entweder durch Pullups/Pulldowns (1k um auf der sicheren Seite zu sein) und/oder durch direktes Verbinden des Eingangs mit Masse oder 5V (Kippschalter).

Das Problem tritt dann auf, wenn man mit FHEM den internen Pullup Widerstand einschaltet. Ich vermute das beim Reconnect das Setzen des internen Pullups den vorhandenen Zustand 0 "überschreibt" und daher keine Leveländerung von Firmata gesendet wird.

MfG Achim

[ntruchsess]

Hallo Achim,
jetzt ist klar, was Du meinst
Das wird wohl tatsächlich so sein, dass das Setzen des internen pullups da durchkommt. Ich schaue ich mir das heute abend genau an. Danke, dass Du das so eingehend untersucht hast!
Gruß,
Norbert

[Achim]

Hallo Norbert,

danke nicht mir für die Tests. Ich (und die vielen Anwender von FHEM) müssen dir für den hohen Aufwand die ganze Module zu programmieren viel mehr danken.

MfG Achim

[ntruchsess]

Das passt schon. Ab einem gewissen Reifegrad einer Software ist man als Entwickler auf qualifizierte Testergebnisse angewiesen. Ich freue mich da sehr darüber, wenn die Community so funktioniert. Fehler kann man ja nur beheben, wenn man von ihnen weiß...

- Norbert

[Stephan]

Gibt es hier schon neue Erkenntnisse?
Ich benutze auch den internen Pullup und habe nach dem Einschalten Impulse.

[ntruchsess]

Mit Impulsen meinst Du, dass FRM_IN bei gesetztem internal-pullup beim Einschalten gleich mal um 1 hochzählt?

[Stephan]

Ja, genau. Das wollte ich damit ausdrücken.
Weiß nicht ob es was damit zu tun hat, ich habe einen UNO r3, ein Ethernet shield mit 5100, ich gehe mit gnd auf 2 readkontakte und von dort auf pin 5 und pin 6 mit gesetztem Attribut internal-pullup on.
Fand ich Schaltungstechnisch am elegantesten. Beim Wasserzähler ist das kein Thema, dort ist das nur ein Liter, beim Gaszähler sind es aber schon 0,1cbm, das sind ja schon mal ~1,x kWh.

[ntruchsess]

sind die reed-kontakte NC oder NO (normaly closed/open)?

[Stephan]

Offen
Wobei man das ja nicht mit Sicherheit vorhersagen kann, er kann genau in den Moment natürlich auch geschlossen sein.
Gruss
Stephan