Frage zu Enocean USB Stick mit USB300 Chip

Begonnen von Haus-Andi, 11 Februar 2018, 17:01:51

Vorheriges Thema - Nächstes Thema

Haus-Andi

Hallo zusammen

Ich habe eine Frage: Wie bekomme ich die Enocean Protokolle von meinem USB-Stick auf den Fhem Rechner?

Folgende Fakten kann ich liefern:
Auf Grund eines Systemabsturzes (MySQL hat die SSD bis aufs letzte Bit gefüllt) muss ich alles neu installieren, resp neu machen. Jetzt möchte ich eigentlich von meiner "Notlösung" Raspberry weg kommen und das ganze gleich in den Keller zügeln und dort an die Solar-USV anschliessen. Meine Enocean Antenne hat eben einen USB-Port und der kann man ja nicht einfach verlängern, dafür gibt es unter Linux die tolle Funktion mittel dem "usbip" die USB-Port freizugeben und auf einem entfernten Linux wieder ein zu binden. Das habe ich gemacht und es funktioniert auf Anhieb, ich konnte im fhem den ESP3 definieren und nach einem reboot von fhem wurde den auch angezeigt "opend". Nur leider kommen keine Daten an.

Gibt es da noch andere Möglichkeiten, den USB-Enocean Stick an einem entfernten Server zu betreiben?

Das Ziel aller Aktivitäten sollte es am Schluss folgendes sein:
- Server mit fhem im Keller
- 1-2 Enocean Antennen in der Wohnung mittels .... an den Server gebunden
- automatisches Tagesbackup auf den NAS kopiert (habe ich bereits erledigt, kann ich auch weitergebn wen interesse besteht)

Andi
Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire

hexenmeister

USB kann man u.U. übers Netz weiterreichen.
Ich benutze für EnOcean eine solche Verbindung über ser2net. Zwar nicht USB300, sondern FGW14-USB, aber das das Prinzip ist ja gleich.
In die Datei /etc/ser2net.conf habe ich folgende Zeilen hinzugefügt (tty-Pfan muss natürlich angepasst werden, für USB300 evtl. auch die Datenrate anpassen):
# <TCP port>:<state>:<timeout>:<device>:<options> EnOcean FGW14
2206:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_Axxxxxxx-if00-port0:57600
8DATABITS NONE 1STOPBIT remctl


in FHEM dann mit IP-Adresse definieren. Beispiel:
defmod FGW14 TCM ESP2 192.168.0.xx:2206
attr FGW14 alias Eltako FGW14
attr FGW14 group IO
attr FGW14 icon DIN_rail_housing
attr FGW14 learningMode demand
attr FGW14 room IO_Devices
attr FGW14 sendInterval 100
attr FGW14 verbose 3


EDIT: ser2net muss natürlich beim Systemstart mitgestartet werden.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Haus-Andi

Hallo Hexenmeister

Verstehe ich das richtig, dass ich den ersten Code beim eigentlichen USB-Server einpflegen muss?

Ich habe den Verusch anhand dieser Site gemacht:http://www.henrykoch.de/de/usb-ueber-ip-netz-wlan-verlaengern-mit-raspberry-pi-arduino-scetches-programmieren
Mit einem USB Stick funktioniert das wunderbar, den kann man so mounten und schreiben und löschen. Der define Eintrag im Server-fhem sieht eigentlich genau gleich aus wie der auf dem Not-Raspi, er kann ihn sogar öffnen, aber eben die Daten kommen nicht an.

Andi

Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire

hexenmeister

Probiere mit ser2net. Diese muss auf dem Server, wo USB-Stick eingesteckt ist, eingerichtet werden (bei mir läuft auf einem Raspberry).
Installieren, und Config ergänzen. Service neu starten. ggf. Autostart sicherstellen (weiß nicht mehr, ob das automatisch beim Installieren schon geschieht).
Bei dem FHEM-Server muss dann  nur tty-Link durch die IP-Adresse/Port ersetzt werden.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Haus-Andi

Guten Abend

Also ich habe es mit dem ser2net getestet, nach langem probieren mit dem conf-File habe ich es soweit gebracht, das mein fhem Server immerhin die Chip-ID auslesen konnte. Also kommuniziert er irgendwie mal. Aber ich frage mich etwas wie stabil ist der Kanal wirklich? Genügt es um die Mikropelt mit den Daten zu versorgen?

Zu dem musste ich das TCM_ESP3_0 Device mittels "define" anlegen, mit dem "defmode" kann die Meldung "unbekannter Befehl"

Das aktuelle Problem besteht im Moment mit folgender Meldung im log:

2018.02.12 19:52:13 2 : EnOcean Cryptographic functions are not available.
2018.02.12 19:52:13 2 : EnOcean XML functions are not available.


für mich heisst das eigentlich das meine fhem installation mit dem EnOcean Protokoll nicht klar kommt. Nach einem fhem restart kommt beim ersten Signal diese beiden Zeilen und danach geht gar nichts mehr. Muss ich jetzt jeden Enocean Device von Hand anlegen ?

Gruss Andi



Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire

hexenmeister

Bei mir läuft die Verbindung seit über einem Jahr absolut stabil. Inwiuefern das vergleichbar mit Deiner Installation, kann ich natürlich nicht sagen. Bei mir laufen darüber neben FGW14 und FAM14 noch 4 Stück FTS14KM, 3x FSB14, 4x FSR14 und 5x FUD14.

defmode gibt es auch nicht, das Befehl heißt defmod. Meldungen wie bei Dir sehe ich bei mir auch. Bei einem FGW dürfte das normal sein, ob das bei USB300 der Fall ist, weiß ich leider nicht.

