[Gelöst] 1Wire Sensoren per Arduino Nano + Firmata und Ser2net übertragen

Begonnen von jumpman_junior, 01 Juni 2024, 09:59:38

Vorheriges Thema - Nächstes Thema

jumpman_junior

Hallo,

ich betreibe eine FHEM Installation auf einem Banana Pi, an dem u.a. ein Arduino Nano am USB Port hängt, an dem mehrere 1Wire Sensoren und ein I2C Sensor angeschlossen sind. Das funktioniert soweit echt prima.

Jetzt möchte ich im Heizungskeller mehrere 1Wire Sensoren installieren. Dort steht bereits ein alter Raspberry Pi 1, der per ser2net und Optokopf den OBIS Stromzähler ausliest.

Nun dachte ich, ich könnte mit einem weiteren Nano aus dem Bastelfundus die 1Wire Sensoren an den Raspberry anschließen und per ser2net an die FHEM Installation weiterreichen.
Nach dem lesen der Commandref kommen mir aber Zweifel, da ja - wenn ich es richtig verstanden habe - unterschiedliche Module je nach Interface (UART / TCP) geladen werden.

Daher die Frage: Kann ich einen Arduino Nano mit ConfigurableFirmata per ser2net an FHEM (Device FRM) anklinken oder sollte ich davon die Finger lassen?

Ich bin auch für andere Vorschläge offen. Vom 1Wire am Raspi direkt denke ich sollte ich die Finger lassen und eine 2. FHEM Instanz auf dem Raspi hochzuziehen kommt mir wie auf Kanonen mit Spatzen schießen vor.
Einen Arduino mit Netzwerkshield habe ich nicht und wollte den eigentlich auch nicht extra anschaffen.

Wenn das Thema besser ins 1Wire Forum passt (ich war mir nicht sicher), dann gerne verschieben.

Und vielen vielen Dank für die engagierte Community hier, das Ergebnis ist ein echt vielseitiges, offenes, gut verwendbares Stück Software auf das die Beitragenden stolz sein können.

LG
Peter

JensS

Zitat von: jumpman_junior am 01 Juni 2024, 09:59:38Daher die Frage: Kann ich einen Arduino Nano mit ConfigurableFirmata per ser2net an FHEM (Device FRM) anklinken oder sollte ich davon die Finger lassen?

Ich bin auch für andere Vorschläge offen. Vom 1Wire am Raspi direkt denke ich sollte ich die Finger lassen und eine 2. FHEM Instanz auf dem Raspi hochzuziehen kommt mir wie auf Kanonen mit Spatzen schießen vor.
Einfach probieren ob ser2net und FRM stabil miteinander laufen. Eine zusätzliche FHEM-Installation, welche über FHEM2FHEM mit der Hauptinstanz verbunden ist, halte ich persönlich für die bessere Variante.

Gruß Jens
Debian auf APU2C4, HM-CFG-USB2, SIGNALduino, HM-ES-PMSw1-Pl, TFA 30.3121, TFA 30.3125, ITS-150, PIR-5000, configurable Firmata USB & LAN, 1-wire: DS-18B20, DS-18S20, DS-2408, DS-2413, diverse I2C-Komponenten, zigbee2mqtt, ESPEasy etc.

jumpman_junior

Zitat von: JensS am 01 Juni 2024, 22:38:18Einfach probieren ob ser2net und FRM stabil miteinander laufen. Eine zusätzliche FHEM-Installation, welche über FHEM2FHEM mit der Hauptinstanz verbunden ist, halte ich persönlich für die bessere Variante.

Hi, besten Dank für die Einschätzung. Werde beide Varianten probieren und über die Ergebnisse berichten.
Gruß
Peter

Prof. Dr. Peter Henning

#3
Das mit einer 2. FHEM-Instanz ist keineswegs "Mit Kanonen auf Spatzen geschossen". Das habe ich auch, um meine Sensoren im Außenbereich physikalisch vom Innenbereich zu trennen.

