Wie wird die serielle Schnittstelle erkannt und zugeordnet für das FGW14

thghh · 29 Juli 2015, 17:55:08

Hallo,

das FGW14 kann im 9,6 k Baud (Pos 5) und im 56 k Baud (Pos 6) Modus betrieben werden.

Ich möchte verstehen wie FHEM prüft in welchem Modus sich der FGW14 befindet. Wird dieses irgendwie abgefragt, da ja der FGW14 keine Abfragen dafür zulässt oder wird das bei der Installation festgelegt?

Desweiteren interessiert mich, wie FHEM die USB Schnittstelle erkennt und richtig zuweist. Wenn z.B. an einem USB Port ein USB to Seriell Wandler angesteckt ist, der dann mit dem FGW14 kommuniziert, wie wird nach einem Neustart des "Servers" sichergestellt, dass immer dieser Wandler an dem zuvor konfiguriertem USB zugewiesen wird, USB ist ja nicht statisch?

Danke

krikan · 29 Juli 2015, 18:42:27

ZitatIch möchte verstehen wie FHEM prüft in welchem Modus sich der FGW14 befindet. Wird dieses irgendwie abgefragt, da ja der FGW14 keine Abfragen dafür zulässt oder wird das bei der Installation festgelegt?

Das wird bei der Definition des TCM-Devices festgelegt:
http://fhem.de/commandref#TCM @baudrate

Zitat
Desweiteren interessiert mich, wie FHEM die USB Schnittstelle erkennt und richtig zuweist. Wenn z.B. an einem USB Port ein USB to Seriell Wandler angesteckt ist, der dann mit dem FGW14 kommuniziert, wie wird nach einem Neustart des "Servers" sichergestellt, dass immer dieser Wandler an dem zuvor konfiguriertem USB zugewiesen wird, USB ist ja nicht statisch?

Gar nicht durch Fhem, dafür nutzt man Betriebssystemfunktionen:
http://www.fhemwiki.de/wiki/LinuxDeviceNaming

Bitte, nur der Sinn dieser Fragen erschließt sich mir nicht...

thghh · 29 Juli 2015, 20:02:13

Der Hintergrund ist, das bis zum heutigen Tag der Save-II von Eltako mit der GFVS Software nur 9600 Baud RS-232 unterstützt und die Zuordnung der Schnitstellen nicht so einfach und stabil ist (wenn auch mit der Version 1.6x nun deutlich besser). Ich habe grosse Probleme mit dem System und überlege mir, einen vollständigen Systemwechsel vorzunehmen. Mir ist sehr wichtig, dass die Kabelverbindung absolut stabil läuft und das mit 56000 Baud.

Was mich immer noch abschreckt ist die kryptische Programmierung in FHEM und derzeit schiele ich auch noch zum Wibutler.

Der Save-II nutzt ja nun auch Linux und es war in der Vergangeheit nicht so einfach, immer die selbe USB Schnittstelle dem FGW14 zuzuordnen.

crispinus · 05 August 2015, 11:55:10

Ich habe das FGW14-USB hier an einem embedded-Board hängen, auf dem Linux läuft. Ab und zu gibt es Neuverbindungen auf der USB-Schnittstelle (das Board hängt mit im Schaltschrank und offensichtlich gibt es dort EMV-Probleme, die manchmal zu Bitfehlern in der USB-Verbindung und zum Reset der Verbindung durch den internen Hub führen). Durch eine entsprechende udev-Regel habe ich sichergestellt, dass für das FGW14 bei Neuverbindung immer derselbe Symlink angelegt wird, FHEM öffnet dann automatisch das serielle Terminal wieder, wenn es wieder verfügbar ist. Die Zuordnung in der udev-Regel geschieht über die Serial-Id des FGW14. Die Neuverbindungen treten hier mit einer Frequenz von deutlich unter 1/Tag auf und stören den Betrieb des Systems nicht.
Als Programmierer (wenn auch nicht hauptsächlich in Perl sondern in anderen Sprachen) komme ich mit FHEM sehr gut zurecht und empfinde es nicht als kryptisch, aber das liegt vielleicht daran, dass ich auch die entsprechende "Denke" habe. Gerade das DOIF-Modul habe ich mittlerweile sehr zu schätzen gelernt, und ein weiterer wesentlicher Faktor für mich ist die Interoperabilität zwischen verschiedenen Heimautomatisierungssystemen (bei mir aktuell im Einsatz: EnOcean via Funk und kabelgebunden über die 14er-Baureihe von Eltako, Homematic via Funk (Heizungs- und Raumthermostate) sowie ein Harmony-Hub von Logitech, dessen Schaltzustände die Beleuchtungsszenarien im Wohnzimmer mit beeinflussen).

VG
crispinus

thghh · 05 August 2015, 21:05:09

Danke für die Hinweise aber seriell scheint es keine ID zu geben, da das FGW14 seriell nicht abgefragt werden kann.

Wenn man unterschiedliche Systeme hat mag FHEM toll sein aber wenn man alles in Enocean hat gibt es Alternativen

crispinus · 05 August 2015, 22:18:01

Zitat von: thghh am 05 August 2015, 21:05:09
Danke für die Hinweise aber seriell scheint es keine ID zu geben, da das FGW14 seriell nicht abgefragt werden kann.

Selbstverständlich gibt es das Attribut beim fgw14-USB. Einfach mal von udevadm die Attribute für das automatisch angelegte ttyUSB-Device anzeigen lassen.

thghh · 06 August 2015, 09:16:05

Es geht hier um das FGW14 mit serieller Schnittstelle NICHT USB! Ist das dort auch so?

Wernieman · 06 August 2015, 09:27:33

Du hast einen Denkfehler:

Deine Serielle Schnittstelle ist des FGW14 ist mit dem Rechner verbunden? Und DIESE Verbindung (z.B. ein USB-Seriell-Konverter) hat eine Seriennnummer.

crispinus · 06 August 2015, 13:56:38

Hatte das mit dem Wandler überlesen. Das Vorgehen bleibt aber gleich, auch Wandler sind Idr. über eine ID zu identifizieren. Im FGW14-USB ist halt der entsprechende Wandlerchip schon eingebaut, den man sonst separat hat.

thghh · 06 August 2015, 15:43:20

Zitat von: Wernieman am 06 August 2015, 09:27:33
Du hast einen Denkfehler:

Deine Serielle Schnittstelle ist des FGW14 ist mit dem Rechner verbunden? Und DIESE Verbindung (z.B. ein USB-Seriell-Konverter) hat eine Seriennnummer.

Der Wandler hat keine ID, der ist Bittransperent

Das FGW14 sendet ja eine ID aber nur wenn etwas auf dem Bus gesendet wird. Aktiv selbst ist das nicht möglich.

Das Problem dabei ist, dass z.B. beim Starten das Save-II die Schnitstelle abgefragt wird mit welcher Geschwindikeit gearbeitet werden soll aber vom FGW14 keine Infos kommen. Würde genau in dem Moment auf dem Buss eine Meldung kommen würde der Save die Info bekommen.

Bei FHEM wird das ja anders gelöst ducrch das feste Eintragen der Geschwindigkeit.

crispinus · 06 August 2015, 23:37:06

Es geht nicht um eine ID, die im Rahmen der seriellen Kommunikation übertragen wird, sondern um die ID, die als Attribut zum USB-Device des Wandlers im sysfs abgelegt wird. Und eben diese kann mit udevadm ausgelesen bzw für udev-Rules verwendet werden. Sollte es wider erwarten keine Serial ID geben, könnten z.B. vendor und product ID als Diskriminatoren kommen.