Was meinst Du mit "per Hand anlegen"? Vollständig automatisch geht es meines Wissens bei EnOcean nicht. Du musst sie alle anlernen (es sei denn, Du hast den alten funktionierenden Konfig).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Haus-Andi

Zitat von: hexenmeister am 12 Februar 2018, 20:25:03
Bei mir läuft die Verbindung seit über einem Jahr absolut stabil. Inwiuefern das vergleichbar mit Deiner Installation, kann ich natürlich nicht sagen. Bei mir laufen darüber neben FGW14 und FAM14 noch 4 Stück FTS14KM, 3x FSB14, 4x FSR14 und 5x FUD14.
dann muss ich da wohl noch etwas weiter probieren

Zitat
defmode gibt es auch nicht, das Befehl heißt defmod. Meldungen wie bei Dir sehe ich bei mir auch. Bei einem FGW dürfte das normal sein, ob das bei USB300 der Fall ist, weiß ich leider nicht.

Was meinst Du mit "per Hand anlegen"? Vollständig automatisch geht es meines Wissens bei EnOcean nicht. Du musst sie alle anlernen (es sei denn, Du hast den alten funktionierenden Konfig).
logisch den meinte ich natürlich auch, bei mir hat fhem bis jetzt immer alle Enocean Geräte beim ersten Protokoll selbständig als Device angelegt und auch ein log dazu, darum verwundert mich das ganze etwas. Aber eben da war der USB 300 auch immer am gleichen PC eingesteckt auf dem das fhem lief, da hat er dann immer auch direkt auf den "/dev/ttyUSB0@57600" zu gegriffen. Aus diesem Grund bin ich eben auch auf die usb2ip Variante gestossen. Da gibt man auf dem Host ganz bewusst nur den entsprechenden Device frei und am Client bindet man den dann eben als USB Device wieder ein. Man kann da sogar den Zugriff exclusiv erlauben (wenn es gebraucht wird).

Ich teste mal noch weiter und melde mich.
Danke für die Hilfe
Gruss Andi




Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire

Haus-Andi

Hallo zusammen

Es ist wieder Sonntag und ich sitze wieder vor meinem Problem. Es scheint mir unterdessen klar zu sein, dass nicht die Netzwerkverbindung mit den verschiedenen Tools das Problem ist, sondern es scheint so zu sein, dass mein Rechner, der als fhem-Server herhalten soll, ein USB Problem zu haben scheint.
Ich dachte vieleicht liegt es ja daran, dass Linux oder fhem das ganze nicht richtig erkennt, also habe ich den Stick nach vielen Stunden ausprobieren mal lokal direkt eingesteckt, in der Not bohre ich dann halt Löcher und kaufe mir so eine aktive USB-Verlängerung.

Aber nicht mal lokal funktioniert es richtig. Linux erstellt beim einstecken einen Device, auch fhem erstellt beim booten einen Device mit allen Einstellungen drin. Nur kommen keine Enocean Protokolle im fhem an? Da läuft irgendwas gewaltig schief, aber ich komme nicht dahinter?

Linux (Debian) und auch fhem habe ich schon mehrmals installiert (mitlerweilen kann ich es bald im schlaf), was mache ich falsch?

Hier mal den Auszug aus dem log:
2018.02.18 14:08:58 1: usb create starting
2018.02.18 14:08:58 3: Probing CUL device /dev/ttyS0
2018.02.18 14:08:58 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 394.
2018.02.18 14:08:58 3: Can't open /dev/ttyS0: Input/output error
2018.02.18 14:08:58 3: Probing CUL device /dev/ttyS1
2018.02.18 14:08:58 3: Can't open /dev/ttyS1: Input/output error
2018.02.18 14:08:58 3: Probing CUL device /dev/ttyS2
2018.02.18 14:08:58 3: Can't open /dev/ttyS2: Input/output error
2018.02.18 14:08:58 3: Probing CUL device /dev/ttyS3
2018.02.18 14:08:58 3: Can't open /dev/ttyS3: Input/output error
2018.02.18 14:08:58 3: Probing TCM_ESP3 device /dev/ttyUSB0
2018.02.18 14:08:58 1: define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600
2018.02.18 14:08:58 3: Opening TCM_ESP3_0 device /dev/ttyUSB0
2018.02.18 14:08:58 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
2018.02.18 14:08:58 3: TCM_ESP3_0 device opened
2018.02.18 14:08:58 1: usb create end
2018.02.18 14:08:58 0: Featurelevel: 5.8
2018.02.18 14:08:58 0: Server started with 10 defined entities (fhem.pl:16204/2018-02-17 perl:5.024001 os:linux user:fhem pid:3910)
2018.02.18 14:08:59 3: FHEMWEB WEB CSRF error: csrf_188522059644026 ne csrf_144765567399067 for client WEB_192.168.168.30_50580 / command shutdown restart. For details see the csrfToken FHEMWEB attribute.
2018.02.18 14:09:11 2: EnOcean Cryptographic functions are not available.
2018.02.18 14:09:11 2: EnOcean XML functions are not available.


Ich denke mir die letzten 2 Einträge sind der springende Punkt? Ich habe wirklich den einfach Standartweg mittels dem Debianpacket.
Gibt es da im fhem etwas neues zum Enocean was ich nicht gesehen haben sollte?

Hier noch den Teil aus der fhem.cfg
# Disable this to avoid looking for new USB devices on startup
define initialUsbCheck notify global:INITIALIZED usb create
define TCM_ESP3_0 TCM ESP3 /dev/ttyUSB0@57600


Raspberry Pi+Enocen Pi
Thermokon SR04
Micropelt
USB to 1-Wire