Firmata+Arduino

[det.]

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!

[ThomasL]

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:

Code Auswählen Erweitern

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

[ThomasL]

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

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

FIRMATA 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

[ntruchsess]

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

define 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

[ntruchsess]

Ü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

[det.]

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 über diesen Adapter angeschlossen: 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.

[ThomasL]

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

[kaizo]

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

[ntruchsess]

Es 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

[ntruchsess]

Allerdings 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

[ntruchsess]

ich 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

[Achim]

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

[ntruchsess]

Geht 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

[ThomasL]

Es 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

[kaizo]

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