FGW14-USB Einrichtung + Einlernen der Schalter

Begonnen von raumhafen, 23 April 2018, 23:04:42

Vorheriges Thema - Nächstes Thema

raumhafen

Guten Abend zusammen,

wir haben in unserem Haus flächendeckend Enocean Schalter (PTM 210) verbaut.
Diese schalten entsprechende Eltako Aktoren im Schaltkasten für Licht und Rollläden.
Die Aktoren habe ich jetzt um einen FGW14-USB erweitert, der mit einem RaspberryPi 3 verbunden ist.
Zukünftig möchte ich die Schaltvorgänge auch parallel über FHEM ausführen können.

Um die Schalter nun in FHEM einzurichten habe ich mich am Enocean Starter Guide im Wiki orientiert,
sowie an diesem Beitrag: https://forum.fhem.de/index.php/topic,22635.0.html

Dazu meine erste Frage.
In oben erwähntem Beitrag steht man sollte die Anbindung mit einer Baudrate von 57600 Baud vornehmen.
Also Drehschalter am FGW14 auf 6 stellen. Nur damit erkennt FHEM (über usb scan) das Gerät nicht mehr.
Stelle ich den Schalter auf 5 (9600 Baud) wird das Gerät problemlos erkannt. Was könnte hier die Ursache sein?

Meine zweite Frage betrifft den automatischen Anlernvorgang. Wie im Wiki beschrieben habe ich FHEM in den
Learning Modus versetzt. Wenn ich jetzt die physischen Schalter bei uns im Haus bediene legt FHEM auch automatisch
den Schalter an. Allerdings werden hier anscheinend immer zwei Schalter in FHEM angelegt.
(Bspw. EnO_003033F8 und parallel dazu EnO_00000001). Der erste Schaltern entspricht vom Namen her der HexID des physischen Schalters.
Der zweite Schalter wird mit laufender Nummer hochgezählt. Was ist hier der Hintergrund dazu?
(Die automatisch generierte Definition aus der fhem.cfg für die beiden Schalter siehe unten...)

Und damit komm ich auch schon zu meiner letzten Frage.
Ich hatte vermutet, dass der zweite angelegt Schalter der korrespondierende logische Schalter in FHEM ist und ich diesen im Aktor einlernen muss,
damit FHEM dann den Aktor auch schalten kann (parallel zum physischen Schalter im Haus).
Es steht auch im Wiki so beschrieben, dass FHEM nicht einfach meine physischen Schalter ,,simulieren kann" sondern eigene logische Schalter definiert werden müssen,
die dann im Aktor einzulernen sind.
Allerdings habe ich heute festgestellt, dass das gar nicht notwendig ist. Ich kann mit den in FHEM automatisch angelegten Schaltern (bspw. EnO_003033F8) problemlos
bereits das Licht ein-/ausschalten, ohne dass ich am Aktor was verändert habe, sprich einen logischen Schalter zusätzlich eingelernt habe.
Woran liegt das?

Vielen Dank & Grüße
raumhafen


—————
Automatisch generierte Definition aus der fhem.cfg nach Betätigen eines physischen Lichtschalters (PTM 210):

define EnO_003033F8 EnOcean 003033F8
attr EnO_003033F8 IODev TCM_ESP2_0
attr EnO_003033F8 eep F6-02-01
attr EnO_003033F8 manufID 7FF
attr EnO_003033F8 room EnOcean
attr EnO_003033F8 subType switch
attr EnO_003033F8 teachMethod RPS
define FileLog_EnO_003033F8 FileLog ./log/EnO_003033F8-%Y.log EnO_003033F8
attr FileLog_EnO_003033F8 logtype text
attr FileLog_EnO_003033F8 room EnOcean

define EnO_00000001 EnOcean 00000001
attr EnO_00000001 IODev TCM_ESP2_0
attr EnO_00000001 eep F6-02-01
attr EnO_00000001 manufID 7FF
attr EnO_00000001 room EnOcean
attr EnO_00000001 subType switch
attr EnO_00000001 teachMethod RPS
define FileLog_EnO_00000001 FileLog ./log/EnO_00000001-%Y.log EnO_00000001
attr FileLog_EnO_00000001 logtype text
attr FileLog_EnO_00000001 room EnOcean
RPI3, EnOcean, FGW14-USB, HM-IP, Synology Diskstation, PIKO Kostal, Proxon FWT 3 2.0

hexenmeister

Natürlich kann fhem die "echte" Schalter simulieren, es ist ja nur eine id, die in fhem frei gewählt werden kann. Nur meistens ist es besser, diese getrennt zu halten. Dann kann fhem weiterhin Geräte direkt steuern, auch wenn die Taster (warum auch immer) anders belegt werden.
Damit auch die Geräte mit den kleinen Nummern funktionieren, müssen sie natürlich in den Aktoren angelernt werden. Am einfachsten mit PCT14 eintragen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

