siehe Betreff. Damit es funktioniert muss man die ConfigurableFirmata (https://github.com/firmata/arduino/archive/configurable.zip) 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 (https://github.com/firmata/arduino/commit/6e723d49db3eef09debef80d041b724ffb902c84) 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
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
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:
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
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
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:
Zitat2013.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:
define D5 FRM_IN 5
attr D5 verbose 0
attr D5 internal-pullup off
attr D5 room NANOWenn ich das internal-pullup Attribut weglasse:
define D5 FRM_IN 5
attr D5 verbose 0
#attr D5 internal-pullup off
attr D5 room NANOwird 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
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
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
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
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
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
Gibt es hier schon neue Erkenntnisse?
Ich benutze auch den internen Pullup und habe nach dem Einschalten Impulse.
Mit Impulsen meinst Du, dass FRM_IN bei gesetztem internal-pullup beim Einschalten gleich mal um 1 hochzählt?
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.
sind die reed-kontakte NC oder NO (normaly closed/open)?
Offen
Wobei man das ja nicht mit Sicherheit vorhersagen kann, er kann genau in den Moment natürlich auch geschlossen sein.
Gruss
Stephan
Zitat von: Achim am 06 Dezember 2013, 08:14:17Das 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.
Dieser Fehler ist jetzt behoben (https://github.com/ntruchsess/fhem-mirror/commit/63ea88447d8b90a50dc12c7b0e8a9f66399d566d). Lag daran, dass die perl-firmata den State der Pins intern speichert und den Callback im FRM_IN nur aufgerufen hat, wenn sich der Zustand (aus Sicht der perl-firmata) beim Empfangen einer Digital-message auch geändert hat.
Fix ist ins fhem-SVN committed.
Wenn man den FRM_IN-internen counter verwendet, können mit internem pullup aber weiterhin noch Pulse beim Initialisieren gezählt werden (da macht der Pin ja tatsächlich einen Statusübergang), dafür mache ich einen separaten Patch (https://github.com/ntruchsess/fhem-mirror/issues/5).
- Norbert
Hallo!
Ich nutze eine Arduino Mega um Impulse eines Stromzählers zu zählen. Mir ist auch schon aufgefallen das hochgezählt wird wenn fhem neu startet.
Hab gerade ein Update gemacht und das mal ausprobiert. Das reading "reading" ist im normal fall on und wenn ein Impuls vom Stromzähler kommt, kurz off.
Leider wird bei mir durch den neustart immer noch reading auf off gesetzt und dann wieder on. activeLow hab ich testweise mal auf on mal auf off gehabt. Hat leider nichts bewirkt.
Hab ich vielleicht noch etwas falsch definiert?
Internals:
CFGFN ./FHEM/arduino.cfg
DEF 46
IODev FIRMATA
NAME arduino_pin_46
NR 67
PIN 46
STATE 1393518630.63931
TYPE FRM_IN
Readings:
2014-02-27 17:30:30 lastPower 175
2014-02-27 17:30:30 power 0.87
2014-02-27 17:30:30 power_avg_day 673.0
2014-02-27 17:30:30 power_avg_month 136.0
2014-02-27 17:30:30 power_cum_day 42417816.07
2014-02-27 17:30:30 power_cum_month 325718641.129995
2014-02-27 00:17:26 power_max_day 1993.1
2014-02-23 13:43:53 power_max_month 1999.9
2014-02-27 17:30:09 power_min_day 0.1
2014-02-25 12:32:09 power_min_month 0.1
2014-02-27 17:31:40 reading on
2014-02-27 17:30:30 state Initialized
2014-02-27 17:30:30 time 1393518630.63931
Attributes:
alias Stromzähler Boiler
internal-pullup on
room Arduino
stateFormat time
userReadings time:reading:.off { use Time::HiRes qw(time); time(); }, power:reading:.off { ReadingsVal("d_stromverbrauchBoiler","state",0); }
Grüße
Zitat von: fhainz am 27 Februar 2014, 17:42:56Hab ich vielleicht noch etwas falsch definiert?
nein, denn:
Zitat von: ntruchsess am 26 Februar 2014, 18:30:06Wenn man den FRM_IN-internen counter verwendet, können mit internem pullup aber weiterhin noch Pulse beim Initialisieren gezählt werden (da macht der Pin ja tatsächlich einen Statusübergang), dafür mache ich einen separaten Patch (https://github.com/ntruchsess/fhem-mirror/issues/5).
ich muss halt noch was einbauen, was den counter erst aktiviert, nachdem der Statusübergang vom Aktivieren des internen-pullups stattgefunden hat.
Gruß,
Norbert
Du meinst du internen counter das Attribut count-mode oder?
Das nutzt ich nicht. Ich zähle die statusänderungen mittels notify, einer Funktionen in der 99_myUtils.pm und hourCounter.
arduino_pin_46:reading:.off { stromverbrauchBerechnen("arduino_pin_46","d_stromverbrauchBoiler",2000,80); }
sub stromverbrauchBerechnen($$$$) {
my $readingDevice = shift; #Trigger
my $writingDevice = shift; #Device in dem das state geschrieben wird
my $maxPower = shift; #Maximale Leistung in W. Größere Werte werden ignoriert
my $allowedDeltaPower = shift; #Maximaler Leistungsunterschied in W. Erst nach dem 2. größeren reading wird geschrieben um Peaks zu verhindern.
my $power = 3600 / ( time() - OldValue($readingDevice) );
my $lastPower = ReadingsVal($readingDevice,"power",0);
my $readingLastPower = ReadingsVal($readingDevice,"lastPower",0);
$power = int(100 * $power + 0.5) / 100;
if( $power > ( $lastPower + $allowedDeltaPower ) && $power < $maxPower ){
if( $readingLastPower eq "0" ){
setReading($readingDevice,"lastPower",$power);
}
else{
setReading($writingDevice,"state",$power);
setReading($readingDevice,"lastPower",0);
}
}
elsif( $power > $maxPower || $power < 0 )
{
}
else{
setReading($writingDevice,"state",$power);
if( $readingLastPower > 0 ) {
setReading($readingDevice,"lastPower",0);
}
}
}
Grüße
Zitat von: fhainz am 27 Februar 2014, 18:37:27Du meinst du internen counter das Attribut count-mode oder?
Ja, aber im Prinzip ist es das gleiche Problem, der FRM_IN-interne counter zählt praktisch genauso. Der Firmata-default für einen input-pin ist ohne Pullup, wenn man den Pullup-aktiviert, gibt es mindestens einen Statusübergang von off nach on (oder auch mehrere, weil der Pin ja vor aktivieren des internen Pullups oftmals 'in der leeren Luft' hängt).
Aber gut dass Du darauf hinweist, ich baue das dann mal so, dass das der default-wert von 'reading' bei gesetztem internal-pullup 'on' ist, damit es keinen Statusübergang gibt.
Gruß,
Norbert
Alles klar verstehe das Problem schon!
Danke das du noch einbaust!
Grüße