Firmata+Arduino

ntruchsess · 20 Juli 2013, 00:49:28

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

kaizo · 28 Juli 2013, 18:21:44

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

Wzut · 28 Juli 2013, 19:52:02

@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

Code Auswählen

define go_myow notify Firmata_IN_5:reading.* { if (!$value{myonwire}) {fhem("define myonwire OWX 7");;}}

ntruchsess · 29 Juli 2013, 22:01:10

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

kaizo · 02 August 2013, 18:07:17

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

ntruchsess · 08 Oktober 2013, 01:13:05

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

ntruchsess · 13 Oktober 2013, 20:15:30

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) 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

- 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

ntruchsess · 17 Oktober 2013, 20:17:53

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

kaizo · 29 Oktober 2013, 20:56:09

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

ntruchsess · 29 Oktober 2013, 21:09:51

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

kaizo · 30 Oktober 2013, 21:01:14

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

ntruchsess · 31 Oktober 2013, 08:57:59

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

kaizo · 01 November 2013, 09:18:25

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.

ntruchsess · 04 November 2013, 12:42:42

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

ntruchsess · 04 November 2013, 13:47:46

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:

Code Auswählen

$owg_str = 0.0 if(!(defined($owg_str)));) jeweils durch:

Code Auswählen

$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 gemerged.