raumhafen

Vielen Dank für die schnelle Rückmeldung.

Es ist super, dass FHEM den Aktor direkt ansprechen kann ohne dass man ihm eine neue ID beibringen muss, auch wenn man, wie du schreibst, dass vielleicht besser trennen sollte.
Trotzdem würde mich interessieren, ob die Beschreibung im Wiki dann inzwischen überholt ist oder ich da was falsch verstanden habe? Denn im Wiki steht je eindeutig, dass das nicht so geht oder bezieht sich das vielleicht auf andere Installationen (bspw. ohne FGW14-USB).

Zitat aus dem Wiki Enocean Starter Guide:
Der angelegte Sensor repräsentiert im Webfrontend den physischen Schalter (bspw. an der Wand). Ein Druck auf den physischen Taster ändert den Zustand im Webfrontend. Jedoch führt ein Schalten des Repräsentanten im Webfrontend nicht zu einer Schaltung des Aktors.

FHEM kann sich nicht als einer der vorhandenen (automatisch angelegten) physischen Sensoren ausgeben (um z.B. das Licht zu schalten), sondern verwendet eigene SenderIDs. Diese FHEM-eigenen SenderIDs können in EnOcean-Aktoren eingelernt werden, damit die Aktoren auf FHEM reagieren siehe unten.


Oder sollte ich mich dazu mit dem Wiki Author mal direkt unterhalten?

Vielen Dank noch mal & Grüße
raumhafen
RPI3, EnOcean, FGW14-USB, HM-IP, Synology Diskstation, PIKO Kostal, Proxon FWT 3 2.0

hexenmeister

Über Funk per USB-Stick können (aus Sicherheitsgründen) nur im Stick fest definierte IDs verwenden werden. Per FGW14 kann fhem beliebige IDs verwenden. Ich weiß jedoch nicht, ob nicht an einer anderen Stelle Probleme geben kann, denn die Tastsensoren werden in Aktoren anders angegeben, als Server-Befehle. Vermutlich funktioniert es für einfache Schalter trotzdem gleich (Beim Dimmen wird es vermutlich nicht mehr so gut klappen).
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

raumhafen

Danke Hexenmeister für das Beantworten meiner Fragen bisher, es hat mich schon sehr viel weiter gebracht  :D
Ich habe die letzten Tage noch etwas weiter experimentiert und dabei sind noch mal ein paar Fragen aufgekommen.

1. Frage:
In FHEM wurde per USB Scan automatisch ein TCM_ESP2 angelegt. (warum kein TCM_ESP3 ... keine Ahnung, ich dachte ich hätte die neuste Soft- und Hardware). Auch kann ich nach wie vor keine 57600 Baud einstellen. Sobald ich den Drehschalter am FGW14-USB auf 6 stelle wird das Gerät in FHEM nicht mehr erkannt. Hab ich hier etwas übersehen oder spielt die Baudrate und ob ESP2 oder ESP3 sowieso keine große Rolle?

2. Frage:
Beim automatischen Anlegen in FHEM wurden manchmal zwei Devices angelegt. Einer mit der echten ID des Senders und einer mit fortlaufender Nummer (beginnend bei 00000001). In meinem Büro habe ich bspw. einen Doppelschalter für Licht und Rolladen.
Hier wurde in FHEM automatisch ein Device mit Namen EnO_003033F8 angelegt (003033F8 ist die HexID des Schalters) und zusätzlich ein zweites Device mit Namen EnO_00000001.
Mit dem ersten kann ich Licht (AO/AI) und Rolladen (BO/BI) problemlos schalten. Mit dem zweiten Device geht nichts. Ich vermute mal, dass das zweite Device für den Rolladenaktor angelegt wurde? Nur was hilft mir der zusätzlich? Mit dem ersten Device kann ich ja beides schalten, Licht und Rolladen.

3. Frage:
Über die PCT14 Software habe ich Zugriff auf die Aktoren. Beim FAM14 gibt es hier einen Tabreiter "Rückmeldeliste". Der ist komplett leer. Ich habe testweise hier mal ein paar Aktoren eingetragen, sehe in FHEM (Weboberfläche oder Logs) keinen erkennbaren Unterschied zu vorher. Was bringen mir hier diese Rückmeldungen? Wie oben geschrieben bekomme ich jetzt schon auf der Weboberfläche auch die physischen Schaltungen mit. Was bringen mir diese Rückmeldungen dann zusätzlich?