Einfach auf dem bereits existierenden Raspberry Pi (oder einem separaten Pi Zero) alle lokalen Sensoren - auch den Stromzähler - im Heizungskeller einbinden und per FHEM2FHEM mit der Hauptinstanz verbinden.

LG

pah

Edit: Hat auch den wesentlichen Vorteil, dass die Instanz im Keller weiter läuft, obwohl man mit der Hauptinstanz gerade etwas experimentiert...

jumpman_junior

#4
Hallo,

ich war noch einen Bericht schuldig, welche der o.g. Varianten sich für meine Begriffe wie gut geschlagen hat. Das Thema ist wegen der Neuinstallation meiner PV-Anlage und deren Einbindung etwas untergegangen, die Temperatursensoren der Heizung hatten dann niedrigere Priorität...

Zunächst einmal habe ich die verschiedenen Versionen ConfigurableFirmata durchprobiert, da ich mit dem letzten Release - gebaut für einen Arduino Nano - nicht erfolgreich war.
Vielleicht habe ich bei der Konfiguration der Library etwas übersehen oder falsch eingestellt, aber ich habe keine einzige 3.x Version nutzen können, um damit einen 1-wire Temperatursensor auszulesen.

Die 2.x Versionen haben alle funktioniert, also habe ich die aktuellste (2.10.1) verwendet, die seitdem einwandfrei ihren Dienst tut.

1) Kopplung mit fhem2fhem

Bei der Variante mit einer 2. FHEM Instanz hatte ich persönlich noch eine Lernkurve zu bewältigen, da ich bisher fhem nie nativ installiert hatte, sondern meine einzige Instanz in einem Docker Container betreibe.
Das Einrichten hat ein bisschen gedauert und bei der Konfiguration der fhem2fhem Verbindung klemmte es zunächst, wobei sich wie so oft herausstellte, dass das Problem vor dem Monitor saß. Das Ergebnis war gut und entsprechend der Ratschläge tut es genau das was es sollte mit der auch gut einstellbaren Eventgenerierung. Danke für den Ratschlag!

2) Anbindung mit ser2net
Das war einfacher als gedacht, ser2net auf dem 2. Raspi installieren, konfigurieren und das Firmata device statt mit "/dev/serial/by-id/foo" mit "host:port" ansprechen, fertig. Läuft bisher auch ohne Beschwerden, außer dass beim Neustart des Raspberrys ser2net nicht startete, weil das USB device noch nicht vorhanden war. Somit meldet dann auch das OWX device in fhem fehler.

Die /etc/ser2net.yaml sieht bei mir so aus:

connection: &firmata
    accepter: tcp,,20000
    connector: serialdev,/dev/serial/by-id/usb-1a86_USB_Serial-if00-port0,57600n81,local
    options:
      kickolduser: true
     
           
Um das leidige Problem beim Neustart des Raspberrys zu lösen habe die service unit von ser2net geändert um auf das USB device zu warten

sudo systemctl edit ser2net.service

[Unit]
Requires=dev-ttyUSB0.device
After=dev-ttyUSB0.device

Was man da hin schreibt hängt davon ab, welches usb device es ist. Das bekommt man mit einem ls -l im Verzeichnis /dev/serial/by-id/ heraus. Das muss zu dem device passen was in der ser2net.yaml steht.

Fazit:
Beide Lösungen funktionieren, für meinen Erfahrungslevel war es einfacher, die Variante mit ser2net zu realisieren.
Das Verfahren hat natürlich seine Grenzen. Wenn die UARTs schneller oder Timings zwischen Bits oder Bytes wichtig werden, ist es wahrscheinlich besser, die Protokollverarbeitung vor Ort zu machen und auf Applikationsebene, sprich mit fhem2fhem zu operieren.
Danke für eure Ratschläge.

Grüße
Peter