Entfernte Anbindung von Sensoren über Ethernet - Die Glaubensfrage

[joachimm]

Hallo,

einige Sensoren sollen über Ethernet angebunden werden. Nun gibt es da ja mehrere Möglichkeiten. Cuno, Aruduino, RPi, UDP Eigenbaulösungen mit Bascom, C, etc.... Noch richtig entschieden konnte ich mich noch nicht. Die günstigste Variante scheint mir ein Arduino Bundle (Uno und Ethernet Shield für 20 Euro vom freundlichem Chinesen). Denn Eigenbaulösungen mit Ethernetadaper von Wiznet kosten genauso viel wie ein weiterer RPi. Wenn man der RPi nur in die Hutschiene unterbringen könnte. Die anderen embedded Linux Boards sind mir noch zu teuer. Klasse wäre auch das X-Bord V2 (kostet 29 Euro, Ethernet und Mega 328) Wie seht Ihr das?

Gruß
Joachim

[ntruchsess]

Beantworte Dir selber erst mal die Fragen:

soll das Ding autonom irgendwas tun (wenn fhem z.B. grade mal nicht erreichbar ist) oder einfach nur die Funktion eines remote-sensors/aktors erfüllen?

Reicht es, wenn mit vergleichsweise geringem Bastelaufwand ein paar schon unterstürzte Sensoren/Aktoren verwendet werden können, oder soll quasi 'alles' gehen, zur Not wird selber Hand an den code gelegt?

Spielt der Stromverbrauch eine Rolle?

Was bringst Du selber an Know/How mit? Möchtest Du dabei viel lernen oder einfach nur etwas bewährtes konfigurieren und verwenden?

Bei mir fiel die Entscheidung auf Arduino mit EthernetShield. Eigentlich auch wegen der 'für 20 EUR aus China zu kriegen' (und weil selber machen halt eben auch ein bischen sexy ist). Damit das läuft habe ich allerdings in den letzten paar Monaten mehrere 1000 Zeilen code neu- bzw. umgeschrieben. (Module FRM/FRM_XXX für FHEM, perl-firmata fit gemacht und Firmata refactored und um OneWire und Ethernet erweitert). Naja, damit der nächste die Arbeit nicht noch mal machen muss sind die Module hier contributed und alles weitere auch open-source gestellt...

Gruß,

Norbert

[joachimm]

Hallo Norbert,
Stromerverbrauch - ja das ist auch ein Argument. Übrigens echt klasse Sache was Du da gemacht hast. Es soll noch die Unterstützung für den enc28j60 folgen? Das wäre dahingehend interessant, weil es für den Nano ein günstiges Ethernetshield gibt. Auch gibt es ein günstiges Gegenstück zum wiz820io auf enc28j60 Basis (ist genauso schnuckelig klein). Ja, da freue ich mich schon darauf....

[ntruchsess]

enc28j60 Unterstützung ist definitiv in der Pipeline, habe mir dafür auf eBay genau so ein Ethernetshield für den Nano bestellt. Leider brauchen die Teile aus China immer so lange. Aber was solls, das Teil habe ich in der Form leider bei keinem deutschen Versender gefunden :-(

Gruß,

Norbert

[det.]

Hallo @ all,
gibt es bezüglich der Anbindung von ENC28J60 schon Neuigkeiten?

[ntruchsess]

nun, das ENC28J60 Shield (für den Nano... echt netter Formfaktor ;-) ) ist vor ein paar Tagen bei mir angekommen. Ich arbeite allerdings grade an einer Asynchronen Variante von OWX, d.h. es kann noch ein paar Tage dauern, bis ich mich dem Teil erfolgreich zuwenden kann.

Gruß,

Norbert

[det.]

hallo Norbert,
da ich es nicht selbst programmiert bekomme warte ich gern, bis Du so weit  bist. Schön, dass Dein Shield schon da ist, meins liegt auch bereit - ist echt schnell geliefert worden ( reichlich eine Woche ).  Onewirefirmata über usb geht gut, ab und zu nach einem Neustart muss ich den Ardunio abziehen und neu einstecken. Dafür sind die Antwortzeiten bei Digital In sensationell. Da hab ich jetzt eine Tüte DS2401 zu viel... Diese Ardunio Technik ist eine echte Bereicherung für das FHEM System - Danke!

[ntruchsess]

ab und zu nach einem Neustart muss ich den Ardunio abziehen und neu einstecken.

Du meinst einen Neustart von FHEM bei vorher aktiv verbundenem Arduino? Da sollte die Firmata eigentlich einfach neu initialisiert werden. Schalt doch mal global verbose auf 5 und schau, ob nach dem Neustart von FHEM was brauchbares im Log auftaucht.

Wenn Du meinst, dass der Arduino bei einem Neustart des Rechners manchmal nicht geht, dann könnte das auch daran liegen, dass der Devicename nicht immer gleich vergeben wird. Das könnte man (unter Linux) mit einer passenden UDEV-Regel (die dem Arduino einen festen Namen wie /dev/arduino anstelle des dynamisch vergebenem /dev/USB0 (das ja auch mal ein /dev/USB1 sein kann) in den Griff kriegen.

Gruß,

Norbert