4. Frage:
Meine Funkschalter wurden alle automatisch in FHEM angelegt, nach dem ich die physischen Schalter in den Räumen das erste mal betätigt habe. Ich kann problemlos über die Weboberfläche von FHEM alles schalten und ich sehe auch sofort in FHEM wenn jemand den physischen Schalter betätigt hat. Soweit also alles gut. Nun habe ich im Wiki einen Artikel zum FSB14 entdeckt (Rolladensteuerung). Da gibt es die Möglichkeit die Rolladen bspw. nur teilweise zu schließen (shutTime, shutTimeClose). Mit den bei mir automatisch angelernten Schaltern funktioniert das aber nicht. Da gibt es nur die Auswahl A0/AI bzw. B0/BI.
Also habe ich nach der Wiki Anleitung zum FSB14 einen entsprechenden zusätzlichen virtuellen Schalter in FHEM angelegt, eine eigens generierte ID in subDef eingetragen und diese per PCT14 auch im Aktor eingetragen.
Soweit funktioniert das auch. Aber sehe ich das richtig, dass hier FHEM anhand meiner Zeitvorgaben die Rolladen-Stellung ,,nur" berechnet? Vom FSB14 kommt keinerlei Rückmeldung in welcher Position der Rolladen wirklich steht und ob er ganz auf oder ganz geschlossen ist, richtig? FHEM ,,merkt" sich einfach intern wieviele Sekunden zwischen bspw. dem Befehl zum Hochfahren und einem Stop Befehl vergangen sind und berechnet daraus dann die Position des Rolladens.

Danke vorab & Grüße
raumhafen
RPI3, EnOcean, FGW14-USB, HM-IP, Synology Diskstation, PIKO Kostal, Proxon FWT 3 2.0

hexenmeister

Moin!

Ich versuche mal Deine Fragen zu beantworten.

Zu 1.
ESP2 ist ok. Das ist die Protokoll-Verion. FGW14 spricht ESP2. Hat keine Nachteile.
Ich verwende 57600 Baud, das Rädchen am FGW ist auf Position 6. Läuft ohne Probleme, allerdings nicht mit Deiner vergleichbar, da über ser2net über Ethernet 'verlängert'.

Meine Definitionen:
Ser2net (wie man sieht mit 57600 Baud):
2206:raw:0:/dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A104FJ6M-if00-port0:57600
8DATABITS NONE 1STOPBIT remctl

Gateway in FHEM:
define FGW14 TCM ESP2 192.168.0.11: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

Zu 2.
Ich benutze automatisches Anlegen nicht. Kann also nur vermuten.
Ich denke, das eine ist die Abbildung von den 'echte' Schaltern, das andere die virtuellen FHEM-Schaltern, die müssen, um zu funktionieren, in den Geräten (per PCT14, oder per Rädchen am Gerät) angelernt werden.

Zu 3.
Hilfe sagt: "In die Rückmeldeliste können Geräteadressen eingetragen werden, die bei der zyklischen Abfrage von Geräten verwendet werden."
Für korrekte Rückmeldungen spielt die die Betriebsart mit:
- 2 für die Rückmeldung ALLER Geräte,
- 5 für die Rückmeldung nur der Geräte die in PCT14 im FAM14 in der Rückmeldeliste konfiguriert sind.

Meine Liste enthält alle Geräte, ich kann mich nicht erinnern, sie manuell angelegt zu haben, sind wohl beim anlernen automatisch erzeugt worden. Ist schon länger her.
Wenn Du Rückmeldungen in FHEM von den Aktoren schon bekommst, dann lass das so.

Zu 4.
Mit den Automatisch angelernten Schaltern kann das auch nicht funktionieren. Damit simulierst Du ja nur einen Tastenklick. Lerne korrekt einen virtuellen Schalter an.
Du hast Recht, FSB14 ist etwas simpel gestrickt. Soweit ich weiß, muss man ihm schon sagen, wie lange er in welche Richtung zu fahren hat. FHEM berechnet die Position. An dem FSB werden ledoch Laufzeiten eingestellt, damit der Aktor weiß, wenn Rollo sicher auf oder sicher zu ist. Rest ist leider eine Schätzung. Meine Motoren haben dazu noch eine merkliche Anlaufzeit (was man in FHEM nicht einstellen kann), da haut FHEM leider oft daneben.

Grüße
Alexander
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

raumhafen

Super, vielen Dank Alexander für Deine ausführlichen Antworten  :)
Das hilft mir auf jeden Fall wieder ein Stück weiter!

Grüße
Michael
RPI3, EnOcean, FGW14-USB, HM-IP, Synology Diskstation, PIKO Kostal, Proxon FWT 3 2.0