FHEM Forum

Mit Interesse habe ich kürzlich diesen Thread (http://forum.fhem.de/index.php?topic=10540.0) gelesen. Bei mir kam umgehend die Frage auf, ob dies nicht eine Alternative zu den AVR-Net-IOs sein kann.

Da ich als "Normalo" in dem gesperrten Bereich nur lesen kann, eröffne ich mal hier einen Thread.

Auf der Firmata.org-Seite habe ich dann versucht, Informationen darüber zu erhalten, wie es denn mit dem "Net" steht. Leider habe ich nichts zum Thema Netzwerkanbindung, also Ethernet, gefunden. Alles deutet darauf hin, dass die Kommunikation mit FHEM "nur" über USB erfolgen kann.

Ich hätte diese Frage auch per PN an den Modulersteller klären können, aber evtl. interessiert es ja den ein oder anderen hier auch.

Ergo ;) : Wie steht es mit einer Netzwerkkommunikation zwischen Arduino/Firmata und FHEM? Wenn z.Zt. nicht ... ist da was in der Planung?

Gruß
Thomas

Julian Gautier hat Ethernet-unterstützung für Firmata implementiert.
https://github.com/jgautier/arduino-1/tree/ethernetclient/examples/StandardFirmataEthernet (//github.com/jgautier/arduino-1/tree/ethernetclient/examples/StandardFirmataEthernet)
Damit sollte ohne weitere Änderungen alles gehen, was Firmata 2.3 unterstützt (digital/analog i/o, servos und i2c). Da meine FRM-module auf IODev aufsetzen sollten sie ohne Änderungen auch mit TCP-Verbindungen zusammenarbeiten. Verbindungsabbruch und wiederaufbau ist im Prinzip auch schon drin (aber mangels Ethernet-arduino nur mit USB getestet).

Wenn Du zusätzlich 1-Wire am Arduino brauchst, müsstest Du die Changes aus o.g. Branch mit meinem OneWireFirmata-branch mergen:
https://github.com/ntruchsess/arduino/tree/master/examples/OneWireSchedulerFirmata (//github.com/ntruchsess/arduino/tree/master/examples/OneWireSchedulerFirmata)

Das sollte nicht allzu schwer sein, da die serielle Kommunikation und Ethernet beide mit cpp-Streams verwirklicht sind muss im Prinzip nur die Initialisierung der Firmata ausgetauscht werden, der eigentliche funktionelle code bleibt dabei unverändert. Wenn Interesse besteht (und mir jemand die Hardware zum testen leiht oder sponsort) könnte ich das natürlich auch machen. Selber habe ich derzeit keinen Bedarf sowas über Ethernet anzuschließen, mein FHEM-server steht nah genug zu allem, was ich mit einem über USB angebundenen Arduino messe.

Gruß,

Norbert

Hallo,

ist richtig, genau das interessiert mich auch. Arduino über Ethernet an Fhem. Habe bisher über "Umwege" den Arduino angesprochen, nun wird ein neuer Weg aufgezeigt.

Leider kann auch ich in diesem Forum/Thread nur bedingt schreiben, daher schließe ich mich dem Ersteller einfach mal an. Bitte weitere Info und weitere Entwicklung!!

MfG
Kai

Hallo Kai,

das Arduino mit den Standard-Arduino-Libs als HTTP-Server / -Client zu betreiben würde ich nicht als Umweg bezeichnen. Viel anders macht es nach dem Überfliegen des Codes die "StandardFirmataEthernet" auch nicht. Falls da jetzt kein "Alleinstellungsmerkmal" kommt, kann ich auch mit den bisherigen Möglichkeiten klar kommen. Ich messe an einem Arduino 5 Stck. DS18B20 und an anderen emontx-Shields über FHEM. Das funktioniert zu meiner Zufriedenheit.

Gruß
Thomas

Firmata verfolgt den Ansatz mit einer Standardfirmware die Ein/Ausgabemöglichkeiten des Arduino remote (z.B. auf einem über USB angeschlossenen Rechner) verfügbar zu machen ohne das der Nutzer hierfür Arduino-code schreiben muss. Rechnerseitig ist alles in einer Bibliotek verpackt, die die komplette Kommunikation wegkapselt. Man kann also z.B. als Perl-programmieren einfach einen Arduino mit der (in der Arduino-IDE mitgelieferten) Standardfirmata flashen und unmittelbar damit beginnen aus Perl heraus auf die Pins des Arduinos zuzugreifen.

Das geht natürlich auch uneingeschränkt mit eigenem Arduino-code. Den muss man halt erst mal schreiben. Nicht jeder kann (und will) das.

Die FHEM-anbindung an Firmata richtet sich primär an Nutzer, die sich nicht mit den Bits und Bytes der Implementierung befassen wollen. Also etwas so wie bei einem CUL, wo der Nutzer auch nur die (nicht selbstgeschriebene) Firmware draufflasht und schon kann er das Teil nutzen.

Wenn man den Arduino über Ethernet nutzen will ist das halt im Moment noch nicht so weit, da noch nicht in den Firmata-Standart aufgenommen.

Ich werde mal die EthernetFirmata mit meiner OneWireFirmata mergen, ich muss mir nur zum Testen noch einen EthernetArduino bestellen. Falls Interesse besteht kann das natürlich auch jeder andere testen sobald ich den gemergten code in Github hochgeladen habe.

Gruß,

Norbert

Hmm,

Firmata ist auf jeden Fall interessant. Ich belasse es zur Zeit mal bei meinem eigenen Code, werde mich aber auch mal in Firmata einlesen und testen.

Ist ja dann sehr ausbaufähig, vor allem wenn man sich mal die Funktionen und Möglichkeiten des Arduino ansieht.

Bei mir wird in absehbarer Zeit der Arduino eigene Daten sammeln und verarbeiten, diese werden dann von Fhem zyklisch abgefragt.

Gruß
Kai

Einen ganz wesentlichen Unterschied zwischen Firmata und einer Abfrage über Http habe ich noch gar nicht erwähnt:
Firmata pollt die Pins Arduino-seitig (setzbar über das Attribut 'sampling-interval' in 10_FRM.pm). Änderungen an als Eingang (sowohl digital als auch analog) konfigurierten Pins werden selbsttätig an den Rechner gesendet. Solange FHEM in der main-loop die Devices per select überwacht, kommen diese Änderungen auch unmittelbar in den konfigurierten FRM_IN/FRM_AD Geräten an und können dort Events auslösen.
Bei einer Abfrage der Messwerte über Http muss man FHEM-seitig zyklisches Pollen implementieren (oder mit dem Arduino FHEM per Http oder den FHEM-telnet-zugang updaten). In ersterm Fall skaliert das wegen des Http-overheads lange nicht so gut (Firmata kann mit einem minimalem Sampling-interval von 19ms Werte reporten), im zweiten Fall skaliert es wg. des Push-prinzips zwar schon besser, dafür muss man Arduino-seitig deutlich mehr implementieren.

von FRM_IN und FRM_AD kann man sich jetzt auch ganz bequem per alarm-reading (zusamen mit 'event-on-change-reading') benachrichtigen lassen, wenn vorher gesetzte Grenzwerte über- bzw. unterschritten werden (Link (http://forum.fhem.de/index.php?topic=10540.msg61832#msg61832)). Dadurch, dass diese Alarme per Push vom Arduino ausgelöst werden, kann FHEM darauf ziemlich unmittelbar reagieren (Reaktionszeiten ab ca. 20ms sind möglich, wenn der Rechner den perl-code schnell genug ausführt).

Das gilt nicht nur für die StandartFirmata über USB, sondern auch für die EthernetFirmata. Ist ja das gleiche Protokoll und die TCP-Verbindung bleibt bei der EthernetFirmata einfach offen.

Gruß,

Norbert

Eine FHEM-Modul für Firmata über Ethernet wäre genau das was ich brauche.

Ein Arduino Mega + Wiznet-Shield stehen zum testen bereit. Der Sketch von https://github.com/jgautier/arduino-1.git (//github.com/jgautier/arduino-1.git) ließ sich ohne Probleme auf das Board aufspielen.

Mit FHEM habe ich noch nicht viel Erfahrung, aber für meine 2 Homematic-Thermostate funktioniert die Darstellung der Grafiken. Die Installation ist also Einsatzbereit (Auf einer VM mit Ubuntu).

Viele Grüße

Eddy

Hallo Eddy,

mein FRM modul sollte so wie es ist auch mit der StandardFirmataEthernet (https://github.com/jgautier/arduino-1.git (//github.com/jgautier/arduino-1.git)) zusammenarbeiten. Ich konnte es mangels EthernetShield selber leider noch nicht testen. Du musst nur in der define-Zeite anstelle der usb-schnittstelle die ip-addresse und den Port angeben:

define Firmata FRM 192.168.0.190:3030

(wenn Du eine andere ip-addresse oder Port benutzen willst, musst Du das im Sourcecode der StandardFirmataEthernet ändern, das findet sich ab Zeile 56:
byte mac[] = {0x90,0xA2,0xDA,0x0D,0x07,0x02};
byte ip[] = {192,168,0,190};
int port = 3030;)

Funktionieren sollten: Digital-i/o, analog-i/o, i2c und Servo. OneWire muss ich erst noch reinmergen, mal sehen ob ich die Tage dazukomme (bin die Woche im Skiurlaub, da sitze ich nicht ständig am Rechner, außerdem geht Internet hier grade nur über GSM...)

Viel Erfolg beim Testen!

- Norbert

Ich mußte gerade feststellen das update und auch update fhem sich nicht für deine Dateien interessiert. Weder die readme noch der Ordner Devices ist bei mir angekommen.

Mach ich da etwas falsch oder ist das so normal?

Vielen Dank

PS.: Wenn es nicht Dein dringenster Wunsch war im Urlaub OneWire zu mergen, dann mach erstmal in Ruhe Urlaub. Zumindest bei mir kommt es auf ein oder zwei Wochen nicht drauf an.

Ich habe den lib Ordner jetzt manuell kopiert.

Dann habe ich die folgende Zeile in meine .cfg eingefügt
define FIRMATA FRM 192.168.54.190:3030
Das gab dann folgende Fehler.
2013.02.12 07:23:05 1: reload: Error:Modul 10_FRM deactivated:
 Can't locate Device/Firmata/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_FRM.pm line 6, <> line 20.
BEGIN failed--compilation aborted at ./FHEM/10_FRM.pm line 6, <> line 20.

2013.02.12 07:23:05 0: Can't locate Device/Firmata/Constants.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl . ./FHEM) at ./FHEM/10_FRM.pm line 6, <> line 20.
BEGIN failed--compilation aborted at ./FHEM/10_FRM.pm line 6, <> line 20.


Das konnte ich (vermutlich total unfachmmenschlich) mit nur 1 Zeile am Anfang von 10_FRM.pm "ändern"
use lib ("./FHEM/lib");
Der Fehler kommt jetzt nicht mehr. Dann habe ich mich wieder meiner .cfg gewidmet und da noch attr FIRMATA loglevel 1

define Firmata_OUT_13 FRM_OUT 13
attr Firmata_OUT_13 room Keller
ergänzt.
Jetzt mit größten Erwartungen auf on gekickt - aber - das antwortet leider nur mit:
Firmata_OUT_13, FIRMATA is not connected
im logfile hinterläßt die Aktion leider keine Spuren - egal ob loglevel 1 oder 6.


Achja, ein rereadcfg hinterläßt jetzt sowas im logfile:

2013.02.12 20:53:39 1: Firmata_OUT_13 is against deletion (2), continuing with rereadcfg anyway


Kann ich den Arduino oder FRM irgendwie einzeln testen (vielleicht gegen Putty oder sowas)?

Viele Grüße

Eddy

Erst mal danke fürs testen!
Und sorry - ich hätte das mal zum Testen selber frisch aus dem tar-file + update installieren sollen, mein fhem läuft hier auf dem svn-Verzeichniss. Der Inhalt des lib-ordners kommt beim fhem-seitigen update wirklich nicht mit (wenn die Datei nicht *.pm heißt und direkt in lib liegt). Muss wohl erst in die filelist von contrig/fhemupdate.pl aufgenommen werden. So wie das aussieht berücksichtigt es keine Unterverzeichnisse von 'lib' beim Hochladen der Änderungen im svn.

Den @INC-pfad erweitere ich im 10_FRM jetzt dynamisch (Deine 'use lib ./FHEM/lib'-direktive funktioniert nur, wenn der modpath nicht irgendwoanders hin gesetzt ist).

zum Testen kannst Du das globale Attribute 'verbose' mal auf 5 setzen, damit Du die Ausgabe von IODev.pm mitkriegst. (Wobei ich vermute, dass es den Arduino auf dem Netzwerk einfach nicht erreicht).
Das kannst Du von dem Rechner auf dem das fhem gestartet wird z.B. mit Telnet testen:

telnet 192.168.54.190 3030

man kann das Firmata-protokoll so zwar nicht bedienen (das ist ein binäres protokoll), aber wenn telnet auf dem port Verbindet, dann hat der EthernetClient auf dem Arduino auf die Verbindungsanfrage reagiert.

Falls telnet nicht verbindet: ist 192.168.54.190 überhaupt im gleichen Subnetz wie der fhem-server? Falls nicht, musst Du die ip-addresse im StandardFirmataEthernet.ino eben ändern. Benutzt Du einen Ethernet-Arduino oder ein originales Ethernet-shield? Die Ethernet-library unterstützt nämlich keine anderen Ethernet-chips.

Gruß,

Norbert

Hi,

ich habe jetzt Deine aktuelle Version drauf.

attr global verbose 5 habe ich probiert. Homematic wird davon so gesprächg, das man mit dem Log kaum noch was anfangen kann. Von FRM finde ich relativ wenig:

CMD: >define FRM FRM 192.168.54.109:3030<
Loading ./FHEM/10_FRM.pm
Opening FRM device 192.168.54.109:3030
Can't connect to 192.168.54.109:3030: No route to host

später dann noch

CMD: >define FRM_OUT_13 FRM_OUT 13<
Loading ./FHEM/20_FRM_OUT.pm
CMD: >attr FRM_OUT_13 loglevel 5<
CMD: >attr FRM_OUT_13 room Keller<


Auf telnet reagiert der Arduino nicht. Auch nicht wenn ich die IP verwende, die ich in der Fritz-Box zu der beim Arduino eingetragenen MAC finde. Mein Netzwerk hat übrigens wirklich die 192.168.54.
Zur Hardware: Ich habe einen Arduino Mega 2560 + Ethernet-Shield mit Wiznet W5100 Controller (allerdings beides direkt aus China). Bis vor ein paar Tagen habe ich darauf an einem NTP-Sketch gebastelt der die gleiche Ethernetlib verwendet. Von daher sollte das also funktionieren.

Dann habe ich mir mal den Code angeschaut. Bei Perl konnte ich leider nur mit den Schultern zucken, den Kopf kratzen und feststellen das das Interessant aussieht. Den Arduino-Code kann ich recht gut verstehen.

Im Grunde macht der Sketch ja folgendes:
1. Firmata-Callbacks an eigene Funktionen zuweisen
2. Das Netzwerk mit einer IP-Adresse vom DHCP initialisieren
3. Eine TCP-Verbindung zu IP:Port aufbauen
4. Den daraus resultierenden Stream an Firmata übergeben
5. Solange die Verbindung steht, "Firmata machen (Ports auslesen, setzen etc)"
   Sonst ab 2. neu beginnen.
Jetzt wissen wir schon mal warum telnet nicht funktionieren konnte und warum das Arduino nicht die erwartete IP hat.
FHEM ist der Server, zu dem Arduino als Client eine Verbindung aufbaut.

Beim FRM soll ich aber auch eine IP (die des Arduino) angeben. Das widerum sieht so aus als wäre FRM der Client der sich zu einem wartenden Aduino verbindet.
Was passiert wenn die Verbindung mal unterbrochen wird (oder beim Start von FHEM noch nicht da ist)?

Kannst Du bitte mal beschreiben wer von der Archtektur her Server und wer Client sein soll?

Ich installier mir in der Zwischenzeit extra für FRM einen FHEM-Test-Server. Wenn das Homematiczeug ständig dazwischenplapert sind mir die Log's sonst zu groß.

Eddy

ja, da hast Du natürlich recht, der StandardEthernetFirmata-sketch ist tatsächlich als Client implementiert. FRM aber leider auch (das liegt daran, das ich zu USB über die DevIO.pm-library verbinde und die die EthernetClient-funktionalität quasi 'umsonst' mitbringt).
Ich muss mir mal ansehen, wie schwer es ist in fhem für ein Device einen Serverport zu öffnen, das würde mir architektonisch fast besser gefallen. Wobei der Arduino dann noch sowas wie eine eindeutige ID mitbringen müsste, oder wenigstens eine feste IP-addresse bräuchte, sonst gäbe es Probleme, wenn man mehrere Arduinos mit EthernetFirmata im Netz hätte. Falls das FHEM-seitig zu kompliziert wird, schreibe ich den Sketch eben auf Server um, das ist im Prinzip ja nicht so schwer.

Wegen des Logings: Wenn DevIO keine Verbindung zum genannten Device aufbauen kann ('no route to host' in Deinem Log), dann gibt's ab da auch nicht mehr viel sinnvolles zu loggen. Falls die Verbindung zwischendrin abbricht, dann ist das (zumindestens beim über USB angeschlossenen Arduino) so implementiert, dass es sich bei Wiederverfügbarkeit des Arduinos wieder verbindet. Für Ethernet muss ich das aber noch mal genau unter die Lupe nehmen, da weiß ich nicht sicher, wie es sich verhält.
Die Änderungen mit denen man den Loglevel FRM-seitig hochstellen kann habe ich schon hier auf der Platte - muss ich aber noch ein bischen durchtesten bevor ich das ins SVN hochlade.

Gruß,

Norbert

Ich habe gerade noch Deine Antwort gelesen.

Den Server auf FHEM-Seite zu setzen würde mir auch besser gefallen. Das mit der ID gefällt mir nicht wirklich. Was spricht gegen mehrere "Server", also unterschiedliche Ports je Arduino?

Wenn Arduino der Server wird, wäre die Frage wie FRM auf Verbindungsabbrüche reagier[t,en könnte] wichtig. Es ist ja auch nicht unbedingt sicher, das Arduino vor FHEM verfügbar ist.

Gruß

Eddy

Hi Eddy,

ich habe grade mal auf die Schnelle den Arduino zum 'Server' gemacht:
https://github.com/ntruchsess/arduino/tree/ethernetserver/examples/StandardFirmataEthernetServer (//github.com/ntruchsess/arduino/tree/ethernetserver/examples/StandardFirmataEthernetServer)

(mangels Hardware nicht getestet, nach der Doku sollte es aber so gehen und compilieren tut's auch...)

Wenn fhem den Server spielt, dann kann man nicht generell ausschließen, dass mal mehrere Arduinos auf dem gleichen Port verbinden (und sei es nur, weil der Anwender die Doku nicht gelesen hat). Das muss FRM dann zuverlässig erkennen können um die reale Welt nicht durcheinanderzubringen. Es könnte ja auch ein Arduino verbunden sein und die Verbindung verlieren, wärend ein zweiter parallel auf die Übernahme 'lauert' oder just in dem Moment aktiv wird.
Ansonsten spricht natürlich nichts gegen einen Port pro Arduino und FRM-Device.

Wenn FRM der Client ist, dann können natürlich auch potentiell mehrere Arduinos mit der gleichen IP-addresse im Netz sein (wenn der Anwender den Sketch einfach unverändert auf mehrere flashed). Das wäre dann fast das gleiche Problem und in FRM selbst praktisch gar nicht zu erkennen. Irgendwie habe ich da noch kein Konzept, wie man damit umgehen sollte. Eventuell bräuchte die Firmata dafür noch eine Erweiterung, mit der beim ersten Verbinden eine eindeutige ID ins EEPROM geschrieben wird oder so was in der Art. Die Mac-addresse mus ja auch auf jedem Gerät eine andere sein...

Naja - wäre lieb, wenn Du erst mal meinen o.g. Sketch testen könntest. Wenn das funktioniert, dann sind wir sowieso schon mal einen großen Schritt weiter ;-)

Gruß,

Norbert

Gruß,

So, vor der Arbeit schnell noch getestet. Es redet miteinander aber der FHEM startet nicht mehr.
Im Log steht folgendes:

2013.02.15 07:22:16 5: Cmd: >define FRM_Device FRM 192.168.54.190:3030<
2013.02.15 07:22:16 5: Loading ./FHEM/10_FRM.pm
2013.02.15 07:22:16 3: Opening FRM_Device device 192.168.54.190:3030
2013.02.15 07:22:16 3: FRM_Device device opened
2013.02.15 07:22:16 5: >ff
2013.02.15 07:22:16 5: SW: ÿ
2013.02.15 07:22:16 5: >f0,79,f7
2013.02.15 07:22:16 5: SW: ðy÷
2013.02.15 07:22:26 5: >ff
2013.02.15 07:22:26 5: SW: ÿ
2013.02.15 07:22:26 5: >f0,79,f7
2013.02.15 07:22:26 5: SW: ðy÷
2013.02.15 07:22:36 5: >ff
2013.02.15 07:22:36 5: SW: ÿ
2013.02.15 07:22:36 5: >f0,79,f7
2013.02.15 07:22:36 5: SW: ðy÷
2013.02.15 07:22:46 5: >ff
2013.02.15 07:22:46 5: SW: ÿ
2013.02.15 07:22:46 5: >f0,79,f7
2013.02.15 07:22:46 5: SW: ðy÷
2013.02.15 07:22:56 5: >ff
2013.02.15 07:22:56 5: SW: ÿ
2013.02.15 07:22:56 5: >f0,79,f7
2013.02.15 07:22:56 5: SW: ðy÷
2013.02.15 07:23:06 5: >ff
2013.02.15 07:23:06 5: SW: ÿ
2013.02.15 07:23:06 5: >f0,79,f7


Aber jetzt muß ich los.
Bis heute Abend.

Hi all,

wär das nicht die Lösung, 2 Telnet Clients miteinander zu verbinden? (zumindest zum Testen).

http://forum.fhem.de/index.php?t=msg&goto=56972&rid=115&srch=telnet+client#msg_56972 (//forum.fhem.de/index.php?t=msg&goto=56972&rid=115&srch=telnet+client#msg_56972)

l.g. erwin

Hallo Eddy,

im Log sieht man das FRM erfolgreich zum Socket des Arduino connected hat und versucht diesen zu initialisieren. (die Logzeilen, die mit '>' anfangen sind ausgehende Firmata-messages). Antwort vom Arduino bleibt leider aus (das wären sonst Zeilen mit '<' am Anfang.

Keine Ahnung warum der Sketch nicht antwortet, im Prinzip ist das so wie z.B. im Webserver-example implementiert (der prinzipielle Unterschied ist, dass der Firmata-sketch die EthernetClient-Verbindung über die loop()-methode hinaus offen hält, solange EthernetClient.connected() true zurückgibt. Das Webserver-example schließt die Verbindung nach jedem Request wieder.

Du könntest den Arduino ja mal parallel per USB verbinden und im Sketch ein paar debug-ausgaben über das Serial-device schicken um zu sehen, ob der EthernetServer eine Client-verbindung zurückgibt und ob es überhaupt über die 'if (client)'-Zeile in den eigentlichen Firmata-code reinkommt.

Das FRM bei ausbleibender Antwort FHEM komplett blockiert, habe ich grade gefixed.

Gruß,

Norbert

Hallo Erwin,

was kann ich denn mit 2 verbundenen Telnetclients in dem Zusammenhang anfangen?

Gruß,

Norbert

Hallo,

Mein Ziel ist einen S0 Reader zum Zählen des Gaszählers zu bauen und die Daten dann in fhem einzulesen.
Das Zählen mit dem Arduino funktioniert schon und die Daten sind über eine simple Webseite auslesbar.

Auf der Suche nach einer Schnittstelle zur Anbindung an fhem habe ich Deine Firmatalösung gesehen, die vielversprechend klingt.

Ich habe gerade versucht deinen Sketch "StandardFirmataEthernetServer.ino" zu kompilieren. Leider bricht der Job ab:

'class FirmataClass' has no member named write.

Ich habe die nochmal die aktuelle Arduinoversion 1.0.3 aufgespielt. Das Beispiel StandardFirmata lässt sich kompilieren. Werden weitere Libraries gebraucht?

Ich stehe gerne für weitere Tests zur Verfügung.

Viele Grüße,

Dirk

Hallo Dirk,

zum compilieren musst Du den ganzen Branch (inklusive Firmata.h/Firmata.cpp und Boards.h) herunterladen und damit den Firmata-ordner im Arduino-libraries Verzeichniss ersetzen. Sonst nimmt die Arduino-IDE immer die installierte Firmata-bibliotek und da fehlt die Firmata.write()-methode halt noch.

Gruß,

Norbert

re: was kann ich denn mit 2 verbundenen Telnetclients in dem Zusammenhang anfangen?

Norbert,

ein paar Einträge weiter oben wurde von der Client- Implementation von Firmata-Ethernet gesprochen und dass auch FRM den Client mode implementiert hat.
Wenn ich TCP-Tee richtig verstehe, ist das ein proxy server, der 2 clients transparent miteinander verbindet, nicht beschränkt auf telnet-protokoll, sondern im raw-mode.

l.g. erwin

Danke Norbert,

ich musste fhem auch auf den Development-Stand heben.

Jetzt läuft die Kommunikation.

Viele Grüße,

Dirk

Hallo Erwin,

re: Wenn ich TCP-Tee richtig verstehe, ist das ein proxy server, der 2 clients transparent miteinander verbindet,

stimmt, das könnte funktionieren. (Wenn man den code nicht ändern will oder kann)
Als Entwickler beider Clients schreibe ich meinen code aber lieber so um, dass es ohne 'Hilfsmittel' einfach so läuft.

Gruß,

Norbert

Hallo Dirk,

freut mich, dass es bei Dir so schnell läuft :-)
Hast Du am StandardFirmataEthernetServer-sketch (abgesehen von der ip-addresse) irgendwas ändern müssen um es zum Laufen zu bekommen? Eddy könnte da sicher auch noch einen Tip brauchen...

Die OneWire-funktionalität (um FRM als OneWire-busmaster für OWX zu benutzen) habe ich übrigens grade mit dem EthernetServer-code gemerged:

https://github.com/ntruchsess/arduino/tree/onewire_scheduler_ethernetserver/examples/OneWireSchedulerEthernetServer (//github.com/ntruchsess/arduino/tree/onewire_scheduler_ethernetserver/examples/OneWireSchedulerEthernetServer)

Gruß,

Norbert

Hallo Eddy,

ich glaube ich habe jetzt verstanden, warum meine EthernetServer-firmata bei Dir nicht antwortet. Wenn die systemReset-methode der Firmata aufgerufen wird, dann werden alle Pins auf Ihre Default-konfiguration zurückgesetzt, inklusive der SPI-pins zum W5100-Ethernet-chip. Beim Verbindungsaufbau von FRM wird halt auch systemReset aufgerufen um den angeschlossenen Arduino in einen definierten Zustand zu bringen. Und schon ist die IP-Verbindung Arduino-seitig abgerissen ohne das es FRM gleich mitkriegen würde...

Ich mach mich gleich mal dran das firmataseitig zu fixen.

Gruß,

Norbert

Hallo,

heute wollte ich Firmata mit Ethernet einmal testen. Hab den "OneWireSchedulerEthernetServer" komplett als Paket runtergeladen, im Verzeichnis "libraries/Firmata" alles damit ersetzt.

Erstes Problem: Die Beispiele werden nicht angezeigt, es bleibt bei den alten FIRMATA-Beispielen. Neustart hat nicht genutzt (Arduino-Umgebung 1.5.2)

Wenn ich das in ein eigenes Verzeichnis setze und kompiliere, dann ist das 2. Problem:
OneWire\OneWire.cpp.o: In function `OneWire::depower()':
D:\Program Files\Arduino\libraries\OneWire/OneWire.cpp:269: multiple definition of `OneWire::depower()'
OneWire.cpp.o:C:\Users\kazo\AppData\Local\Temp\build9057078034995441674.tmp/OneWire.cpp:274: first defined here
d:/program files/arduino/hardware/tools/avr/bin/../lib/gcc/avr/4.3.2/../../../../avr/bin/ld.exe: Disabling relaxation: it will not work with multiple definitions
....
Der Compiler läuft nur durch, wenn ich das #include <OneWire.h> auskommentiere.

Kann das include auskommentiert bleiben?

Gruß
Kai

Hallo Kai,

wenn es ohne das <OneWire.h> compiliert, dann lass es raus - das ist nur drin, weil die Arduino-IDE 1.0.3 bei mir Probleme machte die OneWireFirmata.cpp zu compilieren, wenn es toplevel nicht includiert war. Zwischenzeitlich habe ich die OneWire-lib eh in den Sketch mit aufgenommen (ich habe eine Methode zum Suchen nach Devices im Alarmed-state hinzugefügt).

War die OneWire-library im Arduino-1.5.2 denn schon von Haus aus mit drin?

Edit: hab das <OneWire.h> include bei mir auch rausgeworfen - seit OneWire Bestandteil des Sketches ist compiliert es auch bei mir ohne.

Vom OneWire_Scheduler_EthernetServer-sketch habe ich grade ein Update committed, das dafür sorgt, das die SPI-pins (über die die Ethernet-kommunikation geht) von Firmata ignoriert werden. Das sollte das Problem des Verbindungsabbruchs beim systemReset beheben. Außerdem kann man nicht mehr versehendlich einen SPI-pin für etwas anderes konfigurieren.

Gruß,

Norbert

Hallo Norbert,

danke für die Info. Werde das ganze jetzt mal in der aktuellen, gerade von Dir geänderten Version testen.
Bin gespannt, ob das ganze besser "integriert" in Fhem ist als meine "simple" Version über http. Meine aktuelle Version hat noch den Vorteil, das ich zur Zeit die DHT11-Sensoren abfragen und übertragen kann.

Gruß
Kai

wenn ich das richtig sehe, dann ist der DHT11 gar kein 'echter' OneWire-sensor (im Sinne von Dallas), der wird über FRM im Augenblick gar nicht direkt auslesbar sein :-(

Da müstest Du Dir einen eigenen Firmata-basierten sketch implementieren (der die existierende DHT11-library nutzt) und dazu ein passendes FRM-Client modul schreiben. Direkt über FRM mit dem Arduino-pin kommunizieren und das DHT11-eigene Protokoll 'remote' abzuwickeln wird vom Timing her wohl nicht zuverlässig gehen.

Echte (im Sinne von Dallas) OneWire-devices sind kein Problem. DS18B20 Sensoren z.B. kannst Du über den Weg FRM->OWX->OWTHERM unmittelbar auswerten und mitloggen.

Für Luftfeuchte gibt's auch I2C-Sensoren (z.B. diesen hier: http://shop.emsystech.de/de/SHT21-Breakout-Board (//shop.emsystech.de/de/SHT21-Breakout-Board)). So was wäre über FRM auch ziemlich leicht nutzbar. Das FRM_I2C-modul ist zwar noch recht rudimentär, es ließt bisher nur die Rohdaten angeschlossener I2C-devices - code, der das lesbar aufbereitet wäre allerdings vergleichsweise einfach zu integrieren. Ich hab da selber bisher halt noch keinen eigenen Anwendungsfall gehabt.

Gruß,

Norbert

Ja, stimmt, der DHT11 ist kein 1-wire. Ist nur schade, weil auch der kann sehr einfach vom Arduino abgefragt werden.

Übrigens, wenn ich define frm FRM 192.168.3.89:3030 eingebe kommt ein Fehler. Woran kanns liegen? Die libs sind in /FHEM/libs komplett kopiert.

Das log sagt:
2013.02.18 19:54:36 1: reload: Error:Modul 10_FRM deactivated:
 Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {
   
   "

2013.02.18 19:54:36 0: Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {


Gruß
Kai

na mal schauen, vieleicht hole ich mir ja mal einen DHT11 und schreibe einen FirmataSketch dafür, der dann auch mit FRM redet. Die Beispiele das Teil auf dem Arduino auszulesen sind ja ziemlich simpel, das sollte kein Problem sein.

Zurück zur EthernetFirmata:

Schaut ja im Prinzip schon mal gut aus, damit der Fehler in FRM Zeil 231 überhaupt auftreten kann, muss der Arduino wohl geantwortet haben. Nur ist in der Struktur in der die geparste Antwort landet nicht das drin, was der code erwartet.
Kannst Du mal mit 'attr global verbose 5' den Loglevel beim Start hochdrehen, dann schreibt FRM jedes Byte, das über die Leitung geht ins log.
Der 'syntax-fehler near 343' macht aber irgendwie gar keinen Sinn, der wäre überhaupt nicht von den Antworten des Arduinos abhängig. Auf welcher Perl-version läuft das?

Gruß,

Norbert

P.S. hab mir grade ein EthernetShield bestellt, d.h. in ein paar Tagen wird die Sache laufen ;-)

Ja, ich denke auch, den DHT11 zu integrieren sollte nicht ganz so schwierig sein, ebenso wie einige weitere Sensoren. Nachteil des DHT 11 ist die etwas schlechtere Auflösung der Sensoren.


Bei mir auf der NAS läuft Perl 5.10, leider gibt es von Qnap/ipkg-Verwaltung keine neuere Version.

Das Log sagt bei Verbose 5 nicht viel anderes:
2013.02.19 20:49:41 4: HTTP FHEMWEB:192.168.3.117:54948 GET /fhem?room=Unsorted&cmd=define+frm+FRM+192.168.3.89%3A3030
2013.02.19 20:49:41 5: Cmd: >define frm FRM 192.168.3.89:3030<
2013.02.19 20:49:41 5: Loading ./FHEM/10_FRM.pm
2013.02.19 20:49:42 1: reload: Error:Modul 10_FRM deactivated:
 Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {

"

2013.02.19 20:49:42 0: Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {

"

2013.02.19 20:49:42 4: /fhem?room=Unsorted&cmd=define+frm+FRM+192.168.3.89%3A3030 / RL: 861 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /



Das gleiche kommt auch bei "define frm FRM none"
/
2013.02.19 20:55:12 4: HTTP FHEMWEB:192.168.3.117:55016 GET /fhem?room=Unsorted&cmd=define+frm+FRM+none
2013.02.19 20:55:12 5: Cmd: >define frm FRM none<
2013.02.19 20:55:12 5: Loading ./FHEM/10_FRM.pm
2013.02.19 20:55:12 1: reload: Error:Modul 10_FRM deactivated:
 Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {

"

2013.02.19 20:55:12 0: Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 231, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 236, near "})"
Type of arg 1 to keys must be hash (not hash element) at ./FHEM/10_FRM.pm line 241, near "})"
syntax error at ./FHEM/10_FRM.pm line 343, near "package Firmata_IO {

"

2013.02.19 20:55:12 4: /fhem?room=Unsorted&cmd=define+frm+FRM+none / RL: 861 / text/html; charset=UTF-8 / Content-Encoding: gzip
 /

Was nun?

Gruß
Kai

ok, das liegt wohl wirklich am Perl 5.10 - da werden Ausdrücke wie
keys $device->{metadata}{analog_resolutions}  nicht automatisch dereferenziert. Ich muss mich mal schlau machen, welche Syntax da schon funktioniert. Perl 5.10 ist halt schon ein bischen in die Jahre gekommen.

Gruß,

Norbert

Hallo Kai,

ich habe die Zeilen, die bei Dir Fehler machen mal für Perl 5.10 syntaktisch 'entschärft'. Hoffe das es jetzt auch bei Dir läuft. Das nicht mehr log-ausgaben gekommen sind ist klar - der code, der eigentlich mit dem Arduino kommunizieren soll hat bei Dir ja gar nicht compiliert...

Gruß,

Norbert

Hallo Norbert,

habe das ganze dann heute endlich mal testen können. Der Fehler kommt nicht mehr, FHEM läuft durch und es wird auch alles richtig angezeigt.
Allerdings lässt sich ein 1-Wire-Sensor nicht auslesen.

Habe nach
define frm frm 192.168.3.89:3030
define OWio OWX 2

nichts weiteres erkennen können.

Dann mit
get OWio devices
kommt die Meldung: OWX: 1-Wire devices found on bus OWio
Es werden aber keine Devices angezeigt.

Das ist doch sicherlich nicht alles?
 OWX zeigt folgendes an:
ALARMDEVS
ALARMED no
CFGFN
DEF 2
INTERFACE firmata
IODev frm
NAME OWio
NR 151
PIN 2
PRESENT 1
ROM_ID FF
STATE Active
TYPE OWX
followAlarms off
interval 300

Interessant ist hier das ROM_ID mit FF
Fhem müsste bei mir in dieser Konfig mind. 2 DS1820 erkennen.

Gruß
Kai

Hallo Norbert,

muß mich noch bedanken für Deine Anpassung!

Zur Fehlereingrenzung hier noch ein Log-Auszug:
2013.02.24 09:47:49 4: HTTP FHEMWEB:192.168.3.117:56683 GET /fhem?cmd=get+OWio+devices
2013.02.24 09:47:49 5: Cmd: >get OWio devices<
2013.02.24 09:47:49 5: >f0,73,40,02,f7
2013.02.24 09:47:49 5: SW: �s@�
2013.02.24 09:47:52 1: OWX: 1-Wire devices found on bus OWio ()
2013.02.24 09:47:52 4: /fhem?cmd=get+OWio+devices / RL: 855 / text/html; charset=UTF-8 / Content-Encoding: gzip
 


Hallo Kai,

danke für das Feedback. Ich habe gestern mein Ethernetshield bekommen, verhält sich bei mir genauso - Verbindet, schickt alle Metadaten und reagiert dann nicht mehr. Ich hatte aber gestern nicht viel Zeit das genauer zu untersuchen. Was mir spontan aufgefallen ist, war dass die SPI-pins (10-13) für die Ethernetschnittstelle weiterhin als für I/O verfügbar aufgeführt wurden (Wenn man die Details des FRM-devices anschaut). Das sollte eigentlich nicht so sein - so kann sich die Firmata quasi hintenrum selbst die Ethernetschnittstelle abschießen. Naja - jetzt wo ich die passende Hardware dahabe, kann ich das endlich auch mal genauer unter die Lupe nehmen.

Einen DHT11 habe ich mir übrigens auch bestellt um die Library mal in Firmata einzubinden.

Gruß,

Norbert

Hallo Norbert,

Du hast recht, Firmata könnte über die Pins 10-13 die Ethernetschnittstelle beeinflussen, ebenso den Zugriff auf die SD-Karte.
Den DHT-11 einbinden sollte vom Grundsatz her nicht so schwierig sein, ebenso die Einbindung weiterer Sensoren (wenn man Firmata und das Protokoll erst einmal verstanden hat)

Schön dass du jetzt auch die Hardware besitzt, der Arduino bietet doch einiges an Funktionen und Möglichkeiten.

Gruß
Kai

Hallo Kai,

bin mit dem Shield jetzt ein bischen weiter gekommen. Man muss Pin 4 (SS für den SD-Kartenleser) vom Firmata-handling ausschließen und als Output mit Pegel high konfigurieren.
Soweit, sogut - jetzt verbindet sich FRM mit dem Arduino, bekommt die Metadaten rübergeschickt, der Scan nach OWX-Devices klappt auch, und mal einen Outputpin anschalten. Aber irgendwann antwortet das Teil ohne einen bestimmten Grund einfach nicht mehr. Wenn ich mit netstat -a nachschaue bleibt die Verbindung aber immer noch auf 'CONNECTED' stehen, auch wenn sich der Arduino tot stellt). Im loop frage ich das aktuelle EthernetClient-object per 'connected()' ab, ob die Verbindung noch steht, falls nicht, wird auf die nächste Verbindungsaufnahme gewartet. Die kommt natürlich nicht (der PC meint ja noch verbunden zu sein :-(
Bin grade ein bischen ratlos (ist ja auch schon Mitternacht durch und ich hatte letzte Nacht nur 4 Std. Schlaf).

Muss mal nach (etwas umfangreicheren) Beispielen suchen wie man das mit dem Arduino EthernetServer am besten macht, wenn man die Verbindung offen halten will. Aber vieleicht ist es doch sinnvoller bzw. stabiler den Arduino als Client und FRM mit einem Serverport laufen zu lassen.

Gruß,

Norbert

so, dann mal ein kurzes Update:
hab das mit der EthernetServer Firmata heute mal grundsätzlich ans Laufen gebracht, Digital und Analog-I/O und OneWire haben soweit schon mal funktioniert, allerdings war die Verbindung nicht 100% stabil - die Arduino-Ethernetlibrary hat regelmäßig (arduinoseitig) dis- und reconnected, wärend das FRM-modul davon offenbar nicht viel mitbekommen hat - jedenfalls blieb die IP-verbindung dabei offen.
Das Problem, die Firmata von den SPI-pins wegzuhalten ist jedenfalls gelöst, das ist schon mal ein guter Anfang. Den Firmata-code gibts, wenn er stabil läuft, bin jedenfalls auf dem richtigen Weg dahin.
Ach ja, die Firmata habe ich dazu erst mal ziemlich komplett refactored, es ist jetzt viel einfacher neue Features einzubauen: https://github.com/ntruchsess/arduino/blob/configurable_onewire_scheduler/examples/ConfigurableFirmata/ConfigurableFirmata.ino (//github.com/ntruchsess/arduino/blob/configurable_onewire_scheduler/examples/ConfigurableFirmata/ConfigurableFirmata.ino) Man muss eigentlich nur einen recht dünnen Wrapper um die entsprechende Sensor-library stricken und ein paar vorgegebene Methoden zur Anbindung an die Firmata implementieren. (Hier z.B. der Handler für Analogen Input: https://github.com/ntruchsess/arduino/blob/configurable_onewire_scheduler/utility/AnalogInputFirmata.cpp (//github.com/ntruchsess/arduino/blob/configurable_onewire_scheduler/utility/AnalogInputFirmata.cpp)). Einen DHT11 einzubinden ist damit nur noch eine Sache von wenigen neuen Zeilen code. Leider ist der DHT11 noch nicht da. Sollte zwar angeblich aus dem deutschen Versandlager kommen aber vieleicht liegt das ja doch in Hongkong...

Gruß,

Norbert

so jetzt gibt's endlich mal eine Erfolgsmeldung zum Thema:

FRM kann jetzt im servermode auf Serversocket lauschen und darauf warten, dass sich ein Arduino mit Ethernetfirmata verbindet. Dazu wird in der define-zeile einfach der port (gefolgt von einem 'global') angegeben. Global bedeutet, dass auf allen ip-addressen des FHEM-servers gelauscht wird. (Ohne global lauscht es nur an localhost, das ist in diesem Fall natürlich nicht sinnvoll, da der Arduino ja remote verbindet).

define FIRMATA FRM 3030 global

Der Arduino muss eine EthernetClientFirmata geladen haben. Die gibt's hier auf Github (//github.com/ntruchsess/arduino/archive/configurable_ethernet.zip). Mit dem darin enthaltenen Verzeichnis 'Firmata' bitte die mit der Arduino-IDE mitgelieferte Firmata-library ersetzen. (Siehe auch das beiliegende Readme-file). Anschließend findet man den Sketch unter 'Datei'->'Beispiele'->'Firmata'->'ConfigurableEthernetclient'. Im Sketch muss man die ip-addresse anpassen (hier muss die des FHEM-servers eingetragen werden). Als Port trägt man das ein, was man auch für FRM konfiguriert (bei mir Port 3030). Der Sketch ist 'konfigurierbar' - d.h. man kann die Firmata-features, die man nicht braucht einfach rauskonfigurieren, indem man die entsprechenden defines am Anfang des Sketches entfernt. (Der Rest ist im Sketch mit ifdefs geregelt).

Es spielt keine Rolle, ob zuerst FHEM oder der Arduino gestartet wird. Letzterer versucht solange zur konfigurierten IP-addresse/port zu verbinden, bis es klappt. Leider funktioniert ein Neuaufbau der Verbindung bisher nur, wenn man den Arduino resettet - die Ethernet-Library kriegt einen Verbindungsabbruch durch FHEM offenbar nicht mit. (Dazu gibts auch einen Bug-report und wohl auch einen Fix, ddas muss ich mir aber erst mal näher ansehen). Dafür kommt FRM gut damit klar, dass der Arduino mal weg ist und später wiederkommt.

Es funktioniert bisher Digital- und Analoges I/O, am OneWire-support bin ich dran.

- Gruß,

Norbert

Hallo wiedermal,

ich bin begeistert was Du so auf die Beine stellst. Die aktuelle Version mußte ich jetzt auch gleich mal testen (erstmal nur digital Out mit drei LEDs).

Bei mir funktioniert das schon recht gut. Nach einem Reset des Arduino findet sich das ganze innerhalb weniger Sekunden wieder. Nach einem Verbindungsabbruch auf Seiten FHEM dauert es etwa 2-3 Minuten, danach konnte ich wieder schalten.
In beide Richtungen kommt die Syncronisation aus dem Tritt. Nach einem Reset bleibt auf der jeweiligen Kompnente alles aus, auf der Gegenseite bleibt der letzten Status bestehen. FHEM merkt also nicht wenn sich der Arduino resettet hat und der Arduino interessiert sich auch nicht dafür welche Ports vorher an oder aus waren.

Du bist also auf jeden Fall einen Großen Schritt weiter.

So jetzt versuche ich mal zu verstehen wie Du das auf der Arduino-Seite machst. An dem was Du da ablieferst merke ich das ich offenbar noch "garkene Aanung hab wie mer sowas machn dud"

Hallo Kai, hallo Eddy,

ich grade mal eine FirmataFeature-klasse für den DHT11-sensor geschrieben:
https://github.com/ntruchsess/arduino/tree/configurable_customfeature/examples/DHT11Firmata (//github.com/ntruchsess/arduino/tree/configurable_customfeature/examples/DHT11Firmata)

ist erfrischend einfach, jetzt, da die Grundlagen erst mal gelegt sind ;-)

ein Beispiels perl-client ist auch schon da:
https://github.com/ntruchsess/perl-firmata/blob/master/examples/example_DHT11.pl (//github.com/ntruchsess/perl-firmata/blob/master/examples/example_DHT11.pl)

d.h. das passende FHEM-modul ist damit nicht mehr weit...

Gruß,

Norbert

Hallo Eddy,

danke für das Feedback :-)

Das sich der Arduino und FHEM nach einem Reconnect nicht selbstständig synchronisieren ist bekannt, da habe ich auch noch nichts implementiert. Bin ja erst mal schon froh, dass der Reconnect mittlerweile so reibungslos funktioniert.

Gruß,

Norbert

Hallo Norbert,

ist ja super. Werde das in den nächsten Tagen mal testen und Rückmeldung geben, leider ist meine freie Zeit augenblicklich sehr knapp.
Vielen Dank vorab schon mal, toll, daß Du Dich diesem Thema annimmst.

Gruß
Kai

ich habe jetzt eingebaut, dass die Module FRM_OUT, FRM_PWM und FRM_LCD den letzten bekannten Zustand nach einem Reconnect des Arduinos oder einem Restart von FHEM wiederherstellen. Kann man mit den Attributen 'restoreOnStartup' bzw. 'restoreOnReconnect' an oder abschalten (Default is an).
Das ist keine 'echte' Synchronisation, Der Arduino resettet erst mal alle Pins auf Output, LOW. Nach einem Reconnect bekommt er halt die letzbekannten Statuswerte wieder übertragen, vorher (d.h. auch wenn die Netzverbindung z.B. länger unterbrochen ist) bleiben die Pins auf LOW. (Dieses Verhalten des Arduinos kann man natürlich nur in der Firmware ändern). Eingabepins, an denen HIGH anliegt übertragen diesen Wert beim Reconnect auch sofort an FRM.

OneWire funktioniert im Prinzip auch über Ethernet, allerdings nur, wenn FRM vor dem Start des OWX-moduls schon zum Arduino verbunden hat. Das ist eine Limitierung des OWX, Peter (pah) ist da im Moment am refactoren, ich hoffe, dass wir den Reconnect in diesem Zuge auch hinkriegen. Zum Testen muss man ggf das OWX-device erst definieren, wenn FRM schon auf aktiv steht.

(Wenn der Arduino über USB angebunden ist und beim Start von fhem nicht angesteckt ist, gibts das Problem auch).

Viel Spaß damit,

Norbert

hallo norbert,

kannst du abschätzen wie aufwändig es ist eines der ultraschall module per arduino und firmata an fhem anzubinden?

ich würde gerne versuchen das als tank sensor zu verwenden.

gruss
  andre

nun, man muss halt den code von hier (//arduino.cc/en/Tutorial/Ping?from=Tutorial.UltrasoundSensor) in eine FirmataFeature-klasse wrappen (analog zu meinem DHT11Firmata (//github.com/ntruchsess/arduino/tree/configurable_customfeature/examples/DHT11Firmata)-Beispiel). Wenn ich dazu komme möchte ich ein generisches fhem-modul zum Empfang von solchen Sensordaten schreiben (man kann die Sysex-messages so einer CustomFeatureFirmata-klasse in der perl-firmata mit observe_sysex abonieren und selber parsen, die eingentliche Aufgabe ist, dass man nur einen sysex-observer per FirmataDevice abonieren kann, diese callback-function also im FRM-modul selbst liegen muss und die Messages dann an die eigentlichen - z.B. einem Pin zugeordneten Devices - verteilen muss). Das ist aber eigenlich auch nicht weiter schwer, das ginge analog zu dem FRM_IN oder FRM_AD-modulen. Hab nur ein paar Baustellen gleichzeitig am laufen (so ein Ultraschallsensor liegt hier übrigens schon da, den Gedanken das einzubinden hatte ich auch schon). Wenn Du Lust hast selber Hand anzulegen, dann schau Dir mal o.g. DHT11-example und eben FRM_IN bzw. FRM_AD als Vorlage an.

Gruß,

Norbert

lust ja :) aber wie das so mit baustellen ist... gestern ein neues modul eingecheckt und heute schon wieder eins angefangen :)

da ich noch keinerlei infrastruktur oder komponenten für die ultraschall geschichte hier habe muß ich bei null anfangen und mich erst mal einlesen. es dauert also auf jeden fall bis ich dazu komme. aber endlich was in c++ zu machen wäre eine schöne abwechlsung. das liegt mir doch sehr viel mehr als perl.

ich denke ich werde mal hardware suchen und bestellen. bis das zeug dann da ist läuft das neue itunes modul hoffentlich und die gartenbewässerung muß eh warten bis es etwas wärmer.

gruss
  andre

Zitat von: ntruchsess schrieb am Fr, 08 März 2013 10:23H Bin ja erst mal schon froh, dass der Reconnect mittlerweile so reibungslos funktioniert.

Hallo Norber, Danke für die Arbeit - läuft im Testbetrieb recht gut, beim Reset des Arduino ist diese sehr schnell wieder am fhem Server angemeldet. Starte ich aber fhem neu dauert es manchmal "ewig" bis er sich verbindet. Ich habe daher etwas gespielt und den Pin 13 (interne LED) geopfert und gleich hinter if (client.connected()) die LED auf HIGH
und im else Teil auf LOW gelegt. Fazit : der Arduino bekommt sehr schnell mit das fhem resetet wurde verbindet sich aber nicht.
Meine qick and dirty  Lösung ist nun das ich 10 Sekunden warte und dann einen Arduino Softreset auslöse. Die Verbindung ist dann sofort wieder aufgebaut.
(Hardware : Arduino Mega 2560 mit Ethershield - beides China billig Teile)


#endif
#ifdef StepperFirmata_h
    stepper.update();
#endif
 
  } else {
    delay(10000);
    asm volatile ("  jmp 0");  
  }
}


hi Wzut,

Mir ist auch nicht so recht klar, warum das so lange braucht um wiederzuverbinden. Irgendwie hat die Arduino-Ethernetlib da Probleme mit. Aber coole Idee, den Reconnect einfach über einen Softreset zu triggern :-)

Dabei geht zwar der aktuelle Zustand verloren, das kann aber ja durchaus gewünscht (weil definiert und sicher) sein.

Gruß,

Norbert

Zitat von: ntruchsess schrieb am So, 24 März 2013 00:45Dabei geht zwar der aktuelle Zustand verloren, das kann aber ja durchaus gewünscht (weil definiert und sicher) sein.

Ist für mich auch so OK , da fhem ja den letzten Zustand nach dem Reconnect sofot wieder überträgt. Alternativ kann man natürlich vor dem SoftReset den Zustand der OUT Pins ins EEPROM schreiben und am Ende von Setup wieder auslesen und setzen.

ich mache gerade meine aller ersten versuche mit einem arduino mega und beim kompilieren von OneWireSchedulerFirmata bekomme ich den folgenden fehler:OneWireSchedulerFirmata.ino: In function 'void sysexCallback(byte, byte, byte*)':
OneWireSchedulerFirmata:485: error: 'INTERNAL' was not declared in this scope

kann es sein das          case 1:
            analogReference(INTERNAL);
            break;
genau so in ein #ifdef INTERNAL gehört wie entsprechend case 2 und 3 danach?

gruss
  andre

'INTERNAL' ist in den Board-spezifischen includes definiert, das sollte eigentlich nicht fehlen (Auf jeden Fall nicht bei einem mega). Hast Du das Board auch richtig in der IDE eingestellt?
Ansonsten nimm bitte den neuesten Stand: https://github.com/firmata/arduino/archive/configurable.zip, (//github.com/firmata/arduino/archive/configurable.zip,) da sollte das eigentlich funktionieren.

Wo ist eigentlich noch der alte 'OneWireSchedulerFirmata.ino'-sketch verlinkt? Nur hier im Anfang des threads (wo ich den link leider nicht mehr ändern kann :-( ), oder auch irgendwo im fhem-wiki?

Gruß,

Norbert

hallo norbert,

ich glaube die war tatsächlich aus dem ersten post. inzwischen hatte ich eine OneWireSchedulerEthernetServer firmata aus dem git branch gefunden die ich ohne probleme kompilieren kann.

die version aus dem configurable.zip geht aber bei mir wieder nicht. ich habe das gefühl das er alles was mit utility zu tun hat nicht findet. wenn ich z.b. ConfigurableEthernetserver auf mache ist nur dieses eine file offen und nicht wie bei OneWireSchedulerEthernetServer aus dem branch mehrere. und beim compilieren bekomme ich das hier:ConfigurableEthernetserver:38: error: 'DigitalInputFirmata' does not name a type
ConfigurableEthernetserver:41: error: 'DigitalOutputFirmata' does not name a type
ConfigurableEthernetserver:44: error: 'AnalogInputFirmata' does not name a type
ConfigurableEthernetserver:47: error: 'AnalogOutputFirmata' does not name a type
ConfigurableEthernetserver:51: error: 'ServoFirmata' does not name a type
ConfigurableEthernetserver:59: error: 'I2CFirmata' does not name a type
ConfigurableEthernetserver:62: error: 'OneWireFirmata' does not name a type
ConfigurableEthernetserver:65: error: 'StepperFirmata' does not name a type
ConfigurableEthernetserver:68: error: 'FirmataExt' does not name a type
ConfigurableEthernetserver:71: error: 'FirmataScheduler' does not name a type
ConfigurableEthernetserver.ino: In function 'void setup()':
ConfigurableEthernetserver:170: error: 'class FirmataClass' has no member named 'setPinMode'
ConfigurableEthernetserver:170: error: 'IGNORE' was not declared in this scope
ConfigurableEthernetserver:173: error: 'class FirmataClass' has no member named 'setPinMode'
ConfigurableEthernetserver:173: error: 'IGNORE' was not declared in this scope

oder muß das zip file an eine andere stelle entpackt werden als das original Firmata (auf dem mac .../Arduino.app/Contents/Resources/Java/libraries) ?

gruss
  andre
 

wie das auf dem mac aussehen muss weiß ich leider nicht. Prinzipiell sollte es aber genauso gehen, wie auf den anderen Plattformen auch:
mit dem Inhalt des zip-files den Inhalt des libraries/Firmata Ordners ersetzen. Anschließend den sketch über 'Datei'->'Beispiele'->'Firmata'->'ConfigurableFirmata' laden und compilieren. Wichtig ist, dass der Ordner auch wirklich so wie das zugehörige cpp und header-file 'Firmata' heißt (und nicht so wie das zip-file 'arduino-firmata').
Eigentlich sollte die Arduino-ide den Inhalt des utility-verzeichnisses selbsttätig in den Build-pfad aufnehmen, auch wenn die Dateien nicht im Sketch sichtbar sind.
Stell doch mal unter 'Datei'->'Einstellungen'->'Ausführliche Ausgabe anzeigen während Compilierung' die Debug-ausgabe an, da sieht man genau mit welchen Pfaden der gcc tatsächlich aufgerufen wird.

Ansonsten kannst Du mal unter libraries/Wire oder libraries/Ethernet schauen. Diese libraries haben (unter Linux und Windows) auch Klassen im utility-Verzeichnis. Schau doch mal, wie das auf dem mac abgelegt ist.

Wenn ich mir die Fehlermeldungen allerdings so ansehe, dann habe ich das Gefühl, dass Du die original Firmata-library gar nicht ersetzt hast, sondern immer noch die mit der Arduino-ide ausgelieferte Version angezogen wird. (Das würdest Du mit vorgenannter Debug-einstellung beim compilieren auch genau sehen können).

Gruß,

Norbert

du hast recht. ich war beim hin und her zwischen original und git version und branch mit den directories durcheinander gekommen.

die beispiele aus dem zip file compilieren jetzt. und auch die ConfigurableEthernetclient firmata.

sobald der ultraschall sensor da ist oder die zusätzlichen DS1820 kann ich dann mehr probieren als nur trockenübungen oder leds blinken lassen.

danke und gruss
  andre

hallo norbert,

die ersten versuche mit ein paar leds per ethernet client sind schon mal erfolgreich verlaufen. das ganze ist wirklich ein sehr schönes spielzeug.

dabei auch gleich ein vorschlag:

- ich denke es wäre schön wenn ein unsupported oder unconfigured mode nur eine Fehlermeldung produziert und nicht gleich fhem zum aussteigen bringt. (jeweils die die in is_supported_mode und is_configured_mode.

gruss
  andre

Zitat von: justme1968 schrieb am Mo, 01 April 2013 20:59dabei auch gleich ein vorschlag:
- ich denke es wäre schön wenn ein unsupported oder unconfigured mode nur eine Fehlermeldung produziert und nicht gleich fhem zum aussteigen bringt.

Fände ich auch gut. Nachdem ich heute etwas Zeit hatte, mich nochmals mit Firmata zu beschäftigen, ist FHEM auch öfters abgestürtzt. Einfach eine Definition falsch, diese wieder löschen und FHEM ist weg.

Dabei klappt es bei mir noch nicht, Firmata mit FHEM zu koppeln. EthernetClient ist drauf, die Definitionen sind auch da, aber Firmata verbindet noch nicht richtig.
Ein Auszug des Logs:
2013.04.01 20:24:01 5: Cmd: >define FRM FRM 3030<
2013.04.01 20:24:01 5: Loading ./FHEM/10_FRM.pm
2013.04.01 20:24:01 3: FRM: port 3030 opened
2013.04.01 20:24:01 5: Triggering global (1 changes)
2013.04.01 20:24:01 5: Notify loop for global DEFINED FRM
...
2013.04.01 20:24:41 5: Cmd: >define OWio OWX 2<
2013.04.01 20:24:41 5: Loading ./FHEM/00_OWX.pm
2013.04.01 20:24:42 2: error initializing OWio: no FirmataDevice assigned to FRM
2013.04.01 20:24:42 1: OWX: 1-Wire bus OWio: interface FRM is not connected to Firmata
2013.04.01 20:24:42 5: Triggering OWio (1 changes)
2013.04.01 20:24:42 5: Notify loop for OWio failed


Irgendwas geht hier noch schief. Das FRM meldet das Firmata scheinbar nicht richtig an, es verbindet nicht.
Ich kann auch nicht die Versionsnummer von Firmata in FHEM erkennen.

Ideen?

Gruß
Kai

Hallo Andre,

freut mich, dass es bei Dir jetzt läuft, ich hab auch grade einen Patch eingespielt, dass unconfigured/unsupported Mode dazu führt, dass das FRM_XXX-device gar nicht mit dem FRM-basisdevice associiert wird und eine passende Meldung ins log geschreiben wird. Danach ist das FRM_XXX-device nicht nutzbar und kann auch nicht versehendlich doch Firmata-methoden aufrufen. Die 'die' Aufruf in perl-firmata sind so schon in Ordnung. Das ist die übliche Methoden Exceptions in Perl zu werfen. Natürlich müssen ggf. noch ein paar eval-blöcke um die Aufrufe herum, damit der aufrufende code das abfängt und nicht aussteigt. Falls Du mit meinem letzten Patch noch Abstürze dieser Art bekommst, dann lass es mich wissen.

--------------

Kai,

benutzt Du meine EthernetClientFirmata von hier: https://github.com/ntruchsess/arduino/blob/configurable_ethernet/examples/ConfigurableEthernetclient/ConfigurableEthernetclient.ino (//github.com/ntruchsess/arduino/blob/configurable_ethernet/examples/ConfigurableEthernetclient/ConfigurableEthernetclient.ino) ?

Da drin musst Du die ip-addresse des fhem-servers und den Port, der im FRM konfiguriert wird eintragen. Die EthernetClient-firmata verbindet sich vom Arduino zum FRM. Letzteres macht nichts weiter, als darauf zu warten, dass der Arduino sich von selbst meldet. Soweit sind deine Logmeldungen also (was FRM angeht) in Ordnung, nur der Arduino hat sich noch nicht gemeldet.
Die EthernetClientFirmata unterstützt das WIZ5100-basierete Ethernetshield. ENC28J60-shields oder breakout-boards gehen noch nicht, da von der mit der Arduino-IDE mitgelieferten Ethernet-library nicht unterstützt. (Gib aber beim compilieren keinen Fehler, da die IDE nicht prüfen kann, welche Hardware tatsächlich am Arduino hängt). Ich hab aber jetzt auch so ein ENC28J60-shield für den Nano, wenn ich mal Zeit über habe, dann baue ich auch dafür einen sketch.

Gruß,

Norbert

Hallo Norbert,

Zitat von: ntruchsess schrieb am Di, 02 April 2013 12:59Kai,

benutzt Du meine EthernetClientFirmata von hier: https://github.com/ntruchsess/arduino/blob/configurable_ethernet/examples/ConfigurableEthernetclient/ConfigurableEthernetclient.ino ?

Da drin musst Du die ip-addresse des fhem-servers und den Port, der im FRM konfiguriert wird eintragen. Die EthernetClient-firmata verbindet sich vom Arduino zum FRM.

Die Source stimmt mit meiner überein, Port und IP-Adresse ist auf meinen FHEM-Server angepasst.

ZitatLetzteres macht nichts weiter, als darauf zu warten, dass der Arduino sich von selbst meldet. Soweit sind deine Logmeldungen also (was FRM angeht) in Ordnung, nur der Arduino hat sich noch nicht gemeldet.
Die EthernetClientFirmata unterstützt das WIZ5100-basierete Ethernetshield. ENC28J60-shields oder breakout-boards gehen noch nicht, da von der mit der Arduino-IDE mitgelieferten Ethernet-library nicht unterstützt. (Gib aber beim compilieren keinen Fehler, da die IDE nicht prüfen kann, welche Hardware tatsächlich am Arduino hängt). Ich hab aber jetzt auch so ein ENC28J60-shield für den Nano, wenn ich mal Zeit über habe, dann baue ich auch dafür einen sketch.

Mein Ethernet-Shield hat den WIZnet EthernetW5100-Chipsatz. So müsste dann ja eigentlich alles stimmen.
Will auch nur meine 1-Wire über Firmata an FHEM koppeln.

Wenn ich dann mit "define PIN13 FRM_OUT 13" Pin 13 als Output definiere und dann den Pin einschalten möchte kommt eine Fehlermeldung:
2013.04.02 21:06:51 2: error initializing PIN13: no FirmataDevice assigned to FRM

Wie kommts? Muss ich hier den EthernetServer installieren? Laut FHEM-Commandref ist die Client-Version die richtige.
(Übrigens ist in der Commandref der FRM_OUT falsch beschrieben:

ZitatFRM_OUT

    represents a pin of an Arduino running Firmata configured for digital input.
    Requires a defined FRM-device to work.

Es handelt sich ja um einen digital output

Danke für die (gewohnt) schnelle Hilfe!!! Super!

Gruß
Kai

Hallo Kai,

sorry dass ich erst jetzt zum Antworten komme. Wir waren über Ostern weg und danach hat mir erst mal die Arbeit überfallen :-(

Probier die 1-Wire konfiguration doch erst mal mit Firmata über USB, das hat weniger Fallstricke und Du kannst Dir anschließend beim Umstieg auf EthernetClientFirmata sicher sein, das die FRM-konfig schon mal sinnvoll ist.

Um zu debuggen, ob der Arduino überhaupt verbindet solltest Du das globale Attribut 'verbose' auf 5 stellen. Der Loglevel von FRM zieht leider erst nach dem Initialisieren so dass man den Verbindungsaufbau sonst nur sehen kann, wenn man den Arduino nach dem Starten von fhem noch mal resettet. Mit einem Reset des Arduino kann man übrigend jederzeit einen Reconnect erzwingen - leider ist die Ethernet-library des Arduinio nicht wirklich wasserdicht und bekommt manchmal nicht so recht mit, wenn die Verbindung abreißt. Da kann das FRM-modul leider nichts dagegen tun. Der von Wzut vorgeschlagene Workaround (http://forum.fhem.de/index.php?t=usrinfo&id=1172&rid=677 (//forum.fhem.de/index.php?t=usrinfo&id=1172&rid=677)) funktioniert aber ganz gut, ich habe das nur noch nicht auf github committed, weil ich eigentlich verstehen möchte, was in der Ethernetlibrary tatsächlich fehlschlägt.

Gruß,

Norbert

Hallo Norbert,

danke für die Antwort. Das mit dem "Arbeit überfallen" habe ich seit einem Jahr bei meiner Haussanierung (nach der "normalen" Arbeit) und kann es daher gut nachfühlen.....

Werde am Wochenende das von Dir beschriebene mal probieren, ob ich endlich den Arduino zur Zusammenarbeit mit Firmata überreden kann.


Gruß
Kai

So, nun konnte ich bis zum WE nicht warten.
Haben den Fehler gefunden....
"Define FRM FRM 3030" geht nicht, auch wenn IP und Port in Firmata richtig sind

"Definde FRM FRM 3030 global" geht.

Warum? Keine Ahnung. Liegt wohl an meinem Server, oder wie auch immer, jedenfalls geht es jetzt und alles wird gut!!!!
Danke!!

Gruß
Kai

das 'global' hat die gleiche bedeutung wie bei 'telnet' (//fhem.de/commandref.html#telnet). Das liegt daran, dass ich in FRM den code vom telnet mitverwende.
Das habe ich bei FRM auch dokumentiert:
define <name> FRM {<device> | <port> [global]}
<port> specifies the port the FRM device listens on. If 'global' is specified the socket is bound to all local ip-addresses, otherwise to localhost only.

naja, 'localhost only' macht natürlich beim remote verbindenen arduino keinen Sinn. Vieleicht sollte ich das mal ändern und global intern fest setzen.

Gruß,

Norbert

Ok, das mit dem global hatte ich gelesen, aber anders gedeutet.

Leider geht das ganze nun nicht mehr. Ich weiß nicht, die Abfrage der Sensoren hat einmal funktioniert. Jetzt geht das ganze nicht mehr. Ausserdem beendet FHEM den Prozess eigenständig, d.h. nach einiger Zeit ist FHEM weg.

Das gleiche ist auch bei einem "delete FRM FRM".
Ein "delete OWio OWIO" klappt noch ohne Absturz.

Das FRM meldet eine Verbindung, OWIO meldet Status failed.

Jetzt habe ich einmal Firmata neu drübergebügelt, es geht wieder. Ein Reset reicht bei mir nicht aus, das trennen der Spannungsversorgung hilft scheinbar auch (warum auch immer)

Bei der Abfrage eines Sensors kommt dann folgende Fehlermeldung:
OWTHERM: Could not get values from device Innentemperatur, return was invalid data length, 1 instead of 10 bytes

Also die Sensoren werden erkannt, aber Daten bekomme ich keine mehr.

Was mich stört ist auch das ewige Aufhängen des FHEM-Servers. Auch ein "rereadcfg" führt zu einem Absturz. Woran kann das liegen? Habe gerade noch ein update durchgeführt, keine Änderung. Das ganze mit der Abfrage eines Sensors hat nur einmal funktioniert. Hatte mich wohl zu früh gefreut.


Gruß
Kai

- was meinst Du mit FHEM hängt sich auf? Abbruch des Prozesses (mit entsprechender Ausgabe im log bzw. auf der startenden Konsole)?
- Mit welchem Interval fragst Du die Sensoren ab?
- Hast Du ein logfile parat? (mit verbose 5 oder FRM loglevel <= Wert von verbose)?

Gruß,

Norbert

hallo Norbert,
ich poste nach meiner Dienstreise am Wochenende mal die 3 Zeilen, die auf der Konsole beim FHEM Absturz stehen. Bis dahin ist der Test RPI dann auch paar Tage gelaufen und ich kann sehen, ob Firmata und OWX noch läuft. Habe da seit Dienstag auch ein Display über I2C mit FRM_LCD dran. Wäre es möglich da die Funktionalität von OWLCD hinein zu kopieren? Bekomme bisher nur einen festen Text auf die erste der 4 Zeilen.
vielen Dank,

Zitat von: ntruchsess schrieb am Mi, 17 April 2013 22:23- was meinst Du mit FHEM hängt sich auf? Abbruch des Prozesses (mit entsprechender Ausgabe im log bzw. auf der startenden Konsole)?

Also FHEM läuft nach einiger Zeit nicht mehr und muß neu gestartet werden. Das ist erst seit ich Firmata im Einsatz habe.
Heute morgen um 6.42h gestartet, hat sich dann schnell wieder "beendet". Dann um 6.59h gestartet, ist bis 9.10h gelaufen.

Zitat- Mit welchem Interval fragst Du die Sensoren ab?

Das Instervall steht auf 300, allerdings werden die Sensoren nicht abgefragt. Ich kann mit "get OWio devices" alle 3 Devices abfragen und anzeigen.
Wenn ich mit "get Innentemperatur temperature" abfrage kommt die Fehlermeldung "
OWTHERM: Could not get values from device Innentemperatur, return was invalid data length, 1 instead of 10 bytes "

Zitat- Hast Du ein logfile parat? (mit verbose 5 oder FRM loglevel <= Wert von verbose)?

2013.04.18 21:39:00 3: FRM: port 3030 opened
2013.04.18 21:39:39 3: Firmata Firmware Version: ConfigurableEthernetclient_V1.ino V_2_04
2013.04.18 21:39:59 1: OWX: 1-Wire bus OWio: interface Firmata detected in FRM:192.168.3.126:1025
2013.04.18 21:40:10 3: OWTHERM: Device OWX_10_A08098010800 defined.
2013.04.18 21:40:10 3: OWTHERM: Device OWX_28_395507040000 defined.
2013.04.18 21:40:10 3: OWTHERM: Device OWX_28_95212D040000 defined.
2013.04.18 21:40:10 1: OWX: 1-Wire devices found on bus OWio (OWX_10_A08098010800,OWX_28_395507040000,OWX_28_95212D040000)
2013.04.18 21:40:10 1: OWX: 1-Wire devices found on bus OWio (OWX_10_A08098010800,OWX_28_395507040000,OWX_28_95212D040000)

Wenn ich alles zu Fuß nacheinander definiere, FRM, OWio usw. geht das interessanterweise.



Interessant ist die Konsole: rereadcfg, dann kommt
Argument "" isn't numeric in numeric lt (<) at ./FHEM/21_OWTHERM.pm line 950.
oder auch
Can't use string ("2") as a HASH ref while "strict refs" in use at ./FHEM/10_FRM.pm line 88.
und FHEM ist weg. Im Logfile kein Eintrag, nur das oben in der Konsole.

Beim Neustart kommt dann:
2013.04.18 21:42:46 3: FRM: port 3030 opened
2013.04.18 21:42:46 2: error initializing OWio: no FirmataDevice assigned to FRM
2013.04.18 21:42:46 1: OWX: 1-Wire bus OWio: interface FRM is not connected to Firmata
2013.04.18 21:42:47 3: OWTHERM: Device OWX_10_A08098010800 defined.
2013.04.18 21:42:47 3: OWTHERM: Device OWX_28_395507040000 defined.
2013.04.18 21:42:47 3: OWTHERM: Device OWX_28_95212D040000 defined.

Scheinbar ist das FRM zu schnell oder Firmata hat sich noch nicht gemeldet.
Jedenfalls muß ich erst OWio wieder löschen und neu definieren.

Auch erscheint nach einen "shutdown restart" (anstelle des Absturz-Befehls rereadcfg) hinter den Temperaturen der Sensoren kein Pfeil-Symbol, sondern ein "&".

So, nun alles nochmal durchgeführt.
Fhem neu gestartet ohne FRM und OWX
define FRM FRM 3030 global

Warten, bis bei FRM die Daten vom Arduino kommen
Dann define OWio OWX 2
Dann get OWio devices
Dann erscheinen auch die Temperatursenoren unter der Rubrik OWX:
OWX_10_A08098010800 T: 21.25 °C
OWX_28_395507040000 T: 24.00 °C ▾
OWX_28_95212D040000 T: 7.12 °C ▾

Es erscheint so, als wäre noch ein Timing-Problem vorhanden. OWX und alle weiteren Definitionen müssten warten, bis FRM die Verbindung aufgebaut hat.
Interessant auch die beiden Meldungen auf der Konsole. Ich lasse die mal laufen und warte, bis sich FHEM das nächste mal verabschiedet hat. Einen Logeintrag gibt es trotz dem Loglevel 5 und Verbose 5 nicht.


Wäre wirklich schön, wenn das in Funktion zu bekommen wäre (ohne Abstürze und händische Definitionen). Für mich bedeutet das eine gute Möglichkeit, die Datenerfassung zukünftig über Arduinos dezentral durchzuführen, ohne die Sensoren am USB/CUNO etc zu betreiben. CAT-Leitung liegt im ganzen Haus, notfalls ginge ja auch WLAN.


Gruß
Kai

danke für den ausführlichen Bericht, jetzt sehe ich klarer.

Das Timing-problem ist schon gelöst, dafür haben pah und ich zusammen OWX sehr stark umgebaut. Die angehängte Version ist nur noch nicht im SVN committed, ich wäre Dir dankbar wenn Du damit weitertesten würdest. Damit sollte die Verbindung vom Arduino zu jeder Zeit wieder neu aufgebaut werden können (und zwischendurch beliebig lange wegbleiben) ohne dass man die Devices neu definieren muss.

Gruß,

Norbert

Hallo Norbert,

hab die Dateien gerade getauscht, geht nach einem Neustart leider nicht:
2013.04.19 07:07:26 3: FRM: port 3030 opened
2013.04.19 07:07:27 1: OWX: 1-Wire bus OWio: interface FRM is not connected to Firmata
2013.04.19 07:07:27 2: OWX: Error initializing OWio: OWX_Detect failed

Danach habe ich einen Reset ausgelöst, da war dann FRM wieder i.O., aber OWX läuft nicht.
Wenn ich mit "get <device> temperature" die Temperatur abfrage, erscheint wieder die Meldung
OWTHERM: Could not get values from device Aussentemperatur, return was invalid data length, 1 instead of 10 bytes

Alles nacheinander Manuell definiert führt zu einem Ergebnis, dass die Sensoren abgefragt werden können. Logfile:
2013.04.19 07:20:24 3: FRM: port 3030 opened
2013.04.19 07:20:47 3: Firmata Firmware Version: ConfigurableEthernetclient_V1.ino V_2_04
2013.04.19 07:21:20 1: OWX: 1-Wire bus OWio: interface Firmata detected in FRM:192.168.3.126:1025
2013.04.19 07:21:33 3: OWTHERM: Device OWX_10_A08098010800 defined.
2013.04.19 07:21:34 3: OWTHERM: Device OWX_28_395507040000 defined.
2013.04.19 07:21:34 3: OWTHERM: Device OWX_28_95212D040000 defined.
2013.04.19 07:21:34 1: OWX: 1-Wire devices found on bus OWio (OWX_10_A08098010800,OWX_28_395507040000,OWX_28_95212D040000)
2013.04.19 07:21:48 1: OWX: 1-Wire devices found on bus OWio (OWX_10_A08098010800,OWX_28_395507040000,OWX_28_95212D040000)

Danach führt ein get <device> temperature zu
OWTHERM: Innentemperatur.temperature => 20.6875


Ein "rereadcfg" führt leider immer noch zu einem Absturz des Systems, Konsole:
 Can't use string ("2") as a HASH ref while "strict refs" in use at ./FHEM/10_FRM.pm line 88.

Weiteres werde ich heute abend testen.
Danke Dir für die Hilfe!

Gruß
Kai

Hallo Norbert,

ich habe auch das Problem mit dem Absturz von FHEM.

Zuerst hat es funktioniert, konnte auch den Arduino schon steuern,
aber dann war auf einmal FHEM weg und konnte auch nicht mehr gestartet werden.
Ich kann dies auch wiederholen.
Wenn ich diese Zeilen einfüge:
define FIRMATA FRM 3030 global
define Firmata_OUT FRM_OUT 13
attr Firmata_OUT room FS20

Stürzt FEHM ab und kann auch nicht mehr gestartet werden.
Folgende Meldungen erscheinen im LOG (VERBOSE 5):

2013.04.19 20:14:17 3: FIRMATA: port 3030 opened
2013.04.19 20:14:17 2: error initializing Firmata_OUT: no FirmataDevice assigned to FIRMATA
2013.04.19 20:14:18 3: telnetPort: port 7072 opened
2013.04.19 20:14:18 3: WEB: port 8083 opened
2013.04.19 20:14:18 3: WEBphone: port 8084 opened
2013.04.19 20:14:18 3: WEBtablet: port 8085 opened
2013.04.19 20:14:18 1: Including ./log/fhem.save
2013.04.19 20:14:27 1: Firmata_OUT is against deletion (2), continuing with rereadcfg anyway

Das ganze läuft bei mir auf einer Fritzbox 7390.

Noch ein Test:
Es hatte gerade mal wieder funktioniert und ich hatte die Idee,
dass es an der Zeile
attr Firmata_OUT room FS20
liegt, weil diese nicht enthalten war.
Jetzt bleibt FHEM ab er beim Start so hängen:
2013.04.19 20:48:20 5: Cmd: >attr global verbose 5<
2013.04.19 20:48:20 5: Cmd: >attr global sendStatistics onUpdate<
2013.04.19 20:48:20 5: Cmd: >define FIRMATA FRM 3030 global<
2013.04.19 20:48:20 5: Loading ./FHEM/10_FRM.pm

Folgendes steht in der Konfig:
define FIRMATA FRM 3030 global
define Firmata_OUT FRM_OUT 13

Grüße
Thomas

Hallo Norbert,

das versprochene feedback - nach 4 1/2 Tagen Dauerlauf - was soll ich sagen, haben die "Software Selbstheilungskräfte" gewirkt. Kein Ansturz mit Ardunio Nano und 1wire Firmata auf RPI über USB, angeschlosssen daran 1x DS18B20 Thermometer über OWX, 1x Display am I2C, 1x FRM_OUT zum Blinken an LED13. Soeben noch einen DS2406 bei laufendem Betrieb angeschlossen - get OWX_0 devices - erkannt - funktioniert. Zum Test ein shutdown restart - keine Meldungen mehr auf der putty Konsole und FHEM läuft weiter ohne händisches Neustarten über Telnet.
Ist zwar nicht so hilfreich wie eine genaue Fehlermeldung - sorry - aber ich hab da gerade keine auf Lager. Auf dem RPI läuft neben dem Ardunio noch das SONOS Modul von Reinerlein und FHEM2FHEM zur Fritzbox um bei Telefonanruf über FBCONNECT den SONOS stumm zu schalten, sonst nichts.

Hallo Norbert,
habe soeben die geänderten Module aus Deinem Post eingespielt. Über USB Ardunio geht offenbar alles wie gewünscht, DS1820, DS 2406, FRM_OUT und Display tun es auch nach abziehen USB Kabel und wiederanstecken nach einiger Wartezeit.
vielen Dank!

Also bei mir läuft es nicht stabil.
Mal funktioniert es, dann bekomme ich einen Absturz.
Nach einem Absturz bekomme ich bei einem erneuten Start über Telnet folgende Meldung auf der Console:
root@FBEG:/var/media/ftp/fhem# Undefined subroutine &main::TcpServer_Open called
 at ./FHEM/10_FRM.pm line 61, <$fh> line 18.

Vielleicht hilft das weiter.

Grüße
Thomas

aufgrund der Meldung habe ich jetzt mal die Einträge:

Zitatdefine FIRMATA FRM 3030 global
define Firmata_OUT FRM_OUT 13

ganz nach hinten in die Konfig geschrieben,
weil dachte,
dass vielleicht noch etwas nicht geladen ist.
Der Fehler kommt jetzt nicht mehr, allerdings klappt jetzt die Verbindung zum Arduino nicht mehr.

ZitatFIRMATA listening

Dies kann aber an was anderem liegen.
Ich suche weiter.

edit:
so jetzt wurde der arduino gefunden.
Sieht so aus, als ob alles funktioniert:-)
Es liegt an der Position.
Ich hatte die Einträge direkt nach den "attr" Einträgen

Grüße
Thomas

Zitat von: ThomasL schrieb am Sa, 20 April 2013 20:48aufgrund der Meldung habe ich jetzt mal die Einträge:

Zitatdefine FIRMATA FRM 3030 global
define Firmata_OUT FRM_OUT 13

ganz nach hinten in die Konfig geschrieben,

Danke für das Feedback - aktuell muss FRM nach dem telnet-modul stehen, das läd die TcpServerOpen-funktion. Ich werd mal ein passendes require zum FRM hinzufügen.

Gruß,

Norbert

Zitat von: det. schrieb am Sa, 20 April 2013 17:41Über USB Ardunio geht offenbar alles wie gewünscht, DS1820, DS 2406, FRM_OUT und Display tun es auch nach abziehen USB Kabel und wiederanstecken nach einiger Wartezeit.
vielen Dank!

Bitte, bitte ;-)

Über USB ist FRM aktuel viel stabiler als über Ethernet, das liegt aber an der Arduino-seite, FRM kann nicht viel tun, wenn der Arduino nicht verbinden mag. Da werde ich mich aber noch drum kümmern, es gibt ja offenbar viele, die schon Ethernet im Haus liegen haben (und sich natürlich nicht noch eine USB-Verkabelung dazu legen wollen...).

Was für ein Display benutzt Du? Wir sollten im Wiki am besten eine Rubrik anlegen, die funktionierende Displays dokumentiert.

Leider kann ich die neuen OWX-module noch nicht ins SVN committen, da fehlen noch ein paar Anpassungen für OWX_CCC.

Gruß,

Norbert

Hallo Norbert,
ich habe ein China Billigdisplay http://www.ebay.de/itm/New-2004-204-20X4-Character-LCD-Display-Module-Blue-Backlight-/261162290069?pt=Motoren_Getriebe&hash=item3cce7c4b95 (//www.ebay.de/itm/New-2004-204-20X4-Character-LCD-Display-Module-Blue-Backlight-/261162290069?pt=Motoren_Getriebe&hash=item3cce7c4b95) über diesen Adapter angeschlossen: http://www.ebay.de/itm/390527388644?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649 (//www.ebay.de/itm/390527388644?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649)
Zwei solcher Displays habe ich schon lange im Einsatz mit dem Louis Swart Interface für 1wire und OWLCD von pah. Die Ardunio Variante ist noch günstiger und in Ardunionähe als Füllstandsanzeiger praktisch zu verwenden mit dem von Dir schon angekündigten  Ultraschallmodul nur fehlt Deiner FRM_LCD noch die Möglichkeit ( oder mir die Fähigkeit) Variablen auf den 4 Zeilen des Displays darzustellen.

Hallo Norbert,

ich habe weiter getestet.
Es läuft soweit stabil bei mir,
nur wird der Arduino nach einem Neustart von fhem nicht erkannt.
Wenn ich den Arduino auch neustarte klappt es.
Es scheint, als ob die Funktion Client.connected() nicht richtig funktioniert.

Grüße
Thomas

Interessanter Weise läuft das ganze jetzt seit gestern auch ohne Absturz, ich hoffe, es bleibt jetzt so.

Allerdings stellt sich das Intervall automatisch von 300s auf 9999s, ohne das ich etwas verändere.
Eine Idee, woran es liegen kann?

Gruß
Kai

Zitat von: ThomasL schrieb am So, 21 April 2013 09:52Es scheint, als ob die Funktion Client.connected() nicht richtig funktioniert.

Wzut hat hierzu am 23.März einen Workaround gepostet. Probier den doch mal aus, wenn sich das bewährt, nehme ich das in den Sketch auf.

Gruß,

Norbert

Zitat von: kaizo schrieb am Mo, 22 April 2013 19:00Allerdings stellt sich das Intervall automatisch von 300s auf 9999s

Das macht das OWTHERM modul selbst, wenn OWX (bzw. FRM) die Verbindung zum DS18B20 verloren hat. Es probiert einige Male sein Device zu pollen und gibt dann aber auf (und stellt dazu das Intervall auf 9999). Wenn die Asynchrone OWX-Variante fertig ist, dann läuft das anders - da teilt OWX den Sensor-modulen mit, dass die Verbindung wieder da ist.

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

Gruß,

Norbert

Zitat von: det. schrieb am Sa, 20 April 2013 22:22ich habe ein China Billigdisplay [...] über diesen Adapter angeschlossen: http://www.ebay.de/itm/390527388644?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649[...]nur fehlt Deiner FRM_LCD noch die Möglichkeit ( oder mir die Fähigkeit) Variablen auf den 4 Zeilen des Displays darzustellen.

Mein Displaykontroller (für ein 16x2 Display) sieht exakt genauso aus.

FRM_LCD versteht zur Ausgabe folgende set-commandos:
'text', 'home','clear','display on/off', 'cursor x,y' und 'scroll left/right'

mit 'set <display> cursor 0,1' sollte man in die zweite Zeile kommen. text, Home und clear sollten eh klar sein. Wenn man das autoBreak-attribut gesetzt hat, dann kann man längere Strings ausgeben, FRM_LCD fügt die eintsprechenden 'cursor x,y'-aufrufe dann selber ein.

'scroll' ist bei mir etwas buggy, das funktioniert auch mit der nativen Arduino-library die ich nach perl portiert habe nicht so recht.

Falls das alles nicht tut, hast Du eine native Arduino-library, mit der es geht?

Gruß,

Norbert

Hallo,

ich lese den Thread schon mit Interesses seit Anfang an, weil die Lösung genau das ist, was ich suche.

Ich habe einen RPI mit COC und daran über 1-Wire einen DS18B20er angeschlossen. RPI ist in der Wohnung, der DS18B20 über eine lange Leitung in den Heizraum. Die Anzeige habe ich mit OWServer und OWDevice realisiert.

Nun will ich im Heizraum noch mehrere Temperatursensoren und Schalter realisieren. Da die 1-Wire Leitung nur provisorisch verlegt ist, will ich die Anbindung über LAN, Arduino und Firmata machen.

Und nun die Frage. Geht die im Thread beschriebene Lösung auch mit OWServer und OWDevice oder nur mit OWX und den OWYYYY-Modulen? Die Frage gehört wahrscheinlich ins Anfängerforum, aber dann würde aus meiner Sicht der Bezug zum Thema verloren gehen.

Achim

ZitatGeht die im Thread beschriebene Lösung auch mit OWServer und OWDevice oder nur mit OWX und den OWYYYY-Modulen

FRM arbeitet nur mit OWX zusammen. Die Anbindung über LAN ist auch noch nicht 100% stabil - da kann es dauern bis der Arduino nach einer Netzwerkunterbrechung oder FHEM-neustart von selber wieder zum FHEM connected. Im Prinzip gibt es dafür schon einen recht zuverlässigen Fix (der Ardunio resettet sich als Workaround beim verlieren der Verbindung per Software selber) - dann ist allerdings auch der letzte Zustand (an den Ausgabe-pins) so lange auf die Defaultwerte zurückgesetzt bis FHEM wieder erreichbar ist. (Das kann man allerdings auch gut finden).

Unterstützt wird aktuell nur LAN mit WIZ5100-basierten Ethernetshields (Original Shields und deren Clone). EN28J60 oder WLAN-shield wartet noch auf einen Implementierer ;-)
(EN28J60 ist auch nicht so einfach, da gibt es keine mir bekannte Arduino-library die echte dauerhafte TCP/IP-verbindungen unterstützt)

Gruß,

Norbert

Zitat von: ntruchsess schrieb am Mo, 22 April 2013 23:27

Zitat von: ThomasL schrieb am So, 21 April 2013 09:52Es scheint, als ob die Funktion Client.connected() nicht richtig funktioniert.

Wzut hat hierzu am 23.März einen Workaround gepostet. Probier den doch mal aus, wenn sich das bewährt, nehme ich das in den Sketch auf.

Gruß,

Norbert

Das klappt prima!
Danke!
Jetzt wäre es natürlich noch perfekt, wenn vom FHEM Befehle die an den Arduino gesendet werden sollen,
diese solange gepuffert werden, bis der Ardiuno wieder verbunden ist.
Zumindest ein paar Sekunden.

Grüße
Thomas

Also bei läuft der "Workaround" auch recht zuverlässig, jedenfalls besser als das "reconnect" über den erneuten Aufruf der Ethernet-Routine.

Leider ist das ganze noch nicht stabil genug, es gibt immer noch Abstürze und Intervallverlängerungen auf 9999.

Potential hat das gesamte sehr, mit dem Ardunio eine abgesetzte Steuer- und Messeinheit aufzubauen ist doch seeeeehr verlockend.
Ich hoffe, dass Norbert hier das System noch etwas verbessern kann. Schönen Dank jedenfalls für die geleistete Arbeit!

Gruß
Kai

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 (//%5Burl=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

Zitat von: AchimU schrieb am Mo, 29 April 2013 12:50...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

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

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

Zitat von: ntruchsess schrieb am Mo, 22 April 2013 23:33Der 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"

Zitat von: Wzut schrieb am Do, 02 Mai 2013 09:06Bedeutet 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.

Zitat von: Wzut schrieb am Do, 02 Mai 2013 09:06Ich 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

Zitat von: kaizo schrieb am Mi, 01 Mai 2013 10:34hast 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

Zitat von: AchimU schrieb am Mo, 29 April 2013 12:50The 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

Hallo zusammen,

Zitat von: Wzut schrieb am Do, 02 Mai 2013 09:06Negativ : 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.

Zitat von: ntruchsess schriebNein, 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

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

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 (//www.pjrc.com/teensy/td_libs_OneWire.html) 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

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)

Zitat...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

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.

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

Zitat von: kaizo schrieb am Mi, 08 Mai 2013 21:04Das 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 ;-)

Zitat von: kaizo schrieb am Mi, 08 Mai 2013 21:04...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

ich bring den Zähler am Montag auf die Post, sollte also spätestens Mittwoch bei Dir sein.

Zitat von: woody schrieb am Fr, 10 Mai 2013 21:19Selbst das rereadcfg bewirkt einen Absturz von fhem.

den Absturz beim 'rereadcfg' habe ich grade gefixed und ins svn committed

Gruß,

Norbert

Zitat von: kaizo schrieb am Mi, 08 Mai 2013 21:04Auch wenn das noch nicht Final ist, schick doch mal eine beta ;-)

Für alle, die mal einen Blick auf den aktuellen Arbeitsstand werfen oder (beta-)testen wollen habe ich die files mal auf github gelegt:

Der Branch 'refactoring' enthält den Stand, der mit den aktuellen OWxxxx.pm-Device-modulen zusammenarbeiten sollte:
https://github.com/ntruchsess/fhem_owx/tree/refactoring/fhem/FHEM

Dieser code ist schon recht stabil und enthält z.B. die Umbauten für den Reconnect eines OneWire Busmasters. Getested mit Arduino über USB und DS2480B Busmaster an einem FTDI-USB-adapter. Mit einem CUNO konnte ich diese Version selber nicht testen und pah hat im Moment auch ziemlich viel um die Ohren. Also wenn jemand einen CUNO und Lust auf Experimente hat...

Der Branch 'refactoring_async' enthält die Überarbeitung zur asynchronen Abfrage der OWxxx-devices:
https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM
bisher habe ich erst OWTHERM.pm umgestellt. Läuft bei mir hier mit Arduino/USB und DS2480B. Der Code für den CUNO ist noch gar nicht umgestellt...

Gruß,

Norbert

Hallo Norbert,

Danke, Absturz ist weg!

ZitatDer Branch 'refactoring_async' enthält die Überarbeitung zur asynchronen Abfrage der OWxxx-devices:
https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM (//github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM)
bisher habe ich erst OWTHERM.pm umgestellt. Läuft bei mir hier mit Arduino/USB und DS2480B. Der Code für den CUNO ist noch gar nicht umgestellt...

Hallo Norbert,
mit dem neuen OWTHERM liefern die DS1820 keine Werte und gehen auf present 0 obwohl sie vorher gefunden werden:
OWX: 1-Wire devices found on bus OWX_0
28.F213DD030000      DS18B20        OWX_28_F213DD030000
28.AABDDA030000      DS18B20        OWX_28_AABDDA030000
28.467BDA030000      DS18B20        OWX_28_467BDA030000
28.EE81DA030000      DS18B20        OWX_28_EE81DA030000
28.A5A5DA030000      DS18B20        OWX_28_A5A5DA030000
28.1B7BDA030000      DS18B20        OWX_28_1B7BDA030000
12.4EF17B000000      DS2406/DS2507  OWX_12_4EF17B000000
OWX über Ardunio-USB angeschlossen

ach so, das 'get XXX present' vom FRM_OWX, da muss ich noch mal ran, das geht nicht asynchron. Da muss ich noch was implementieren, dass es nicht nur einen Search auf dem Bus anstößt, sondern auch (synchron) auf das Ergebnis wartet.

Die Temperaturen werden bei mir aber gemessen. Stell doch mal das Interval auf 10 Sekunden und refreshe die 'Everything'-Übersicht. Das sollte deutlich besser antworten als bei der bisherigen synchronen Variante. Man darf das Intervall aber auch nicht zu kurz einstellen, weil OWTHERM gnadenlos Anfragen losschickt, die der Arduino auch nur ca. 1/sec abarbeiten kann (wegen der 1 Sekunde Pause zwischen Conversion und Abfrage).

Wenn Du ein 'get XXX temperature' aufrufst, dann wird im Device die Convertierung und das auslesen getriggert. Der angezeigte Wert ist aber (sofern schon vorhanden) noch der alte, da die Antwort ja asynchron (und daher erst nach Aufruf des get XXX temperature) vom Arduino empfangen wird. Da muss ich (analog zum get XXX present) noch ein synchrones Warten auf die asynchrone Antwort einbauen.

Soll auch erst mal der erste Wurf sein, der demonstriert, dass die zyklische Abfrage eben auch asynchron im Hintergrund geht.

Gruß,

Norbert

P.S. hab grade gemerkt, dass das 'reconnect' im Prinzip zwar geht, wenn man OWTHERM aber z.B. im 5 Sekunden Rythmus abfragen läßt, ist die Weboberfläche so lange lamgelegt, bis man den Arduino wieder verbunden hat, oder die 5 Errors pro DS18B20 erreicht sind, bei denen OWTHERM auf 999 Sekunden Interval umstellt. Die Baustellen gehen nicht aus ;-)

Zitat von: ntruchsess schrieb am Mo, 13 Mai 2013 22:48Für alle, die mal einen Blick auf den aktuellen Arbeitsstand werfen oder (beta-)testen wollen habe ich die files mal auf github gelegt:

Der Branch 'refactoring' enthält den Stand, der mit den aktuellen OWxxxx.pm-Device-modulen zusammenarbeiten sollte:
https://github.com/ntruchsess/fhem_owx/tree/refactoring/fhem/FHEM

Dieser code ist schon recht stabil und enthält z.B. die Umbauten für den Reconnect eines OneWire Busmasters. Getested mit Arduino über USB und DS2480B Busmaster an einem FTDI-USB-adapter. Mit einem CUNO konnte ich diese Version selber nicht testen und pah hat im Moment auch ziemlich viel um die Ohren. Also wenn jemand einen CUNO und Lust auf Experimente hat...

Also Norbert,
da hat sich ja scheinbar einiges getan. Habe die "refactoring" seit gestern abend im Einsatz, seit dem läuft FHEM ohne Absturz durch!
Und die DS2423-(Fake)-Counter können ausgelesen werden!
rereadcfg geht auch wieder.

Super!

Jetzt noch asynchron, dann ist alles gut. Obwohl ich schon mit der dieser Version zufrieden bin, endlich keine Abstürze mehr

Werde mal weiter testen, auch was "save config" und ein Neustart angeht.

Gerade gemacht,.. und:
Den ersten Test hat das alles gut überstanden, nur die Zählerabfrage vom Counter hat bei einer gespeicherten Config mit FRM & OWX nicht mehr geklappt. Die Zählerstände werden scheinbar nur angezeigt, wenn ich beim FHEM-Start FRM und OWX manuell definiere und dann anzeigen lasse.


Gruß
Kai

Ich weiss nicht wo ich aktuell am besten diese Frage stellen soll, allerdings passt der Titel und wenigstens ist das Thema im weitesten sinne auf Haustechnik bezogen.

Ich frage mich ob es möglich ist Funksteckdosen via Fimata over Ethernet zu steuern, die Sketches nutzen normalerweise die RC-Switch library und die sended dann die Impulse als digitalwrite auf den pin in abständen von z.B. 320 Mikrosekunden.
Kann man das dem Arduino so schnell via am ethernet angebundenem Firmata mitteilen ?

so ist der arduino aktuell verkabelt: http://www.homecontrol4.me/de/?id=bauanleitung (//www.homecontrol4.me/de/?id=bauanleitung)
natuerlich mit dem entsprechenden sketch von homecontrol4, im firmata ethernet gebe ich ja eine feste ip direkt im sketch.

danke

Yaku

mir ist nicht ganz klar, was Du machen möchtest. Daher erst mal, was ich meine verstanden zu haben:

Arduino mit Funkmodulen soll über Standard-Firmata angesteuert werden um Funksteckdosen zu steuern (ohne Verwendung der RC-Switch library)? Also alles was die Library macht z.b. nach Perl portieren und den Arduino nur als Firmata-IO-interface über Ethernet nutzen?
-> ich glaube nicht, dass das von Timing her zuverlässig geht. Da sollte man die RC-Switch-library in eine Firmata-Feature-Klasse wrappen (siehe 'configurable'-Firmata auf GitHub (//github.com/firmata/arduino/tree/configurable)) und nur noch 'High-level' commands per Firmata an den Arduino schicken. Das exakte Timing würde dann der Microcontroller machen, Netzwerkverzögerungen wären dann unkritisch.

Gruß,

Norbert

Hallo Leute,
habe refactoring ausprobiert. Leider findet er jetzt meine dvices nicht mehr.

2013.05.16 21:37:58 3: Arduino: port 3030 opened
2013.05.16 21:37:59 1: reload: Error:Modul 00_OWX deactivated:
 Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.16 21:37:59 0: Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.16 21:37:59 3: Please define 1Wire first
2013.05.16 21:37:59 1: define: OWTHERM: Warning, no 1-Wire I/O device found for OWX_10_E2EE54020800.

Kennt jemand das Problem?

Grüße
woody

ZitatArduino mit Funkmodulen soll über Standard-Firmata angesteuert werden um Funksteckdosen zu steuern (ohne Verwendung der RC-Switch library)?
Also alles was die Library macht z.b. nach Perl portieren und den Arduino nur als Firmata-IO-interface über Ethernet nutzen?
-> ich glaube nicht, dass das von Timing her zuverlässig geht.

Das war mein Gedanke da wenn es so funktioniert hätte man immer neue Sensoren anstecken hätte können ohne was am Arduino zu ändern :), aber ich dachte mir schon fast das es nicht ganz so einfach ist.

ZitatDa sollte man die RC-Switch-library in eine Firmata-Feature-Klasse wrappen (siehe 'configurable'-Firmata auf GitHub (//github.com/firmata/arduino/tree/configurable)) und nur noch 'High-level' commands per Firmata an den Arduino schicken. Das exakte Timing würde dann der Microcontroller machen, Netzwerkverzögerungen wären dann unkritisch.

Das hoert sich sinnvoll an aber in dem Fall ist es evtl. Interessanter einen Gateway fuer die Signale ohne RC-Switch zu benutzen da es 2 so wie ich es verstanden habe freie Oberflächen gibt die eine Art Standart benutzen in dem Sie den Code ohne RC-Switch direkt an das Gateway schicken und nur noch angeben wieviele Microsekunden zwischen den bit´s liegen.
Ich weis nur nicht ob man das einfach so einen gateway wie beim http://www.hmb-tec.de/HMB-TEC/House_Control.html, (//www.hmb-tec.de/HMB-TEC/House_Control.html,) usw. einbauen darf, es gibt schon 3 Verschiedene Gateways(Intertechno,hcgw und conn-air) die das so machen und prinziprell sieht das auch aus wie die Ausgabe der RC-Switch library bevor sie den digitalwrite(); auf den datenpin macht...

Die Befehle sehen eigentlich ganz Simpel aus die Interpretiert werden müssen. Von perrpf im power-switch.eu Forum.
TXP:0,0,6,0,360,25,1,3,1,3,1,3,3,1,1,3,1,3,1,3,1,3,1,3,3,1,1,3,1,3,1,3,3,1,1,3,3,1,1,3,1,3,1,3,3,1

Für mich ist das alles eine Gedankenspielerei, wäre schön wenn man diese Apps nutzen könnte mit dem Arduino und zumindest power-switch scheint auch open source zu werden beim release.
http://power-switch.eu (//power-switch.eu)

naja, wäre halt schoen bestehendes mitnutzen zu können, da hab ich gestern auch mit jemandem im Powerswitch Forum drüber gesprochen: http://forum.power-switch.eu/viewtopic.php?f=8&t=79 (//forum.power-switch.eu/viewtopic.php?f=8&t=79)

gruß

Yaku

Hallo Yaku,

Sehe ich das richtig, das Timing spielt sich im 1-3ms Bereich ab? Remote bit für bit über das Netzwerk klappt das garantiert nicht, das ist schneller als übliche Ping-zeiten, wenn man nicht grade per cross-over-kabel direkt verbunden ist.

Mit der configurable-Firmata https://github.com/firmata/arduino/tree/configurable (//github.com/firmata/arduino/tree/configurable) könnte man das im Prinzip schon machen - da kann man eine Serie von digitalOut-befehlen mit delays im ms-Bereich als Tasks speichern und in einem Rutsch abspielen. Die Länge der Bitfolge wird dabei nur durch das RAM des Arduinos begrenzt (allerdings mehrere Bytes pro Bit, da ja für jede Zustandsänderung ein Firmata-kommando abgelegt wird). So ein Task kann dabei jeweils ein- oder mehrfach nacheinander laufen. Wenn er nur einmal laufen soll, ist der Speicher direkt im Anschluss daran wieder frei. Da die gesammte Bitfolge vor dem Abspielen komplett übertragen wird, spielt das Netzwerk für das Timing keine Rolle mehr.

Natürlich könnte man damit nur präzise senden. Wenn man Funk-kommandos empfangen wollte, müsste man das Timing auf dem Arduino aufschlüsseln. Die Firmata Digital-in-messages würden zwar vermutlich schnell genug generiert, allerdings ohne jede timing-information, also für diesen Anwendungsfall wertlos.

Ein Beispiel, wie man so einen Task mit der perl-firmata zusammenbaut findet sich (für 1-Wire-kommunikation) hier (ab Zeile 44): https://github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire.pl#L44 (//github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire.pl#L44)

Wenn Du Dich daran versuchen willst und ggf. ein auf FRM basierendes FHEM-modul basteln möchtest, gebe ich Dir gerne alle nötigen Tipps.

Gruß,

Norbert

Zitat von: woody schrieb am Do, 16 Mai 2013 21:45habe refactoring ausprobiert[...]
 Unrecognized character \xC2; marked by <-- HERE after factoring <-- HERE near column 60 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

00_OWX.pm line 9 ist ja im Anfangskommentar der Datei, da steht überhaupt kein code der Fehler haben könnte. Irgendwie scheint die beim Übertragen kapput gegangen zu sein? Auf welcher Plattform läuft das?

Gruß,

Norbert

Zitat von: kaizo schrieb am Mi, 15 Mai 2013 18:34Jetzt noch asynchron, dann ist alles gut.

So ein kleines Update:
Ich habe am refactoring_async weitergearbeitet und einige Bugs gefixed, so dass OWTHERM jetzt tatsächlich asynchron geht. Beim letzten Update ist mir ein Fehler unterlaufen, da habe ich eine gar nicht laufähige Version von OWTHERM commitet (aber gegen eine andere getestet, die den fehlerhaften asynchronen code noch gar nicht aktiv benutzt hat). Naja - dafür läufts jetzt, und man kann seine DS18B20 auch im 5-Sekunden-rythmus abfragen (ok, ich habe es mit 2 Stück getestet, da ging das problemlos. Mit dem synchronen OWX war bei 5-Sekunden Abfrage-intervall das Webinterface auch mit 2 DS18B20 schon ziemlich zäh).

Alles wie gehabt auf GitHub: https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM

Die Firmata-firmware hat auch ein Update bekommen. Damit das ganze nicht aus dem Tritt kommt, wenn viele Devices am 1-Wire-bus hängen und die Requests der verschiedenen Module sich überschneiden wird jetzt mit jedem Firmata-request eine correlation-id mitgeschickt:

https://github.com/ntruchsess/arduino/tree/onewire_id

Installation wie gehabt (bestehendes Firmata-library Verzeichnis komplett ersetzen (inkl. utility-unterverzeichnis). Dann in der Arduino-IDE den Sketch unter Beispiele->Firmata->ConfigurableFirmata auswählen und auf den Arduino hochladen.

Meldet sich mit 'ConfigurableFirmata V_2_05' (Vorher war V_2_04).

Das update der perl-firmata ist abwärtskompatibel und schon ins fhem-svn committet. Der 'refactoring_async'-branch arbeitet mit beiden Firmwareversionen zusammenarbeiten (mit der V_2_05 sollte es aber stabiler laufen).

Über Feedback würde ich mich freuen.

Gruß,

Norbert

P.S.: Um OWCOUNT konnte ich mich noch nicht kümmern, erst musste der asynchrone Modus mal stabil laufen...

Zitat von: ntruchsess schrieb am Fr, 17 Mai 2013 23:51Hallo Yaku,

Sehe ich das richtig, das Timing spielt sich im 1-3ms Bereich ab?

Leider nein, im Mikrosekundenbereich als Beispiel aus HC4M: https://github.com/xkonni/homecontrol4me/blob/master/sketchbook/homecontrol4me_v_1_1/homecontrol4me_v_1_1.pde#L217

Da wird der Delay auf 0,35ms gestellt.

und die RC-Switch baut den Sendecode zusammen mit den anderen Parametern was es für eine Steckdose ist.

https://github.com/r10r/rcswitch-pi/blob/master/RCSwitch.cpp#L347  

hab die RPi lib gelinkt da ich nicht weis wie ich die RC-Switch für Arduino hier verlinken könnte: http://code.google.com/p/rc-switch/downloads/list

Diese Gateways scheinen wenn ich es richtig Verstanden habe auch nur den Delay ein paar Parameter und dann die Codeausgabe die die RC-Switch sonst Onboard generiert zu empfangen.

ZitatRemote bit für bit über das Netzwerk klappt das garantiert nicht, das ist schneller als übliche Ping-zeiten, wenn man nicht grade per cross-over-kabel direkt verbunden ist.

Mit der configurable-Firmata https://github.com/firmata/arduino/tree/configurable könnte man das im Prinzip schon machen - da kann man eine Serie von digitalOut-befehlen mit delays im ms-Bereich als Tasks speichern und in einem Rutsch abspielen. Die Länge der Bitfolge wird dabei nur durch das RAM des Arduinos begrenzt (allerdings mehrere Bytes pro Bit, da ja für jede Zustandsänderung ein Firmata-kommando abgelegt wird). So ein Task kann dabei jeweils ein- oder mehrfach nacheinander laufen. Wenn er nur einmal laufen soll, ist der Speicher direkt im Anschluss daran wieder frei. Da die gesammte Bitfolge vor dem Abspielen komplett übertragen wird, spielt das Netzwerk für das Timing keine Rolle mehr.

Natürlich könnte man damit nur präzise senden. Wenn man Funk-kommandos empfangen wollte, müsste man das Timing auf dem Arduino aufschlüsseln. Die Firmata Digital-in-messages würden zwar vermutlich schnell genug generiert, allerdings ohne jede timing-information, also für diesen Anwendungsfall wertlos.

Ein Beispiel, wie man so einen Task mit der perl-firmata zusammenbaut findet sich (für 1-Wire-kommunikation) hier (ab Zeile 44): https://github.com/ntruchsess/perl-firmata/blob/master/examples/example-onewire.pl#L44

Wenn Du Dich daran versuchen willst und ggf. ein auf FRM basierendes FHEM-modul basteln möchtest, gebe ich Dir gerne alle nötigen Tipps.

Gruß,

Norbert

Interessiert bin ich an beidem, nen Sketch um den Arduino als einen 433mhz gateway laufen zu lassen kompatibel mit dem HCGW,Connair,Intertechno Gateway als auch Firmata Ethernet.

Was auch interessant wäre für FHEM diese Gateways zu unterstützen, momentan habe ich selbst noch keinen 24/7 Server für FHEM allerdings werde ich wenn ich fest in Schweden lebe meinen Mele a2000 dazu machen, http://romanrm.ru/en/a10 , ich hoffe FHEM läuft auf Debian.

Firmata Ethernet ist ja viel universeller und wenn es mit Firmate möglich wäre die Codes so zu Senden und Sensoren auszuprobieren ohne Ständig den Arduino neu mit sketchen bespielen zu müssen wäre das die flexibelste Lösung.

Ich würde wirklich gerne selbst etwas zu den Projekten beisteuern für die ich mich aktuell interessiere, allerdings kann ich bisher nur ein paar Elemente im Code ändern aber selbst nichts schreiben, evtl. hilft es einigen wenn ich meine Chinashoppinglinks zeige da man wenn man die 4-6 Wochen Lieferzeit(Schweden meist nur 2,damn Zoll) abwarten kann günstigst an die Komponenten kommt.

Transmitter: http://www.ebay.com/itm/New-1pcs-433Mhz-RF-Transmitter-And-Receiver-Kit-For-Arduino-Project-WST-/390562575788?
Arduino Uno: https://www.fasttech.com/products/0/10000015/1001700-arduino-uno-r3-rev3-development-board
Ethernetshield: https://www.fasttech.com/products/0/10000007/1000701-ethernet-shield-with-wiznet-w5100-ethernet-chip
Dupontkabel Male-Female: http://www.ebay.com/itm/350769139083

Wenn die Configurable Firmata Mikrosekunden kann wäre da perfekt, erstmal bis man Funkwetterstationen empfangen möchte(braucht ja den Rückkanal) ohne für 200€ für die rxfcom lan :P, aber jetzt wird das zuviel im Post... (gestern auf dieses Projekt gestossen: http://wmrx00.sourceforge.net/index.html)
mit diesem shield: http://www.osengr.org/WxShield/Web/WxShield-V1.html

gruß

Yaku

ZitatDiese Gateways scheinen wenn ich es richtig Verstanden habe auch nur den Delay ein paar Parameter und dann die Codeausgabe die die RC-Switch sonst Onboard generiert zu empfangen.[...]
Firmata Ethernet ist ja viel universeller und wenn es mit Firmate möglich wäre die Codes so zu Senden und Sensoren auszuprobieren ohne Ständig den Arduino neu mit sketchen bespielen zu müssen wäre das die flexibelste Lösung.[...]Wenn die Configurable Firmata Mikrosekunden kann wäre da perfekt

Richtig erkannt, nur ist die Firmata ohne eine dafür spezialisierte Feature-klasse gerade wegen Ihrer Flexibilität leider nicht tauglich Timing im Microsekunden-bereich zu machen. Wenn man den Firmata-scheduler benutzt, dann versucht die Firmata während der delays andere Messages oder Sensoren zu bedienen. Wenn das dann länger dauert als das gewünschte Delay ist das Timing futsch.

Das muss man dann so wie bei den genannten Gateways machen: Mit einer (oder mehreren) Firmata-message(s) das komplette Funk-kommando übertragen und dann in einem Rutsch abspielen lassen. Im Prinzip gar nicht mal so schwer - ich würde vorschlagen dafür die existierende rcswitch-library herzunehmen (oder substanziell Anleihen dort nehmen) und in eine Firmata-Feature-klasse zu kapseln. Ich benutze selber aber keine 433MHZ basierten Sensoren oder Aktoren und habe auch erst mal genug Baustellen, wenn Dich das also interessiert, dann müsstest Du auch programmieren lernen... Du könntest als Anfang auch erst mal ein Proposal für die zu verwendenen Firmata-messages machen (und ggf. auf Firmata.org veröffentlichen). Im saubernen Design des Protokolls steckt sicher genauso viel Arbeit, wie nachher in der eigentlichen Implementierung...

Gruß,

Norbert

Hallo,
habe mal mit dem aktuellen refactoring getestet. Folgende fehlermeldung bekomme ich:

2013.05.18 16:20:57 3: Arduino: port 3030 opened
2013.05.18 16:20:57 1: Error:Modul 00_OWX deactivated:
 Unrecognized character \xC2; marked by <-- HERE after ing_async <-- HERE near column 66 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.

2013.05.18 16:20:57 0: Unrecognized character \xC2; marked by <-- HERE after ing_async <-- HERE near column 66 at ./FHEM/00_OWX.pm line 9, <$fh> line 65.


Ist dieser Fehler schon bekannt?

Grüße

woody

Hallo zusammen,

ich hab folgendes Relaismodul:
http://www.ebay.com/itm/New-16-Channel-12V-Relay-Module-For-Arduino-UNO-MEGA-2560-R3-ATMEL-ATMEGA-1280-/281037857443?pt=LH_DefaultDomain_0&hash=item416f2962a3 (//www.ebay.com/itm/New-16-Channel-12V-Relay-Module-For-Arduino-UNO-MEGA-2560-R3-ATMEL-ATMEGA-1280-/281037857443?pt=LH_DefaultDomain_0&hash=item416f2962a3)

an einem Arduino Mega 2560 angeschlossen.
Alle Relais funktionieren nur die an Pin 47,39,31 und 23 nicht:
z.B:
define KellerKuecheHoch FRM_OUT 47
define EGSpielHoch FRM_OUT 39

Ich hab aber in der Pinbelegung nicht besonders für diese Pins gefunden.
Könnte es ein Bug sein?
Die Pins scheinen auch irgendwie in Wechselwirkung mit dem Nachbarpin zu stehen,
wenn ich z.B. versuche Pin 39 zu schalten funktioniert Pin 38 (oder 40 weiß nicht mehr genau) nicht mehr.

Noch was,
die Relais-Platine ist Low-Level input .
Könnte man die Pins in der Arduinofirmware standradmäßig auf HIGh schalten?
Damit Sie nicht zuerst geschaltet werden?

Grüße
Thomas

Zitatdie Relais-Platine ist Low-Level input .
Könnte man die Pins in der Arduinofirmware standradmäßig auf HIGh schalten?

Hallo Thomas,

die Vorgabewerte kannst du im Configurable-Firmata Sketch ab Zeile 94 (//github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L94) so ändern, wie Du es benötigst.
Wegen der nicht schaltbaren Pins habe ich auch erst mal keine Idee, aber auch keinen MEGA2560 um das auszuprobieren. Was taucht denn im FHEM-webclient in der Übersicht des Firmatadevices unter input-pins und output-pins auf?

Gruß,

Norbert

Hallo Norbert,

was muss ich denn da ergänzen?
So in etwa:

     // sets the output to 0, configures portConfigInputs
      Firmata.setPinMode(i, OUTPUT);
      digitalWrite(i, HIGH);

DAnke
Thomas

Hallo Norbert,

nachdem ich:
digitalWrite(i, HIGH);
eingefügt habe, funktioniert es schon besser,
aber noch nicht optimal.

Sobald nun die Verbindung mit FHEM hergestellt wurde,
gehen die Pins teilweise auf LOW und werden dann wieder korrekt auf HIGH gesetzt.
Das dauert aber einige Sekunden bei 32 Pins.

Kann man die Pins beim Initialiesieren auf High setzen?

Grüße
Thomas

Hallo Norbert,
habe heute mal den Stand von https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM (//github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEM)eingespielt. Funktioniert prima mit 6 Stück DS18B20 im 5s Takt und einem DS2406. Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

Zitat von: ThomasL schrieb am Di, 21 Mai 2013 16:08Kann man die Pins beim Initialiesieren auf High setzen?

Du meinst FRM-Seitig? Beim Wiederverbinden macht löst FRM erst mal einen SystemReset (Softwareseitig, nur die Firmata) auf dem Arduino aus. Anschließend werden alle Pins der Reihe nach wieder so konfiguriert, wie sie vorher waren.
Das kurz auf 'LOW' gehen passiert Arduino-seitig. In der DigitalOutputFirmata-feature-class, methode handlePinMode werden die Pins per Default auf Low gesetzt. D.h. da wenn Du es da änderst, dann kannst Du den 'digitalWrite' Aufruf aus der systemReset-methode der ConfigurableFirmata.ino wieder herausnehmen. Mach doch auf Github ein Issue auf und wünsch Dir, dass man den Default-wert in der DigitalOutputFirmata-klasse konfigurierbar machen soll, oder besser noch: Wenn Du das vernünftig implementierst (so dass man den Default aus dem Sketch heraus z.B. über den Constructor setzen kann), clone das Repository und mache einen pull-request mit den Änderungen gegen den 'configurable'-branch.

P.S.: es gibt mal wieder ein Update: im refactoring_async branch geht jetzt 'get <owx_device> present' und 'get <owx_busmaster_device> alarms'

Gruß,

Norbert

Zitat von: det. schrieb am Mi, 22 Mai 2013 18:51Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

Danke für das Feedback. So allmählich reift die Sache...
Hab grade gemerkt, dass pah irgendwann das 'buspower'-attribut entfernt hat, da kann OWX_FRM das natürlich auch nicht mehr setzen. Und ohne Buspower geht der Bus zwischen den Anfragen auf Low, d.h. die DS18B20 gehen nach dem Triggern der Konvertierung erst mal wieder aus so dass beim Auslesen kein aktualisierter Wert da sein kann.

Gruß,

Norbert

ZitatDu meinst FRM-Seitig? Beim Wiederverbinden macht löst FRM erst mal einen SystemReset (Softwareseitig, nur die Firmata) auf dem Arduino aus. Anschließend werden alle Pins der Reihe nach wieder so konfiguriert, wie sie vorher waren.
Das kurz auf 'LOW' gehen passiert Arduino-seitig. In der DigitalOutputFirmata-feature-class, methode handlePinMode werden die Pins per Default auf Low gesetzt. D.h. da wenn Du es da änderst, dann kannst Du den 'digitalWrite' Aufruf aus der systemReset-methode der ConfigurableFirmata.ino wieder herausnehmen. Mach doch auf Github ein Issue auf und wünsch Dir, dass man den Default-wert in der DigitalOutputFirmata-klasse konfigurierbar machen soll, oder besser noch: Wenn Du das vernünftig implementierst (so dass man den Default aus dem Sketch heraus z.B. über den Constructor setzen kann), clone das Repository und mache einen pull-request mit den Änderungen gegen den 'configurable'-branch.

Hallo Norbert,

ich kenne mich noch nicht so gut aus.
Die Stelle hatte ich vorher schon gefunden und mal geändert.
Dann mit Ardunio 1.0.4 den Sketch neu überprüft und geladen.
Hat aber nicht geändert.
Muss ich die anderen Klassen auch irgendwie neu kompilieren?
Oder passiert dies automatisch mit?

Danke
Thomas

Hallo Norbert,

erstmal vielen Dank für die super Arbeit. Ich habe über ethernet / firmata meine Alarmanlage angeknubbelt. Das funktioniert prima.
Ich habe im Haus fünf DHT21 verstreut, welche ich auch gerne über firmata auslesen würde. Wirst Du das weiter entwickeln?

Grüße Chris

Zitat von: ThomasL schrieb am Mi, 22 Mai 2013 20:19Muss ich die anderen Klassen auch irgendwie neu kompilieren?
Oder passiert dies automatisch mit?

Man kann ein komplettes Neucompilieren erzwingen, indem man in der Konfiguration ein anderes Board auswählt, baut und wieder zum eigentlich gewünschten Board zurückwechselt.

Gruß,

Norbert

Zitat von: cberl schrieb am Mi, 22 Mai 2013 22:39Ich habe im Haus fünf DHT21 verstreut, welche ich auch gerne über firmata auslesen würde. Wirst Du das weiter entwickeln?

für den DHT11 habe ich vor ein paar Wochen ein Firmata-Custom-feature geschrieben, Ein Perl-Beispiel, wie man damit kommuniziert findet sich hier. Vieleicht magst Du beides auf den DHT21 umschreiben? Dann könnte ich das recht fix in ein FRM-Client-modul packen.
Ich hab selber keine DHT21 und bin auch grade mit dem Refactoring vom OWX hinreichend ausgelastet.

Gruß,

Norbert

Zitat von: det. schrieb am Mi, 22 Mai 2013 18:51Hallo Norbert,
habe heute mal den Stand von https://github.com/ntruchsess/fhem_owx/tree/refactoring_async/fhem/FHEMeingespielt. Funktioniert prima mit 6 Stück DS18B20 im 5s Takt und einem DS2406. Die Thermometer wollten dringend den Modus mit 5V, passiv zeigen sie 85°C.

so, wieder mal ein Update an gleicher Stelle...

OWCOUNT geht jetzt asynchron - konnte ich mit dem ATiny-basiertem Board das det mir freundlicherweise geschickt hat erfolgreich testen. Mit diesem Board gibt es zwar (noch) Fehlermeldungen, die allerdings daher kommen, das die ATiny-emulation nur den Zähler, aber nicht das 1K-memory des DS2423 emuliert.

Kann das jemand mit einem 'richtigen' DS2423 testen?

OWTHERM hat auch ein paar Fixes abbekommen und geht jetzt weitestgehen. Nur die Messwerte hängen hin und wieder eine Messung hinterher (weil das asynchrone Auslesen öfter mal die Konvertierung überholt).

Gruß,

Norbert

Hallo zusammen
Ich habe soeben meine ersten Gehversuche mit einem Arduino UNO R3(Standard Firmata) gemacht und ihn problemlos als USB Device mit FHEM verbunden.
Ich würde den UNO R3 gerne über Ethernet ansprechen, damit ich meinen Klingeltaster einbinden kann. Am UNO R3 hängt ein ENC28J60 EthernetShield.

Meine Frage dazu:
Gibt es schon einen Firmata-Sketch, der meinen ENC28J60 EthernetShield ansprechen kann? Den bisherigen (falls überhaupt möglich) zu übersetzen, traue ich mir mangels Kentnissen (noch) nicht zu.

Danke für die Hilfe.
Gruss Dani

hallo norbert,

ich habe gerade mal versucht dein DHT11 beispiel für den ultraschall sensor anzupassen und habe das problem ich nicht weiss wie ich damit umgehen muss das ich zwei pins zum ansteuern des sensors brauche. lässt sich das überhaupt so direkt als bedingung abbilden oder  muss das der anwender dann einfach wissen ?

gruss
  andre

Zitat von: eppi schrieb am Fr, 24 Mai 2013 18:52Gibt es schon einen Firmata-Sketch, der meinen ENC28J60 EthernetShield ansprechen kann?

Hallo Dani,
leider gibt es noch keinen Firmata-sketch für den ENC28J60. Ist auch nicht so trivial - ich habe jedenfalls noch keine Arduino-library für diesen Chip gefunden, die eine echte TCP/IP-Socketverbindung unterstützen würde. Die Beispiele, die ich gefunden habe (vornehmlich Webserver) haben immer alles in ein einzelnes Packet gepackt, das reicht aber nicht um einen zuverlässigen Stream zwischen Arduino und FHEM zu realisieren. Das liegt primär daran, das der Chip selbst nicht mehr kann und wesentliche Teile des IP-protokolls in Software realisiert sein müssten.

Wenn Du kurzfristig Firmata über Ethernet einsetzen willst, dann kauf Dir ein WIZ5100-basiertes Shield (so eines wie das Standard-ethernetshield halt). Der Chip hat komplette IP-unterstützung schon in Hardware, die zugehörige Library ist recht schlank und trotzdem deutlich leistungsfähiger als die für den ENC28J60. Oder steig tiefer in die Materie ein und bringe z.B. den µIP-Stack auf dem Arduino zum Laufen.

Gruß,

Norbert

Zitat von: justme1968 schrieb am Fr, 24 Mai 2013 20:40ich habe gerade mal versucht dein DHT11 beispiel für den ultraschall sensor anzupassen

Hallo Andre,

prima :-)! Ich würde erst mal einfach damit anfangen die Pins hardcodiert festzulegen und die Sensorwerte in der report-methode zu ermitteln und als Sysex-message (auch erst mal als als 'Reserved command' wie im DHT11-example) abzuschicken. Dazu dann mal ein perl-beispiel umd das auch zu empfangen.
Wenn das erst mal läuft sollte man sich natürlich noch ein paar mehr Gedanken über das Protocoll drumrum machen - Um die 2 Pins zu configurieren solltest Du erst mal eine passendes config-message-format definieren. In der Message, die man in report abschickt sollte natürlich auch irgendwie codiert sein, dass es ein Messwert vom Ultraschallsensor ist. (Lass Dich dazu mal von den Proposals auf firmata.org oder den schon standartisierten Firmata-messages z.B. für I2C inspirieren). Mein Vorschlag wäre für eher exotische Sensoren alles weiter unter 'RESERVED COMMAND'-sysex-message laufen zu lassen, dann in den 14 bits nach dem 'RESERVED COMMAND' einen eigenen Wert für jeden Sensortyp abzulegen, die darauffolgenden 7 bits als sensorspezifisches Commando zu nutzen und anschließend die Nutzdaten zu übertragen. Wenn man das einheitlich für alle Sensoren so macht, dann wäre die Behandlung in Perl genauso einheitlich abzuwickeln und es wäre sehr einfach ein relativ generisches FHEM-modul für unterschiedlichste Sensoren, die jeweils nur einen analogen Messwert liefern, zu schreiben.

Gruß,

Norbert

Hallo Norbert
Danke für deine Einschätzung!

Zitat....dann kauf Dir ein WIZ5100-basiertes Shield

Habe mir eben einen bestellt! Sobald er hier ist werde ich probieren und Feedback geben.

Cooles Projekt, herzlichen Dank für wertvolle Arbeit!
Gruss Dani

ZitatOder steig tiefer in die Materie ein und bringe z.B. den µIP-Stack (//en.wikipedia.org/wiki/UIP_(micro_IP)) auf dem Arduino zum Laufen.

Gruß,

Norbert

Wenn etwas für den Atmel 328 portiert ist ist es somit noch nicht automatisch fuer den Arduino nutzbar ?
Nein ich habe selbst nur w5100 und kein interesse etwas mit uIP zu machen aber ich war interessiert und habe das hier gefunden:
http://code.google.com/p/avr-uip/ (//code.google.com/p/avr-uip/)

fragend schaut

Yaku

Zitat von: Yaku schrieb am Sa, 25 Mai 2013 10:02Wenn etwas für den Atmel 328 portiert ist ist es somit noch nicht automatisch fuer den Arduino nutzbar ?[...]habe das hier gefunden:
http://code.google.com/p/avr-uip/

Hallo Yaku,

vielen Dank für den Hinweis, da bin ich noch nicht drüber gestolpert. Klar, das sollte sich tatsächlich mit geringem Aufwand für den Arduino nutzen lassen!

Gruß,

Norbert

noch eine kleine versändiss frage:

im report() des DHT11   features sendest du nach dem reserved command eine 7. auf der perl seite liest du dort den pin aus. müsste statt der hard codierten 7 nicht wirklich der pin gesendete werden ?

gruss
  andre

Zitat von: justme1968 schrieb am So, 26 Mai 2013 12:49müsste statt der hard codierten 7 nicht wirklich der pin gesendete werden ?

Hallo Andre,

jetzt wo Du's sagst merk ich, dass ich im März vergessen habe meinen letzten commit auf github zu pushen... die '7' ist natürlich ein Tippfehler. Die Fehlerbereinigte Version ist jetzt auf Github aktualisiert

Gruß,

Norbert

so. eine aller erste version läuft und ich kann die daten mit dem perl test programm lesen.ich konnte aber nicht die NewPing library verwenden sondern habe den sensor direkt von hand angesteuert. die library liefert mir nur 0 statt einer entfernung. gibt es einschränkungen bezüglich timern oder interupts mit firmata ?

gruss
  andre

Zitat von: justme1968 schrieb am So, 26 Mai 2013 17:39gibt es einschränkungen bezüglich timern oder interupts mit firmata ?

Die Firmata selbst benutzt keine Interrupts oder Timer explizit. Im Zweifelsfall würde ich für die zeitkritschen Codezeilen aber sowieso die Interrupts disablen (schau z.B. mal wie das in der OneWire-library gemacht wird).

Gruß,

Norbert

Hallo Leute,
leider bin ich jetzt mit den ganzen sketches und owx/frm versionen durcheinander gekommen.
Kann mir mal einer vieleicht sagen was mit wem läuft?
welcher arduino-sketch läuft mit welcher owx-version?

Vieleicht auch mit links?

Viele Grüße und Dank im Vorraus

woody

PS: verwende einen Arduino uno mit wiznet board, DS1820 als Sensoren.

Zitat von: justme1968 schrieb am So, 26 Mai 2013 17:39ich konnte aber nicht die NewPing library verwenden

Hallo Andre,

muss man zum messen mehr machen als einen Pin An + Auschalten und anschließend am anderen Pin per 'pulseIn' die Zeit messen? Wenn ja, dann wäre ein Ansatz auch das pulseIn-protocoll (siehe Proposal und Beispielsimplementierung) als Firmata-feature-klasse zu implementieren und den Rest remote zu steuern. Man müsste halt die Folge 'Pin an -> Pin aus -> PulseIn' als Task schedulen (siehe mein Beispiel hier) um das Timing zu garantieren, es hätte halt den Vorteil, das (sobald PulseIn in der ConfigurableFirmata aufgenommen wird) man mit einer 'StandardFirmata' auskäme und der Rest im FHEM-modul abläuft.
Eine Ultraschall-ping-feature-klasse hätte halt den Vorteil vom Protokoll her etwas schlanker zu sein (dafür aber vermutlich ein bischen mehr Flash Speicher zu brauchen) und fortlaufende schnelle Messungen per report-methode zu ermöglichen. Nur denke ich, dass man grade letzteres im Hausautomationsbereich eher nicht benötigt.

Gruß,

Norbert

Zitat von: woody schrieb am Mo, 27 Mai 2013 14:34Kann mir mal einer vieleicht sagen was mit wem läuft?[...]uno mit wiznet board

Hallo Woody,

OWX mit Arduino am besten hiermit: fhem_owx Branch refactoring bzw. direkt als zip file.
Noch in Entwicklung (da mache ich regelmäßig updates), OWTHERM und OWCOUNT laufen damit bei mir recht stabil fhem_owx Branch refactoring_async bzw. auch als zip file. Fragt DS18B20 und DS2423 asynchron ab. Damit bleibt die Weboberfläche auch bei kürzeren Abfrageintervallen recht flott.

Die EthernetClientFirmata ist im Prinzip immer noch die gleiche (aus dem Branch 'configurable_ethernet') bzw. auch als zip file. Da gibt's aber bald mal ein Update, die nächsten Tage ist schlechtes Wetter und ich wollte mich mal um eine Überarbeitung des Reconnects kümmern.

Gruß,

Norbert

hallo norbert,

im prinzip ist es das. den impuls los schicken und mit pulsein auf das echo warten.

allerdings habe ich bemerkt das zumindest bei meinem sr04 die messergebnisse deutlich stabiler und genauer sind wenn man noch ein wenig aufbereitung rein steckt. d.h. eindeutige ausreißer weg schmeißen eventuell den rest klassifizierrn und auswählen und dann über den rest mitteln. de anzahl der messungen kann dann durchaus 20 bis 50 betragen aus denen dann das ergebnis erzeugt wird. da die temperatur auch fast 10% einfluss auf das ergebniss hat sollte man die auch berücksichtigen. da man die idealer weiß gleich mit erfasst ist halt wieder die frage wie intelligent man den sensor macht. die glich ist es ja schade wenn man das auf aufbereiten dann doch auf dem server macht. ich würde am liebsten sogar die bestimmung der füllmenge aus dem füllstand noch auf arduino machen und nicht in fhem.

ich schaue mir deinen vorschlag aber auf jeden fall mal an. schließlich ist die zeit ja nur nur beschränkt.

gruss
   andre

Servus Miteinander,

ich bin hier auf diesen Thread gestoßen und bin leider etwas verwirrt.

Ich habe einen Arduino Micro (unter Anderem)
und einen Raspberry.

Ich möchte den Micro über USB an den Raspberry anbinden und im einfachsten Fall
nur Temperaturen Messen.

Im etwas komplexeren Fall wäre da noch ein BMP085 Luftdrucksensor ...

Was ich jetzt nicht ganz kapiere, welche von den StandardFirmata Versionen
ich denn da jetzt benutzen kann.

Und dann wäre da noch ein generelles Problem den Arduino Micro betreffend.
Wenn ich die ganz normale StandardFirmata aus der IDE benutze und das Testtool
anwerfe bekomme ich vom Arduino Micro nichts zurück wenn ich das Selbe mit meinem
Arduino Uno mache klappt es.
Der Micro ist ja etwas abgespeckt was die USB Seite angeht muss ich da irgend
etwas spezielles machen?

Danke & Gruss
   Ekkehard

 

Zitat von: eburkon schrieb am Sa, 01 Juni 2013 10:16Was ich jetzt nicht ganz kapiere, welche von den StandardFirmata Versionen
ich denn da jetzt benutzen kann.

Temperaturen messen kannst Du z.B. über 1-Wire (DS18B20-chips gibt's günstig auf eBay). 1-Wire-support ist in der Configurable-Firmata enthalten. Der BMW085-Sensor wird über I2C angebunden, der wäre auch mit der StandardFirmata (so wie sie bei der Arduino-IDE dabei ist) ansteuerbar. Ein passendes FHEM-modul müsste man aber noch schreiben. Da könntest Du Dich am FRM_LCD-modul orientieren, das verwendet auch I2C.

Zitat von: eburkon schrieb am Sa, 01 Juni 2013 10:16Und dann wäre da noch ein generelles Problem den Arduino Micro betreffend.

mit dem Micro habe ich noch nichts gemacht. Steht auch nicht eplizit in der Boards.txt. Stell die Frage am besten auf der Firmata-developer-mailingliste

Gruß,

Norbert

Servus Norbert,

vielen Dank. Jetzt bin ich schon mal ein paar Schritte weiter.

Habe die Configurable Firmata auf den Arduino Micro geladen.

Mit FRM_OUT kann ich schön die LED auf Pin 13 schalten.

OWX erkennt auch ganz brav den Sensor. Nur kann FHEM noch kein Temperaturen lesen.
Der Wert bleibt immer auf 0 und und der ERRCOUNT zählt langsam hoch.
Im Log finde ich aber keine Meldungen, die mir etwas sagen würden.

Wenn ich einen simplen 1-Wire Scetch aus den Beispielen lade wird die Temperatur auf dem
Arduino korrekt angezeigt. Also vermute ich mal dass was auf dem Weg Firmata -> Fhem
fehlschlägt.

Wo könnte ich denn jetzt am besten mit dem Debugging ansetzen?

Gruß
   Ekkehard

Hi Norbert,
vielen Dank für deine Antwort, aber ich meinte welche Firmata Version auf den Arduino muß.
Ich habe momentan die configurablefirmata drauf und wenn ich im FHEM schaue wird die Version 2_05 angezeigt.
In der Firmata.h steht aber das es die Version 2 5 3 ist. Laut der ide benutzt er zum compilieren auch die richtige, zumindest vom Pfad her.
Trotzdem bekomme ich im serial monitor "unknown pinmode" angezeigt. Das meldet mir Fhem auch. Bild im Anhang. Die logdatei gibt leider keine genauere Fehlermeldung her.

Viele Grüße

woody

Hallo Woody,

das mit der Version ist ok so. In Firmata.cpp wird der Versionnummernstring nur aus Major (2) und Minor (5) zusammengebaut, ergibt dann 2_05. Point-releases (Änderung der Versionsnummer auf der 3. Stelle) enthalten ausschließlich Bugfixes und Änderungen, die das Protokoll unverändert lassen. Die 2_05 enthält eine für das asynchrone OWX wichtige Anpassung.

Die 'unknown pinmode' Fehlermeldung kommt denke ich (beim Reset des Arduinos) von der systemResetCallback-routine, die die Pins ab Nummer '0' anfängt auf Analog bzw. Output zu stellen, tatsächlich aber Pin 0 und 1 von der Seriellen Schnittstelle belegt sind. Wenn Du in die for-schleife mit 2 beginnen läßt ist sollte der Fehler weg sein. Ist aber rein kosmetisch.

Gruß,

Norbert

Hi Norbert,
ja das wars....Fehlermeldung ist weg.

Steuerst du auch ein LCD über i2c an der Firmata ? Ich bekomme irgendwie keine textausgabe aus fhem hin.

Habe das LCD so eingebunden:

fhem.cfg
.......
define LCD1 FRM_LCD i2c 16 2 63
attr LCD1 room Firmata
.......

Hab ich da einen Fehler in der config? Die i2c Adresse stimmt, und es ist ein 16x2 LCD mit i2c controller.

Viele Grüße

woody

Hallo,
kann mir mal jemand ein Beispiel seiner fhem.cfg schicken?
Bekomme das mit der Ausgabe auf das Display irgendwie nicht hin.

Viele Grüße

woody

Hallo zusammen,
ich habe etwas den Überblick verloren, bzw. wäre vielleicht auch was fürs Wiki.
Funktioniert jetzt Firmata mit ethernet und Onewire?
Wenn ja wie? Gibt es eine Anleitung?

Am 1-Wire (bzw. an der Unterstützung aller OWX-Module mit FRM) bin ich grade wieder am arbeiten. OWTHERM geht recht gut, OWCOUNT, OWID und OWSWITCH auch. OWAD und OWMULTI machen noch Schwierigkeiten.

Der aktuelle Stand findet sich hier: (//github.com/ntruchsess/fhem_owx)

Es ist leider so, dass sich der Arduino leicht aufhängt, wenn man zu viele 1-Wire Devices zu oft abfragt. Da geht Ihm wohl der Speicher aus. Ich versuche das dahingehend abzusichern, dass das OWX_FRM-modul darauf achtet bei Ausstehenden Antworten nicht munter weiter Requests zum Arduino geschickt werden bis gar nichts mehr geht.

Der normale I/O geht mit den ganzen FRM_xxx-modulen geht gut, dafür muss der Arduino auch nicht so zeitkritische Dinge wie 1-Wire bustiming tun.

Vieleicht probiere ich mal einen 1-Wire-Busmaster über i2c an den Arduino zu hängen. I2C wird vom Arduino in Hardware unterstützt, da müssen eigentlich nur Daten durchgereicht werden (1-Wire auf dem Arduino ist eine reine Softwarelösung). In Verbindung mit der Ethernetschnittstelle könnte das dann doch ganz nützlich sein.

Nur um die EthernetFirmata konnte ich mich in letzter Zeit leider gar nicht kümmern.

Gruß,

Norbert

P.S. die OWX-module an sich laufen asynchron mit einem Seriellen Busmaster (DS2480) jetzt ganz prima, ich habe grade einen Test mit je einem DS2401, DS2406, DS2413, DS2416, DS2438, DS2450 und DS18B20, alle am gleichen Bus im 5-Sekundentakt abgefragt, laufen. Da läuft das tadellos...

Hallo,

ist es eigentlich möglich, mehrere Arduinos über Ethernet mit Firmata zu betreiben?
In Fhem könnte könnte man ja mehrere Ports, also einen pro Arduino öffnen.
Wie mache ich das aber mit den Pin`s? So kann z.B. FRM_IN 7 doch nur einmal belegt werden.
Oder wie verhält sich das?

Schonmal Danke. Chris

ja, das geht ohne weiteres. Einfach mehrere FRM-Devices (eines je Port bzw. Arduino) definieren. Natürlich muss man dann für jeden Arduino in der EthernetFirmata individuell den gewünschten Zielport anpassen.
Bei den Pin-spezifischen Devices muss man dann per IODev-Attribut das zugehörige FRM-Device referenzieren. Gibt es nur ein FRM-Device, dann findet sich das automatisch.

Ich weiß, grundsätzlich ginge das auch über einen einzigen Port, die Arduinos müssten sich dann mit einer individuellen Kennung identifizieren. Darauf ist derzeit halt weder die Firmata-firmware noch das FRM-modul eingerichtet. (Contributions encouraged...)

Gruß,

Norbert

Hallo Norbert,

schön, das zu hören. Ich habe das aber nicht ganz gerafft.
Wie kann ich auf das IODev-Attribut refenzieren?

Der erste würde so aussehen:
define FIRMATA FRM 3030 [global]
define Arduino1_IN7 FRM_IN 7

für den zweiten Arduino:
define FIRMATA2 FRM 3031 [global]
define Arduino2_IN7 ??FRM_IN?? ?7?

Grüße, Chris

guckst Du hier: attr IODev (//fhem.de/commandref.html#IODev)

#für den ersten Arduino:
define FIRMATA FRM 3030 [global]
define Arduino1_IN7 FRM_IN 7
attr Arduino1_IN7 IODev FIRMATA

#für den zweiten Arduino:
define FIRMATA2 FRM 3031 [global]
define Arduino2_IN7 FRM_IN 7
attr Arduino2_IN7 IODev FIRMATA2

Viel Erfolg :-),

Norbert

Zitat von: ntruchsess schrieb am Mo, 15 Juli 2013 23:35für jeden Arduino in der EthernetFirmata individuell den gewünschten Zielport anpassen

und bitte nicht vergessen die MAC Adresse an min einer Stelle auch zu ändern um doppelte MACs im Netzwerk zu vermeiden.

@Norbert, wie hoch sind die Chancen auf ein Firmatamodul das die serielle Schnittstelle unterstützt ?
Hintergrund : Ich habe an einem Arduino an dessen seriellen Schnittstelle einen Ultraschallsensor (URM37 -> http://www.dfrobot.com/index.php?route=product/product&product_id=53) hängen der den Füllstand in meinem Heizöltank ermittelt. Die Kommunikation zwischen Arduino und Sensor ist recht primitiv : Vier Byte zum Sensor schicken und es kommen auch wieder vier Byte als Ergebnis zurück (Also kein echtes serielles Protokoll bei dem zig Regeln zu beachten sind)
Ich würde da gerne selbst etwas zu diesem Thema beitragen, dazu benötige ich allerdings deinen Rat welches bestehende Firmata und FHEM Modul sich gut als Vorlage dafür eignet.  

Unterstützung für (Software-)Serial fehlt in Firmata leider (noch) (//github.com/firmata/arduino/issues/5).

Entweder schreibst Du für ein spezielles Firmata-Feature für Deinen Sensor (so dass nur das eigentliche Ergebniss übertragen wird), oder Du machst Dir Gedanken, wie man die Serielle Kommunikation generisch im Firmata-protocoll abbildet. Grundsätzlich sind ja (bei Sysex-messages) Firmata-Messages variabler Länge möglich - damit sollte sich ein serielles Protokoll ohne sinnlosen Overhead definieren lassen. Wenn Du letzteres angehen magst, dann solltest Du ein Proposal auf http://www.firmata.org/wiki/Proposals (//www.firmata.org/wiki/Proposals) schreiben und in o.g. Issue referenzieren (oder dort erst mal diskutieren). Um eine Implementierung in die ConfigurableFirmata aufgenommen zu kriegen musst Du das Firmata/aduino (//github.com/firmata/arduino)-repository auf Github clonen, das Feature in einem neuen Branch implementieren und dann einen Pull-request gegen den Configurable-Branch machen. Als Vorlage kannst Du z.B. das OneWireFirmata-Feature (//github.com/firmata/arduino/blob/configurable/utility/OneWireFirmata.cpp) nehmen (das verwendet u.a. Sysex-messages und die Encoder7Bit-Klasse, die man hernehmen sollte, wenn man auch längere Datenblöcke in eine Sysex-message packen will).
Die Gegenseite (in Perl) solltest Du erst mal ohne FHEM nur mit der perl-firmata (//github.com/ntruchsess/perl-firmata) prototypisch implementieren bevor Du Dich an ein echtes FHEM-modul machst.

Gruß,

Norbert

Das funktionierte auf Anhieb. Vielen Dank für die Hinweise. Chris

Zitat von: ntruchsess schrieb am Fr, 24 Mai 2013 22:43leider gibt es noch keinen Firmata-sketch für den ENC28J60.[...]Oder steig tiefer in die Materie ein und bringe z.B. den µIP-Stack auf dem Arduino zum Laufen.

So mal ein Update dazu in eigener Sache:

Ich hab eine Wrapper-library um den µIP-Stack von Adam Dunkels geschrieben, mit der man mit dem Arduino jetzt auch richtige persistente Socket-verbindungen mit einem ENC28J60-Shield machen kann. Ist noch nicht 100% stabil, aber das erste Beispiel (ein Server, der alle Eingaben als Echo wieder zurückschickt) geht schon. Zu verwenden fast exakt so, wie die Stock-Ethernet-library :-)

eine Firmata-Version für ENC28J60 rückt damit in greifbare Nähe!

Code findet sich wie immer auf GitHub.

Gruß,

Norbert

Hallo Norbert,

mittlerweile habe ich wieder etwas mehr Zeit zum Testen, folgendes ist mir noch aufgefallen:
-FRM benötigt unterschiedlich lange, bis sich der Arduino gemeldet hat. Bis dahin am besten OWX nicht definieren
-Wenn das beim shutdown-restart oder reread nicht richtig geklappt hat und man versucht, den FRM wieder zu löschen und neu zu definieren kommt die Meldung:"FRM: Can't open server port at 3030: Address already in use"
Abhilfe ist hier ein shutdown-restart.

Da mein Arduino mittlerweile im Keller steht ist der Weg immer recht weit, den Arduino über RESET zum reden zu bringen. Wenn RESET gedrück ist meldet sich die Firmata bei FHEM und alles kann weitergehen.

Gibt es einen Workaround hierzu?
Kann nicht FRM eine Variable setzen, so daß OWX erst warten muß, bis FRM/Arduino/Firmata sich gemeldet hat?

Gruß
Kai

@Kai, das Prob hatte ich auch. Meine Lösung : ich habe einen Pin des Arduino ( Pin 5 ) direkt mit 5 V verbunden und frage ihn in fhem auf HIGH ab und erst dann definiere ich OWX
define go_myow notify Firmata_IN_5:reading.* { if (!$value{myonwire}) {fhem("define myonwire OWX 7");;}}

Zitat von: kaizo schrieb am So, 28 Juli 2013 18:21Gibt es einen Workaround hierzu?
Kann nicht FRM eine Variable setzen, so daß OWX erst warten muß, bis FRM/Arduino/Firmata sich gemeldet hat?

Hallo Kai,

teste doch mal das asynchron überarbeitete OWX, das sollte kein Problem damit haben schon definiert zu sein, bevor der Arduino sich an FRM verbunden hat.

Bin allerdings erst ab 08.08. wieder in der Lage irgendwas dran zu machen. Vorher ist Urlaub angesagt.

Gruß,

Norbert

Hallo Norbert,

also die asynchrone Version geht schon besser, aber wenn zum Start das FRM nicht definiert ist gibt das OWX zwar keine direkte Fehlermeldung, aber die Daten von den DS1820 sind nicht ok. Auch ein "get OWX devices" ergibt kein Ergebnis, FHEM springt einfach zum Hauptmenü ohne Meldung

Versuche jetzt mal zusätzlich den "Workaround" von Wzut, der hört sich auch nicht schlecht an.

Schönen Urlaub noch, Norbert.

Gruß
Kai

Zitat von: ntruchsess schrieb am Sa, 20 Juli 2013 00:49

Zitat von: ntruchsess schrieb am Fr, 24 Mai 2013 22:43leider gibt es noch keinen Firmata-sketch für den ENC28J60.[...]

Ich hab eine Wrapper-library um den µIP-Stack von Adam Dunkels geschrieben, mit der man mit dem Arduino jetzt auch richtige persistente Socket-verbindungen mit einem ENC28J60-Shield machen kann.
Code findet sich wie immer auf GitHub.

So, lange nix mehr von mir hören lassen, war den August über in Urlaub (aber derweil nicht untätig...)

Wer mal wieder mit dem Arduino spielen möchte und mit dem ENC28J60 Shield bisher nicht warm wurde: meine arduino_uip-library ist mittlerweile ziemlich stabil, man kann z.B. das Stock Ethernet-Webserver-example damit praktisch ohne Änderungen laufen lassen. Man muss nur den include von "Ethernet.h" auf "UIPEthernet.h" ändern :-). DHCP und DNS laufen auch. Das coole an der Library (und der wesentliche Unterschied zu anderen enc28J60-libs für Arduino ist: Sie unterstützt echtes TCP-ip mit persistenten Verbindungen - 4 parallele connections - und nutzt das interne Memory des enc28j60 als Streambuffer in beide Richtungen... (Die oft referenzierte EtherCard-library kann nur quasi-tcp mit jeweils einem großen Packet in jede Richtung und anschließendem Verbindungsabbruch...)

Gruß,

Norbert

Den ConfigurableEthernetclient habe ich mir jetzt mal wieder zur Brust genommen und das Problem mit dem automatischen Reconnect mal überarbeitet. Vorrausgesetzt der Arduino merkt, dass er nicht mehr verbunden ist wird der bisherige EthernetClient sauber geschlossen und dann im 5-Sekunden Takt versucht wieder zu verbinden. Wenn man den Stecker einfach so zieht, merkt er leider nur dann, wenn er auch was zu senden hat, dass die Verbindung weg ist (Der WIZ5100 schickt nach meiner Beobachtung keine ACK-packete zum Keepalive). Um das zu beschleunigen muss man ggf. dafür zu sorgen, dass immer was über die Leitung geht, dafür kann man z.B. einen Analog-pin konfigurieren (FRM_AD) - ggf. mit einem etwas längerem Reporting-interval.

Mit meiner neuen UIPEthernet-library (https://github.com/ntruchsess/arduino_uip (https://github.com/ntruchsess/arduino_uip)) funktioniert das genauso. Auf einem Uno kann man nur nicht alle Features aktivieren, weil die Library mehr Speicher als die für den WIZ5100 braucht. Digital+Analog-I/O + OneWire passt aber rein. Auf einem Mega ist das natürlich kein Thema mehr.

Hier gibt den aktuellen Sketch:
https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata (https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata)

- Norbert

Edit: boa - ich seh grad der Thread wurde schon 19770 mal gelesen. Is ja heftig...
Edit: Link aktualisiert, ist jetzt in die standart ConfigurableFirmata integriert

Zur Info für alle, die Firmata über Ethernet verwenden: Die EthernetClientFirmata hat es jetzt in den 'standart' configurable-branch geschafft :-)
https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata (https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata)

Hallo Norbert,

schön zu hören, dass es mit Firmata weitergeht. Die neue Version habe ich seit heute auf dem Arduino, und die scheint nach dem ersten Start auch wieder vernüftig einen Reconnect auszuführen. Ich habe mehrfach FHEM neu gestartet, und bisher war ein Reset des Arduino nicht erforderlich. Das konnte ich bei der vorherigen Ardunio-Soft so nicht feststellen. Wäre schön, wenn es jetzt immer mit dem Reconnect klappt.
Was ein Problem zu sein scheint ist die aktuelle Version von 10_FRM.pm, die mit dem Update ausgerollt wurde. Hiermit bekomme ich immer wieder eine Fehlermeldung, dass die Werte nicht ok sind (habe die Meldung nicht mehr parat, aber was mit Länge der Bytes, steht leider nicht im Log)
Wenn ich die vorherige Version von 10_FRM.pm wieder zurücksichere, können die Werte wieder ausgelesen werden.

Gruß
Kai

Kai, danke für das Feedback.

Vieleicht kannst Du die Fehlermeldung irgendwie abfangen (fhem per screen starten oder so, wenn es nur auf die Konsole geschrieben wird)...

Gruß,

Norbert

Hallo Norbert,

die Fehlermeldung lautet z.B.
OWCOUNT: Could not get values from device Zaehler, reason: invalid data length, 3 instead of 45 bytes in three stepsinvalid data length, 3 instead of 45 bytes in three steps

Zaehler ist natürlich der Name des Devices

Gruß
Kai

hallo Kai,

kann es sein, dass Du die asynchronen OWX-Module benutzt und dir das Update nur FRM überschrieben hat?

Edit: ich denke, dass mein letzter Commit (vorgestern Nacht) das Problem behebt, da war tatsächlich ein Bug in Verbindung mit owx und frm über Netzwerk... kannst du damit nochmal testen?

Gruß,
Norbert

Hallo Norbert,

heute morgen das Update durchgeführt, und bisher keine Probleme mit den Versionen gehabt. Keine Fehlermeldungen von FRM oder seinen Modulen.
Das ist bisher das beste aller Updates in Richtung FRM. Bin gespannt, ob beim nächsten Neustart auch die Verbindung wieder automatisch hergestellt wird.
Danke dafür.

Einen Fehler gibt bei mir OWCOUNT aus:
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1226.
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1235.

Ich habe mir die Zeilen im Modul mal angesehen und festgestellt, du hast da auch was angepasst, gerade bei diesen Zeilen
Vielleicht kannst da auch noch etwas bereinigen?

Gruß
Kai

PS: Bin heute nicht mehr zu erreichen, wenn ich da noch mal Daten liefern soll, geht das erst ab Sonntag wieder.

Zitat von: kaizo am 01 November 2013, 09:18:25
Das ist bisher das beste aller Updates in Richtung FRM. Bin gespannt, ob beim nächsten Neustart auch die Verbindung wieder automatisch hergestellt wird.
Danke dafür.

Prima :-)
In den nächsten Tagen gibt es noch ein kleineres Update der OWX-Module die beim Reconnect bzw. Restart noch ein paar Details feinschleifen. Kommt aber erst in den Trunk, wenn ich alles auf Herz und Nieren getestet habe. (Wer will kann sich die schon mal aus dem branch 'refactoring_owtherm (https://github.com/ntruchsess/fhem-mirror/tree/refactoring_owtherm) runterladen und mittesten, über Feedback würde ich mich freuen).
Geändert habe ich:
- Setzen der Statuswerte beim Neustart gefixed (alle Devices, bisher gabs immer Mecker 'define Device ... first').
- Device-discovery (incl. Autocreate) auch bei verzögertem Connect (FRM, alle OW-Devices).
- Device-spezifisches Interval jetzt auch per Attribut 'interval' (alle Devices). Das Attribut überlebt im Gegensatz zum 'set xxx interval 123' auch einen Restart ;-)
- Neues Attribute 'resolution' für den DS18x20 (9-12 Bit, 12 Bit default. Bei niedrigerer Auflösung geht die Messung schneller, geht mit OWX und OWServer).
- Initialisierung des OWTHERM-devices erst nach Auslesen der Configuration aus dem DS18x20 (sonst überschreiben die Default-werte die im Baustein ggf. schon gespeicherte Config - auch OWX und OWServer).

Zitat von: kaizo am 01 November 2013, 09:18:25
Einen Fehler gibt bei mir OWCOUNT aus:
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1226.
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1235.

ja, kenn ich, hat mit der (mit dem DS2343-ATiny-Nachbau eh nicht funktionierenden) Speicherung der Tageswerte im Zähler zu tun. Habe ich schon auf der Todo-liste.

- Norbert

Zitat von: kaizo am 01 November 2013, 09:18:25
Einen Fehler gibt bei mir OWCOUNT aus:
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1226.
Argument "" isn't numeric in multiplication (*) at ./FHEM/21_OWCOUNT.pm line 1235.

Ersetzte doch bitte im 21_OWCOUNT.pm die beiden Zeilen 1226 und 1235 (beide: $owg_str = 0.0 if(!(defined($owg_str)));) jeweils durch:
$owg_str = 0.0 if(!defined($owg_str) or $owg_str !~ /^\d+\.?\d*$/);
Ich kann das selber (mangels Hardware die passenden 'Müll' aus dem Tageswertspeicher schickt) nicht testen

- Norbert

Edit:
- pattern angepasst (ein Satz Klammern war zuviel).
- hab den Fix selber grade getestet und in den branch refactoring_owtherm (https://github.com/ntruchsess/fhem-mirror/tree/refactoring_owtherm) gemerged.

ach so: Antworten zu den OWX-Änderungen bitte besser in diesem Thread (http://forum.fhem.de/index.php/topic,16101.0.html)

Hallo Norbert,

nach einigen Tagen des Testbetriebs muß ich sagen, einschl. neuer Firmata auf der Arduino, ist wirklich die beste Version bis jetzt. Mit Reconnect und allen weiteren Umständen beim Neustart brauche bis jetzt keinen Reset mehr machen.
Allerdings werden meine DS2423-Nachbauten nicht mehr erkannt. Sobald der 1Wire angeschlossen wird erkennt fhem/frm/ardunio keinen Sensor mehr, d.h. auch die DS1820 sind weg.
Ist noch ein Fehler in der Soft?

Da ich zwei der Nachbauten habe und beide nicht mehr erkannt werden vermute ich dieses so, da diese bis letzte Woche noch munter gezählt haben.


Weil ich vermute, das es nicht an den OWxxx sondern am FRM/Arduino liegt hab ich es auch hier gepostet.

Gruß
Kai

freut mich, dass die Firmata jetzt stabil läuft.
Mach wegen dem OWX doch bitte ein FHEM-Update - ich hab gestern ein paar Fixes hochgeladen, bei irgendeiner Zwischenversion vor 8 Tagen ging OWX mit FRM praktisch gar nicht.

- Norbert

Habe das Update durchgeführt, keine Regung mit dem ds2423. Probiere jetzt den Zähler mal ohne frm an einem Arduino, mal sehen, ob der sich mit den Arduino-Standard-Sketch meldet.

Gruß
Kai

Zitat von: kaizo am 12 November 2013, 16:41:43
Habe das Update durchgeführt, keine Regung mit dem ds2423. Probiere jetzt den Zähler mal ohne frm an einem Arduino, mal sehen, ob der sich mit den Arduino-Standard-Sketch meldet.

Gruß
Kai

Verstehe ich Dich richtig: 1-Wire geht solange die DS2423 nicht angeschlossen sind? Merkwürdig...
Ich meine zwar, dass das bei mir letzte Woche auch in Kombination funktioniert hat (hab keine Counter produktiv, sondern nur im Testaufbau), komme aber vorraussichtlich erst morgen abend dazu, das noch mal selber nachzutesten.

Gruß,

Norbert

Richtig verstanden.

Teste jetzt mal dem Nachbau-2423 von Ralf, ich habe aber auch noch original Ds2423 hier. Wenns mit dem Nachbau nicht geht werde ich mal die Originalteile anklemmen und dann berichten. Vor Donnerstag wird das bei mir auch nix.

Gruß
Kai

So, nun getestet, und Fehler gefunden.
Liegt nicht an der Software, sondern an einem mechanischen Defekt meines DS2423-Nachbaus im Bereich der Anschlußklemmen. Dadurch kam es scheinbar zu einer Belastung auf dem 1-Wire-Bus.
Scheinbar waren die Klemmen von Versandhaus nicht die Besten, aber nun werden die Zähler wieder 1A erkannt und sind schon eifrig am Zählen.

Gruß
Kai

top, freut mich, dass Du den Fehler gefunden hast  :)

Ich möchte gerne nochmal das Thema Firmata und 433MHz Baumarkt ( Intertechno ) Funksteckdosen aufgreifen ( Seite 8 & 9 hier vom 17 und 18 Mai 2013).
Ich wollte auch eine Steckdose mit einem Arduino + Firmata steuern und habe versucht Norberts Vorschlag mit der RCSwitch Lib in Firmata einzubauen.
Leider musste ich feststellen das meine C Kentnisse doch recht bescheiden für dieses Vorhaben sind ... ich habe mir daher eine der kleinstenn Firmata Libs als Grundlage genommen, die Servo Firmata , passte soweit ganz gut da ich sie selbst nicht brauche und das FHEM Modul 20_FRM_SERVO mit nur einem SET Kommando auch ganz gut (miss)brauchbar erschien.
Verwendete Hardware :
mehre Baumarkt Funksteckdosen (bsp ELRO) mit den 10 DIP Schaltern ( 5 Schalter Hauscode + 5 Schalter Geräteadresse )
433 MHZ Sendemodul für 3,50  €  ->  http://www.watterott.com/de/RF-Link-Sender-434MHz

Software :
RCSwitch Lib für Arduino -> http://code.google.com/p/rc-switch/
Firmata von Norbert V2.05

Nachdem die RCSwitch Lib installiert ist und das Modul am Arduino hängt sollte man zuerst mal mit der beiligende SendDemo versuchen seine Steckdosen zu schalten.
War das erfolgreich kann nun Firmata neu komiliert werden, hierzu die beiden Dateien von Norbert durch meine Version ersetzen und in der ino Datei beim Abschnitt Servo noch die RCSwitch.h mit aufnehmen :
#include <Servo.h> //wouldn't load from ServoFirmata.h in Arduino1.0.3
#include <RCSwitch.h>
#include <utility/ServoFirmata.h>
ServoFirmata servo;

Config in FHEM :
define Funkschalter FRM_SERVO <PIN Nr des 433MHZ Moduls>

Nach einem  Neustart von FHEM sollte nun im Webinterface der Funkschalter mit dem Status Initialized auftauchen
Ein und Ausgeschaltet wird mit dem Kommando Set Funkschalter angle <WERT>
Die Berechnung von WERT  ( wir benötigen 12 Bit ):
Bsp HouseCode = 10001
Bsp Geräteadresse = 01000
Aus = 01  , Ein = 10
würde Binar den Code 100010100010 ->  dezimal  = 2210  für EIN und 100010100001 ->  dezimal  = 2209 für AUS ergeben
( wer Probleme hat die 12 Bit Binär in Dezimal umzurechen -> http://www.jetzt-rechnen.de/Informatik/Binaer-Dezimal-Umrechner.html )

Wie bereits oben geschrieben ist das alles andere als schön und sauber, aber mehr war für mich z.Z. nicht möglich , vllt erbarmt sich ja doch jemand das ganze in eine Form zu bringen die Norbert in sein Paket aufnehmen kann ( inkl. einem neuen FHEM Modul) Ich hätte auch gerne noch die Servo.h ganz aus dem Code herausgenommen, doch leider bin ich an den PIN Modes gescheitert.

Viel Spass beim testen ;)

Hallo Wzut,

Nicht schlecht, ich habe da auch mehrere Steckdosen im Einsatz, bei 9.95€ für 3 Stück konnte ich nicht widerstehen und kann dann auch auf eine Rückmeldung ala Homematic verzichten.
Allerdings nutze ich da das IT-Modul von fhem, finde ich auch eine gute Lösung.

Der Arduino hat sicher noch viel Potential, was für fhem zusätzlich genutzt werden kann.

Gruß
Kai

hallo WZut,

finde ich cool, dass Du dich da dran gewagt hast   :)
Schau ich mir gerne näher an und mach gerne was 'vernünftiges' (d.h. ein darauf angepasstes Modul) draus. Braucht nur ein paar Tage, hab (wie immer) zu viele offene Baustellen ;-)

Gruß,

Norbert

@Norbert, nur kene Eile ... du brauchst bestimmt nur etwas "suchen & ersetzen" um aus Servo RCSwitch zu machen ;)

@Kai , ja das IT Modul war auch mein erser Gedanke. Es gibt hier im Forum einen Beitrag wo jemand einen CUL mit dem Arduino emuliert. Das hatte ich zuerst von Seriell auf Ethernet umgeschrieben und lief gut mit dem IT Modul. Allerdings habe ich den Arduino der die Steckdose steuern soll nun schon seit sechs Monaten mit Firmata aktiv am laufen ( Seriell mit Digital IO und 1-Wire) Ich häte gerne das IT Modul genommen habe es allerdings nicht geschafft ihm als IODevice Firmata beizubringen. Sollte das jemand schaffen wäre auf der FHEM Seite kein neues Modul für Firmata nötig.

Hallo Nobert,

ich habe etwas den Überblick verloren.
Ich hab seit Mai einen Ardiuno Mega 256 über Ethernet an FHEM angeschlossen.
Läuft auch sehr stabil.
In den letzten Wochen hatte ich aber ein paar Fehler,
weil die Verbindung nicht wiederhergestellt wurde.
Jetzt hab ich gelesen,
dass Du da ja einiges verbessert hast.
Ich habe diesen Sketch aufgespielt:
https://github.com/firmata/arduino/tree/configurable/examples/ConfigurableFirmata
(vorher natürlich angepasst)
Jetzt wird keine Verbindung mehr hergestellt.

Ich vermisse in dem Sketch auch folgende Funktion:
void setupEthernetClient()
{
  Ethernet.begin(mac,ipClient);  //start ethernet
  delay(1000); // wait 1 second before connecting
  client.connect(ip,port);
  Firmata.begin(client);
  systemResetCallback();  // reset to default config
}
Die wurde im alten Sketch aufgerufen beim Start.

Muss ich auf der FHEM-Seite auch noch was für den neuen Sketch anpassen?

Danke
Thomas

Hast Du nur den Sketch oder den ganzen Branch (https://github.com/firmata/arduino/archive/configurable.zip) genommen?

Die Verbindung zum EthernetServer wird im aktuellen Sketch in der Klasse EthernetClientStream.cpp (https://github.com/firmata/arduino/blob/configurable/utility/EthernetClientStream.cpp) gekapselt, damit entfällt die setUpEthernetClient-methode auf Sketch-ebene.

Konfiguration in FHEM sollte unverändert sein ('define <name> FRM <port> global')

nicht vergessen im Sketch oben '#include <SPI.h> und #include <Ethernet.h> (bzw. '#include UIPEthernet.h' falls Du ein ENC28J60-basiertes Board hast) durch Entfernen des Kommentars zu aktivieren

- Norbert

Danke Norbert,
jetzt klappt es!

Hallo,

hab mich in den letzten Tagen viel mit Firmata und dem Arduino beschäftigt.
Ich habe einen Nanode RF SMT http://openenergymonitor.org/emon/Modules aus der Zeit, als ich mit fhem anfing und schnell mal Kaufen ein Anfang war.
Siehe:
https://wiki.london.hackspace.org.uk/view/Project:Nanode/Applications#Before_You_Start
Das Board hat einen ENC28J60 Ethernet Controller
Hab Firmata angepasst und draufgeladen, und es auch geschafft, das Ethernet zum Laufen zu bringen (in der Fritzbox ist der Nanode aufgetaucht mit IP und MAC-Adresse). Dafür hab ich lange gesucht und in der Datei Enc28J60Network.h die Zeile so geändert:
#define ENC28J60_CONTROL_CS     8 //war vorher 10, 8 für Nanode
Allerdings kam ich da nicht weiter.
Meine Frage: Kennt jemand den Nanode und kann mir weiterhelfen, oder soll ich das Teil an jemanden abgeben, der was damit anfangen kann?
Liegt das Problem nur an falsch belegten PINs in Enc28J60Network.h?

Danke schon mal
Charles

den Nanode hatte ich leider noch nicht in der Hand und aus dem Schaltplan (http://ichilton.github.io/nanode/rf/schematic.pdf) werde ich auch nicht recht schlau. D.h. ich denke der Plan ist fehlerhaft, da ist MISO gar nicht verbunden und DS hängt dauerhaft auf VCC. Gleichzeitig steht an der Leitung noch 'DIG8', auch wenn es im Schaltplan nicht mit dem passenden Pin verbunden ist, aber das wäre zumindestens ein Hinweis, dass das Define für CS in der Enc28J60Network.h stimmern könnte.
Wenn auf dem Nanode noch mehr Chips über SPI angeschlossen sind, dann müssen deren CS-Pins von der Firmata ignoriert und auf Output/high geschaltet sein (siehe ConfigurableFirmata.ino ab Zeile 235 (https://github.com/firmata/arduino/blob/configurable/examples/ConfigurableFirmata/ConfigurableFirmata.ino#L235).


Funktionieren die Beispiele von UIPEthernet denn? Du kannst in der UIPEthernet.h noch ein paar Defines zum Debuggen auskommentieren (die Meldungen kommen dann auf der Seriellen Schnittstelle) an denen Du erkennen kannst, ob die Library überhaupt mit dem Enc28J60 kommuniziert. Paralell mit Wireshark auf der Leitung schauen, ob die erwarteten Pakete überhaupt verschickt werden, hilft auch, Fehlerquellen einzugrenzen.

- Norbert

Hallo Norbert,

hab gerade erst gesehen, dass Du geantwortet hast. Ich war in der grossen Stadt und hab kurzen Prozeß gemacht und hab mir einen Arduino Ethernet geholt. Da bin ich gerade am Ausprobieren. Hier komm ich aber nur genauso weit wie mit dem anderen Board.
Ethernet läuft jetzt. Aber sonst rührt sich nichts. Temperaturen kann ich auslesen (Dallas-Sensor-Beispiel)
Ich seh also den Arduino im Heimnetz von der Fritzbox. fhem meldet, dass Firmata nicht angebunden ist. Ich kann auch die IP im Browser nicht aufrufen.
Den Webserver aus Beispiele hab ich auch nicht zum Laufen gebracht.

Die Arduino Anbindung in fhem.cfg sieht so aus
# -------------Arduino-Anbindung ---------------------
define FIRMATA FRM 3030 global
define Eingang OWX 3

Ich häng mal den geänderten Sketch an - vielleicht ist da ja doch etwas falsch.
Schon mal vielen Dank für die Hilfe!

Charles

die Beispiels-sketche der Ethernet-library solltest Du natürlich schon zum Laufen kriegen, wenn die nicht gehen, dann stimmt irgendwas grundlegendes nicht.

Ansonsten: zum gemeinsamen Verständnis: Dein FHEM-server läuft auf ip-addresse 192.168.0.1, richtig? Dann sollte die Netzkonfiguration im Sketch passen.
die FRM-config sieht eigentlich auch ok aus.

Es ist übrigens normal, dass man den Arduino mit NetworkFirmata nicht per Browser aufrufen kann - der Arduino versucht kontinuierlich zur im Sketch angegebenen 'remoteIp' auf dem 'remotePort' zu verbinden. Dafür macht das FRM-modul im FHEM einen Server-socket auf dem konfigurierten Port auf. (Den kann man aber auch nicht mit dem Browser abrufen, der erwartet eine Verbindung, auf der das binäre Firmata-protokoll gesprochen wird).

Vieleicht hast Du ja ein Firewall-problem? Ist der port 3030 auf dem FHEM-server (bei laufendem FHEM) denn aus dem Netzwerk (z.B. mit telnet) verbindbar?

- Norbert

Hallo Norbert,

dann fang ich morgen mal mit den Beispielskripten an und teste die mal durch.

Das Heimnetz lädt mit der IP 192.168.0.xx und 192.168.0.1 ist der Router also die Fritzbox mit fhem.

Beim Aufruf über tenet kam Folgendes heraus:MacBook-Pro:~ G$ telnet 192.168.0.1 3030
Trying 192.168.0.1...
Connected to 192.168.0.1.
Escape character is '^]'.
y??y??y?Connection closed by foreign host.

Das sieht doch eigentlich ganz gut aus, oder?
Ein Firewall-Problem? Ich hatte gedacht, Alles hinter dem Router ist normalerweise erreichbar? Weiß ich nicht, konnte auch in der Fritzbox nichts finden.
Wie kann ich denn nachverfolgen, was auf dem Arduino passiert? Welche Möglichkeiten gibts denn da?

Charles

ja, das mit dem telnet sieht gut aus. Also kein Firewall-problem (eine Firewall kann auch die Ports auf dem Router selbst gegen das Netz abblocken, scheint bei Deiner FB nun aber ja nicht so zu sein).

Auf dem Arduino könntest Du ein paar Serielle Debug-Ausgaben einstreuen und über den Seriellen Monitor schauen, ob alles läuft. Vor einem produktiven Einsatz aber unbedingt entfernen.

- Norbert

Hallo Norbert,

ich habe gefunden. Ethernet ist auf der Fritzbox abgestürzt. Nach einem Neustart der FB bekomme ich jetzt Daten von meinen Temperatursensoren.Super! Werde ich gleich morgen installieren. Vielen Dank!
Charles

Hallo Norbert,

ein gutes neues Jahr wünsch ich Dir erstmal!
Ich hab den Tag heute genutzt, um den Arduino im Keller zu installieren und die Sensoren zu verdrahten.
Steht Alles. Folgendes finde ich im Log. Die Sensoren tauchen nicht auf. Gestern kamen die im room OWX an.2014.01.01 14:12:58 0: Server started with 100 defined entities (version $Id: fhem.pl 4501 2013-12-29 17:59:52Z rudolfkoenig $, os linux, user root, pid 5037)
2014.01.01 14:13:02 3: querying Firmata Firmware Version
2014.01.01 14:13:02 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.01 14:13:02 3: received String_data: Unhandled sysex command
2014.01.01 14:13:05 3: received String_data: Unhandled sysex command
2014.01.01 14:13:14 1: OWX: 1-Wire devices found on bus Eingang ()
2014.01.01 14:16:59 3: querying Firmata Firmware Version
2014.01.01 14:17:00 3: querying Firmata Firmware Version
2014.01.01 14:17:01 3: querying Firmata Firmware Version
2014.01.01 14:17:01 3: no response from Firmata, closing DevIO
2014.01.01 14:17:01 1: 3030 disconnected, waiting to reappear
2014.01.01 14:17:04 3: querying Firmata Firmware Version
2014.01.01 14:17:04 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.01 14:17:04 3: received String_data: Unhandled sysex command
2014.01.01 14:17:06 3: received String_data: Unhandled sysex command
2014.01.01 14:17:16 1: OWX: 1-Wire devices found on bus Eingang ()
Mehr kommt nicht an. Weisst Du vielleicht, um welchen Fehler es sich handelt?

Danke Charles

Hallo Charles,

auch erst mal ein gutes neues Jahr!.
Irgendwas stimmt mit Deinem Arduino bzw. seiner Ethernetanbindung nicht. Scheint so, als ob er beim Verbindungsaufbau zwar senden kann (der Versionsstringt und die beiden 'Unhandles sysex command'-meldungen kommen noch an), aber nichts empfängt (auf 'Querying Firmata Fimware Version' sollte eigentlich eine Antwort kommen). Das kann auch ganz banal an Deiner Netzwerkverkabelung liegen, wenn nicht alle Adern sauber verbunden sind. Mit einem Ethernet-shield hatte ich den gleichen Effekt auch mal, da war der ISP-Stecker meines Ethernet-shields einen kleinen Tick zu kurz um zuverlässig Kontakt zum Arduino zu halten, dann hat er manchmal noch brav senden können, aber im Sketch nichts mehr empfangen.

Gruß,

Norbert

Hallo Norbert,

dann handelt es sich wahrscheinlich um eine Hardwaresache. Das ist leicht möglich, weil ich da auch Anfänger bin. Ich begebe mich mal auf die Suche nach schlechten Verbindungen.

Danke
Charles

Hallo Norbert,

der Stand der Dinge:
Hab gestern noch das Breadboard an den Arduino gehängt. Sofort wurden die 3 Sensoren darauf erkannt und OWX tauchte als Menu mit den 3 Sensoren auf. Das lief so die ganze Nacht. Morgens konnte alle aktuellen Temperaturen sehen.
Hab dann meine Anschlussplatte überprüft und einen Lötfehler behoben (Stromversorgung war falsch angelötet).
Leider bring ich jetzt weder das Breadboard noch die Anschlussplatte zum Laufen. Ich hatte heute morgen die Einträge von OWX aus der fhem.cfg gelöscht, da die Sensoren ja nur zum Testen benutzt wurden, und die Festinstallierten laufen sollten. Vielleicht war das ein Fehler?
Ich bin ratlos. ->Neustart von fhem ------------------
2014.01.02 18:06:16 0: Server started with 100 defined entities (version $Id: fhem.pl 4501 2013-12-29 17:59:52Z rudolfkoenig $, os linux, user root, pid 10108)
2014.01.02 18:06:20 3: querying Firmata Firmware Version
2014.01.02 18:06:20 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 18:06:35 1: OWX: 1-Wire devices found on bus Eingang ()
->Neustart des Arduino ---------------------
2014.01.02 18:08:32 3: querying Firmata Firmware Version
2014.01.02 18:08:32 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 18:08:47 1: OWX: 1-Wire devices found on bus Eingang ()
->set FIRMATA reinit --------------------------
2014.01.02 18:10:34 1: 3030 disconnected, waiting to reappear
2014.01.02 18:10:37 3: querying Firmata Firmware Version
2014.01.02 18:10:37 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 18:10:52 1: OWX: 1-Wire devices found on bus Eingang ()
Weiter will OWX nichts tun.

Die Internats für FIRMATA sehen so aus:Internals:
   CONNECTS   5
   DEF        3030 global
   FD         35
   NAME       FIRMATA
   NR         220
   PARTIAL   
   PORT       3030
   STATE      disconnected
   TYPE       FRM
   Socketdevice:
     BUF       
     DeviceName 3030
     FD         4
     NAME       FRM:192.168.0.80:1025
     NR         370
     SNAME      FIRMATA
     STATE      Connected
     TEMPORARY  1
     TYPE       FRM
     firmware   ConfigurableFirmata.ino
     firmware_version V_2_05
Attributes:
   group      Firmata
   room       HEIZUNG
Weisst Du vielleicht Rat?

Danke Charles

mach mal ein 'get <owx-device> devices'

Hallo Norbert,

der "get Eingang devices"-Befehl gibt im Log2014.01.02 23:26:40 1: OWX: 1-Wire devices found on bus Eingang ()
2014.01.02 23:27:12 1: OWX: 1-Wire devices found on bus Eingang ()
2014.01.02 23:32:42 1: OWX: 1-Wire devices found on bus Eingang ()
2014.01.02 23:33:00 1: OWX: 1-Wire devices found on bus Eingang ()
hab ich 4-mal versucht.

ich hab weiter versucht, den Fehler zu finden:
Also hab ich Eins nach dem Anderen gestartet, also erst fhem, dann
hab ich FRM definiert, danach OWX.
Im Log kam Folgendes an:
2014.01.02 23:25:21 3: FIRMATA: port 3030 opened
2014.01.02 23:25:22 2: error initializing Eingang: error initializing 'Eingang': Eingang, FIRMATA is not connected
2014.01.02 23:25:22 1: OWX: 1-Wire bus Eingang: interface FIRMATA is not connected to Firmata
2014.01.02 23:25:22 1: Including ./log/fhem.save
2014.01.02 23:25:27 3: querying Firmata Firmware Version
2014.01.02 23:25:27 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 23:25:42 1: OWX: 1-Wire devices found on bus Eingang ()
Die Initialisierung von Eingang scheint vielleicht das Problem zu sein.

Hier noch das Logfile von heute Nacht, als Alles funktioniert hat!2014.01.02 00:54:07 3: FIRMATA: port 3030 opened
2014.01.02 00:54:07 2: error initializing Eingang: error initializing 'Eingang': Eingang, FIRMATA is not connected
2014.01.02 00:54:07 1: OWX: 1-Wire bus Eingang: interface FIRMATA is not connected to Firmata
2014.01.02 00:54:07 1: Including ./log/fhem.save
2014.01.02 00:54:13 3: querying Firmata Firmware Version
2014.01.02 00:54:13 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 00:54:13 3: received String_data: Unhandled sysex command
2014.01.02 00:54:15 3: received String_data: Unhandled sysex command
2014.01.02 00:54:25 1: OWX: 1-Wire devices found on bus Eingang ()
2014.01.02 01:01:41 3: querying Firmata Firmware Version
2014.01.02 01:01:41 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.02 01:01:41 3: received String_data: Unhandled sysex command
2014.01.02 01:01:43 3: received String_data: Unhandled sysex command
2014.01.02 01:01:53 3: OWTHERM: Device OWX_10_38A3AD020800 defined.
2014.01.02 01:01:53 3: OWTHERM: Device OWX_10_0CA98E020800 defined.
2014.01.02 01:01:53 3: OWTHERM: Device OWX_10_C1AA8E020800 defined.
2014.01.02 01:01:53 1: OWX: 1-Wire devices found on bus Eingang (OWX_10_38A3AD020800,OWX_10_0CA98E020800,OWX_10_C1AA8E020800)
2014.01.02 01:04:07 2: ventil_SchlafTemp : 0

Charles

Ich denke Du hast da ein Hardwarproblem. 1-Wire-bus kurzgeschlossen oder so was. Wenn Du genau sehen willst, ob OWX und FRM tun, was sie sollen, dann kannst Du das Attribut loglevel am FRM-device auf 5 setzten, dann sieht man, ob die 'get <owxdevice> devices'-Anfrage vom Arduino mit einer leeren Liste beantwortet wird (Das würde ich jedenfalls erwarten).

Gruß,

Norbert

Hallo Norbert,

hab jetzt Folgendes gemacht:
1) Temperatur-Skript auf den Arduino hochgeladen und damit die Platinen überprüft.
Alle Sensoren werden erkannt und ausgelesen auf dem Breadboard und meiner Anschlussplatine. Funktioniert.

2) StandartFirmata hochgeladen und mit dem Programm firmata_test die Anschlüsse überprüft. Funktioniert.

3) Mein ConfigurableFirmata-Skript hochgeladen. Verbose auf 5 gesetzt, mit "get Eingang devices" die Sensoren gesucht,
leider mit dem alten Ergebnis "OWX: 1-Wire devices found on bus Eingang ()" und keiner Zeile mehr.

4) Jetzt hab ich nach und nach Sensoren ausgesteckt usw. Inzwischen ist das Breadboard nicht mehr am Arduino angeschlossen. Alle Pins sind unbelegt.
Auch nach einem "shutdown restart" von fhem kommt mit "get Eingang devices" das Ergebnis "OWX: 1-Wire devices found on bus Eingang ()". Er kann doch jetzt eigentlich gar nichts mehr finden? Ein Rätsel!

Danke Charles

Hallo Norbert,

hab inzwischen Einiges Weiteres versucht:

Lade abwechselnd das 1Wire-Temperaturskript auf den Arduino und lese damit Temperaturen aus.
Danach mein ConfigurableFirmata und versuche, auch hier an die Sensoren zu kommen.
Immer das gleiche Ergebnis (siehe oben). Auch der Loglevel 5 oder 6 brachte nichts Neues. Es kommt nicht mehr im Logfile an.
Inzwischen hab ich mir auch die aktuellsten OWX-, FRM- und  OWTHERM-Dateien geholt, weil ich dachte, die sind vielleicht beschädigt. Hat aber auch nichts gebracht. Ich hab die Namen gewechselt, die Pins gewechselt ...
list Input (umbenannt von Eingang) bringt Folgendes:Internals:
   DEF        7
   FRM_OWX_CORRELATIONID 0
   INTERFACE  firmata
   IODev      FRM_Input
   NAME       Input
   NR         221
   PIN        7
   PRESENT    0
   ROM_ID     FF
   STATE      Initialized
   TYPE       OWX
   ALARMDEVS:
   DEVS:
   Frm_owx_replies:
   Readings:
     2014-01-05 14:48:11   state           failed
Attributes:
   group      Firmata
   loglevel   6
   room       HEIZUNG

fhem.cfg sieht so aus:# -------------Arduino-Anbindung ---------------------
define FRM_Input FRM 3030 global
attr FRM_Input loglevel 6
define Input OWX 7
attr Input loglevel 6


FRM_Input status: listening
Input status: Initialized
FRM:192.168.0.80:1028 status: Connected


Nochmal der Filelog-Auszug nach Neustart:2014.01.05 14:48:13 0: Server started with 100 defined entities (version $Id: fhem.pl 4519 2014-01-01 15:43:32Z rudolfkoenig $, os linux, user root, pid 18583)
2014.01.05 14:48:17 3: querying Firmata Firmware Version
2014.01.05 14:48:17 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.01.05 14:48:32 1: OWX: 1-Wire devices found on bus Input ()

Ich wäre für Hilfe sehr dankbar!
Charles

Hallo Charles,

jetzt hatte ich grade mal Zeit deinen Sketch_Firmata.txt vom 30. Dezember genauer unter die Lupe zu nehmen. Du hast das ein bischen viel wild auskommentiert - die ganzen #ifdefs sind so aufgebaut, dass jedes Feature, dass man im oberen Teil (vor Zeile 108) per Kommentar abschalted weiter unten auch nicht mehr verwendet wird. Da hast Du das FirmataExt-feature irgendwie durcheinandergebracht (sieht man unter anderem daran, dass 2 mal die Fehlermeldung 'unhandles Sysex Command' kommt und in den FRM-details die Pin-eigenschaften fehlen. Ohne FirmataExt werden die Sysex-commands nicht verteilt und OneWire geht nicht.

Also nimm einfach noch mal ConfigurableFirmata im Originalzustand, und passe erst mal nur die Netzwerkkonfig so wie in Deinen bisherigen Sketch an, dann läuft das.

übrigens: Wegen des ENC28J60-shields das bei Dir mit '#define ENC28J60_CONTROL_CS 8' nicht funktioniert hat - dafür gibts im UIPEthernet mitlerweile einen Patch (siehe aktuelle UIPEthernet-Releases (https://github.com/ntruchsess/arduino_uip/releases))

Gruß,

Norbert

Hallo Norbert,

Ja!!!!! das wars. Ich hab das Ausgangsskript genommen und vorsichtiger auskommentiert. Sofort krieg ich meine Sensoren.
Vielen Dank für die Hilfe

Charles

Hallo,

die Sensorenanbindung funktioniert perfekt. Alles absolut stabil. Jetzt hab ich mich endlich weitergewagt und wollte mit dem Arduino noch einen Schalter auslesen. Da ging fhem wieder in die Knie.
Das Wiki gibt zum dem Thema zu wenig her. So hab ich Ein- und Ausgang und Sensoren angebunden:
define FRM_Input FRM 3030 global
define FRM_Input_OUT FRM_OUT 6
attr FRM_Input_OUT stateFormat 1
define FRM_Input_IN FRM_IN 5
attr FRM_Input_IN stateFormat reading
define Input OWX 7
attr Input buspower real
define ofen_ruecklauf OWTHERM DS18B20 38E5F4040000 60
attr ofen_ruecklauf IODev Input
attr ofen_ruecklauf model DS1822
...


Die stateFormat Zeilen wurden automatische eingefügt.
Was ist denn da falsch?

Das Log sagt Folgendes nach einem Neustart:
2014.01.19 23:16:50 3: FRM_Input: port 3030 opened
2014.01.19 23:16:50 2: error initializing FRM_Input_OUT: error initializing 'FRM_Input_OUT': FRM_Input_OUT, FRM_Input is not connected
2014.01.19 23:16:50 2: error initializing FRM_Input_IN: error initializing 'FRM_Input_IN': FRM_Input_IN, FRM_Input is not connected
2014.01.19 23:16:50 2: error initializing Input: error initializing 'Input': Input, FRM_Input is not connected
2014.01.19 23:16:50 1: OWX: 1-Wire bus Input: interface FRM_Input is not connected to Firmata
2014.01.19 23:16:51 1: Including ./log/fhem.save
2014.01.19 23:16:53 4: Connection accepted from FRM:192.168.0.80:1026
2014.01.19 23:16:56 3: querying Firmata Firmware Version
2014.01.19 23:16:56 3: Firmata Firmware Version: ConfigurableFirmata_Uno.ino V_2_05
2014.01.19 23:16:56 3: received String_data: Unhandled sysex command
2014.01.19 23:28:36 1: Including fhem.cfg


Danke für Hilfe

Charles

Hallo Norbert,
ich habe inzwischen ein I2C LCD 20x4 Display das ich mit 20_FRM_LCD nutze. Zu diesem Modul hätte ich drei Erweiterungs Vorschläge in der angehängten .pm :
1. set <name> backlight on|off  , Zwecks einfaches ein und ausschalten

2. set <name> reset , resetet das LCD ohne FHEM neu starten zu müsssen. Grund : Ich hatte des öfteren nur noch Zeichsensalat auf dem Display, keine Ahnung ob meinem Display ne Macke hat , der I2C Bus auf dem Schreibtisch zu chaotisch oder das Display bestimmte Codes nicht mag. Mit dem set reset habe ich es jedenfalls sofort wieder einsatzbereit.

3. set <name> writeXY PosX,PosY,max.Länge, aligment L|R  belieber Text
Mit der jetzigen set text Funktion bin ich nicht recht glücklich geworden , da ich aus verschiedenen Modulen bestimmte Werte an ganz bestimmten Stellen ausgeben wollte. Mit der neuen Funktion ist das recht leicht , zumal mein Display z.Z keine Umlaute darstellen kann und diese auch gleich ersetzt.

Achso , ich hatte es auch nicht geschafft mit der set text Funktion Texte mit Leerzeichen auszugeben egal wie ich versucht habe den Text zu maskieren.
Vllt. hast du ja einen Tipp, ich habe jetzt mit einem join gelöst
     

Zitat von: det. am 20 April 2013, 22:22:21
Hallo Norbert,
ich habe ein China Billigdisplay http://www.ebay.de/itm/New-2004-204-20X4-Character-LCD-Display-Module-Blue-Backlight-/261162290069?pt=Motoren_Getriebe&hash=item3cce7c4b95 (http://www.ebay.de/itm/New-2004-204-20X4-Character-LCD-Display-Module-Blue-Backlight-/261162290069?pt=Motoren_Getriebe&hash=item3cce7c4b95) über diesen Adapter angeschlossen: http://www.ebay.de/itm/390527388644?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649 (http://www.ebay.de/itm/390527388644?ssPageName=STRK:MESINDXX:IT&_trksid=p3984.m1436.l2649)
Zwei solcher Displays habe ich schon lange im Einsatz mit dem Louis Swart Interface für 1wire und OWLCD von pah. Die Ardunio Variante ist noch günstiger und in Ardunionähe als Füllstandsanzeiger praktisch zu verwenden mit dem von Dir schon angekündigten  Ultraschallmodul nur fehlt Deiner FRM_LCD noch die Möglichkeit ( oder mir die Fähigkeit) Variablen auf den 4 Zeilen des Displays darzustellen.

@ Norbert und Wzut,
die Frage treibt mich auch noch immer um und resultiert in einer gefüllten Kiste ungenutzter Bauteile. Norbert, wenn es deine knappe Zeit erlaubt, da weiterzumachen wäre das großartig.

hallo WZut,

find ich prima dass Du Dich daran gemacht hast. Ich teste Deine Änderungen in den nächsten Tagen mal mit meinem 2-Zeiligem Display und checke das dann ein.

@det. konnstest Du das von WZut geänderte Modul mal mit Deinem 4-zeiligem Display testen?

Gruß,

Norbert

Zitat von: Charles am 21 Januar 2014, 20:11:45
Jetzt hab ich mich endlich weitergewagt und wollte mit dem Arduino noch einen Schalter auslesen.
[...]
Was ist denn da falsch?

Config sieht eigentlich gut aus.

Zitat von: Charles am 21 Januar 2014, 20:11:45
Das Log sagt Folgendes nach einem Neustart:

Code Auswählen Erweitern


2014.01.19 23:16:56 3: received String_data: Unhandled sysex command
[/quote]

Hast Du vieleicht das DigitalInputFirmata oder DigitalOutputFirmata oder das FirmataReporting-feature aus der ConfigurableFirmata rauskonfiguriert?

Gruß,

Norbert

Hallo,

ich habe mal wieder Zeit gefunden, an meinem Firmata-Arduino Projekt weiterzumachen. Dabei bin ich auf folgendes Problem gestoßen:

Mit FRM_IN und FRM_OUT kann ich die Pins D20 (A6) und D21 (A7) nicht ansprechen bzw. auslesen. Bis D19 (A5) funktionieren alle Pins ausgenommen D0/D1 (TX/RX) und D10-D13 (Kommunikation mit dem Ethernetshield). Ich habe einen NANO mit ENC28J60 Shield.

In der Datei "boards.h" im Firmataverzeichnis habe ich folgenden Eintrag gefunden:
#define IS_PIN_DIGITAL(p)       ((p) >= 2 && (p) <= 19)

Ein Ändern auf
#define IS_PIN_DIGITAL(p)       ((p) >= 2 && (p) <= 21)
hat aber keine Änderung am Verhalten bewirkt.

Wo ist noch eine Begrenzung der digitalen IN/OUT Ports im Programmcode vorhanden? Oder können diese zwei Ports digital gar nicht angesprochen werden?

Viele Grüße
Achim

Hast du den I2C Teil in Firmata auskommentiert ?  Wenn nein müssten sie die dir in FHEM als I2C Pins gelsitet werden.

Hallo,
versuche mich gerade an einem 1602 Display über firmata_2.05.

############################
define Arduino2 FRM 3040 [192.168.0.73]
attr Arduino2 i2c-config 1
attr Arduino2 room Arduino
define Input OWX 8
attr Input IODev Arduino2
attr Input buspower real
attr Input room Arduino
define OWX_10_68A454020800 OWTHERM DS1820 68A454020800
attr OWX_10_68A454020800 IODev Input
attr OWX_10_68A454020800 model DS1820
attr OWX_10_68A454020800 room Arduino
attr OWX_10_68A454020800 tempHigh 75
attr OWX_10_68A454020800 tempLow 70
define OWX_10_E2EE54020800 OWTHERM DS1820 E2EE54020800
attr OWX_10_E2EE54020800 IODev Input
attr OWX_10_E2EE54020800 model DS1820
attr OWX_10_E2EE54020800 room Arduino
attr OWX_10_E2EE54020800 tempHigh 75
attr OWX_10_E2EE54020800 tempLow 70
define LCD_1 FRM_LCD i2c  16 2 0x3F
attr LCD_1 IODev Arduino2
attr LCD_1 room Arduino
attr LCD_1 stateFormat text

Onewire funktioniert wunderbar, aber das Display bekomme ich nicht zum laufen. Irgendwas scheint laut log mit der I2C Adresse nicht zu stimmen.
Welche Eingabe erwartet FRM_LCD?

LOG:
Argument "0x3F" isn't numeric in bitwise and (&) at FHEM/lib/Device/Firmata/Protocol.pm line 542.

Viele Grüße

woody

Zitat von: Achim am 30 Januar 2014, 22:16:52
Ein Ändern auf

Code Auswählen Erweitern

#define IS_PIN_DIGITAL(p)       ((p) >= 2 && (p) <= 21)
hat aber keine Änderung am Verhalten bewirkt.

Port C des ATmega328p hat nur 6 bits für Digital-I/O. (Siehe Datasheet 1.1.4, Pin Description Port C (http://www.atmel.com/images/atmel-8271-8-bit-avr-microcontroller-atmega48a-48pa-88a-88pa-168a-168pa-328-328p_datasheet.pdf). Da kann die Software nichts dran ändern.

Gruß,

Norbert

Zitat von: woody am 02 Februar 2014, 13:21:12
Argument "0x3F" isn't numeric in bitwise and (&) at FHEM/lib/Device/Firmata/Protocol.pm line 542.

versuchs mal mit 63 (dezimalwert von 0x3F)

- Norbert

Hallo Norbert,

ZitatPort C des ATmega328p hat nur 6 bits für Digital-I/O.

da habe ich mich wohl durch den Belegungsausdruck des NANO in die Irre führen lassen. Da ist A6 und A7 mit angegeben. Vielen Dank.

Viele Grüße
Achim

Zitat von: ntruchsess am 02 Februar 2014, 14:52:29
versuchs mal mit 63 (dezimalwert von 0x3F)

- Norbert

Hallo Norbert,
ja das wars......habs leider nirgends gesehen das es so eingegeben werden muß..

Danke

Hallo Leute,
habe noch ein anderes Problem, die Suche hat leider nichts gebracht und ich verstehs net.

Nach einem Reset oder rereadcfg, also wenn der Arduino sich neu connected hat er immer einen anderen Port.
Das bedeute allerdings auch, das die OWX-Devices immer neu gefunden werden.

Wie kann ich dem FRM-Device mitteilen das es für die IP X immer den Port y nutzen soll?

meine fhem.cfg sieht momentan so aus:

###############
#    Waeschekeller      #

define Arduino1 FRM 3030 [192.168.0.72]
attr Arduino1 room Arduino
define Arduino1_ANALOG18 FRM_AD 18
attr Arduino1_ANALOG18 event-min-interval 5
attr Arduino1_ANALOG18 event-on-change-reading 1
attr Arduino1_ANALOG18 room Arduino
attr Arduino1_ANALOG18 stateFormat reading

############
#      Heizung      #

define Arduino2 FRM 3040 [192.168.0.73]
attr Arduino2 room Arduino
#attr Arduino2 i2c-config 1
define Input OWX 8
attr Input IODev Arduino2
attr Input buspower real
attr Input room Arduino
define OWX_10_68A454020800 OWTHERM DS1820 68A454020800
attr OWX_10_68A454020800 IODev Input
attr OWX_10_68A454020800 model DS1820
attr OWX_10_68A454020800 room Arduino
attr OWX_10_68A454020800 tempHigh 30
attr OWX_10_68A454020800 tempLow 20

Ergebnis unter everything:

Arduino1                           listening
Arduino2                           listening
FRM:192.168.0.72:2903    Connected
FRM:192.168.0.73:1071    Connected

soweit ja OK. aber beim nächsten reboot oder reconnect ändert sich der Port und damit auch das FRM Device.

Ich raffs net.

Grüße
woody

also dass sich der Port beim neu-verbinden ändert ist normal, der wird beim Socket-accept vom Betriebssystem dynamisch vergeben. Das mit den OWX-devices muss ich mir aber näher ansehen, dass ist mir so noch nicht aufgefallen. Hat ziemlich sicher damit zu tun, dass Du mehrere Arduinos parallel verwendest, das habe ich bei meinen Tests so noch nicht auf dem Schirm gehabt.

- Norbert

Hallo Jürgen,

Hab mir auch ein 20x4-Display besorgt um Deine Änderungen am FRM_LCD-modul zu testen. Sind jetzt eingepflegt (https://github.com/ntruchsess/fhem-mirror/commit/209decc94cacd6c1d59b2202e53b4bc184911a82) und auch schon in den fhem-SVN-trunk committed ;-)

Gruß,

Norbert

Zitat von: Wzut am 22 Januar 2014, 11:52:19
Hallo Norbert,
ich habe inzwischen ein I2C LCD 20x4 Display das ich mit 20_FRM_LCD nutze. Zu diesem Modul hätte ich drei Erweiterungs Vorschläge in der angehängten .pm :
1. set <name> backlight on|off  , Zwecks einfaches ein und ausschalten

2. set <name> reset , resetet das LCD ohne FHEM neu starten zu müsssen. Grund : Ich hatte des öfteren nur noch Zeichsensalat auf dem Display, keine Ahnung ob meinem Display ne Macke hat , der I2C Bus auf dem Schreibtisch zu chaotisch oder das Display bestimmte Codes nicht mag. Mit dem set reset habe ich es jedenfalls sofort wieder einsatzbereit.

3. set <name> writeXY PosX,PosY,max.Länge, aligment L|R  belieber Text
Mit der jetzigen set text Funktion bin ich nicht recht glücklich geworden , da ich aus verschiedenen Modulen bestimmte Werte an ganz bestimmten Stellen ausgeben wollte. Mit der neuen Funktion ist das recht leicht , zumal mein Display z.Z keine Umlaute darstellen kann und diese auch gleich ersetzt.

Zitat von: ntruchsess am 26 Februar 2014, 23:49:21
Sind jetzt eingepflegt (https://github.com/ntruchsess/fhem-mirror/commit/209decc94cacd6c1d59b2202e53b4bc184911a82) und auch schon in den fhem-SVN-trunk committed ;-)

Hallo Norbert, vielen Dank
ein Punkt ist mir in der command.ref aufgefallen bei dem attr writexy
set <name> writeXY x-pos,y-pos,len[,l] <text to be displayed>
wäre ich nicht der Autor von writexy würde ich es nicht verstehen .... d.h das vor dem eigentlichen Text vier Paramter zu übergeben sind :
set <name> writeXY x-pos,y-pos,len, align l|r <text to be displayed>

neues FRM-modul FRM_ROTENC -> http://forum.fhem.de/index.php/topic,20837.msg143685.html#msg143685

Hallo zusammen,

seit dem gestrigen Update, kann ich keine 2 Firmata Arduinos mehr parallel betreiben. Egal ob 1x USB und 1x Ethernet, oder 2x USB. Sobald mehr als ein Firmata Device  definiert ist, gehen die Devices nicht auf "opened"
Beim Starten bleiben die Devices auf "Initialized" stehen. Erst nach einem "set Firmata_USB reset" funktionieren diese wieder.

Gehe ich auf die Version vom 28.02.2014 (mein vorletztes Update + Backup) zurück, werden die Devices automatisch verbunden.

Kann ich einen Befehl nach einem Neustart ausführen lassen, damit ein Reset ausgeführt wird?

Gruß
Torsten

Auszug aus meiner Konfiguration
define FIRMATA_USB FRM /dev/ttyUSB0@57600

define OWFRM OWX 6
attr OWFRM IODev FIRMATA_USB

define FIRMATA_USB1 FRM /dev/ttyUSB1@57600
attr FIRMATA_USB1 i2c-config 1

define FIRMATA_NET FRM 3030 global

#################################

define Firmata_OUT_7 FRM_OUT 7
attr Firmata_OUT_7 IODev FIRMATA_USB
attr Firmata_OUT_7 room FRM
attr Firmata_OUT_7 stateFormat value

define Firmata_OUT_13 FRM_OUT 13
attr Firmata_OUT_13 IODev FIRMATA_NET
attr Firmata_OUT_13 group Netzwerk
attr Firmata_OUT_13 room FRM
attr Firmata_OUT_13 stateFormat value

define LCD FRM_LCD i2c 20 4 39
attr LCD IODev FIRMATA_USB1
attr LCD backLight on
attr LCD stateFormat text


hab ich letzte Woche auch bemerkt, dass das mit der IODev-Zuordnung im FRM plötzlich nicht mehr tut. Hatte aber noch keine Gelegenheit das näher zu untersuchen. (bin grade auf der Rückfahrt von einem Kurztripp nach Berlin).

Vielleicht hilft dir der Fix, der vorhin zuIODevv reingekommen ist:

http://forum.fhem.de/index.php?topic=21227.msg147212.msg#147212

fhem.pl: fixing IODev issues

<b>fhem.pl: fixing IODev issues</b><br /><br />fhem.pl: fixing IODev issuesView Changes<br /><br />Source: fhem.pl: fixing IODev issues (http://sourceforge.net/p/fhem/code/5175/)

Gruß, Norbert

Hallo,

versuche das MOdul mit einem Arduino Nano und einem ENC28j60 zum laufen zu bekommen:

der ENC ist folgendermassen am nano angeschlossen:
ENC SO -> Arduino pin 12
ENC SI -> Arduino pin 11
ENC SCK -> Arduino pin 13
ENC CS -> Arduino pin 10
ENC VCC -> Arduino 3V3 pin
ENC GND -> Arduino Gnd pin

In meinem sketch sieht das dann so aus:

#define NETWORK_FIRMATA
//replace with ip of server you want to connect to, comment out if using 'remote_host'
#define remote_ip IPAddress(192,168,1,11)
//replace with hostname of server you want to connect to, comment out if using 'remote_ip'
//#define remote_host "server.local"
//replace with the port that your server is listening on
#define remote_port 3030
//replace with arduinos ip-address. Comment out if Ethernet-startup should use dhcp
#define local_ip IPAddress(192,168,1,16)
//replace with ethernet shield mac. It's mandatory every device is assigned a unique mac
const byte mac[] = {0x90,0xA2,0xDA,0x0D,0x07,0x02};
#endif


die Pin Definition sieht so aus


ifdef NETWORK_FIRMATA
  // ignore SPI and pin 4 that is SS for SD-Card on Ethernet-shield
  for (byte i=0; i < TOTAL_PINS; i++) {
    if (IS_PIN_SPI(i)
        || 4==i
        || 10==i //explicitly ignore pin 10 on MEGA as 53 is hardware-SS but Ethernet-shield uses pin 10 for SS
        ) {
      Firmata.setPinMode(i, IGNORE);
    }
  }


Firmdata lauscht aber hoert nix, Arduino leuchtet rot, ebenso der ENC, die LEDs am ENC fuer Netzwerkaktivitaet blinkt, aber ich finde ihn nicht unter der IP.
Was mich wunderte ist, dass ich die anderen MOdule nicht auskommentiert habe und der Arduino trotzdem nicht meckert...ueberall steht dass Speicher zu knapp ist.

Was mache ich falsch?


W

hast Du den Kommentar vor #include "UIPEthernet.h" entfernt?

Hallo Jürgen,

Zitat von: Wzut am 27 Februar 2014, 21:45:03
ein Punkt ist mir in der command.ref aufgefallen bei dem attr writexy

Code Auswählen Erweitern

set <name> writeXY x-pos,y-pos,len[,l] <text to be displayed>
wäre ich nicht der Autor von writexy würde ich es nicht verstehen ....

tu Dir keinen Zwang an und verbessere die Dokumentation nach Deinen Vorstellungen ;-)

- Norbert

Also ich bin jetzt soweit, dass ich den enc im Netz sehe ( die IP), somit denke ich, dass ich das enc Modul richtig angeschlossen habe. Frm in fhem bleibt aber immer bei listening....frm_in und frm_out sagen, dass sie nicht erkannt sind.....hat jemand Ideen woran das liegen könnte?
Danke. W

Sent from my Nexus 7 using Tapatalk

mit 'im Netz sehe' meinst Du, dass der Arduino auf ein Ping antwortet?

Ich sehe die ihm zugewiesene IP auftauchen. Ich benutze fing als tool alle Teilnehmer in meinem Netz zu zeigen.

Sent from my Nexus 7 using Tapatalk

hm... keine Ahnung was fing so treibt um die Services im Netz aufzuspüren, versuch es mal ohne - nicht dass dein 'fing' die ConfigurableFirmata mit einem Portscan zumüllt und runterreißt :-(

Laufen denn die UIPEthernet-examples (wie z.B. der EchoServer-sketch (https://github.com/ntruchsess/arduino_uip/blob/master/examples/EchoServer/EchoServer.ino)?

@Norbert kann man dich eigtl. irgendwie bestechen, das du Support für ein DHT22 in die Firmata einbaust?! Ich würde total gerne kleine "Kistchen" basteln mit Bewegungsmelder,Reedkontakt für Fensterkontakt und DHT22 Sensoren, die dann in einige Räume (Flur, Garage, HWR) kommen (wo sich kein komplettes Homematicsystem lohnt, aber die Werte trotzdem interessant sind). Leider fehlt mir sowohl das Wissen als auch die Zeit (kleine Tochter) das hinzubekommen.
Aber vielleicht kann ich dich ja mit einem Arduino und DHT22 Sensor o.ä. motivieren da was umzusetzten :-).

Hallo,

Update bezüglich IODev hat leider nichts gebracht. Fehler ist weiterhin vorhanden.

2014.03.11 22:35:42 1: 3030 disconnected, waiting to reappear
2014.03.11 22:35:42 1: /dev/ttyUSB1 disconnected, waiting to reappear
2014.03.11 22:35:42 1: /dev/ttyUSB0 disconnected, waiting to reappear
2014.03.11 22:35:42 1: Including fhem.cfg
2014.03.11 22:35:42 3: telnetPort: port 7072 opened
2014.03.11 22:35:42 3: WEB: port 8083 opened
2014.03.11 22:35:42 3: WEBphone: port 8084 opened
2014.03.11 22:35:42 3: WEBtablet: port 8085 opened
2014.03.11 22:35:43 3: Opening FIRMATA_USB device /dev/ttyUSB0
2014.03.11 22:35:43 3: Setting FIRMATA_USB baudrate to 57600
2014.03.11 22:35:43 3: FIRMATA_USB device opened
2014.03.11 22:35:46 3: querying Firmata Firmware Version
2014.03.11 22:35:46 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.03.11 22:35:46 1: OWX: 1-Wire bus OWFRM: interface Firmata detected in FIRMATA_USB
2014.03.11 22:35:46 3: Opening FIRMATA_USB1 device /dev/ttyUSB1
2014.03.11 22:35:46 3: Setting FIRMATA_USB1 baudrate to 57600
2014.03.11 22:35:46 3: FIRMATA_USB1 device opened
2014.03.11 22:35:49 3: querying Firmata Firmware Version
2014.03.11 22:35:49 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.03.11 22:35:49 3: FIRMATA_NET: port 3030 opened
2014.03.11 22:36:01 3: OWTHERM: Device OWX_10_072780020800 defined.
2014.03.11 22:36:01 2: error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_8: error initializing 'Firmata_OUT_8': Firmata_OUT_8, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_8: error initializing 'Firmata_OUT_8': Firmata_OUT_8, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_9: error initializing 'Firmata_OUT_9': Firmata_OUT_9, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_9: error initializing 'Firmata_OUT_9': Firmata_OUT_9, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_10: error initializing 'Firmata_OUT_10': Firmata_OUT_10, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_10: error initializing 'Firmata_OUT_10': Firmata_OUT_10, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_11: error initializing 'Firmata_OUT_11': Firmata_OUT_11, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_11: error initializing 'Firmata_OUT_11': Firmata_OUT_11, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_12: error initializing 'Firmata_OUT_12': Firmata_OUT_12, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_12: error initializing 'Firmata_OUT_12': Firmata_OUT_12, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_14: error initializing 'Firmata_OUT_14': Firmata_OUT_14, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_14: error initializing 'Firmata_OUT_14': Firmata_OUT_14, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_15: error initializing 'Firmata_OUT_15': Firmata_OUT_15, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_OUT_15: error initializing 'Firmata_OUT_15': Firmata_OUT_15, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_IN_3: error initializing 'Firmata_IN_3': Firmata_IN_3, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_IN_3: error initializing 'Firmata_IN_3': Firmata_IN_3, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_IN_4: error initializing 'Firmata_IN_4': Firmata_IN_4, FIRMATA_NET is not connected
2014.03.11 22:36:02 2: error initializing Firmata_IN_4: error initializing 'Firmata_IN_4': Firmata_IN_4, FIRMATA_NET is not connected
2014.03.11 22:36:03 2: error initializing Firmata_IN_5: error initializing 'Firmata_IN_5': Firmata_IN_5, FIRMATA_NET is not connected
2014.03.11 22:36:03 2: error initializing Firmata_IN_5: error initializing 'Firmata_IN_5': Firmata_IN_5, FIRMATA_NET is not connected
2014.03.11 22:36:03 2: error initializing LCD: no IODev set
2014.03.11 22:36:04 1: Including ./log/fhem.save
2014.03.11 22:36:08 1: OWX: 1-Wire devices found on bus OWFRM (OWX_10_072780020800)
2014.03.11 22:36:08 1: OWX: 1-Wire devices found on bus OWFRM (OWX_10_072780020800)
2014.03.11 22:36:12 3: querying Firmata Firmware Version
2014.03.11 22:36:12 3: Firmata Firmware Version: ConfigurableFirmata_net.ino V_2_05


IODev ist aber gesetzt (s.o. 1. Beitrag von mir).


Wenn ich dann mein Firmata_Net deaktiviere passiert folgendes
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.

und das System wird lahm gelegt.
"n_Test_scharf" ist ein notify!
"Firmata_IN_3:.*on set Test_scharf scharf; set Firmata_OUT_7 on"


Mein "OWX_10_072780020800" liefert die ganze Zeit über Daten. OWFRM schein nicht betroffen zu sein.

Beim Starten wird zwar "FIRMATA_USB device opened" im Log ausgegeben und die Firmware kann ausgelesen werden, aber im FHEM unter Unsorted wird FIRMATA_USB als "Initialized" angezeigt.
Erst wenn ich ein "set FIRMATA_USB reinit" oder "set FIRMATA_USB reset" ausführe, geht es wieder und FIRMATA_USB wird als opened angezeigt.

Gruß
Torsten

Zitat von: strauch am 11 März 2014, 18:14:21@Norbert kann man dich eigtl. irgendwie bestechen, das du Support für ein DHT22 in die Firmata einbaust?!

klar kann man das. Schick mir einfach die nötige Zeit ;-). Arduino und DHT22 hab ich schon.

Aber helfen könntest Du dabei schon: arbeite mal ein passendes Konzept aus, wie man solche spezialisierten Sensoren ins Firmata-protocoll einbaut, ohne massenhaft 'pinmodes' für solche Spezialfälle zu 'verschwenden'. Firmata-protocol siehe firmata.org (http://firmata.org), diskussion und Änderungsvorschläge auf firmata-protocol auf github (https://github.com/firmata/protocol/issues).

Wenn das Protokoll steht ist das Einbauen in FHEM eine Kleinigkeit

Zitat von: ntruchsess am 13 März 2014, 14:06:17
klar kann man das. Schick mir einfach die nötige Zeit ;-). Arduino und DHT22 hab ich schon.

Kommt mir bekannt vor

Zitat von: ntruchsess am 13 März 2014, 14:06:17Aber helfen könntest Du dabei schon: arbeite mal ein passendes Konzept aus, wie man solche spezialisierten Sensoren ins Firmata-protocoll einbaut, ohne massenhaft 'pinmodes' für solche Spezialfälle zu 'verschwenden'. Firmata-protocol siehe firmata.org (http://firmata.org), diskussion und Änderungsvorschläge auf firmata-protocol auf github (https://github.com/firmata/protocol/issues).

Wenn das Protokoll steht ist das Einbauen in FHEM eine Kleinigkeit

Des ist doch mal eine Aufgabe. Ob ich das kann.... werde ich wohl nur Wissen wenn ich mir das anschaue. Danke, das werde ich mal machen.

Zitat von: cyberdwarf am 11 März 2014, 23:12:58

Code Auswählen Erweitern

2014.03.11 22:35:42 1: 3030 disconnected, waiting to reappear
2014.03.11 22:36:01 2: error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected
2014.03.11 22:36:01 2: error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected
...


das ist kein Fehler. Das sagt nur aus, dass der Arduino sich noch nicht über das Netzwerk verbunden hatte als fhem die FRM_IN/OUT...-Devices definiert hat. Da sollte ich ggf. den Loglevel ändern, oder das 'error' durch ein 'warning' ersetzten. Das ist aber schon seit mindestens 4 Monaten so im code, von welcher Version her hast Du denn geupdated?

Zitat von: cyberdwarf am 11 März 2014, 23:12:58
Wenn ich dann mein Firmata_Net deaktiviere passiert folgendes

Code Auswählen Erweitern

2014.03.11 22:33:10 3: n_Test_scharf return value: pin '7' is not configured for mode 'INPUT' or 'OUTPUT' at FHEM/lib/Device/Firmata/Platform.pm line 467.
...

und das System wird lahm gelegt.
"n_Test_scharf" ist ein notify!
"Firmata_IN_3:.*on set Test_scharf scharf; set Firmata_OUT_7 on"

das habe ich (erfolglos) versucht nachzuvollziehen. Wie 'deaktivierst' Du das Firmata_net? Einfach abziehen? (so hab ich das jedenfalls nicht reproduzieren können).

Zitat von: cyberdwarf am 11 März 2014, 23:12:58
Beim Starten wird zwar "FIRMATA_USB device opened" im Log ausgegeben und die Firmware kann ausgelesen werden, aber im FHEM unter Unsorted wird FIRMATA_USB als "Initialized" angezeigt.
Erst wenn ich ein "set FIRMATA_USB reinit" oder "set FIRMATA_USB reset" ausführe, geht es wieder und FIRMATA_USB wird als opened angezeigt.

Der (rein optische) Fehler ist, dass nach einen (erfolgreichen) set xxx reset als state 'opened' und nicht 'Initialized' angezeigt wird, das habe ich gerade geändert und ins SVN committed.
'opened' bedeutet DevIO konnte das Device erfolgreich öffnen.
Anschließend wir versucht es (inklusive aller Client-devices) zu initialisieren. Wenn das geklappt hat, ist der State 'Initialized'.

der Unterschied zwischen set xxx reset und set xxx reinit ist, dass reset erst die Verbindung schließt und neu öffnen, bevor es (wie set xxx reinit) das FRM-device mit allen client-devices neu inititialisiert. Ein 'set xxx reset' ist somit fast dasselbe wie abziehen und wiederanstecken eines USB-devices (mit dem Unterschied, dass das USB-device nicht stromlos wird und auf OS-ebene auch bestehen bleibt).

- Norbert
(dass ich dachte mit den IODevs funktioniert irgendwas nicht lag daran, dass ich die neuen Module FRM_STEPPER und FRM_ROTENC vergessen hatte zur Liste der FRM-clients hinzuzufügen, ist jetzt aber auch drin und hätte auf FRM_IN/OUT/OWX etc.. keinen Einfluss gehabt)

Zitat von: woody am 02 Februar 2014, 19:49:25
Hallo Leute,
habe noch ein anderes Problem, die Suche hat leider nichts gebracht und ich verstehs net.

Nach einem Reset oder rereadcfg, also wenn der Arduino sich neu connected hat er immer einen anderen Port.
Das bedeute allerdings auch, das die OWX-Devices immer neu gefunden werden.

da hatte ich eigentlich schon mal drauf geantwortet (auf die Sache mit dem Port), jetzt habe ich aber grade mal ein Testsetup mit mehreren Arduinos dranhängen um zu testet, ob da alles passt:

Also bei einem rereadcfg legt fhem alle Devices neu an, das ist normal.
OWX-Devices haben als IODev das zugehörige OWX-device (das ist nicht das FRM-device!). Dieses ändert sich bei einem rereadcfg nicht.
Das OWX-device hat als IODev das logische FRM-device (also das, was per 'define' erzeugt wird).
Sobald der Arduino sich über das Netzwerk verbindet, wird das OWX-device dynamisch mit dem temporären FRM-device für den dynamisch geöffneten Port verbunden. Anschließend macht das OWX-device den üblichen Bus-scan (wie beim fhem-neustart) und legt ggf. OWX-Devices neu an. Existierende bleiben dabei so, wie gehabt.

Also alles so, wie es (aus meiner Sicht) sein soll.

Das einzige, das mir aufgefallen ist, ist das ein 'set frmdevice reset' bei einem Network-Firmata-device einen Fehler macht, weil es nach dem Reset sofort versucht zu verbinden (bei der Network-Firmata aber auf den Arduino gewartet werden muss). Das werde ich gleich mal beheben, aber eigentlich ist das auch eher ein Schönheitsfehler, weil sobalt der Arduino nach dem 'reset' wieder verbindet ist alles in Butter.

- Norbert

P.S.: 'set frm reset' für Network-Firmata habe ich grade gefixed. Macht jetzt einen sauberen Firmata-reset, schließt die Client-connection und warted darauf, dass sich die Network-firmata wieder verbindet.

Hallo,

Zitat von: ntruchsess am 13 März 2014, 16:44:38
das ist kein Fehler. Das sagt nur aus, dass der Arduino sich noch nicht über das Netzwerk verbunden hatte als fhem die FRM_IN/OUT...-Devices definiert hat. Da sollte ich ggf. den Loglevel ändern, oder das 'error' durch ein 'warning' ersetzten. Das ist aber schon seit mindestens 4 Monaten so im code, von welcher Version her hast Du denn geupdated?

Klingt logisch. Allerdings verstehe ich nicht, warum error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected

FIRMATA_NET den Firmata_OUT_7 bedienen will.
FIRMATA_NET hat nur ein Device definiert und zwar Firmata_OUT_13.
Firmata_OUT_7 hat FIRMATA_USB als IODev.

Ich habe die Logs überprüft. Die Meldungen kommen schon länger, allerdings hat sich vorher mein Firmata_USB Device bei einem rereadcfg oder shutdown restart automatisch verbunden.
Jetzt sieht das so aus, wie im angehängten Screenshot.

Zitat von: ntruchsess am 13 März 2014, 16:44:38
das habe ich (erfolglos) versucht nachzuvollziehen. Wie 'deaktivierst' Du das Firmata_net? Einfach abziehen? (so hab ich das jedenfalls nicht reproduzieren können).

Ich kommentiere die Zeilen in der fhem.cfg aus. Danach tritt der Fehler auf.

#define FIRMATA_NET FRM 3030 global
#
#define Firmata_OUT_13 FRM_OUT 13
#attr Firmata_OUT_13 IODev FIRMATA_NET
#attr Firmata_OUT_13 group Netzwerk
#attr Firmata_OUT_13 room FRM
#attr Firmata_OUT_13 stateFormat value


Es sind dann nur noch FIRMATA_USB und FIRMATA_USB1 aktiviert.

Am FIRMATA_USB habe ich Firmata_OUT_ (7-12 und 14-15) und Firmata_IN_ (3-5)
Firmata_USB1 bedient das I2C Display.

Gruß
Torsten

Zitat von: cyberdwarf am 13 März 2014, 21:34:44
Klingt logisch. Allerdings verstehe ich nicht, warum

Code Auswählen Erweitern

error initializing Firmata_OUT_7: error initializing 'Firmata_OUT_7': Firmata_OUT_7, FIRMATA_NET is not connected

FIRMATA_NET den Firmata_OUT_7 bedienen will.
FIRMATA_NET hat nur ein Device definiert und zwar Firmata_OUT_13.
Firmata_OUT_7 hat FIRMATA_USB als IODev.

Hallo Thorsten,

ich verstehe das Problem mitlerweile. Mein IODev-handling beim Network-arduino spielt nicht mit den Änderungen der letzen Monate an der AssignIODev-funktion zusammen. Ich muss dafür einiges am Startup der FRM-module umstellen, das dauert ein bischen. Danach sollten aber alle durch den bisherigen Versuch der Initialisierung bei noch-nicht-verbundener Networkfirmata Effekte erledigt sein.

Gruß,

Norbert

P.S.: FRM scheint nicht der einzige Leittragende zu sein  (http://forum.fhem.de/index.php/topic,21377.0.html). Den Fehler habe ich jetzt beim Basteln auch bekommen ;-) Wobei ich die Änderung, wie AssignIOPort jetzt das IODev-attribut behandelt grundsätzlich mal gut finde, die Module müssen halt passend dazu gestrickt sein.

So bei mir läuft der arduino jetzt. Mein Problem war, dass ich hinter 3030 kein global hatte.

Sent from my Nexus 7 using Tapatalk

Hallo Norbert,

ist doch schon mal gut, das du es nachstellen konntest. Danke für Deine Arbeit.


Gruß
Torsten

ich habe die initialisierung von FRM umgestellt (https://github.com/ntruchsess/fhem-mirror/commit/54ef462c2d771ce4cda64284db67e31e7d09a60d), jetzt werden die Devices erst nach dem kompletten Laden der fhem.cfg initialisiert. Mit dem geänderten Verhalten der AssignIOPort-methode kommt es jetzt zurecht.

Fix ist im SVN committed.

Gruß,

Norbert

moin,
Ist mit der ConfigurableFirmata OneWireVersion möglich mehrere DS2482 anzusteuern?
Ist es möglich auch mehrere DS2480 anzusteuern? Also sind mehrere RX/TX Pins am Arduino konfigurierbar?

Hintergrund: im 1wire Thread ist eine Dual-1wirePlatine mit 2x DS2480 per Ethernetanbindung entstanden. Ich schaue nun inwieweit sich das ganze auch mit einem Arduino betreiben lässt. Im Idealfall mit bis zu 3x DS2482

Hallo!

Nach dem heutigem Update spielen meine Stromzähler verrückt. Anscheinend überlebt der internal-pullup den neustart nicht.

2014.03.16 09:43:23.637 1: Including ./FHEM/arduino.cfg
2014.03.16 09:43:23.655 3: cannot set attribute internal-pullup to on for arduino_pin_45: arduino_pin_45, FIRMATA is not connected
2014.03.16 09:43:23.660 3: cannot set attribute internal-pullup to on for arduino_pin_46: arduino_pin_46, FIRMATA is not connected
2014.03.16 09:43:23.690 1: configfile: cannot set attribute internal-pullup to on for arduino_pin_45: arduino_pin_45, FIRMATA is not connected
cannot set attribute internal-pullup to on for arduino_pin_46: arduino_pin_46, FIRMATA is not connected
2014.03.16 09:43:23.690 1: Including ./log/fhem.save
2014.03.16 09:43:23.720 3: FIRMATA: port 3030 opened
2014.03.16 09:43:23.722 0: Server started with 258 defined entities (version $Id: fhem.pl 5197 2014-03-10 21:07:30Z rudolfkoenig $, os darwin, user Fabian, pid 63056)
2014.03.16 09:43:29.833 3: querying Firmata Firmware Version
2014.03.16 09:43:29.856 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05

Hab jetzt wieder die Versionen von gestern am laufen.

Grüße

Zitat von: Tobias am 16 März 2014, 07:48:19
Ist mit der ConfigurableFirmata OneWireVersion möglich mehrere DS2482 anzusteuern?Ist es möglich auch mehrere DS2480 anzusteuern? Also sind mehrere RX/TX Pins am Arduino konfigurierbar?

OneWire in der ConfigurableFirmata ist erst mal eine reine Softwarelösung, bei der der Arduino selber der Busmaster ist und das komplette Timing ganz ohne DS-irgendwas abwickelt. Die Vorteile eines speziellen Busmasters sind da gering (entlastet zwar den µC, aber das muss man erst mal so implementieren, dass der in der gesparten Zeit tatsächlich was anderes machen kann). Nur bei längeren Bussen mit vielen Chips dran kann ein spezialisierter Busmaster (mit eingebauter Slewrate-control) echte Vorteile bringen.
Aber der DS2480 ist wenig sinnvoll, RX/TX ist bei den Arduinos mit USB ja schon belegt und nur die Mega2560 und Due haben mehrere Hardware-serials. Der DS2482 mit I2C ist da die bessere Wahl, davon kann man ja auch bis zu 4 Stück an einem I2C-bus anschließen. Die ConfigurableFirmata-anbindung dafür habe ich im Oktober schon mal implementiert (https://github.com/ntruchsess/arduino/tree/DS2482). Braucht allerdings noch Feinschliff, der DS2482 macht das Timing doch nicht komplett autonom wie ich ursprünglich dachte, da muss der µC mitarbeiten (ist beim DS2480 genauso). Das ist auch der Grund, warum eine Lösung, bei der die Intelligenz direkt am 1-Wire bus und nicht am anderen Ende einer 'verlängerten seriellen Schnittstelle' sitzt, sinnvoller ist. Da hängt die Stabilität nicht von der Qualität der Netzwerkverbundung ab. Der primäre Nachteil ist: der Arduino spricht kein owfs (hat noch niemand implementiert), sondern z.B. Firmata.

Falls Du eine Platine mit DS2482 für den Arduino machen willst: Am besten fände ich persönlich, wenn man die Platine direkt huckepack auf ein ENC28J60-modul (wie z.B. dieses (http://www.ebay.de/itm/mini-ENC28J60-Ethernet-LAN-Netzwerk-Modul-Arduino-RJ45-SPI-CP01002-C44-/271348956366?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3f2da87cce) stecken könnte und obendrauf einen 'Arduino mini pro (http://www.ebay.de/itm/New-Mini-Pro-Compatible-Nano-Atmega328-5V-16M-Replace-ATmega128-For-Arduino-ESY-/121282344052?pt=LH_DefaultDomain_0&hash=item1c3cfdb474)'. Das hätte dann den kleinsten möglichen Formfaktor. Kann aber sein, dass andere lieber ein Shield im standard-Arduino-layout hätten. Als dritte Alternative einfach eine Platine, auf die man einen Arduino-nano aufstecken kann - da kann man dann ein Enc28J60-Ethernet-shield für Nano (http://www.ebay.de/itm/Ethernet-Shield-for-Arduino-Nano-UNO-R3-work-as-ENC28J60-RJ45-Webserver-/111242798349?pt=Wissenschaftliche_Ger%C3%A4te&hash=item19e696650d) dazwischenstecken. Ist halt etwas teuerer als die Variante 'Mini Pro + ENC28J60-breakoutboard'...

Gruß,

Norbert

Zitat von: fhainz am 16 März 2014, 10:03:10Nach dem heutigem Update spielen meine Stromzähler verrückt. Anscheinend überlebt der internal-pullup den neustart nicht.

Danke für die Rückmeldung, habe ich grade behoben (https://github.com/ntruchsess/fhem-mirror/commit/89464b2c1c317674ead9417307053eb5c2fecb0e)

Gruß,

Norbert

Bei mir funktioniert alles, danke!

Danke das klappt nun.

Leider wird nach einen neustart wieder das reading "reading" aktualisiert/on-off gesetzt.


Grüße

Zitat von: fhainz am 17 März 2014, 18:43:38Leider wird nach einen neustart wieder das reading "reading" aktualisiert/on-off gesetzt.

Das sollte mit Attribut 'count-mode' auf 'falling' nicht stören.

Gruß,

Norbert

Ich nutze zum zählen das HourCounter Modul, nicht den internen zähler.
Mir ist es nur bei meinem Boiler aufgefallen da dieser auf nachtstrom läuft und zu dieser Zeit eigentlich keine impulse ankommen sollten ;)

Grüße

Hallo!

Ich hab heute ich 2 Ein-/Ausgänge definiert um meine Stromstossschaltung im Vorzimmer "anzuzapfen". Das funktioniert problemlos solange ich immer on/off befehle absetzte.
Wenn ich aber ein paar mal (manchmal schon beim 1. mal) zB on-for-timer 1 sende, stürzt die Mega ab. Es lassen sich keine befehle mehr senden, naja senden via FHEM geht aber es passiert anschließend nichts, und am S0 Zähler tut sich auch nichts mehr. Nach dem An/Abstecken der Stromversorgung passt wieder alles.

- 1x 230V Relais das anzieht wenn das Licht an ist, Schließer-Kontakt zum Arduino Mega Eingang
- 1x 5V Relais das die Arduino Mega schaltet, Schließer-Kontakt parallel zum Stromstossschalter um das Taster-Drücken zu simulieren

Meine Defines:

define allgVorzimmerLicht FRM_IN 47
attr allgVorzimmerLicht IODev FIRMATA
attr allgVorzimmerLicht alias Licht
attr allgVorzimmerLicht devStateIcon .*on.*:light_ceiling_off .*off.*:light_ceiling@green
attr allgVorzimmerLicht group 1. Vorzimmer
attr allgVorzimmerLicht internal-pullup on
attr allgVorzimmerLicht room 5. Wohnung
attr allgVorzimmerLicht stateFormat reading

define allgVorzimmerLichtSchalten FRM_OUT 48
attr allgVorzimmerLichtSchalten IODev FIRMATA
attr allgVorzimmerLichtSchalten alias Licht schalten
attr allgVorzimmerLichtSchalten devStateIcon .*:light_toggle
attr allgVorzimmerLichtSchalten group 1. Vorzimmer
attr allgVorzimmerLichtSchalten room 5. Wohnung
attr allgVorzimmerLichtSchalten stateFormat value
attr allgVorzimmerLichtSchalten webCmd on-for-timer 1

Jemand eine Idee?


Grüße

Hallo,
ich habe gerade mehrere on-for-timer auf dem Mega am laufen, bis jetzt hat sich noch nichts verabschiedet.
Auch auf einem zweiten Arduino, einem Ethernet funzt das ganze im Grunde.

Welche Firmata verwendest du? Ich habe Configurable 2_05 am laufen.

Ich kämpfe gerade mit einem anderen Wunder.
Ich habe eine 8-Kanal Relaismodul welchen nach masse geschaltet werden möchte. Der Mega macht das auch anstandslos aber
der Ethernet nicht...
Es sieht so aus als wenn die Pins des Ethernet Arduinos nur zwischen 5v und floating wechseln.

Nebenbei, in der 20_FRM_OUT idt mir in Zeile 59 folgendes ins Auge gestochen:
my $invert = AttrVal($hash->{NAME},"activeLow","no");
soll das "no" vielleicht "on" heissen?
Dürfte aber meines Erachtens keine Auswirkung haben...

Was ich auch komisch finde ist, dass wenn ich den Mega in FHEMWEB anklicke bekomme ich eine schöne Übersicht über die Pis und deren
Möglichkeiten. z.B. i2c_pins 20,21 Beim Ethernet steht zwar auch firmware ConfigurableFirmata.ino und firmware_version V_2_05
aber keine Pins...   Obwohl das nicht kriegsentscheidend ist...

Warum das mit dem nach Masse schalten nicht funktionieren will ist mir jedoch schleierhaft...

MFG Lars

Zitat von: fhainz am 19 März 2014, 17:59:27
Jemand eine Idee?

Ja, vermutlich bringen die Schaltimpulse der Relais den Arduino zum Absturz. Abhilfe: Suppressordioden gegen die Spannungsspitzen und ausreichend weit weg vom Arduino plazieren.

Gruß,

Norbert

Zitat von: lars am 19 März 2014, 20:34:05
Hallo,
ich habe gerade mehrere on-for-timer auf dem Mega am laufen, bis jetzt hat sich noch nichts verabschiedet.
Auch auf einem zweiten Arduino, einem Ethernet funzt das ganze im Grunde.

Welche Firmata verwendest du? Ich habe Configurable 2_05 am laufen.

Ich verwende auch die Configurable 2_05. Eigenartig das es bei dir Problemlos funktioniert. Schaltest du damit auch Relais?

Zitat von: ntruchsess am 19 März 2014, 23:11:55
Ja, vermutlich bringen die Schaltimpulse der Relais den Arduino zum Absturz. Abhilfe: Suppressordioden gegen die Spannungsspitzen und ausreichend weit weg vom Arduino plazieren.

Ich hab RC-Glieder die direkt in dem Relais-Sockel stecken. Sollte genügen oder? Weit weg platzieren wird unmöglich da der arduino im Verteiler sitzt.
Hast du noch einen andern Tipp was ich versuchen könnte? Bzw. hast du eine Erklärung warum es bei einem normalen on und anschließendem off problemlos funktioniert?

Grüße

Hallo,
ja ich schalte auch Relais, allerdings schaltet der Arduino nur Optokoppler welche dann die Relais schalten. Die 5V für Die Relais habe ich zwar vom gleichen Netzteil abgezwackt aber halt vor dem Arduino.

Ich verwende das "8 Kanal 5V Relay Relais Module Modul für Arduino" von Amazon


MFG Lars

Ich habe mal einen Test gemacht bzgl. meines Masseschaltproblems.

Wenn ich einen Pin darauf Programmiere zu blinken:
define arduinoblinka2 at +*00:00:01 set Out_2_7 on-for-timer .5 #Dauerblinken
Das ganze identisch am Mega (über USB) und am Ethernet.

und dann eine LED mit Vorwiderstand nehme und diese einmal von GND-PIN und einmal verpolt von 5v-PIN stecke blinkt sie am Mega
immer und am Ethernet nur wenn sie vom PIN nach GND gesteckt ist. Der EThernet schaltet also bei ON 5V raus, aber bei OFF nicht auf
Masse sondern floating.

1wire habe ich auch getestet, das funktioniert auch nur am Mega.
Mit dem Atrribut activeLow habe ich auch schon gespielt

Hat jemand eine Idee?

MFG Lars

Hallo,

ich habe es hinbekommen. Das Problem muss an der Programmierung des Arduino selber gelegen haben.
Ich habe ihn neu Programmiert (eigendlich mit dem identischen Sketch) und siehe da, ich bekomme die
Übersicht der Funktionen der Pinne und das Masseschalten funktioniert auch.

MFG Lars

Hallo,
ersteinmal vielen Dank für die Tolle arbeit mit den FRM Geschichten. Ich bin gerade dabei so einiges auf Arduinos umzustellen
weil es nach meiner Ansicht eine der flexibelsten und preisgünstigsten Lösungen ist.

bei verwendung eines 1wire Temperatursensors am Etnernet Arduino und einem reradcfg hängt sich FHEM immer auf.
Im fhem.log steht zuletzt folgendes:
2014.03.21 20:30:27 1: OWX: 1-Wire bus Arduino_OW_Temp1: interface Firmata detected in Arduino2

Wenn ich den Prozess kille und neu starte bzw. bevor ich ein rereadcfg versuche über shutdown restart starte funktioniert ersteinmal alles.
Auch die Temperatur des 1wire Sensors wird gelesen.
Allerdings hat sich FHEM letze nach wieder von selbst verabschiedet.

Jetzt habe ich mal eine kleine Verständnisfrage.
Norbert, in diesem Thread hattest du doch im laufe des letzten Jahres die module 11_OWX_FRM.pm etc. gepostet.
Ich habe diese mal testweise eingesetzt und auch versucht herauszufinden ob es davon auf Github schon neuere gibt.
Mit denen aus dem Thread hier bekam ich eine Fehermeldung, dass mein ausgewählter Pin für 1wire ungültig sei.
Dann hab ich die von https://github.com/ntruchsess/fhem-mirror/blob/owx_async/fhem/FHEM/ ausprobiert, aber FHEM hat
sich trotzdem beim rereadcfg aufgehängt. Ich konnte da ersteinmal keinen direkten Unterschied zum aktuellen Update feststellen.

Könntest du mir eventuell einen Kurzen überblick geben welchen Stand die jeweiligen Varianten haben?
Oder bin ich völlig auf dem falschen Dampfer? :)

MFG Lars

Zitat von: lars am 22 März 2014, 10:58:50
Könntest du mir eventuell einen Kurzen überblick geben welchen Stand die jeweiligen Varianten haben?

der Stand im SVN ist aktuell der einzige der an die Semantikänderung von AssignIOPort angepasst ist, wobei ich da noch ein paar Kleinigkeiten nachschärfen muss. Komme ich aber nicht vor heute abend oder morgen im Laufe des Tages dazu.

Der owx_async-branch auf Github ist noch nicht darauf angepasst. Der wird mit einer aktuellen fhem.pl vermutlich Probleme haben.

Gruß,

Norbert

Zitat von: fhainz am 19 März 2014, 17:59:27
Hallo!

Ich hab heute ich 2 Ein-/Ausgänge definiert um meine Stromstossschaltung im Vorzimmer "anzuzapfen".
Wenn ich aber ein paar mal (manchmal schon beim 1. mal) zB on-for-timer 1 sende, stürzt die Mega ab. Es lassen sich keine befehle mehr senden, naja senden via FHEM geht aber es passiert anschließend nichts, und am S0 Zähler tut sich auch nichts mehr. Nach dem An/Abstecken der Stromversorgung passt wieder alles.

Mittlerweile hab ich mir ein 8 Kanal Schaltmodul (http://www.amazon.de/gp/product/B00AEIDWXK/ref=oh_details_o00_s00_i00?ie=UTF8&psc=1) bestellt. Gestern ist es angekommen und das schalten der Relais hat den ganzen Abend ohne absturz funktioniert. Heute morgen ist die Mega wieder aber wieder abgestürzt. :(
Jetzt nach dem nachhause kommen hab ich es noch ein paar mal versucht, aber spätestens beim 3. mal schalten ging nichts mehr. Es war auch egal welchen Befehl ich absetzte. on, on-for-timer und blink hab ich versucht und die mega ist immer nach ein paar versuchen abgestürzt.   

Meine Defines:
define FIRMATA FRM 3030 global
attr FIRMATA sampling-interval 1000
attr FIRMATA verbose 3

define allgVorzimmerLicht FRM_IN 47
attr allgVorzimmerLicht IODev FIRMATA
attr allgVorzimmerLicht alias Licht
attr allgVorzimmerLicht devStateIcon .*on.*:light_ceiling_off .*off.*:light_ceiling@green
attr allgVorzimmerLicht group 1. Vorzimmer
attr allgVorzimmerLicht internal-pullup on
attr allgVorzimmerLicht room 5. Wohnung
attr allgVorzimmerLicht stateFormat reading

define allgVorzimmerLichtSchalten FRM_OUT 48
attr allgVorzimmerLichtSchalten IODev FIRMATA
attr allgVorzimmerLichtSchalten alias Licht schalten
attr allgVorzimmerLichtSchalten group 1. Vorzimmer
attr allgVorzimmerLichtSchalten restoreOnReconnect on
attr allgVorzimmerLichtSchalten restoreOnStartup on
attr allgVorzimmerLichtSchalten room 5. Wohnung
attr allgVorzimmerLichtSchalten stateFormat value
attr allgVorzimmerLichtSchalten webCmd on-for-timer 1


Bin schon kurz vorm verzweifeln... Hat jemand eine Idee?

Grüße

Edit:
Ausserdem hab ich nach jedem FHEM Neustart diese Fehlermeldungen im Log:
2014.04.02 16:42:07.494 1: Including ./FHEM/arduino.cfg
2014.04.02 16:42:07.518 3: [HourCounter] HourCounter_Initialize.215 Init Done with Version 1.02 - 17.03.2014 (john)
2014.04.02 16:42:07.527 3: Registering GEOFANCY geofancy for URL /geo...
2014.04.02 16:42:07.530 3: kuGeschirrspuehler: I/O device is jeelink
2014.04.02 16:42:07.533 3: kuKuechenGeraete: I/O device is jeelink
2014.04.02 16:42:07.545 2: error initializing 'allgVorzimmerLichtSchalten': allgVorzimmerLichtSchalten, FIRMATA is not connected
2014.04.02 16:42:07.545 3: Licht schalten
2014.04.02 16:42:07.545 3: 1. Vorzimmer
2014.04.02 16:42:07.545 3: on
2014.04.02 16:42:07.545 3: on
2014.04.02 16:42:07.545 3: 5. Wohnung
2014.04.02 16:42:07.545 3: value
2014.04.02 16:42:07.545 3: on-for-timer 0.5
2014.04.02 16:42:07.561 2: error initializing 'allgBoiler': allgBoiler, FIRMATA is not connected
2014.04.02 16:42:07.561 3: Arduino
2014.04.02 16:42:07.562 3: value
2014.04.02 16:42:07.563 1: configfile: Licht schalten
1. Vorzimmer
on
on
5. Wohnung
value
on-for-timer 0.5
Arduino
value
2014.04.02 16:42:07.563 1: Including ./log/fhem.save
2014.04.02 16:42:07.601 3: FIRMATA: port 3030 opened
2014.04.02 16:42:07.602 1: usb create starting
2014.04.02 16:42:07.609 3: Probing CUL device /dev/cu.usbmodem1d1321
2014.04.02 16:42:07.609 3: Can't open /dev/cu.usbmodem1d1321: Resource busy
2014.04.02 16:42:07.610 3: Probing TCM310 device /dev/cu.usbserial-AE01DUEH
2014.04.02 16:42:07.610 3: Can't open /dev/cu.usbserial-AE01DUEH: Resource busy
2014.04.02 16:42:07.635 1: usb create end
2014.04.02 16:42:07.638 0: Server started with 283 defined entities (version $Id: fhem.pl 5369 2014-03-30 06:58:52Z rudolfkoenig $, os darwin, user Fabian, pid 8708)
2014.04.02 16:42:07.638 1: HMLAN_Parse: HMLan new condition ok
2014.04.02 16:42:09.834 3: Device szFensterkontakt added to ActionDetector with 028:00 time
2014.04.02 16:42:12.923 3: querying Firmata Firmware Version
2014.04.02 16:42:12.946 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_05
2014.04.02 16:42:14.823 3: FHT8V set wzStellventil valve 18

Anscheinend hat mein Pin 49 irgendetwas. Ich bin draufgekommen das ich gestern, als es problemlos funktionierte, einen anderen PIN verwendet hab.
Umgesteckt und es funktioniert -.- Auf die Idee hätte ich auf früher kommen können..  ::)

Die Fehlermeldungen nach dem start hab ich aber immer noch.


Grüße

Edit
Nun ist das ding schon wieder abgestürzt. Für heut hab ich die Nase voll...
Diese Fehlermeldung steht im FHEM log.
2014.04.02 18:05:59.727 3: set allgBoiler on : Can't call method "message_prepare" on an undefined value at FHEM/lib/Device/Firmata/Platform.pm line 481.
2014.04.02 18:05:59.727 3: n_allgBoiler return value: Can't call method "message_prepare" on an undefined value at FHEM/lib/Device/Firmata/Platform.pm line 481

die 'Firmata is not connected'-meldung beim Fhem-start ist kein Fehler im eigentlichen Sinn, das liegt einfach daran, dass der Arduino ein bischen braucht um sich mit FHEM zu verbinden.

der andere Fehler läßt darauf schließen, dass die Netzverbindung zum Arduino (temporär) unterbrochen war.

Gruß,

Norbert

Hallo,

ich bekomme beim schalten folgende Fehlermeldung

Rollo_ab no IODev assigned at ./FHEM/10_FRM.pm line 587

fhem.cfg
#####################
....
define FRM FRM 3030 [global]

define OWio OWX 3 // Pin 3 am Arduino
attr OWio IODev FRM
define OWX_28_BAXXXX OWTHERM DS18B20 BAXXXX
......

define Rollo_ab FRM_OUT 5

define Rollo_auf FRM_OUT 6

#####################
hatte schonmal funktioniert, kann leider mit der Fehlermeldung nichts anfangen?

Für eine Rückmeldung besten Dank

Grüße
fhemegon

Dem Rollo_ab fehlt das IODev (http://fhem.de/commandref.html#IODev). Seit einer Änderung in fhem (an der AssignIoPort)-funktion muss das an allen FRM-clients gesetzt sein. (Setzt sich bei manuellem definieren bei laufendem fhem von selber, aber leider nicht, wenn FHEM ohne diese IODev-attribute in der fhem.cfg startet). Kann man auch über das Webfrontend machen, danach aber Save Config drücken.

Zitat von: fhemegon am 03 April 2014, 20:42:59
define FRM FRM 3030 [global]
......
define Rollo_ab FRM_OUT 5
attr Rollo_ab IODev FRM

define Rollo_auf FRM_OUT 6
attr Rollo_auf IODev FRM
#####################

Gruß,

Norbert

Zitat von: ntruchsess am 16 März 2014, 12:51:05
OneWire in der ConfigurableFirmata ist erst mal eine reine Softwarelösung, bei der der Arduino selber der Busmaster ist und das komplette Timing ganz ohne DS-irgendwas abwickelt. Die Vorteile eines speziellen Busmasters sind da gering (entlastet zwar den µC, aber das muss man erst mal so implementieren, dass der in der gesparten Zeit tatsächlich was anderes machen kann). Nur bei längeren Bussen mit vielen Chips dran kann ein spezialisierter Busmaster (mit eingebauter Slewrate-control) echte Vorteile bringen.
Aber der DS2480 ist wenig sinnvoll, RX/TX ist bei den Arduinos mit USB ja schon belegt und nur die Mega2560 und Due haben mehrere Hardware-serials. Der DS2482 mit I2C ist da die bessere Wahl, davon kann man ja auch bis zu 4 Stück an einem I2C-bus anschließen. Die ConfigurableFirmata-anbindung dafür habe ich im Oktober schon mal implementiert (https://github.com/ntruchsess/arduino/tree/DS2482). Braucht allerdings noch Feinschliff, der DS2482 macht das Timing doch nicht komplett autonom wie ich ursprünglich dachte, da muss der µC mitarbeiten (ist beim DS2480 genauso). Das ist auch der Grund, warum eine Lösung, bei der die Intelligenz direkt am 1-Wire bus und nicht am anderen Ende einer 'verlängerten seriellen Schnittstelle' sitzt, sinnvoller ist. Da hängt die Stabilität nicht von der Qualität der Netzwerkverbundung ab. Der primäre Nachteil ist: der Arduino spricht kein owfs (hat noch niemand implementiert), sondern z.B. Firmata.

Falls Du eine Platine mit DS2482 für den Arduino machen willst: Am besten fände ich persönlich, wenn man die Platine direkt huckepack auf ein ENC28J60-modul (wie z.B. dieses (http://www.ebay.de/itm/mini-ENC28J60-Ethernet-LAN-Netzwerk-Modul-Arduino-RJ45-SPI-CP01002-C44-/271348956366?pt=Wissenschaftliche_Ger%C3%A4te&hash=item3f2da87cce) stecken könnte und obendrauf einen 'Arduino mini pro (http://www.ebay.de/itm/New-Mini-Pro-Compatible-Nano-Atmega328-5V-16M-Replace-ATmega128-For-Arduino-ESY-/121282344052?pt=LH_DefaultDomain_0&hash=item1c3cfdb474)'. Das hätte dann den kleinsten möglichen Formfaktor. Kann aber sein, dass andere lieber ein Shield im standard-Arduino-layout hätten. Als dritte Alternative einfach eine Platine, auf die man einen Arduino-nano aufstecken kann - da kann man dann ein Enc28J60-Ethernet-shield für Nano (http://www.ebay.de/itm/Ethernet-Shield-for-Arduino-Nano-UNO-R3-work-as-ENC28J60-RJ45-Webserver-/111242798349?pt=Wissenschaftliche_Ger%C3%A4te&hash=item19e696650d) dazwischenstecken. Ist halt etwas teuerer als die Variante 'Mini Pro + ENC28J60-breakoutboard'...

Gruß,

Norbert

Hallo Norbert,
ich greife das Thema nochmal auf. Ich habe immermal wieder hänger in FHEM weil der owserver nicht antwortet, aus welchem Grund auch immer. (nonblocking ist deaktiviert)
Ich würde gerne eine DS2482 Platine für ein Hutschienenmodul bauen auf die sowohl die ETH-Platine als auch der Arduino Mini Pro sitzt. Blöderweise wird die ETH-Platine mit 3.3V betrieben, muss also noch zusätzlich ein Spannnugswandler mit drauf...

Jetzt die Fragen:
1. können meherer DS2482 mit einem Arduino Mini mit Firmata angesteuert werden?
2. Funktioniert jetzt schon sauber der Betrieb mit einem DS2482?

Ich benötige zwingend einen "echten" Busmaster da ich 2 sehr große Busnetze habe mit sehr vielen Clients (ca 40Stk) dran. Wenn möglich möchte ich ein Abfrageintervall von unter 5sek bei ca 15x DS2406 haben . Leitungslängen bis zu 60m

Zitat von: Tobias am 04 April 2014, 11:05:46
1. können meherer DS2482 mit einem Arduino Mini mit Firmata angesteuert werden?
2. Funktioniert jetzt schon sauber der Betrieb mit einem DS2482?

1) Grundsätzlich ja. Natürlich teilen die sich die Rechenzeit und Bandbreite der Schnittstelle. D.h. es können z.B. nicht mehrere parallele 1-Wire searches auf einem einzelnen Arduino gleichzeitig laufen. Wenn jeder Busmaster seinen eigenen Arduino hat, dann schon.

2) keine Ahnung, Ich habe das DS2482 Firmatafeature (https://github.com/ntruchsess/arduino/commits/DS2482/utility/DS2482.cpp) vor einem halben Jahr geschrieben. Es hat auch funktioniert, war aber in meinem Testaufbau auch nicht stabiler als die Softwarelösung. Das lag aber wohl eher daran, dass ich in beiden Fällen den Bus nur mit einem einzigen Pullup-wiederstand ohne jede weitere Entstörmaßname angeschlossen habe. Ich habe das seitdem nicht weiter verfolgt. Aber wenn sich jemand (z.B. Du ;-)) um eine robuste, und im Hinblick auf die Strong-pullup-möglichkeiten des DS2482 vollständige Auslegung der Hardwareseite kümmern würde, dann würde ich die Softwareseite auch wieder in die Hand nehmen :-)

ich kümmer mich mal drum... aber nicht heute und morgen ;) Bin gerade mit meinem Innenraumsensor ausgelastet...
Hab mal von beiden ein Exemplar zum testen bestellt... Versand dauert ja 4Wochen

Als Bauteile sehe ich vorerst diese vor:
- Arduino (http://www.ebay.co.uk/itm/New-Pro-Mini-atmega328-5V-16M-Replace-ATmega128-Arduino-Compatible-Nano-TF-/291112526853?pt=LH_DefaultDomain_0&hash=item43c7a8a405)
- Ethernet LAN (http://www.ebay.co.uk/itm/251202467066?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)

Zitat von: Tobias am 04 April 2014, 12:50:50
- Arduino (http://www.ebay.co.uk/itm/New-Pro-Mini-atmega328-5V-16M-Replace-ATmega128-Arduino-Compatible-Nano-TF-/291112526853?pt=LH_DefaultDomain_0&hash=item43c7a8a405)
- Ethernet LAN (http://www.ebay.co.uk/itm/251202467066?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)

Passt. Das verlinkte Ethernetmodul hat den nötigen 3.3V Spannungswandler auch schon onboard. Sollte sich direkt an den Arduino anschließen lassen.

Zitat von: ntruchsess am 04 April 2014, 12:59:14
Passt. Das verlinkte Ethernetmodul hat den nötigen 3.3V Spannungswandler auch schon onboard. Sollte sich direkt an den Arduino anschließen lassen.

hehe, hab auch lange danach gesucht... ;)

Hi Norbert,
ich bin jetzt dabei die ConfigurableFirmata mit UIPEthernet zu kompilieren.
Edit: gelaberter Müll entfernt...
Wie kann ich ein Master.zip vom DS2482 Branch bekommen? Auf der github Seite finde ich keinen Link...

Btw: der Wiki Artikel ist nicht mehr aktuell... Der Sketch heißt jetzt ConfigurableFirmata und nicht OneWireSchedulerFirmata

wenn man auf Github über den Knopf 'branches' die Sicht auf den gewünschten Branch einstellt, dann ändert sich auch der hinter dem 'Download ZIP'-Knopf (rechts unten) hinterlegte Link: DS2482.zip (https://github.com/ntruchsess/arduino/archive/DS2482.zip)

Hab grade noch mal den aktuellen Stand der ConfigurableFirmata reingemerged.

Wer Fehler im Wiki findet sollte sie am besten gleich korrigieren ;-)

Gruß,

Norbert

Hi Norbert,
ich fühle mich mal bzgl Wiki angesprochen ;) Wollte nur dir in "deinen" Artikel nicht reinmurksen.

Btw möchte ich dich mal auf diesen Beitrag hier aufmerksam machen..
http://forum.fhem.de/index.php/topic,22608.msg167686.html#msg167686

Zitat von: Tobias am 12 Mai 2014, 12:22:47
Die ENC28J60 Module arbeiten aber nicht per RX/TX sondern per SPI
Aber die Diskussion ist wohl wieder besser hier (http://forum.fhem.de/index.php/topic,10744.msg167689.html#msg167689) aufgehoben ;)

Nun, dann hier. Klär mich mal darüber auf, was ein ENC28J60-modul mit WLAN zu tun hat.
Das von Tobias verlinkte WLAN FunkModul (http://www.aliexpress.com/item/Free-Shipping-serial-TTL-RS232-to-802-11-b-g-n-converter-Embedded-WiFi-Module/659755905.html) hat ganz sicher weder ENC28J60, noch SPI ;-)
[/quote]
Gruß,

Norbert

Ich habe jetzt  mal ConfigurableFirmata auf den Arduino Mini Pro per ParallelProgrammer geflashed. Ging gut. Außer das es kein zweites Mal mehr funktioniert :( Die LED auf dem Mini hat ein schwaches Dauerleuchten. Der angeschlossene ENC ist im Netzwerk angemeldet. Auf der Fritzbox sehe ich die vergebene IP. Hab den ENC nur per VCC/Gnd + Mosi/Miso/SCK/CS an die korrespondierenden Pins auf dem ArduinoMini angeschlossen. Mehr nicht

Ist das Normal das die LED auf dem Mini dauerleuchtet?

Zitat von: Tobias am 12 Mai 2014, 21:19:21
Ist das Normal das die LED auf dem Mini dauerleuchtet?

wenn Dein Mini Pro dieses Schaltbild (http://arduino.cc/de/uploads/Main/Arduino-Pro-Mini-schematic.pdf) hat, dann hängt eine LED an PB5 (= SCK). Dann ist es normal, dass die ein bischen leuchtet.

Ist ein atmega328p und der enc hängt an Pin 10,11,12,13
Ich such morgen mal raus wo die LED dran hängt

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

So, das ist der Schaltplan (http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/Arduino-Pro-Mini-v13.pdf) des Arduino Pro Mini. Die LED hängt auch hier am PB5/SCK.

* 14 Digital input / output ports RX, TX D13, D2 ~~ of,
* 2 or 8 analog input port A0 to A7
* The TTL level serial transceiver port RX / TX
* 6 PWM ports, D3,, D5 , D6, D9, D10, D11
* Using Atmel Atmega328P-AU microcontroller
* supports serial download
* Support for external 3.3V ~ 12V DC power supply
* Support 9V battery-powered
* clock frequency 16MHz
* Dimensions: 33.3 * 18.0 (mm)

Ich weiß noch nicht warum sich der Mini nicht ein 2tes Mal flashen lässt. Angeschlossen zum Programmieren hab ich nur GND/VCC/RX/TX. CTS und DTR benötige ich nicht, korrekt? Oder ist es besser per ISP zu flashen?

Kann ich davon ausgehen das die Kommunikation mit dem ENC per SPI grundsätzlich funktioniert wenn dieser sich per DHCP am Netzwerk anmeldet? Im Sketch habe ich die fixe IP auskommentiert damit DHCP genutzt wird.

Final ist es, wie vor ein paar Monaten angedeutet, das Ziel, den Mini, den ENC und optional einen DS2482 in einem DIN Hutschienengehäuse unterzubringen

Der zum Flashen nötige Autoreset wird beim Arduino über das DTR-signal erzeugt (über den 0.1µF Kondensator C2 auf dem von Dir verlinkten Schaltplan). Alternativ kann man unmittelbar vor dem Flashen den Arduino auch manuell resetten.

Wenn sich der Arduino eine DHCP-addresse abholt, dann funktioniert SPI. Wenn man eine fixe IP benutzt kann man UDP abstellen (in uipethernet-conf.h), dann hat man ca. 5kb mehr Flash (und natürlich auch mehr RAM) frei für Firmata-features. Wenn man auschließlich 1-Wire benutzen will ist das natürlich kein Thema, das sollte auch mit DHCP passen, ansonsten muss man halt probieren, was geht (Man kann zwar mit 'avr-size' schauen, was wieviel Speicher initial belegt ist. Ob der Heap dann tatsächlich reicht kann avr-size allerdings nicht vorhersagen). Wenn der Heap nicht reicht stürzt der Arduino in der Regel einfach ab oder startet neu.

Gruß,

Norbert

Hallo Norbert,

nachdem ich es schon ohne große Probleme geschafft hatte, einen Arduino Uno+Ethernet Shield WizNet W5100 mit Configurable Firmata ins Netz zu bringen, verzweifle ich an Arduino Nano V3 + Ethernet Shield ENC28J60. Könntest Du mal kurz schauen, ob meine Anpassung in dem bekannten Code-Abschnitt in Ordnung ist?


  // Network Firmata communicates with Ethernet-shields over SPI. Therefor all
  // SPI-pins must be set to IGNORE. Otherwise Firmata would break SPI-communication.
  // add Pin 10 and configure pin 53 as output if using a MEGA with Ethernetshield.
  // No need to ignore pin 10 on MEGA with ENC28J60, as here pin 53 should be connected to SS:
#ifdef NETWORK_FIRMATA
  // ignore SPI and pin 4 that is SS for SD-Card on Ethernet-shield
  for (byte i=0; i < TOTAL_PINS; i++) {
    if (IS_PIN_SPI(i)
        || 10==i
        // || 10==i //explicitly ignore pin 10 on MEGA as 53 is hardware-SS but Ethernet-shield uses pin 10 for SS
        ) {
      Firmata.setPinMode(i, IGNORE);
    }
  }
// pinMode(PIN_TO_DIGITAL(53), OUTPUT); configure hardware-SS as output on MEGA
  pinMode(PIN_TO_DIGITAL(10), OUTPUT); // switch off SD-card bypassing Firmata
  digitalWrite(PIN_TO_DIGITAL(4), HIGH); // SS is active low;


Ansonsten habe ich die beiden "Dinger" nach folgendem Schema verbunden:
http://arduino.alhin.de/index.php?n=24 (http://arduino.alhin.de/index.php?n=24)

Gruß
Blueberry63

...noch schnell eine Frage hinterher: kann/muss man sich irgendeine MAC-Adresse für das Ethernet Shield ausdenken? Es ist nämlich keine MAC Adresse aufgedruckt.

Gruß
Blueberry

passt soweit eigentlich. Darauf kannst Du aber verzichten (das ist für den SD-Card-reader des originalen WIZ5100-ethernet shield):

'digitalWrite(PIN_TO_DIGITAL(4), HIGH); // SS is active low;'

den '|| 10==i' braucht's eigentlich auch nicht (der sollte beim Nano im IS_PIN_SPI(i)-macro mit drin sein), schadet aber auch nix.
Mac-addresse musst Du Dir ausdenken (oder lassen, was im Sketch steht). Keine besonderen Anforderungen außer dass sie in Deinem eigenen Segment (d.h. alles was physikalisch am gleichen Switch, Hub oder Router hängt) eindeutig sein muss.

Aber wahrscheinlich hast Du einfach zu viele Features gleichzeitig aktiviert. I2C und 1Wire passen z.B. nicht gleichzeitig mit UIPEthernet ins RAM eines ATMega328. Kann man zwar noch flashen, stürzt dann aber mangels ausreichend Heap sofort ab. Also erst mal sparsam anfangen und nur die Dinge, die Du wirklich nutzen willst gleichzeitig aktivieren. Wenn's geht, dann eine fixe IP verwenden (kein DHCP), dann kannst Du UDP in der uipethernet-conf.h abstellen - das spart ca. 5kb Flash und ein paar 100 Bytes RAM.

Gruß,

Norbert

mhh, dann habe ich ja eigentlich alles richtig gemacht. Du hast nicht zufällig  ::)  einen Minimal-Sketch für "Arduino Nano V3 + Ethernet Shield ENC28J60", den man zum Testen der Netzwerkanbindung nehmen kann? Wäre sicher auch für andere interessant.

Alternativ könnte ich meinen Sketch hier posten.

Gruß
Blueberry63

probier doch erst mal, ob die Beispiele der UIPEthernet-library funktionieren um sicher zu gehen, dass mit der Hardware alles passt.

Hallo Norbert,

sorry, ich wollte einfach zu schnell zu viel. Ich werde morgen nochmal "klein" anfangen und mit den UIPEthernet-libraries testen.

Gute Nacht
Blueberry63

bei einem "MinimalSketch" ist auch noch wichtig zu wissen, das die erste Kompilierung fehl schlägt :(
Man muss erst "oberhalb" des 1wire-Includes alles aktiviert lassen und nach der Kompilierung (aber abbruch wegen zu großem Sketch) kann (muss) man erst die nicht benötigten Features  herausnehmen.

Mein Sketch für den Arduino Mini Pro (Atmega 328p) mit DHCP, UIP-Library und 1wire ist gute 29kb groß. Passt also gerade so in die 32kb Flash.
Wenn ich den zum fliegen bekommen habe wechsel ich auf ConfigurableFirmata mit DS2482 Unterstützung...

Edit: Habe den Wiki-Artikel  (http://www.fhemwiki.de/wiki/Arduino_mit_OneWireFirmata)mal angepasst

Edit2: wird beim ENC in unserem 1wireKontext eigentlich der Reset- und INT-Pin benötigt? Siehe hier (http://www.geeetech.com/wiki/index.php/Arduino_ENC28J60_Ethernet_Module#Usage).

Zitat von: Tobias am 14 Mai 2014, 07:15:50
Edit: Habe den Wiki-Artikel  (http://www.fhemwiki.de/wiki/Arduino_mit_OneWireFirmata)mal angepasst

danke :-)

Zitat von: Tobias am 14 Mai 2014, 07:15:50
Edit2: wird beim ENC in unserem 1wireKontext eigentlich der Reset- und INT-Pin benötigt? Siehe hier (http://www.geeetech.com/wiki/index.php/Arduino_ENC28J60_Ethernet_Module#Usage).

nein.

Aktuell habe ich folgendes Problem: Ich habe den Sketch mit ENC28J60 am laufen. Daran hängen 3 DS18B20 und ein Relaisboard. Die Temperaturen lassen sich auslesen, die Relais schalten. Aber mein Problem ist, daß nach einiger Zeit (ungefähr einmal pro Tag) sich FHEM aufhängt und nicht mehr erreichbar ist. Die letzte Fehlermeldung im Log ist meistens:

3030 disconnected, waiting to reappear

Man muß dann FHEM neu starten, Problem ist dann allerdings daß er Firmata nicht mehr findet, der Arduino ist im Status listening. Erst wenn man den Arduino mit Firmata neu startet, läuft alles wieder. Problem ist, den Arduino kann man ja schlecht aus der Ferne starten (aus FHEM ist er ja nicht erreichbar, auf Ping reagiert er auch nicht mehr).

@blueberry63: Wenn du brauchst, könnte ich Dir eine Sketch für den Arduino Nano mit OneWire und Digital In/out zur Verfügung stellen, DHCP ist aus Platzgründen nicht drin. Funktioniert soweit problemlos - bis auf mein oben geschildertes Problem mit dem Verlieren der Verbindung zu FHEM

Zitat von: T.ihmann am 14 Mai 2014, 09:15:39
... und ein Relaisboard.
[...]

Code Auswählen Erweitern

3030 disconnected, waiting to reappear
[...]
auf Ping reagiert er auch nicht mehr.

Du bist leider nicht der erste bei dem der Arduino wg. Störungen vom Relais-board abschmiert. Die Relais müssen hinreichend funkentstört und möglichst potentialfrei über Optokoppler angebunden sein. Dann die Relais nicht zu nah an den Arduino positionieren (hochfrequente Störungen gehen ja auch durch die Luft) und ein Verbindungskabel mit Ferritring zum entstören verwenden.
Und/oder dem Arduino noch einen Watchdog spendieren.

Gruß,

Norbert

Zitat
...noch schnell eine Frage hinterher: kann/muss man sich irgendeine MAC-Adresse für das Ethernet Shield ausdenken? Es ist nämlich keine MAC Adresse aufgedruckt.

Hat dazu jemand eine Antwort.

@T.ihmann
Du könntest mir den Sketch ja mal posten, dann habe ich noch eine Vergleichs-Möglichkeit

Danke
Blueberry63

MAC Adresse kann man sich frei ausdenken...

Zitat von: blueberry63 am 14 Mai 2014, 11:04:30
Hat dazu jemand eine Antwort.

Lesen bildet:

Zitat von: ntruchsess am 13 Mai 2014, 22:02:47
Mac-addresse musst Du Dir ausdenken (oder lassen, was im Sketch steht). Keine besonderen Anforderungen außer dass sie in Deinem eigenen Segment (d.h. alles was physikalisch am gleichen Switch, Hub oder Router hängt) eindeutig sein muss.

Ich habe im Forum / Internet mal nach Watchdog gesucht, sollte ja wohl mit


#include <avr/wdt.h>
wdt_enable(WDTO_2S);
wdt_reset();


gehen. Die letzte Zeile muß irgendwie in den Loop hinein. Nur an welche Stelle im Beispiel Sketch. Könntet Ihr hier noch mal eine Tipp geben. Ich möchte keine Dauer-Reboot-Schleife auf meinen Arduino flashen..

Hallo,

melde mich kurz zurück. Ich hatte wohl einen Verkabelungsfehler, aber jetzt ist der Nano im Netz  :D, sogar mit der Configurable Firmata. Nun würde ich gerne das Servo-Modul verwenden, aber dafür ist der Speicher wohl zu klein. Hat jemand einen Tip, was die Minimal-Konfig. ist, wenn man das Servo-Modul via Ethernet verwenden möchte?

Gruß
Blueberry63

Was willst Du denn verwenden, Nano mit UipEthernet Digital in/out, OneWire, Servo hat bei mir eine Größe von 29528 Bytes ohne DHCP. Kannst noch UDP rauskonfigurieren, spart auch noch etwas. Es sollte immer etwas Platz sein, sonst funktioniert UipEthernet manchmal nicht

Hallo Norbert,

das erneute flashen mit verbundenem DTR hat funktioniert, danke!
Der Arduino holt sich jetzt seine IP per DHCP und connected erfolgreich zu FHEM. Das FRM Device habe ich vorher definiert. SUPER!!!

Jetzt scheitere ich allerdings an folgendem WIKI Satz:

ZitatWenn man das FRM device schon definiert hat, findet man im laufenden FHEM unter den FRM-attributen einen Eintrag: 'onewire-pins', dieser listet alle Pins auf, die OneWire unterstützen:

Wo finde ich 'onewire-pins'?? Habe mir die Attribute von meinem FRM-Device und neuem OWX-Device angeschaut aber keinen derartigen Eintrag gefunden. Auch in der Commandref zum FRM steht nichts.

Btw: Wenn ich von diesem Schaltplan (http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/Arduino-Pro-Mini-v13.pdf) ausgehe, und ich schließe OneWire an D2 an, muss dann als OWX-Pin 32 angegeben werden?
Kann ich zb. auch analoge Pins angeben? zb. A0 (PC0/ADC0)

@t.ihmann,

ich habe die temporäre Lösung aus diesem Thread auf einem UNO realisiert:

http://forum.fhem.de/index.php/topic,22320.0.html (http://forum.fhem.de/index.php/topic,22320.0.html)

Es geht hier darum, mittels RC-Switch und eines angepassten Servo-Moduls über RF433 handelsübliche Funksteckdosen zu steuern. Das funktioniert bei mir auch ganz gut.

Z.zt. sind Norbert und Michael dabei, das Ganze in Firmata zu implementieren. Ich warte also besser auf dieses Ergebnis. Vielleicht passt diese Version ja dann auf einen NANO.

Gruß
Blueberry63

Zusätzlich zu meinen obigen Fragen noch etwas:
mir ist aufgefallen das der ENC den Link (grüne/gelbe LED) oft einfach beendet, sich vorher aber auch nicht per DHCP angemeldet wird. Kann das sein das sich der ENC einfach abschaltet (die rote LED auf der Platine bleibt aber an) wenn keine IP erhalten wird? Versucht dann der Arduino nach einem bestimmten TimeOut die Verbindung neu herzustellen?
Ich habe die Pins INT/RESET/WOL/CLKOUT des ENC nicht angeschlossen.

Weiterhin ist mir aufgefallen das an einigen Stromversorgungen der Arduino zwar "an" geht, aber anscheinend keine Arbeit aufnimmt, die grüne LED blinkt nicht wie sonst. Ebenfalls geht zwar die rote LED des ENC auf der Platine an, aber kein NetzwerkLink, grüne LED, bleibt aus.
Ist das ganze Konstrukt sehr sensibel bzgl Stromversorgung? Gibt es da ähnliche Erfahrungen?

Die Link-LED ist unabhängig davon, ob eine IP-addresse vergeben wurde oder nicht. Die zeigt ausschließlich die physikalische Verbindung an. Die ConfigurableFirmata ruft regelmäßig Ethernet.maintain() auf. Damit sollte sie eigentlich solange versuchen per DHCP eine Adresse zu bekommen, bis sie schließlich eine hat. Eine vernünftige Stromversorgung des Arduinos bzw. ENC28J60 ist unverzichtbar. Auch wenn es in der Regel schon funktioniert - wenn Du den ENC28J60 über den 3,3V Spannungsregler des Arduinos versorgst, kann es knapp werden, der bringt ja nur recht wenig Strom, je nachdem, was der Arduino sonst noch so macht.

Gruß,

Norbert

Norbert, Danke!
Hast du auch hierfür noch eine Antwort?

ZitatWo finde ich 'onewire-pins'??

Zitat von: Tobias am 16 Mai 2014, 13:12:52
Wo finde ich 'onewire-pins'??

in den Internals des FRM-devices

Komisch. Die gab es bei mir nicht... ich teste heute Abend noch einmal

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

@Tobias , war bei dir bei firmware_version mit der Ausgabe Schluss ?
Wenn ja, keine Sorge das passiert immer dann wenn man viel auskommentiert
( bei mir werden die ganzen Pin Zeilen auch nicht angezeigt , hat aber keinen Einfluss auf die Funktion ) 

@wzut: korrekt
Ist aber eine dumme Eigenart :(

Gesendet von meinem ALCATEL ONE TOUCH 997D mit Tapatalk

Ich wieder....
Habe im Sketch nur 1wire aktiviert sowie dhcp ausgeschaltet. Der Sketch ist gute 25kb groß bei 32kb flash.
In meinen Internals sehe ich die onewirePins nicht... siehe screenshot

nach besserer Verkabelung mit stabiler Stromversorgung läuft nun das Gespann warscheinlich stabil...

Habe einen DS2408 und einen DS2438 an Arduino Pin D9 angeschlossen.
define owxFRM owx 9

Leider bekomme ich im Log nur folgendes und die 2 Devices werden nicht per autocreate angelegt :(
2014.05.16 19:48:12 3: querying Firmata Firmware Version
2014.05.16 19:48:12 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2014.05.16 19:51:05 1: OWX: 1-Wire bus owxFRM: interface Firmata detected in MyFRM
2014.05.16 19:51:18 1: OWX: 1-Wire devices found on bus owxFRM ()
2014.05.16 19:51:21 1: OWX: 1-Wire devices found on bus owxFRM ()

Edit: Wenn ich den Arduino vom Netz nehme, verabschiedet sich FHEM :(
Can't call method "packet_onewire_request" on an undefined value at FHEM/lib/Device/Firmata/Platform.pm line 779.
2014.05.16 23:10:07 1: Including fhem.cfg

Nach dem "ungeplanten" Neustart ist FRM wieder im listening Mode. Den Arduino habe ich heute morgen wieder eingeschaltet und es wurde wieder automatisch connected.

Edit2: kann das sein das ich am 1wirePin einen Pullup einziehen muss? Muss mir mal einen 4k7 besorgen....

ja einen 4,7K zwischen Busleitung und 5V habe ich auch überall drin , ohne geht nichts.
Nur noch das OneWire Modul drin ? Irgendwo hatte Norbert mal geschrieben was mindestens drin sein muss bin mir im Moment nicht sicher ob der FirmataScheduler nicht auch noch gebraucht wird.

Firmata Scheduler habe ich auskommentiert, lief auch ohne

Hallo ich würde gerne nach dieser Anleitung einen Wasserstandssenor für meine Zisterne realisieren:

http://forum.hanfburg.de/fhb/showthread.php?t=299000

Es wird mittels Ultraschallsensor die Höhe gemessen, auf dem Arduino wird die Berechnung vorgenommen und im Beispiel auf der seriellen Konsole ausgegeben. Kann ich das Ergebnis auch mit Firmata ausgeben lassen, also Messung und Berechnung auf dem Arduino und Ausgabe per Firmata / Ethernet an Fhem...

Tipp : nimm als Sensor den SFR02 und hänge ihn mit Onewire an Firmata. Um den SFR02 an Onwire zu bringen gibt es fertig :http://forum.fhem.de/index.php/topic,10962.0.html oder   http://forum.fhem.de/index.php/topic,21512.msg149891.html#msg149891

mit dem Pullup klappts auch nicht... Habe das Gefühl mit dem Pin passt etwas nicht.
Habe beim OWX Pin9 angegeben, auf dem Arduino steht auch 9. Hoffe das ist richtig... ODer muss ich den ATMEGA-Pin angeben??
D9 = Atmega Pin 13 = PB1
Im Log mit frm verbose=5 hab ich  folgendes...
2014.05.17 19:26:41 4: Connection accepted from FRM:192.168.10.19:1027
2014.05.17 19:26:41 5: FRM:>ff
2014.05.17 19:26:44 3: querying Firmata Firmware Version
2014.05.17 19:26:44 5: FRM:>f079f7
2014.05.17 19:26:44 5: FRM:<f079020643006f006e0066006900670075007200610062006c0065004600690072006d006100740061002e0069006e006f00f7
2014.05.17 19:26:44 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2014.05.17 19:26:44 5: FRM:>f069f7
2014.05.17 19:26:44 5: FRM:>f06bf7
2014.05.17 19:26:46 5: FRM:>f07a6807f7
2014.05.17 19:26:46 5: FRM:>f40907
2014.05.17 19:26:46 1: possible freeze: timer should 17:26:42, delay is 3.47404909133911
2014.05.17 19:26:46 5: FRM:>f0734009f7
2014.05.17 19:26:49 1: OWX: 1-Wire devices found on bus owxFRM ()
2014.05.17 19:26:49 1: possible freeze: timer should 17:26:47, delay is 2.13275909423828
2014.05.17 19:26:49 5: FRM:>f0730109f7
2014.05.17 19:26:56 5: FRM:>f0734009f7
2014.05.17 19:26:59 1: OWX: 1-Wire devices found on bus owxFRM ()
2014.05.17 19:26:59 1: possible freeze: timer should 17:26:56, delay is 2.86885595321655

Welchen Arduino hast Du denn ? Pin ist nicht gleich Pin, das war auch erst mein Problem

Beim Arduino Nano ist Pin D9 z.B. Pin 12. Sollte auf dem Arduino auch stehen...

Bildquelle: http://www.reseau.org/arduinorc/index.php?n=Main.HomePage

Mein Arduino:
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/Dev/Arduino/Boards/Arduino-Pro-Mini-v13.pdf
Wenn ich das richtig sehe ist D9 der Pin13?? Trotzdem kommt nichts per autocreate :(

Zitat von: Tobias am 17 Mai 2014, 19:21:20
mit dem Pullup klappts auch nicht... Habe das Gefühl mit dem Pin passt etwas nicht.
Habe beim OWX Pin9 angegeben, auf dem Arduino steht auch 9. Hoffe das ist richtig... ODer muss ich den ATMEGA-Pin angeben??
D9 = Atmega Pin 13 = PB1

2014.05.17 19:26:49 1: OWX: 1-Wire devices found on bus owxFRM ()

9 stimmt ein deinem Fall , siehe -> http://arduino.cc/en/Hacking/PinMapping168
die Zeile oben in deinem log zeigt doch auch das an dem Pin etwas in Richtung 1-W gefunden wird.
Teste doch zuerst mal OneWire alleine mit einem simplen Arduino Sketch ganz ohne Firmata. 

Ich bräuchte doch mal Hilfe mit meinem Arduino + Firmata + Ethernet. Das Problem ist der Arduino verschwindet irgendwann, Fhem Log ist dann, Fhem hängt dann komplett:

2014.05.18 11:29:08 1: 3030 disconnected, waiting to reappear (FRM:192.168.178.150:1026)
2014.05.18 11:29:30 1: 192.168.178.25:1000 reappeared (HMLAN1)
2014.05.18 11:29:30 1: HMLAN_Parse: HMLAN1 new condition init
2014.05.18 11:29:31 1: HMLAN_Parse: HMLAN1 new condition ok
2014.05.18 11:31:39 1: CallBlockingFn: Can't connect to localhost:7072

Weiter oben war mal der Vorschlag gekommen, ich solle es mal mit einem Watchdog versuchen, habe ich gemacht, hat aber nichts gebracht, der Arduino hängt dann immer noch, eine LED blinkt ganz wild. Anbei mein Sketch:

/*
* Firmata is a generic protocol for communicating with microcontrollers
* from software on a host computer. It is intended to work with
* any host computer software package.
*
* To download a host software package, please click on the following link
* to open the download page in your default browser.
*
* http://firmata.org/wiki/Download
*/

/*
  Copyright (C) 2006-2008 Hans-Christoph Steiner.  All rights reserved.
  Copyright (C) 2010-2011 Paul Stoffregen.  All rights reserved.
  Copyright (C) 2009 Shigeru Kobayashi.  All rights reserved.
  Copyright (C) 2009-2013 Jeff Hoefs.  All rights reserved.
  Copyright (C) 2013 Norbert Truchsess. All rights reserved.
  Copyright (C) 2014 Nicolas Panel. All rights reserved.
 
  This library is free software; you can redistribute it and/or
  modify it under the terms of the GNU Lesser General Public
  License as published by the Free Software Foundation; either
  version 2.1 of the License, or (at your option) any later version.

  See file LICENSE.txt for further informations on licensing terms.

  formatted using the GNU C formatting and indenting
*/


#include <Firmata.h>

/*
* by default Firmata uses the Serial-port (over USB) of Arduino.
* ConfigurableFirmata may also comunicate over ethernet using tcp/ip.
* To configure this 'Network Firmata' to use the original WIZ5100-based
* ethernet-shield or Arduino Ethernet uncomment the includes of 'SPI.h' and 'Ethernet.h':
*/

//#include <SPI.h>
//#include <Ethernet.h>

/*
* To configure 'Network Firmata' to use an ENC28J60 based board include
* 'UIPEthernet.h' (no SPI.h required). The UIPEthernet-library can be downloaded
* from: https://github.com/ntruchsess/arduino_uip
*/

#include <UIPEthernet.h>

#if defined ethernet_h || defined UIPETHERNET_H
/*==============================================================================
* Network configuration for Network Firmata
*============================================================================*/
#define NETWORK_FIRMATA
//replace with ip of server you want to connect to, comment out if using 'remote_host'
#define remote_ip IPAddress(192,168,178,20)
//replace with hostname of server you want to connect to, comment out if using 'remote_ip'
//#define remote_host "server.local"
//replace with the port that your server is listening on
#define remote_port 3030
//replace with arduinos ip-address. Comment out if Ethernet-startup should use dhcp
#define local_ip IPAddress(192,168,178,150)
//replace with ethernet shield mac. It's mandatory every device is assigned a unique mac
const byte mac[] = {0x90,0xA2,0xDA,0x0D,0x08,0x03};
#endif

// To configure, save this file to your working directory so you can edit it
// then comment out the include and declaration for any features that you do
// not need below.

// Also note that the current compile size for an Arduino Uno with all of the
// following features enabled is about 22.4k. If you are using an older Arduino
// or other microcontroller with less memory you will not be able to include
// all of the following feature classes.

#include <utility/DigitalInputFirmata.h>
DigitalInputFirmata digitalInput;

#include <utility/DigitalOutputFirmata.h>
DigitalOutputFirmata digitalOutput;

#include <avr/wdt.h>

//#include <utility/AnalogInputFirmata.h>
//AnalogInputFirmata analogInput;

//#include <utility/AnalogOutputFirmata.h>
//AnalogOutputFirmata analogOutput;

//#include <Servo.h> //wouldn't load from ServoFirmata.h in Arduino1.0.3
//#include <utility/ServoFirmata.h>
//ServoFirmata servo;

//#include <Wire.h> //wouldn't load from I2CFirmata.h in Arduino1.0.3
//#include <utility/I2CFirmata.h>
//I2CFirmata i2c;

#include <utility/OneWireFirmata.h>
OneWireFirmata oneWire;

//#include <utility/StepperFirmata.h>
//StepperFirmata stepper;

#include <utility/FirmataExt.h>
FirmataExt firmataExt;

//include <utility/FirmataScheduler.h>
//FirmataScheduler scheduler;

#include <utility/EncoderFirmata.h>
EncoderFirmata encoder;


// dependencies. Do not comment out the following lines
#if defined AnalogOutputFirmata_h || defined ServoFirmata_h
#include <utility/AnalogWrite.h>
#endif

#if defined AnalogInputFirmata_h || defined I2CFirmata_h || defined EncoderFirmata_h
#include <utility/FirmataReporting.h>
FirmataReporting reporting;
#endif

// dependencies for Network Firmata. Do not comment out.
#ifdef NETWORK_FIRMATA
#if defined remote_ip && defined remote_host
#error "cannot define both remote_ip and remote_host at the same time!"
#endif
#include <utility/EthernetClientStream.h>
EthernetClient client;
#if defined remote_ip && !defined remote_host
#ifdef local_ip
  EthernetClientStream stream(client,local_ip,remote_ip,NULL,remote_port);
#else
  EthernetClientStream stream(client,IPAddress(0,0,0,0),remote_ip,NULL,remote_port);
#endif
#endif
#if !defined remote_ip && defined remote_host
#ifdef local_ip
  EthernetClientStream stream(client,local_ip,IPAddress(0,0,0,0),remote_host,remote_port);
#else
  EthernetClientStream stream(client,IPAddress(0,0,0,0),IPAddress(0,0,0,0),remote_host,remote_port);
#endif
#endif
#endif

/*==============================================================================
* FUNCTIONS
*============================================================================*/

void systemResetCallback()
{
  // initialize a defalt state

  // pins with analog capability default to analog input
  // otherwise, pins default to digital output
  for (byte i=0; i < TOTAL_PINS; i++) {
    if (IS_PIN_ANALOG(i)) {
#ifdef AnalogInputFirmata_h
      // turns off pullup, configures everything
      Firmata.setPinMode(i, ANALOG);
#endif
    } else if (IS_PIN_DIGITAL(i)) {
#ifdef DigitalOutputFirmata_h
      // sets the output to 0, configures portConfigInputs
      Firmata.setPinMode(i, OUTPUT);
#endif
    }
  }

#ifdef FirmataExt_h
  firmataExt.reset();
#endif
}

/*==============================================================================
* SETUP()
*============================================================================*/

void setup()
{
wdt_enable(WDTO_2S);
#ifdef NETWORK_FIRMATA
#ifdef local_ip
  Ethernet.begin((uint8_t*)mac,local_ip);  //start ethernet
#else
  Ethernet.begin((uint8_t*)mac); //start ethernet using dhcp
#endif
  delay(1000);
#endif
  Firmata.setFirmwareVersion(FIRMATA_MAJOR_VERSION, FIRMATA_MINOR_VERSION);

#if defined AnalogOutputFirmata_h || defined ServoFirmata_h
  /* analogWriteCallback is declared in AnalogWrite.h */
  Firmata.attach(ANALOG_MESSAGE, analogWriteCallback);
#endif

  #ifdef FirmataExt_h
#ifdef DigitalInputFirmata_h
  firmataExt.addFeature(digitalInput);
#endif
#ifdef DigitalOutputFirmata_h
  firmataExt.addFeature(digitalOutput);
#endif
#ifdef AnalogInputFirmata_h
  firmataExt.addFeature(analogInput);
#endif
#ifdef AnalogOutputFirmata_h
  firmataExt.addFeature(analogOutput);
#endif
#ifdef ServoFirmata_h
  firmataExt.addFeature(servo);
#endif
#ifdef I2CFirmata_h
  firmataExt.addFeature(i2c);
#endif
#ifdef OneWireFirmata_h
  firmataExt.addFeature(oneWire);
#endif
#ifdef StepperFirmata_h
  firmataExt.addFeature(stepper);
#endif
#ifdef FirmataReporting_h
  firmataExt.addFeature(reporting);
#endif
#ifdef FirmataScheduler_h
  firmataExt.addFeature(scheduler);
#endif
#ifdef EncoderFirmata_h
  firmataExt.addFeature(encoder);
#endif
#endif
  /* systemResetCallback is declared here (in ConfigurableFirmata.ino) */
  Firmata.attach(SYSTEM_RESET, systemResetCallback);

  // Network Firmata communicates with Ethernet-shields over SPI. Therefor all
  // SPI-pins must be set to IGNORE. Otherwise Firmata would break SPI-communication.
  // add Pin 10 and configure pin 53 as output if using a MEGA with Ethernetshield.
  // No need to ignore pin 10 on MEGA with ENC28J60, as here pin 53 should be connected to SS:
#ifdef NETWORK_FIRMATA
  // ignore SPI and pin 4 that is SS for SD-Card on Ethernet-shield
  for (byte i=0; i < TOTAL_PINS; i++) {
    if (IS_PIN_SPI(i)
        || 4==i
        // || 10==i //explicitly ignore pin 10 on MEGA as 53 is hardware-SS but Ethernet-shield uses pin 10 for SS
        ) {
      Firmata.setPinMode(i, IGNORE);
    }
  }
//  pinMode(PIN_TO_DIGITAL(53), OUTPUT); configure hardware-SS as output on MEGA
  pinMode(PIN_TO_DIGITAL(4), OUTPUT); // switch off SD-card bypassing Firmata
  digitalWrite(PIN_TO_DIGITAL(4), HIGH); // SS is active low;

  // start up Network Firmata:
  Firmata.begin(stream);
#else
  // start up the default Firmata using Serial interface:
  Firmata.begin(57600);
#endif
  systemResetCallback();  // reset to default config
}

/*==============================================================================
* LOOP()
*============================================================================*/
void loop()
{
wdt_reset();  a
#ifdef DigitalInputFirmata_h
  /* DIGITALREAD - as fast as possible, check for changes and output them to the
   * stream buffer using Firmata.write()  */
  digitalInput.report();
#endif

  /* STREAMREAD - processing incoming messagse as soon as possible, while still
   * checking digital inputs.  */
  while(Firmata.available()) {
    //wdt_reset();
    Firmata.processInput();
#ifdef FirmataScheduler_h
    if (!Firmata.isParsingMessage()) {
      goto runtasks;
    }
  }
  if (!Firmata.isParsingMessage()) {
runtasks: scheduler.runTasks();
#endif
  }

  /* SEND STREAM WRITE BUFFER - TO DO: make sure that the stream buffer doesn't go over
   * 60 bytes. use a timer to sending an event character every 4 ms to
   * trigger the buffer to dump. */

#ifdef FirmataReporting_h
  if (reporting.elapsed()) {
#ifdef AnalogInputFirmata_h
    /* ANALOGREAD - do all analogReads() at the configured sampling interval */
    analogInput.report();
#endif
#ifdef I2CFirmata_h
    // report i2c data for all device with read continuous mode enabled
    i2c.report();
#endif
#ifdef EncoderFirmata_h
    // report encoders positions if reporting enabled.
    encoder.report();
#endif
  }
#endif
#ifdef StepperFirmata_h
  stepper.update();
#endif
#if defined NETWORK_FIRMATA && !defined local_ip
  if (Ethernet.maintain())
    {
      stream.maintain(Ethernet.localIP());
    }
#endif
}

Hat jemand eine Idee für mich ? Vielen Dank. Ist Wdt so richtig in den Sketch eingebaut ?

@T.Ihmann
Mit dem "Verschwinden" hatte ich auch erst zu kämpfen, lag an einer nicht optimalen Stromversorgung. Der Arduino war am Strom angeschlossen und der Ethernetadapter am Arduino. Jetzt hängt der Ethernetadapter direkt an der Stromversorgung und er löppt seit Tagen ohne Probleme durch :)

@Wzut:

Zitat9 stimmt ein deinem Fall , siehe -> http://arduino.cc/en/Hacking/PinMapping168
die Zeile oben in deinem log zeigt doch auch das an dem Pin etwas in Richtung 1-W gefunden wird.
Teste doch zuerst mal OneWire alleine mit einem simplen Arduino Sketch ganz ohne Firmata. 

Der Arduino Mini Pro hat einen ATMEGA328P drauf, ich glaube aber das dieser mit dem ATMEGA168 pinkompatibel ist..?
Wo in meinem Log siehtst du das etwas gefunden wird? Die krytischen Log5 Meldung des FRM -Moduls kann ich auch nicht deuten :(
Z.B. pünktlich alle 5Minuten kommt dieses "FRM:>f073010df7"

Was für einen "simplen" 1w Sketch meinst du? Hänge ich einen "normalen" 1w-Busmaster dran, werden die Devices auch gefunden. Ich überprüfe es aber sicherheitshalber heute abend noch einmal...

Leider ist Norbert gerade abwesend, die Sketch-Minimalkonfiguration für 1wire wäre noch wichtig. Mit oder Ohne Scheduler? Was muss aktiviert werden damit in den Internals die onewire-pins stehen? Auch schmiert FHEM immer ab wenn der Arduino vom Netz getrennt wird :(

Zitat von: Tobias am 19 Mai 2014, 08:06:26
Was für einen "simplen" 1w Sketch meinst du?

z.B sowas : http://playground.arduino.cc/Learning/OneWire-DE , ist zwar für DS1820 gedacht, aber wenn du die Adressen deiner Geräte da siehst kannst  den Punkt doch schon mal den grünen Haken geben.

Um die anderen Dinge zu testen würde ich mal Analog und Digital I/O reinnehmen und Ethernet raus und den Arduino dann seriell an FHEM ankoppeln

Zitat von: Tobias am 19 Mai 2014, 08:06:26
Leider ist Norbert gerade abwesend, die Sketch-Minimalkonfiguration für 1wire wäre noch wichtig. Mit oder Ohne Scheduler? Was muss aktiviert werden damit in den Internals die onewire-pins stehen?

Naja, ich hab halt noch eine andere Baustelle (diesmal eine Echte), die verzehrt im Moment an den Wochenenden einiges von meiner Energie. Hab grade für die Perimeterdämmung mehrere Qubikmeter Erde mit dem Russischen Bagger ausgehoben. Danach kann man abends nicht mehr wirklich gut denken :-(

Also: Scheduler brauchts nicht, der wird von FRM (bisher) noch gar nicht unterstützt. Ich habe vor damit iButtons über OWID mit einer schnellen, arduinoseitig getriggerten Bussuche zu versorgen, aber das ist aktuell noch Zukunftsmusik.

FirmataExt ist für SysEx-basierte Features (wie 1-Wire) unverzichtbar. Ohne FirmataExt geht nur Digital+Analog-I/O.

Zitat von: Tobias am 19 Mai 2014, 08:06:26Auch schmiert FHEM immer ab wenn der Arduino vom Netz getrennt wird :(

Ja, hab ich schon mitgekriegt, Fix ist in Arbeit ;-)

Gruß,

Norbert

Hallo Norbert,
ich kann dich gut verstehen... bin auch vor langer Zeit mal in den Genuss gekommen alleine 130m³ ausheben zu dürfen... allerdings einen ganzen Sommer lang...
Die Sache mit dem Scheduler hört sich zu an als ob Firmata z.Z. garnicht  selbstständig alleine den Bus durchsucht und Änderungen per push an fhem rausgibt? Die Frage, wo ich denn das pollingIntervall einstellen kann, wäre von mir gekommen sobald 1wire bei mir erkannt wird.
Ansich ist es genau DAS Kriterium um von meinen USB-Busmaster auf einen ArduinoBusmaster zu wechseln um das Polling von FEHM auf den Arduino zu verlagern..

Den neuen Sketch mit FirmataExt spiel ich heute abend mal ein und prüfe. Leider habe ich nirgens eine Modulbeschreibung außerhalb der Haupt-Funktionen gefunden, also zb. Wozu ist Stepper/Ext/Encoder da, was macht Servo - Beispiele?
Aber da könnten sich ja bereits vorhandene Anwender dieser Module im Wiki verewigen.
Sobald 1wire bei mir läuft passe auch ich wieder das Wiki an.

Zitat von: Tobias am 19 Mai 2014, 13:35:22
Die Sache mit dem Scheduler hört sich zu an als ob Firmata z.Z. garnicht  selbstständig alleine den Bus durchsucht und Änderungen per push an fhem rausgibt?

Die Bussuche mit FRM läuft schon selbstständig, aber der Startbefehl kommt aktuell vom OWX(_ASYNC). Das könnte man über den Firmatascheduler automatisieren. Würde aber nicht wirklich die Welt an Rechenzeit auf FHEM-seite einsparen, das Start-kommando zur Bussuche ist nur ein paar Bytes lang.

Beim DS2480 ist das anders, da steuert OWX(_ASYNC) jeden Schritt.

Gruß,

Norbert

Zitat von: ntruchsess am 19 Mai 2014, 14:03:12
Die Bussuche mit FRM läuft schon selbstständig, aber der Startbefehl kommt aktuell vom OWX(_ASYNC). Das könnte man über den Firmatascheduler automatisieren. Würde aber nicht wirklich die Welt an Rechenzeit auf FHEM-seite einsparen, das Start-kommando zur Bussuche ist nur ein paar Bytes lang.

Beim DS2480 ist das anders, da steuert OWX(_ASYNC) jeden Schritt.

Mit Startbefehl meinst du das zb. OWTHERM-Define andem ja auch das Intervall hängt? Übernimmt der Arduino dann das Pollen für dieses angegebene Intervall im DeviceDefine oder ein anderes? Das ursprüngliche OWX-Pollen läuft dann warscheinlich ins leere (weil ja Firmata pollt)?
Mit DS2480 meinst du den DS2482? Kommt bei mir im zweiten Schritt...

Tobias,

ich denke, Du hast das Prinzip der OneWire-Firmata noch nicht ganz verstanden. Der Arduino ist in der Lage bestimmte 1-Wire-kommandoabfolgen selbstständig auszuführen. Der Firmata-client (OWX(_ASYNC)) sagt der Firmata entweder: 'mache eine 1-Wire-Bussuche', dann läuft diese auf dem Arduino und schickt das Ergebniss (alle gefundenen Devices) an den Firmata-client zurück. Oder er sagt: 'mache einen Bus-reset, sprich ein bestimmtest Device mit der Addresse XXX an, schicke folgende Bytes dorthin und lese anschließend YY Bytes. Der Arduino tut das und wenn er fertig ist, schickt er die YY Bytes an den Firmata-client zurück. Mehr Intelligenz steckt im OneWire-firmata feature nicht drin. Der Arduino merkt sich dabei nichts. Nach dem Abarbeiten einer 1-Wire-kommandfolge und dem Verschicken des Ergebnisses vergisst er alles, was er getan hat. Mehr Eingenintelligenz wäre bei der Speicherknappheit auch nicht stabil unterzubringen, als Alternaive müsste man die Anzahl der Devices auf dem 1-Wire Bus (stark) einschränken. Das ist aber schon deutlich mehr Eigenintelligenz als die anderen Busmasterchips (DS2480 oder DS2482) mitbringen. Denen muss man jeden Einzelschritt vorgenannter Abfolgen einzeln sagen (und dabei noch auf das korrekte Timing achten). Beim Arduino bedeutet das Starten einer Bussuche, dass OWX gerade einmal 4 Bytes in einem Rutsch abschickt und dann auf das fertige Ergebnis wartet. OWX wartet dabei synchron und blockiert FHEM, OWX_ASYNC wartet in einem Protothread wärend FHEM weiterläuft und der Arduino parallel dazu den 1-Wire-bus durchsucht.

Der FirmataScheduler ist in der Lage Firmata-kommando-abfolgen zu speichern und zeitversetzt (auch zyklisch) abzuspielen, damit kann man sich das Senden der genannten 4 Bytes zum Starten der Bussuche sparen. Der Arduino schickt dann die Ergebnisse selbstständig im vorgegebenen Interval. Leider kann man (wg. des begrenzten Speichers) keine komplexeren Aufgaben im FirmataScheduler unterbringen, insbesonders kann man nicht einfach mal alle Device-abfragen da rein programmieren, da wäre schon nach einer Handvoll Devices der Speicher des Arduinos voll. (Eine DS18B20 Abfrage braucht z.B. ca. 30 Bytes pro Device. Das klingt nach wenig, ist aber eine ganze Menge, wenn nur wenige 100kb verfügbar sind). Ist der Speicher zu Ende stürzt der Arduino einfach ab bzw. resettet sich.

Nur mal soviel dazu, was man erwarten kann und was nicht.

Gruß,

Norbert

P.S. wenn man einen DS2482 am Arduino hat, dann ändert das nichts prinzipielles an oben gesagtem. Mit dem DS2482 hat der Arduino ggf. ein physikalisch besser an 1-Wire angepasstes Interface und muss weniger Timing selber in Software machen. Damit sollten mehr Devices bei längerem 1-Wire-bus funktionieren, als mit der reinen Softwarelösung. Alle anderen Einschränkungen und/oder Möglichkeiten sind aber praktisch identisch.

Hallo NOrbert,
vielen Dank für die doch recht ausführliche Antwort :) Diese allgemeinen Grundlagen fehlten zum Verständnis was ich erwarten kjann und was nicht. Habe ich auch  noch nirgends gefunden. Aber ev. ging nur mir das so :(
Ich werde das Ganze mal im WikiArtikel aufarbeiten.

Jetzt zu den Erfolgsmeldungen:
Habe jetzt Firmata_Ext mit im Sketch und prompt Fehlermeldungen in FHEM bekommen.
Ich musste noch manuell ProtoThreads.pm nachladen:
wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/lib/ProtoThreads.pm
Könnte man das ev. mit im Standard-FHEM-SVN einchecken?

Als nächstes startete FHEM erst garnicht und ist mit dem Fehler abgebrochen:
error initializing 'owxFRM': unsupported mode '7' for pin '13'
Dadurch das im FRM Device die onewire-pins nicht ausgegeben werden musst ich probieren. Pin 12 ging auch nicht, aber Pin9 = D9 und funktionierte. Wie ich schon weiter oben schrieb wäre es schön wenn diese noch angezeigt werden könnten :)
Manuelles Ändern der fhem.cfg sowie ein restart und mein DS2438 und DS2408 wurden angelegt :)
Yippiiiii :)

Jetzt zu meiner ursprünglichen fehlerhaften Annahme: Du schriebst weiter oben das du den FirmataScheduler genau dafür angedacht hast, aber noch auf der ToDoListe steht, korrekt?
<wunsch-an>
Meine Vision wäre, wenn durch das OWxxx Define die ID und das Intervall im Arduino gespeichert werden würde und dann selbstständig gepollt wird. Bei Änderung des Wertes wird selbstständig ein Push zum FHEM durchgeführt. Das Pollen durch OWX führt dann is Leere da der Arduino ja selbst pollt. Damit hätte man ein 1wireNetz mit Push-Prinzip. Quasi was die FunkSensoren heute schon machen. Ich denke ich habe mich von diesem Thread hier  (http://forum.fhem.de/index.php/topic,22609.0.html)leiten lassen da dieser dies dem Leser suggeriert. Wie ich dich verstanden habe scheitert es am internen Speicher.
Was kann man dagegen tun? Einen Arduino Busmaster mit einem ATMEGA2560 designen? Oder einem Arduino Mini einen externen SRAM-Baustein spendieren? Bei meinem/Justme1968 Innenraumsensor arbeiten wir mit einem ATMEGA2560 und einen externen i2c NVSRAM Speicher mit 1MB
<wunsch-aus>
Alles In Allem: Hut ab und Respekt was du bisher mit FRM geschafft hast :) :)

Edit: für die Nutzung von OWX_ASYNC musste ich noch folgende Module nachladen, FHEM hatte ich vorher per update aber auf den neuesten Stand gebracht:
wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/GPUtils.pm
wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/OWX_FRM.pm

Zitat von: Tobias am 19 Mai 2014, 19:50:52
Ich musste noch manuell ProtoThreads.pm nachladen:

Code Auswählen Erweitern

wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/lib/ProtoThreads.pm
Könnte man das ev. mit im Standard-FHEM-SVN einchecken?

ist dort schon lange drin: http://sourceforge.net/p/fhem/code/HEAD/tree/trunk/fhem/FHEM/lib/ProtoThreads.pm
sollte eigentlich auch per 'update development' übernommen werden.

Zitat von: Tobias am 19 Mai 2014, 19:50:52
Habe jetzt Firmata_Ext mit im Sketch und prompt Fehlermeldungen in FHEM bekommen.
[...]
Dadurch das im FRM Device die onewire-pins nicht ausgegeben werden musst ich probieren. Pin 12 ging auch nicht, aber Pin9 = D9 und funktionierte. Wie ich schon weiter oben schrieb wäre es schön wenn diese noch angezeigt werden könnten :)
[...]

Code Auswählen Erweitern

error initializing 'owxFRM': unsupported mode '7' for pin '13'

diese Meldung spricht sehr dafür, dass die onewire_pins in den Device-details jetzt (mit FirmataExt) wie gewünscht angezeigt werden. Du solltest noch mal gucken  ;-)

Zitat von: Tobias am 19 Mai 2014, 19:50:52
Jetzt zu meiner ursprünglichen fehlerhaften Annahme: Du schriebst weiter oben das du den FirmataScheduler genau dafür angedacht hast, aber noch auf der ToDoListe steht, korrekt?
<wunsch-an>
Meine Vision wäre, wenn durch das OWxxx Define die ID und das Intervall im Arduino gespeichert werden würde und dann selbstständig gepollt wird.[...]Wie ich dich verstanden habe scheitert es am internen Speicher.
Was kann man dagegen tun? Einen Arduino Busmaster mit einem ATMEGA2560 designen?

Im Prinzip ja. Mit ausreichend Speicher wäre das kein Problem. Nur was gewinnt man damit? Die paar Bytes zum Steuern der 1-Wire-firmata brauchen kaum FHEM-seitig kaum Resourcen und mit OWX_ASYNC wird auch nix blockiert. Wenn man einen iButton-leser dauerpolllen will, dann macht das Sinn, sonst eher nicht. Und dafür muss der Arduino auch keine IDs kennen, da muss er einfach 1-Wire-Search machen und alles melden, was er findet (ist ja normalerweise eh nur maximal 1 Device am iButton-leser vorhanden, und dann immer wieder ein anderes). Und für Bandbreitenlimitierte Funkschnittstellen im ISM-Band gibt es (in Bezug auf die Anpassung an die Bedürfnisse der Funkschnittstelle) effizientere Protokolle als das Stream-basierte Firmata-protokoll. Das ist halt dafür optimiert, dass der Firmata-client das Sagen hat. Wenn man echte standalone arbeitende Logik auf dem Arduino will, dann schreibt man dafür einen spezialisierten Sketch, da ist Firmata nicht die richtige Wahl, das ist dafür nicht designt. Dafür hat es eben andere Stärken (wie z.b. sehr große Flexibilität mit einer einzigen Firmware oder äußerst prompte Reaktion auf digitale I/O-ereignisse).

Zitat von: Tobias am 19 Mai 2014, 19:50:52
Edit: für die Nutzung von OWX_ASYNC musste ich noch folgende Module nachladen, FHEM hatte ich vorher per update aber auf den neuesten Stand gebracht:

Code Auswählen Erweitern

wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/GPUtils.pm
wget --no-check-certificate https://raw.githubusercontent.com/mhop/fhem-mirror/master/fhem/FHEM/OWX_FRM.pm

auch die sollten per 'update development' von selber rüberkommen?

Gruß,

Norbert

noch eine kleine Ergänzung:
nicht dass der Eindruck entsteht, ich würde eine Architektur a la 'autonom messender Arduino' irgendwie ablehnen. In den OWX-Frontendmodule müsste man die Definitionen der AfterexecuteFn wieder reinschreiben, die verweist dann auf die jeweilige 'BinValues'-funktion, die mittlerweile jedes Frontendmodul besitzt. Und OWX(_ASYNC) müsste man noch ein bischen erweitern, damiut es mit Firmata 1-Wire messages ohne Kontext klarkommt.
Und natürlich einen auf 1-Wire spezialisierten Firmata-sketch schreiben, der eben autonom sendet....
Nur zu, ich bin für Kontributions offen ;-)

Gruß,

Norbert

Hi Norbert,
ich habe ein simples "update" gefahren. Kein "update development". Dummerweise benötigen die stable-OW-Module warscheinlich die developmentModule.
Jedenfalls hat ein simples update in meiner Produktivumgebung zur Deaktivierung von OWMULTI/OWSWITCH etc geführt. Ein Einspielen des Backup brachte alles wieder zum Laufen.
Was ich damit dagen wollte, liegt es an mir oder müssen die abhängigen DevelopmentModule mit in den MainTree?

ICh bin jetzt am testen mit ASYNC, poste dann aber im async Thread.
Danke dir für die Unterstützung. Ich poste dann hier wieder wenn es an an die Einbindung mit dem DS2482 geht...

Hallo Norbert,

Zitat von: ntruchsess am 19 Mai 2014, 23:26:13
diese Meldung spricht sehr dafür, dass die onewire_pins in den Device-details jetzt (mit FirmataExt) wie gewünscht angezeigt werden. Du solltest noch mal gucken  ;-)

Ich kann mir nicht helfen, ich find Sie ums verrecken nicht...


Internals:
   CONNECTS   1
   DEF        3030 global
   DeviceName 3030
   FD         19
   NAME       MyFRM
   NOTIFYDEV  global
   NR         96
   NTFY_ORDER 50-MyFRM
   PORT       3030
   STATE      Initialized
   TYPE       FRM
   firmware   ConfigurableFirmata.ino
   firmware_version V_2_06
   CHANGETIME:
   Readings:
     2014-05-20 09:18:24   error           Unhandled sysex command
   Socketdevice:
     BUF
     DeviceName 3030
     FD         20
     NAME       FRM:192.168.10.19:1036
     NR         100
     SNAME      MyFRM
     STATE      Connected
     TEMPORARY  1
     TYPE       FRM
Attributes:
   room       OWX


PS: habe das Wiki  (http://www.fhemwiki.de/wiki/Arduino_mit_OneWireFirmata#Allgemeine_Funktionsweise)nochmal angepasst

Zitat von: ntruchsess am 19 Mai 2014, 12:48:16Zitat von: Tobias am 19 Mai 2014, 08:06:26
Auch schmiert FHEM immer ab wenn der Arduino vom Netz getrennt wird
Ja, hab ich schon mitgekriegt, Fix ist in Arbeit ;-)

Dieser Fix würde mich sehr interessieren. Im Moment schmiert Fhem einmal pro Tag ab, weil der Arduino nicht mehr gefunden wird -> nicht geeignet für eine Produktivumgebung. Hat dieser Fix etwas mit OWX asyncron zu tun oder ist das ein anderes Problem ?

Hallo Norbert,
Den Arduino schalte ich abends immer aus. Bei Anschalten heute morgen hatte ich folgendes Phänomen bei den freezes:

2014.05.21 05:44:30 3: querying Firmata Firmware Version
2014.05.21 05:44:30 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2014.05.21 05:44:30 3: received String_data: Unhandled sysex command
2014.05.21 05:44:32 1: possible freeze: timer should 03:44:28, delay is 4.16706490516663
2014.05.21 05:44:32 3: received String_data: Unhandled sysex command
2014.05.21 05:44:36 1: possible freeze: timer should 03:44:34, delay is 1.44242382049561
2014.05.21 05:44:39 1: possible freeze: timer should 03:44:37, delay is 2.23392105102539
2014.05.21 05:44:43 1: possible freeze: timer should 03:44:40, delay is 3.05241394042969
2014.05.21 05:44:46 3: OWTHERM: Device OWX_28_F6A72A040000 defined.
2014.05.21 05:44:46 3: OWTHERM: Device OWX_28_25B52A040000 defined.
2014.05.21 05:44:47 2: OWX: 1-Wire devices found on bus owxFRM (OWX_28_F6A72A040000,OWX_28_25B52A040000,OWX_28_2DB12A040000,OWX_28_EFAC2A040000,OWX_26_3D2E27010000,O$
2014.05.21 05:44:49 1: possible freeze: timer should 03:44:44, delay is 4.72820019721985
2014.05.21 05:44:55 1: possible freeze: timer should 03:44:50, delay is 4.68467998504639
2014.05.21 05:45:01 1: possible freeze: timer should 03:44:56, delay is 5.52330183982849
2014.05.21 05:45:10 1: possible freeze: timer should 03:45:02, delay is 7.74322819709778
2014.05.21 05:45:19 1: possible freeze: timer should 03:45:11, delay is 7.86965990066528
2014.05.21 05:45:28 1: possible freeze: timer should 03:45:20, delay is 8.67838597297668
2014.05.21 05:45:39 1: possible freeze: timer should 03:45:29, delay is 9.47321009635925
2014.05.21 05:45:51 1: possible freeze: timer should 03:45:40, delay is 11.1279678344727
2014.05.21 05:46:03 1: possible freeze: timer should 03:45:52, delay is 11.0893700122833
2014.05.21 05:46:16 1: possible freeze: timer should 03:46:04, delay is 11.956127166748
2014.05.21 05:46:30 1: possible freeze: timer should 03:46:17, delay is 12.7660098075867
2014.05.21 05:46:44 1: possible freeze: timer should 03:46:31, delay is 13.606724023819
2014.05.21 05:47:00 1: possible freeze: timer should 03:46:45, delay is 14.3072431087494
2014.05.21 05:47:16 1: possible freeze: timer should 03:47:01, delay is 15.1567580699921
2014.05.21 05:47:33 1: possible freeze: timer should 03:47:17, delay is 15.916473865509
2014.05.21 05:47:51 1: possible freeze: timer should 03:47:34, delay is 16.8377499580383
2014.05.21 05:48:09 1: possible freeze: timer should 03:47:52, delay is 17.5270171165466
2014.05.21 05:48:29 1: possible freeze: timer should 03:48:10, delay is 18.5397200584412
2014.05.21 05:48:41 3: set CULMAX0 fakeWT HZ_Bad 10.0 22.2
2014.05.21 05:48:49 1: possible freeze: timer should 03:48:30, delay is 19.2941839694977
2014.05.21 05:49:10 1: possible freeze: timer should 03:48:50, delay is 20.075101852417
2014.05.21 05:49:32 1: possible freeze: timer should 03:49:11, delay is 20.8146159648895
2014.05.21 05:49:55 1: possible freeze: timer should 03:49:33, delay is 21.6062231063843


Meine fhem.cfg im Ausschnitt:
define MyFRM FRM 3030 global
attr MyFRM room OWX
define owxFRM OWX_ASYNC 9
attr owxFRM IODev MyFRM
attr owxFRM room OWX
define OWX_26_3D2E27010000 OWMULTI DS2438 3D2E27010000
attr OWX_26_3D2E27010000 DbLogExclude .*
attr OWX_26_3D2E27010000 IODev owxFRM
attr OWX_26_3D2E27010000 model DS2438
attr OWX_26_3D2E27010000 room OWX
define OWX_29_8A0E11000000 OWSWITCH DS2408 8A0E11000000
attr OWX_29_8A0E11000000 DbLogExclude .*
attr OWX_29_8A0E11000000 IODev owxFRM
attr OWX_29_8A0E11000000 model DS2408
attr OWX_29_8A0E11000000 room OWX
define OWX_28_F6A72A040000 OWTHERM DS18B20 F6A72A040000
attr OWX_28_F6A72A040000 DbLogExclude .*
attr OWX_28_F6A72A040000 IODev owxFRM
attr OWX_28_F6A72A040000 model DS1822
attr OWX_28_F6A72A040000 room OWX

Plus noch 3 weitere DS18B20 nach gleichem Schema. Nach einem Restart läuft es wieder.

Nachdem ich das Intervall des DS2408 auf 1sek und die Intervall der anderen auf 5sek heruntergedreht habe, habe ich sehr oft kurze freezes. Muss ich bei OWX_ASYNC noch etwas einstellen?
2014.05.21 07:49:04 1: possible freeze: timer should 05:49:03, delay is 1.04655909538269
2014.05.21 07:49:14 1: possible freeze: timer should 05:49:13, delay is 1.33024215698242
2014.05.21 07:49:19 1: possible freeze: timer should 05:49:18, delay is 1.11995792388916
2014.05.21 07:49:29 1: possible freeze: timer should 05:49:28, delay is 1.2128849029541
2014.05.21 07:49:39 1: possible freeze: timer should 05:49:38, delay is 1.21618890762329
2014.05.21 07:49:49 1: possible freeze: timer should 05:49:48, delay is 1.20056104660034
2014.05.21 07:49:59 1: possible freeze: timer should 05:49:58, delay is 1.00980997085571
2014.05.21 07:50:39 1: possible freeze: timer should 05:50:38, delay is 1.14530396461487
2014.05.21 07:50:41 1: possible freeze: timer should 05:50:40, delay is 1.02528691291809

PS: Bitte nicht auf die Sinnhaftigkeit von einem 5sek Intervall bei den DS18B20 nachdenken ;) Im Produktivsystem sollen später 10x DS2408/DS2406 im 1-3sek Intervall pro Busmaster abgefragt werden.
Keine Ahnung ob das in den ASYNC-Thread gehört oder hier bzgl Firmata...

Zitat von: T.ihmann am 20 Mai 2014, 22:51:52
Im Moment schmiert Fhem einmal pro Tag ab, weil der Arduino nicht mehr gefunden wird[...]Hat dieser Fix etwas mit OWX asyncron zu tun oder ist das ein anderes Problem ?

Die OWX-Frontendmodule sind (noch) nicht für ein temporäres Verschwinden und Wiederverbindendes Busmasters ausgelegt, das macht auf jeden Fall noch Schluckauf. Ob Du noch ein anderes Problem damit hast, kann ich mangels genauerer Fehlerbeschreibung nicht sagen. Wenn FHEM 'abschmiert' (also den fhem.pl prozess beendet), würde ich gerne wissen, welche Fehlermeldung auf der Konsole erscheint (ggf. fhem.pl einfach manuel von der Kommandozeile starten und das Fenster geöffnet lassen).

Gruß,

Norbert

Hallo Norbert,
kannst du etwas zu meinen Freezes oben sagen was ich falsch mache? Hast du eine Idee? Oder jemand anderes?
Ist sogar reproduzierbar.
GErade eben habe ich FHEM neu gestartet. Die Intervalle meiner 6 Devices liegen bei 5sek. And gleich ab Start erhöhen sich die Freezes alle Minute um eine sekunde

2014.05.21 18:21:30 3: querying Firmata Firmware Version
2014.05.21 18:21:30 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2014.05.21 18:21:30 3: received String_data: Unhandled sysex command
2014.05.21 18:21:32 1: possible freeze: timer should 16:21:27, delay is 4.11132311820984
2014.05.21 18:21:32 3: received String_data: Unhandled sysex command
2014.05.21 18:21:36 1: possible freeze: timer should 16:21:33, delay is 3.10706496238708
2014.05.21 18:21:42 2: OWX: 1-Wire devices found on bus owxFRM (OWX_28_F6A72A040000,OWX_28_25B52A040000,OWX_28_2DB12A040000,OWX_28_EFAC2A040000,OWX_26_3D2E27010000,OWX_29_8A0E11000000)
2014.05.21 18:22:22 1: possible freeze: timer should 16:22:21, delay is 1.09562587738037
2014.05.21 18:25:11 1: possible freeze: timer should 16:25:10, delay is 1.00993204116821
2014.05.21 18:32:11 1: possible freeze: timer should 16:32:10, delay is 1.04083919525146
Use of uninitialized value in addition (+) at FHEM/lib/Device/Firmata/Protocol.pm line 206.
2014.05.21 18:32:51 1: possible freeze: timer should 16:32:50, delay is 1.28742718696594
2014.05.21 18:32:54 1: possible freeze: timer should 16:32:52, delay is 1.45405077934265
2014.05.21 18:32:56 1: possible freeze: timer should 16:32:55, delay is 1.33058905601501
2014.05.21 18:32:59 1: possible freeze: timer should 16:32:57, delay is 1.78740096092224
2014.05.21 18:33:02 1: possible freeze: timer should 16:33:00, delay is 2.02476906776428
2014.05.21 18:33:06 1: possible freeze: timer should 16:33:03, delay is 3.3959641456604
2014.05.21 18:33:10 1: possible freeze: timer should 16:33:07, delay is 3.06353282928467
2014.05.21 18:33:15 1: possible freeze: timer should 16:33:11, delay is 3.76115393638611
2014.05.21 18:33:20 1: possible freeze: timer should 16:33:16, delay is 3.63669204711914
2014.05.21 18:33:25 1: possible freeze: timer should 16:33:21, delay is 4.54132318496704
2014.05.21 18:33:31 1: possible freeze: timer should 16:33:26, delay is 5.04398584365845
2014.05.21 18:33:38 1: possible freeze: timer should 16:33:32, delay is 5.20851802825928
2014.05.21 18:33:44 1: possible freeze: timer should 16:33:39, delay is 5.8185019493103
2014.05.21 18:33:52 1: possible freeze: timer should 16:33:45, delay is 6.33954906463623
2014.05.21 18:33:59 1: possible freeze: timer should 16:33:53, delay is 6.33356690406799
2014.05.21 18:34:07 1: possible freeze: timer should 16:34:00, delay is 6.74962520599365
2014.05.21 18:34:15 1: possible freeze: timer should 16:34:08, delay is 7.47924184799194
2014.05.21 18:34:24 1: possible freeze: timer should 16:34:16, delay is 7.9153299331665
2014.05.21 18:34:34 1: possible freeze: timer should 16:34:25, delay is 8.46360421180725
2014.05.21 18:34:44 1: possible freeze: timer should 16:34:35, delay is 8.95366477966309
2014.05.21 18:34:54 1: possible freeze: timer should 16:34:45, delay is 9.87611103057861
2014.05.21 18:35:06 1: possible freeze: timer should 16:34:55, delay is 10.0356090068817
2014.05.21 18:35:16 1: possible freeze: timer should 16:35:07, delay is 9.95836114883423
2014.05.21 18:35:29 1: possible freeze: timer should 16:35:17, delay is 11.2512488365173
2014.05.21 18:35:41 1: possible freeze: timer should 16:35:30, delay is 11.3728280067444
2014.05.21 18:35:54 1: possible freeze: timer should 16:35:42, delay is 11.6626491546631
2014.05.21 18:36:07 1: possible freeze: timer should 16:35:55, delay is 12.214653968811
2014.05.21 18:36:21 1: possible freeze: timer should 16:36:08, delay is 12.6083030700684
2014.05.21 18:36:35 1: possible freeze: timer should 16:36:22, delay is 13.1050088405609
2014.05.21 18:36:49 1: possible freeze: timer should 16:36:36, delay is 13.7609691619873
2014.05.21 18:37:05 1: possible freeze: timer should 16:36:50, delay is 14.756865978241
2014.05.21 18:37:22 1: possible freeze: timer should 16:37:06, delay is 15.448333978653
2014.05.21 18:37:38 1: possible freeze: timer should 16:37:23, delay is 15.1541199684143
2014.05.21 18:37:55 1: possible freeze: timer should 16:37:39, delay is 15.7820029258728
2014.05.21 18:38:12 1: possible freeze: timer should 16:37:56, delay is 16.3231401443481
2014.05.21 18:38:30 1: possible freeze: timer should 16:38:13, delay is 16.9220848083496
2014.05.21 18:38:49 1: possible freeze: timer should 16:38:31, delay is 17.8170690536499
2014.05.21 18:39:08 1: possible freeze: timer should 16:38:50, delay is 18.8117890357971
2014.05.21 18:39:28 1: possible freeze: timer should 16:39:09, delay is 18.6175510883331
2014.05.21 18:39:48 1: possible freeze: timer should 16:39:29, delay is 19.0862638950348
2014.05.21 18:40:09 1: possible freeze: timer should 16:39:49, delay is 19.6078469753265
2014.05.21 18:40:31 1: possible freeze: timer should 16:40:10, delay is 20.8426570892334
2014.05.21 18:40:53 1: possible freeze: timer should 16:40:32, delay is 21.4144489765167
2014.05.21 18:41:16 1: possible freeze: timer should 16:40:54, delay is 21.8636450767517
2014.05.21 18:41:39 1: possible freeze: timer should 16:41:17, delay is 22.3144099712372
2014.05.21 18:42:03 1: possible freeze: timer should 16:41:40, delay is 23.0152409076691
2014.05.21 18:42:27 1: possible freeze: timer should 16:42:04, delay is 23.013130903244
2014.05.21 18:42:52 1: possible freeze: timer should 16:42:28, delay is 23.8629190921783
2014.05.21 18:43:17 1: possible freeze: timer should 16:42:53, delay is 24.050724029541
2014.05.21 18:43:43 1: possible freeze: timer should 16:43:18, delay is 24.5271320343018
2014.05.21 18:44:09 1: possible freeze: timer should 16:43:44, delay is 25.3856198787689
2014.05.21 18:44:36 1: possible freeze: timer should 16:44:10, delay is 25.5516941547394
2014.05.21 18:45:03 1: possible freeze: timer should 16:44:37, delay is 26.6178448200226
2014.05.21 18:45:32 1: possible freeze: timer should 16:45:04, delay is 27.4679710865021
2014.05.21 18:46:00 1: possible freeze: timer should 16:45:33, delay is 27.5050749778748
2014.05.21 18:46:30 1: possible freeze: timer should 16:46:01, delay is 28.6605319976807
2014.05.21 18:47:00 1: possible freeze: timer should 16:46:31, delay is 29.1207430362701
2014.05.21 18:47:30 1: possible freeze: timer should 16:47:01, delay is 29.0245718955994
2014.05.21 18:48:01 1: possible freeze: timer should 16:47:31, delay is 29.6257719993591
2014.05.21 18:48:32 1: possible freeze: timer should 16:48:02, delay is 30.5094630718231
2014.05.21 18:49:04 1: possible freeze: timer should 16:48:33, delay is 30.6545879840851
2014.05.21 18:49:36 1: possible freeze: timer should 16:49:05, delay is 31.5840620994568
2014.05.21 18:50:09 1: possible freeze: timer should 16:49:37, delay is 31.865464925766
2014.05.21 18:50:43 1: possible freeze: timer should 16:50:10, delay is 32.7615010738373
2014.05.21 18:51:17 1: possible freeze: timer should 16:50:44, delay is 33.2562880516052
2014.05.21 18:51:52 1: possible freeze: timer should 16:51:18, delay is 34.1289780139923
2014.05.21 18:52:28 1: possible freeze: timer should 16:51:53, delay is 34.4205389022827
2014.05.21 18:53:04 1: possible freeze: timer should 16:52:29, delay is 35.0394690036774
2014.05.21 18:53:40 1: possible freeze: timer should 16:53:05, delay is 34.8253629207611
2014.05.21 18:54:17 1: possible freeze: timer should 16:53:41, delay is 36.5087630748749
[...]

Hallo Tobias,

wie ich Tillman schon geschrieben habe, das Abstecken und Wiederverbinden funktioniert mit den OWX-Frontendmodulen noch nicht (und hat auch noch nie sauber funktioniert). Da muss ich in den Modulen erst mal die (Re-)Initialisierung überarbeiten, die laufen beim FHEM-start los und pollen im eingestellten Interval ohne auf den Status des OWX-devices zu achten. Das führt dann zu den freezes (kann ich auch ohne weiteres reproduzieren). Ist kein wirkliches FRM/Firmata-problem, wirkt sich aber in Verbindung mit dem über Netzwerk angebundenen Arduino unschön aus (weil die Netzverbindung ja erst mal in Timeouts laufen muss, bevor OWX(_ASYNC) das überhaupt merken kann).

Gruß,

Norbert

Zitat von: ntruchsess am 21 Mai 2014, 10:08:48Wenn FHEM 'abschmiert' (also den fhem.pl prozess beendet), würde ich gerne wissen, welche Fehlermeldung auf der Konsole erscheint (ggf. fhem.pl einfach manuel von der Kommandozeile starten und das Fenster geöffnet lassen).

Ich habe jetzt Fhem mal mit

./fhem.pl fhem.cfg > log.txt 2>&1

gestartet. Jetzt sollte ja hoffentlich irgendwann eine Fhem Fehlermeldung in die Datei geloggt werden. Soll ich Fhem mit weiteren Parametern starten ? Fhem scheint auf der Kommandozeile bislang nicht sehr gesprächig....

nein keine weiteren Parameter nötig. Auf der Commandozeile kommen nur Laufzeitfehler des perl-prozesses, d.h. in der Regel ist da einfach Stille. Nur wenn fhem.pl mit einem Laufzeitfehler abstürzt, dann ist eben genau der Fehler nicht im Log, sondern auf dern Konsole...

Norbert, danke für die Antwort. Ist also dasselbe Problem. Dann warte ich auf die nächste Version... bzw mach mit meinen DS2482 Tests weiter.
Nebenbei arbeite ich am Layout für ein Hutschienenmodul sowohl mit, als auch ohne DS2482. Soll ich für Fragen zum 1wireFirmata+DS2482 einen eigenen Thread aufmachen?

Zitat von: Tobias am 22 Mai 2014, 07:40:10Soll ich für Fragen zum 1wireFirmata+DS2482 einen eigenen Thread aufmachen?

ja, macht Sinn...

Hallo Norbert,
diesmal kein Disconnect ;)
Den ganzen Vormittag ist der Busmaster sauber ohne freezes gelaufen.
Folgender Fehler erscheint plötzlich im Log, danach schaukelten sich die Freezes hoch. Musste FHEM restarten....
Use of uninitialized value in addition (+) at FHEM/lib/Device/Firmata/Protocol.pm line 206.
2014.05.22 15:44:35 1: possible freeze: timer should 13:44:34, delay is 1.04684615135193
2014.05.22 15:44:41 1: possible freeze: timer should 13:44:39, delay is 1.37943196296692
2014.05.22 15:44:43 1: possible freeze: timer should 13:44:42, delay is 1.29942202568054
2014.05.22 15:44:46 1: possible freeze: timer should 13:44:44, delay is 1.83002901077271
2014.05.22 15:44:49 1: possible freeze: timer should 13:44:47, delay is 1.78572702407837
2014.05.22 15:44:52 1: possible freeze: timer should 13:44:50, delay is 2.2315239906311
2014.05.22 15:44:55 1: possible freeze: timer should 13:44:53, delay is 1.92627596855164
2014.05.22 15:44:59 1: possible freeze: timer should 13:44:56, delay is 2.77701687812805
2014.05.22 15:45:02 1: possible freeze: timer should 13:45:00, delay is 2.40023708343506
2014.05.22 15:45:05 1: possible freeze: timer should 13:45:03, delay is 2.35229110717773
2014.05.22 15:45:09 1: possible freeze: timer should 13:45:06, delay is 2.44162082672119
2014.05.22 15:45:12 1: possible freeze: timer should 13:45:10, delay is 2.44399404525757
2014.05.22 15:45:17 1: possible freeze: timer should 13:45:13, delay is 3.49837708473206
2014.05.22 15:45:21 1: possible freeze: timer should 13:45:18, delay is 3.37428498268127
[...]

da ist vermutlich der Arduino abgestürzt. Jedenfalls hat er Daten geschickt, die gar nicht ins Protocol gepasst haben. Fällt (was die Freezes angeht) eigentlich in die gleiche Kathegorie wie ein Disconnect, nur dass die TCP-Verbindung noch steht. Da muss ich mir echt Gedanken machen, wie sowas sinnvoll zu Erkennen und zu Handhaben wäre.

Gruß,

Norbert

So hier haben wir das Log von fhem.pl beim Absturz

Can't call method "packet_onewire_request" on an undefined value at FHEM/lib/Device/Firmata/Platform.pm line 779.
Can't use an undefined value as a symbol reference at FHEM/Blocking.pm line 129.


Und hier das dazugehörige Fhem interne Log

2014.05.22 04:16:24 1: 3030 disconnected, waiting to reappear (FRM:192.168.178.150:1025)
2014.05.22 04:18:14 1: CallBlockingFn: Can't connect to localhost:7072


Uptime ist immer ca. 10h, dann wird fhem.pl beendet  :(

Norbert, zur Info....
Diese Meldungen finde ich auch öfters im Log, immer im Doppelpack:
Use of uninitialized value in sprintf at ./FHEM/OWX_FRM.pm line 166.
Use of uninitialized value in sprintf at ./FHEM/OWX_FRM.pm line 166.


Ich bin ein Stück weitergekommen: Meine Recherchen haben folgendes ergeben. Ein Großteil der Standard Arduino Bootloader unterstützt den Watchdog Timer wdt nicht, der Arduino bleibt in einer Bootschleife stecken. Es gibt einen Bootloader der wdt unterstützt: optiboot. Ich habe also folgendes gemacht

- optiboot heruntergeladen und in die Arduino IDE integriert
- optiboot Bootloader mit einem USBASP Programmer auf den Arduino Nano geflasht
- Sketch um wdt ergänzt, neu compiliert und auf den Arduino Nano geflasht

Jetzt läuft der Arduino testhalber, ich hoffe er rebootet, wenn er sich aufhängt und fhem.pl bleibt nicht hängen....wir werden sehen

Kleiner Zwischenstand: 21h später immer noch kein Absturz von fhem.pl. Ob sich der Arduino in der Zeit rebootet hat kann ich im Log so nicht wirklich erkennen. Soweit bin ich schon mal zufrieden, werde weiter berichten. Wenn es wirklich eine stabile Lösung ist, werde ich es noch einmal genau beschreiben.

Hi,
ich kann mir u.U. nicht ganz vorstellen das der Arduino Sketch an allem Schuld sein soll.
Es kommt oft vor das ich fhem neu starten muss, und sehr oft von der ersten Uptime-Minute an habe ich 1sek freezes die sich dann immer weiter hochschaukeln.
Gott-sei-Dank habe ich den Arduino nur auf dem BreadBoard in meiner Testumgebung integriert...

Habe jetzt OWX ohne ASYNC laufen, da kamen jetzt innerhalb der ersten 4h nur selten 1,5sek freezes, aber ab ca der 4h schauelte sich das langsam hoch... Eine explizite  Fehlermeldung kam diesmal nicht im Log
Ich bin gerade ratlos wie ich genauere Fehlerbeschreibungen liefern kann....
2014.05.26 10:41:42 3: querying Firmata Firmware Version
2014.05.26 10:41:42 3: Firmata Firmware Version: ConfigurableFirmata.ino V_2_06
2014.05.26 10:41:42 3: received String_data: Unhandled sysex command
2014.05.26 10:41:44 1: possible freeze: timer should 08:41:40, delay is 3.96334505081177
2014.05.26 10:41:44 3: received String_data: Unhandled sysex command
2014.05.26 10:41:47 1: possible freeze: timer should 08:41:45, delay is 2.32190704345703
2014.05.26 10:41:54 2: OWX: 1-Wire devices found on bus owxFRM (OWX_28_F6A72A040000,OWX_28_25B52A040000,OWX_28_2DB12A0400                                             00,OWX_28_EFAC2A040000,OWX_26_3D2E27010000,OWX_29_8A0E11000000)
2014.05.26 10:42:19 1: possible freeze: timer should 08:42:18, delay is 1.04033017158508
2014.05.26 10:49:15 1: possible freeze: timer should 08:49:14, delay is 1.11959910392761
2014.05.26 10:50:15 1: possible freeze: timer should 08:50:14, delay is 1.01773810386658
2014.05.26 10:51:15 1: possible freeze: timer should 08:51:14, delay is 1.11456799507141
2014.05.26 10:53:15 1: possible freeze: timer should 08:53:14, delay is 1.12165284156799
2014.05.26 10:54:15 1: possible freeze: timer should 08:54:14, delay is 1.11236119270325
2014.05.26 10:54:45 1: possible freeze: timer should 08:54:44, delay is 1.11431097984314
2014.05.26 11:02:45 1: possible freeze: timer should 09:02:44, delay is 1.1352379322052
2014.05.26 11:03:45 1: possible freeze: timer should 09:03:44, delay is 1.05948185920715
2014.05.26 11:04:15 1: possible freeze: timer should 09:04:14, delay is 1.10373711585999
2014.05.26 11:10:16 1: possible freeze: timer should 09:10:15, delay is 1.26301789283752
2014.05.26 11:41:13 1: possible freeze: timer should 09:41:12, delay is 1.20133590698242
2014.05.26 11:50:10 1: possible freeze: timer should 09:50:09, delay is 1.07961010932922
2014.05.26 11:50:40 1: possible freeze: timer should 09:50:39, delay is 1.07968592643738
2014.05.26 12:22:08 1: possible freeze: timer should 10:22:07, delay is 1.34107208251953
2014.05.26 12:43:34 1: possible freeze: timer should 10:43:33, delay is 1.14691305160522
2014.05.26 12:44:04 1: possible freeze: timer should 10:44:03, delay is 1.22000503540039
2014.05.26 12:48:04 1: possible freeze: timer should 10:48:03, delay is 1.18778204917908
2014.05.26 12:51:04 1: possible freeze: timer should 10:51:03, delay is 1.3338611125946
2014.05.26 12:54:02 1: possible freeze: timer should 10:54:01, delay is 1.02016711235046
2014.05.26 14:52:00 1: possible freeze: timer should 12:51:59, delay is 1.1133120059967
2014.05.26 14:52:02 1: possible freeze: timer should 12:52:01, delay is 1.09643387794495
2014.05.26 14:52:04 1: possible freeze: timer should 12:52:03, delay is 1.30282211303711
2014.05.26 14:52:06 1: possible freeze: timer should 12:52:05, delay is 1.3389630317688
2014.05.26 14:52:09 1: possible freeze: timer should 12:52:07, delay is 1.24475502967834
2014.05.26 14:52:11 1: possible freeze: timer should 12:52:10, delay is 1.74670600891113
2014.05.26 14:52:14 1: possible freeze: timer should 12:52:12, delay is 1.44876098632812
2014.05.26 14:52:17 1: possible freeze: timer should 12:52:15, delay is 1.863126039505
2014.05.26 14:52:20 1: possible freeze: timer should 12:52:18, delay is 2.24562692642212
2014.05.26 14:52:23 1: possible freeze: timer should 12:52:21, delay is 2.30546593666077
2014.05.26 14:52:27 1: possible freeze: timer should 12:52:24, delay is 3.21186113357544
2014.05.26 14:52:31 1: possible freeze: timer should 12:52:28, delay is 2.68441987037659
2014.05.26 14:52:35 1: possible freeze: timer should 12:52:32, delay is 3.09687614440918
2014.05.26 14:52:39 1: possible freeze: timer should 12:52:36, delay is 3.11249899864197
2014.05.26 14:52:43 1: possible freeze: timer should 12:52:40, delay is 2.87595200538635
2014.05.26 14:52:47 1: possible freeze: timer should 12:52:44, delay is 3.13055896759033
2014.05.26 14:52:52 1: possible freeze: timer should 12:52:48, delay is 3.97237491607666
2014.05.26 14:52:57 1: possible freeze: timer should 12:52:53, delay is 3.39404106140137
2014.05.26 14:53:02 1: possible freeze: timer should 12:52:58, delay is 4.5477979183197
2014.05.26 14:53:08 1: possible freeze: timer should 12:53:03, delay is 4.49539804458618
2014.05.26 14:53:13 1: possible freeze: timer should 12:53:09, delay is 4.14216804504395
2014.05.26 14:53:19 1: possible freeze: timer should 12:53:14, delay is 4.67156887054443
2014.05.26 14:53:24 1: possible freeze: timer should 12:53:20, delay is 4.35747408866882
2014.05.26 14:53:31 1: possible freeze: timer should 12:53:25, delay is 5.63847088813782
2014.05.26 14:53:37 1: possible freeze: timer should 12:53:32, delay is 5.58831906318665
2014.05.26 14:53:44 1: possible freeze: timer should 12:53:38, delay is 5.79695701599121
2014.05.26 14:53:51 1: possible freeze: timer should 12:53:45, delay is 5.65792107582092
2014.05.26 14:53:57 1: possible freeze: timer should 12:53:52, delay is 5.73518586158752
2014.05.26 14:54:05 1: possible freeze: timer should 12:53:58, delay is 6.35047197341919
2014.05.26 14:54:13 1: possible freeze: timer should 12:54:06, delay is 7.44526314735413
2014.05.26 14:54:21 1: possible freeze: timer should 12:54:14, delay is 7.28559398651123
2014.05.26 14:54:29 1: possible freeze: timer should 12:54:22, delay is 6.48327088356018
2014.05.26 14:54:37 1: possible freeze: timer should 12:54:30, delay is 7.29587197303772
2014.05.26 14:54:46 1: possible freeze: timer should 12:54:38, delay is 7.37442016601562
2014.05.26 14:54:55 1: possible freeze: timer should 12:54:47, delay is 8.47437500953674
2014.05.26 14:55:04 1: possible freeze: timer should 12:54:56, delay is 7.82140898704529
2014.05.26 14:55:13 1: possible freeze: timer should 12:55:05, delay is 8.32250285148621
2014.05.26 14:55:23 1: possible freeze: timer should 12:55:14, delay is 8.76477909088135
2014.05.26 14:55:33 1: possible freeze: timer should 12:55:24, delay is 9.35533905029297
2014.05.26 14:55:43 1: possible freeze: timer should 12:55:34, delay is 9.15457797050476
2014.05.26 14:55:54 1: possible freeze: timer should 12:55:44, delay is 9.07524704933167
2014.05.26 14:56:04 1: possible freeze: timer should 12:55:55, delay is 9.86088490486145
2014.05.26 14:56:16 1: possible freeze: timer should 12:56:05, delay is 10.4884929656982
2014.05.26 14:56:27 1: possible freeze: timer should 12:56:17, delay is 9.63496112823486
2014.05.26 14:56:38 1: possible freeze: timer should 12:56:28, delay is 10.7487919330597
2014.05.26 14:56:51 1: possible freeze: timer should 12:56:39, delay is 11.502454996109
2014.05.26 14:57:03 1: possible freeze: timer should 12:56:52, delay is 11.3467049598694
2014.05.26 14:57:15 1: possible freeze: timer should 12:57:04, delay is 11.2846300601959
2014.05.26 14:57:29 1: possible freeze: timer should 12:57:16, delay is 12.39821600914
2014.05.26 14:57:42 1: possible freeze: timer should 12:57:30, delay is 12.4572739601135
2014.05.26 14:57:55 1: possible freeze: timer should 12:57:43, delay is 11.9162659645081
2014.05.26 14:58:10 1: possible freeze: timer should 12:57:56, delay is 13.8344261646271
2014.05.26 14:58:24 1: possible freeze: timer should 12:58:11, delay is 12.9472048282623
2014.05.26 14:58:38 1: possible freeze: timer should 12:58:25, delay is 13.1953661441803
2014.05.26 14:58:53 1: possible freeze: timer should 12:58:39, delay is 14.1782069206238
2014.05.26 14:59:08 1: possible freeze: timer should 12:58:54, delay is 14.0698349475861
2014.05.26 14:59:24 1: possible freeze: timer should 12:59:09, delay is 14.4133810997009
2014.05.26 14:59:39 1: possible freeze: timer should 12:59:25, delay is 14.671835899353
2014.05.26 14:59:56 1: possible freeze: timer should 12:59:40, delay is 15.1609079837799
2014.05.26 15:00:12 1: possible freeze: timer should 12:59:57, delay is 15.741574048996
2014.05.26 15:00:30 1: possible freeze: timer should 13:00:13, delay is 16.2122130393982
2014.05.26 15:00:47 1: possible freeze: timer should 13:00:31, delay is 16.650671005249
2014.05.26 15:01:05 1: possible freeze: timer should 13:00:48, delay is 16.3852858543396
2014.05.26 15:01:23 1: possible freeze: timer should 13:01:06, delay is 16.8800311088562
2014.05.26 15:01:40 1: possible freeze: timer should 13:01:24, delay is 16.7454850673676
2014.05.26 15:01:59 1: possible freeze: timer should 13:01:41, delay is 17.8772439956665
2014.05.26 15:02:18 1: possible freeze: timer should 13:02:00, delay is 17.717964887619
2014.05.26 15:02:37 1: possible freeze: timer should 13:02:19, delay is 18.0434391498566
2014.05.26 15:02:57 1: possible freeze: timer should 13:02:38, delay is 19.3171048164368
2014.05.26 15:03:17 1: possible freeze: timer should 13:02:58, delay is 18.7500851154327
2014.05.26 15:03:37 1: possible freeze: timer should 13:03:18, delay is 19.0350549221039
2014.05.26 15:03:57 1: possible freeze: timer should 13:03:38, delay is 19.4059960842133

Wollte nur mal kurz auch hier alle informieren (damit das nicht im 1-Wire Forum untergeht): ich habe vor ein paar Tagen einen Fix für einen Bug in der perl-firmata committed (und hier (http://forum.fhem.de/index.php/topic,24702.msg180357.html#new) darüber berichtet), der in praktisch allen FRM-clients sporadisch zu Fehlern geführt hat (auf schnellen Rechnern mit höherer Wahrscheinlichkeit).

Ein Update lohnt sich also auch für alle, die gar kein 1-Wire einsetzen.

Gruß,

Norbert

Hallo Norbert,

ich habe mal wieder eine Frage ::)

Auf einem Arduino Mega läuft deine Configurable Firmata alles soweit ok!

Ich habe mir folgendes LCD besorgt: Saint Smart 2004 I2C Ardesse 63
Das ganze habe ich eingebunden mit
define Display FRM_LCD i2c 16 2 63

Soweit auch alles Ok! Ich kann Texte setzten und da beginnt meine Frage.
Im Commandref sind die einzelnen Befehle aufgelistet (backlight, reset, text, ......) leider gibt es keine nähere Beschreibung dazu bzw. ich habe keine gefunden.
Gibt es da irgendwo eine Übersicht?

Ich würde gerne Texte in verschiedene Zeilen schreiben nur steh ich im Moment etwas auf dem schlauch wie ich das hinbekomme?

Gruß
Markus

FRM_LCD (http://fhem.de/commandref.html#FRM_LCD) ist obsolet und nach I2C_LCD (http://fhem.de/commandref.html#I2C_LCD) migriert worden (geht jetzt nicht nur mit FRM, sondern auch mit anderen I2C-busmastern). Eine bessere Beschreibung als in der Commandref habe ich leider nicht.

ein 2004 LCD solltest Du aber besser mit

define Display I2C_LCD 20 04 63

(beachte die parameter '20 04' für die korrekte Größe, der parameter 'i2c' ist weggefallen) definieren...

Gruß,

Norbert

Gibt es eine Möglichkeit mit der Firmata auf dem Arduino berechnete Werte abzufragen ?

Hallo,

Zitatein 2004 LCD solltest Du aber besser mit
Code: [Auswählen]
define Display I2C_LCD 20 04 63
(beachte die parameter '20 04' für die korrekte Größe, der parameter 'i2c' ist weggefallen) definieren...

Ja habe ich bereits angepasst gehabt aber trotzdem danke für den Hinweis.
Ich werde mal ein neue Thema hier im Forum aufmachen vielleicht weis ja jemand mehr über die Befehle.

Gruß
Markus

Hallo Norbert,

ich habe gesehen bei ebay gibts Regensensoren für den Arduino
http://www.ebay.de/itm/Regensensor-Regentropfen-Schneesensor-Feuchtigkeitsensor-Sensor-Arduino-Bascom-/121370374741?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1c423cf255 (http://www.ebay.de/itm/Regensensor-Regentropfen-Schneesensor-Feuchtigkeitsensor-Sensor-Arduino-Bascom-/121370374741?pt=Wissenschaftliche_Ger%C3%A4te&hash=item1c423cf255)

Einmal kann man ihn Anschließen wie einen normalen Schließer (Active Low) und einmal per Analoganschluss dieser kann Quasi anzeigen wie stark es Regnet die Spannung fällt dann von 5VDC entsprechend ab.

Kann man den Analoganschluss mit der Firmata auswerten?

Gruß
Markus

sollte mit FRM_AD kein Problem sein

Gruß,
Norbert

Hallo Norbert,

ja passt so weit ich kann ihn über einen Analog Pin auslesen.

Eine Frage noch.  ::)
Die Daten kommen ja Sekundenweise an beim reading. Ist da der Traffic auf Dauer nicht zu hoch?

Mir würde es besser gefallen nur alle 2 min oder so abzufragen ist das möglich?

Hintergrund ist das ich etwas Bedenken habe das die Performance des Pi darunter leiden könnte.
Zusätzlich verwende ich die dbLog, und dort wird alles mit geloggt, jetzt ists halt so das mir der Regensensor die dbLog ganz schön vollmüllt  :-\.


Danke und Gruß
Markus

kein Problem, man kann das Sampling-Intervall am FRM-device per Attribut einstellen. Leider nur ein Intervall für alle FRM_AD Geräte (liegt an Firmata, nicht FRM)

Hallo Norbert,

ich habe es mit dem Attribut versucht leider kein Erfolg!


define Arduino FRM 3030 [global]
attr Arduino group Test
attr Arduino sampling-interval 300000


define Regensensor FRM_AD 55
attr Regensensor IODev Arduino
attr Regensensor event-min-interval 5  (Wurde automatisch gesetzt)


Da ich gelesen habe das das sampling-interval in MS angegeben wird habe ich es mal auf 5min also 300000 gestellt.
An dem Verhalten des Reading hat sich nichts geändert
siehe Log:


2014-09-13_10:41:08 209
2014-09-13_10:41:18 208
2014-09-13_10:41:23 210
2014-09-13_10:41:43 208
2014-09-13_10:42:04 210
2014-09-13_10:42:09 209
2014-09-13_10:42:14 210
2014-09-13_10:42:19 209
2014-09-13_10:42:29 210
2014-09-13_10:42:34 209
2014-09-13_10:42:39 210
2014-09-13_10:42:45 211
2014-09-13_10:42:50 209
2014-09-13_10:43:10 208
2014-09-13_10:43:16 209
2014-09-13_10:43:25 211
2014-09-13_10:43:30 208
2014-09-13_10:43:41 210
2014-09-13_10:43:46 208
2014-09-13_10:43:51 209
2014-09-13_10:44:01 208
2014-09-13_10:44:06 209
2014-09-13_10:44:16 210
2014-09-13_10:44:21 208
2014-09-13_10:44:26 209
2014-09-13_10:44:47 208
2014-09-13_10:44:52 209
2014-09-13_10:44:57 210
2014-09-13_10:45:02 208
2014-09-13_10:45:07 207
2014-09-13_10:45:12 208

Hast du ne Idee an was es liegen könnte?

Gruß
Markus

Hi, ich habe da nicht-invasive AC Stromwandler SCT-013 http://openenergymonitor.org/emon/buildingblocks/ct-sensors-interface mit einem Messbereich von 30A (wie eine Strommesszange). Die kann ich über Arduino und die EmonLib.h auslesen, was auch prima klappt. Da ich mittlerweile drei FRMs über Ethernet in Betrieb habe (Danke Norbert), hätte ich diese Sensoren auch gerne über Firmata ausgelesen. Das klappt ja nun nicht so ohne weiteres, da die Sensoren eine Wechselspannung liefern und die EmonLib die Spitzenwerte ermittelt (FRM_AD ohne alles bringt also nichts). Nun wäre es ja möglich mittels eines Messwandlers das in eine per AD auslesbare Gleichspannung zu wandeln. Ich hätte aber gerne eine softwarebasierende Lösung. Hat da jemand eine Idee zu?

Bye Chris

Hallo cberl

Ich bin gerade interessiert über Deinen Beitrag gestolpert.
Zumindestens als Idee für Zukünftiges oder zum Mitbasteln! Mind. 1 Arduino ist bei mir noch frei....
Der Messwandler kostet ja nicht die Welt, dachte die kosten mehr. Woher hast Du die bezogen?
Sehe ich das richtig, daß der Sketch über den den Serial-Monitor die Werte ausgibt?

ZitatDas klappt ja nun nicht so ohne weiteres, da die Sensoren eine Wechselspannung liefern und die EmonLib die Spitzenwerte ermittelt (FRM_AD ohne alles bringt also nichts).

Für mich ist das eine pulsierende Gleichspannung, die am Arduino-Pin ankommt und somit auswertbar ist.

CK

AC-Mittelwertbildung in Software wäre im Firmatakontext vermutlich nicht ausreichend  echtzeitfähig (weil ja noch andere Protokolle parallel bedient werden mussen Ich befürchte daher, dass sich die ecomonlib nicht sinnvoll in die Firmata integrieren läßt. Dafür müsste man sich mal genau ansehen, wie die lib das intern macht.
Gruß, Norbert

Wie ist der Stand?
Konnte es gelöst werden?

Steh vor ähnlichem Problem und bin absolut neu in der FHEM Welt.
Werte im Moment die Stromwandler SCT-013 30A mit der emon-lib im Arduino Uno aus.
Das klappt auch so weit ganz passabel.
Nun möchte ich z.B.: alle 10sec einen Wert vom Arduino über ein Ethernetshield via TPLINK tl-wr702n zum Raspberry PI senden und dort auswerten.

Wie löst man dieses Problem?
Firmata? 

Ich habe ein Problem, das ein Eingang im Eventmonitor flattert. Einen 10k PU habe ich schon am Eingang.
Was kann es noch sein?

ZitatEvents:
2015-02-15 23:35:39 FRM_OUT DQ08 value: on
2015-02-15 23:35:39 FRM_IN DI02 reading: on
2015-02-15 23:35:39 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on
2015-02-15 23:35:40 FRM_IN DI02 reading: off
2015-02-15 23:35:40 FRM_IN DI02 reading: on

edit:

Ich gehe mal davon aus, das es das Relais ist, welches mechanisch prellt.

Hallo Cihan,

bin gerade auf deinen Beitrag gestoßen, bei mir gibt es scheinbar das gleiche Problem. Konntest du das Problem lösen? Welches Relais Board setzt du ein?

Gruß
Markus

kann es sein das es mit diesem OWCOUNTER probleme gibt ?
http://forum.fhem.de/index.php/topic,35863.0.html

kann ihn manuell einbinden
define OWX_1D_A2D984000002 OWCOUNT DS2423 A2D984000002
attr OWX_1D_A2D984000002 model DS2423eold
attr OWX_1D_A2D984000002 nomemory 0

sobald ich aber "get OWX devices" abfrage ist der OWCOUNTER wieder weg und ich muss ihn manuell einbinden

Hallo,möchte über einen Counter Eingang einen Windsensor auslesen dazu muss ich alle 3 Sekunden auf 0 Null rücksetzen und die zuletzt gezählten Impulse umrechnen um auf einen Brauchbaren Wert zu kommen wie kann ich das umsetzen.
Bitte um Hilfe.

Danke Mani

Fhem läuft bei mir auf einem Raspi ausschliesslich zum Erfassen und Loggen von Sensordaten. Das funktioniert prima  mit einem nanoCUL (433MHz) und 4 Revolt-Strommessdosen und einer (Aldi?) SD_WS07 Wetterstation.
Problem:
Den Füllstand meiner Zisterne (ein Analogsignal 0 bis 5Volt) erfasse ich bisher autark mit einem Arduino YUN und Anzeige auf einer 2x20 LCD.

Dessen Übernahme bzw. Anzeige mittels Firmata / FRM_AD übers WLAN klappt leider nicht.

Der Sketch auf dem YUN läuft, er wurde mit FirmataBuilder
und nur der Option "analog in" erzeugt.
Ich habe einen 2sec-delay eingefügt, weil der ungebremste Datenstrom im FHEM zu heftig war.
Das Signal liegt am Yun-PIN A1 = 19. Ich schicke es zur Kontrolle übers WLAN zur Console, wo es korrekt angezeigt wird:

    analogPin = PIN_TO_ANALOG(pin);
    U1 = analogRead(analogPin);
    Firmata.sendAnalog(analogPin, U1);
    Console.println(U1);
    digitalWrite(13, HIGH);
    delay(600);
    digitalWrite(13, LOW);
    delay(1400);
   

Ausschnitt aus fhem.cfg:
...
define FIRMATA FRM 3030 global
attr FIRMATA sampling-interval 3000
...
define 7_Zisterne FRM_AD 19
attr 7_Zisterne IODev FIRMATA
attr 7_Zisterne event-min-interval 30
attr 7_Zisterne stateFormat reading
...
define Level1 FileLog ./log/Level1-%Y-%m.log 7_Zisterne
attr Level1 logtype text
...
define SVG_Level1_1 SVG Level1:SVG_Level1_1:CURRENT
...

Fhem "all" zeigt:

FRM
FIRMATA                  Initialized
FIRMATA_192.168.1.67_58285  Connected
FRM_AD
7_Zisterne                reading

Es kommen reichlich Daten,
kleiner Ausschnitt aus dem Log: ("3_Gesamt" ist eine der Revolt-Dosen)
2016.02.28 17:09:41 5: FRM:<e1
2016.02.28 17:09:41 5: FRM:<77
2016.02.28 17:09:41 5: FRM:<03
2016.02.28 17:09:43 5: Triggering 3_Gesamt (2 changes)
2016.02.28 17:09:43 5: Notify loop for 3_Gesamt power: 240.5
2016.02.28 17:09:43 5: FRM:<e17703
2016.02.28 17:09:45 5: FRM:<e1
2016.02.28 17:09:45 5: FRM:<77
2016.02.28 17:09:45 5: FRM:<03
2016.02.28 17:09:47 5: FRM:<e1
2016.02.28 17:09:47 5: FRM:<77
2016.02.28 17:09:47 5: FRM:<03
2016.02.28 17:09:49 5: FRM:<e1
(...usw..)

Die FRM-Daten sind gemäss Firmata-Protokoll korrekt, nämlich e1 = Analogpin 1, 77 03 = Messwert = 503 (LSB, MSB in 7-bit).


Also alles prima, aber wie bekomme ich meine Füllstandsdaten zu sehen ???

Im Logfile Level1-2016-02.log sieht man nur meine diversen Neustarts, aber keine Messwerte:

2016-02-27_20:53:04 7_Zisterne Initialized
2016-02-27_20:54:44 7_Zisterne Initialized
2016-02-27_21:04:56 7_Zisterne Initialized
2016-02-27_21:06:11 7_Zisterne Initialized
2016-02-27_22:58:19 7_Zisterne Initialized
2016-02-28_01:01:13 7_Zisterne Initialized
2016-02-28_01:14:24 7_Zisterne Initialized

Der SVG-Plot bleibt auch leer :-(.

Mache ich da irgendwo einen saudummen simplen Fehler?

Ich bin für jede Hilfe dankbar!

Hallo,

Ich wollte mal Frage ob jemand Erfahrung hat über die max. länge des Kabel zwischen einem Arduino Mega I2C Bus und einem BH1750?
Sind 5m geschirmtes Kabel machbar?
Ich habe mal was von 100m gelesen?
Mit wie viel khz arbeitet der i2c Bus bei Frimata? 400khz?


Ist es möglich am Mega 2x I2C Bus zu nutzen?

Ist es richtg das vom FHEM bis jetzt nur Firmata 2.06 unterstütz wird und 2.07 ...... noch nicht?