Eltako 14er Serie via FGW14 inkl Statusnachrichten von bid. Aktoren an FHEM

[g.carls]

(1) der rot markierte Index In der Bedingung für "autoMeterReading.01" muss 1 und nicht 0 sein,
denn db0 wird ja vorher schon auf 8F geprüft. D.h., es wird immer der else Zweig abgearbeitet.
(2) Die beiden printf müssen sprintf sein,
(3) Im (s)printf muss dann noch das %4c durch %4s ersetzt werden, da sonst der erste Teil der Seriennummer als ASCII Code interpretiert wird und je nach Inhalt nicht lesbar ist.

im Eventlog erhalte ich nach diesen Korrekturen dann folgende Ausgaben:
2014-03-20 07:31:05 EnOcean C_BRUNNENPUMPE serialNumber: S-70
2014-03-20 07:31:06 EnOcean C_BRUNNENPUMPE serialNumber: S-700032
2014-03-20 07:31:07 EnOcean C_BRUNNENPUMPE energy0: 13.3

Damit in den FileLogs und in DbLog nicht alle 10min die verstümmelte Seriennummer ("S-70") auftaucht möchte ich noch gerne den grün markierten Code hinzufügen, der analog zu Deiner Lösung zur Verarbeitung der hinteren Digits sich den Rest der Seriennummer aus dem letzten Reading holt.

Damit erhält man dann folgende Eventlog-Ausgaben:
2014-03-20 08:11:26 EnOcean C_BRUNNENPUMPE serialNumber: S-700032
2014-03-20 08:11:27 EnOcean C_BRUNNENPUMPE serialNumber: S-700032

Macht man diese Anpassung nicht, dann führt
event-on-change-reading zu überflüssigen Events mit kurzzeitig falschen Werten (S-70).
oder bei event-min-interval wird u.U. die ganze Zeit nur S-70 angezeigt.

Als Reading wird dann
serialNumber    S-700032    2014-03-20 07:31:06
in FHEM angezeigt.

Hier der Quellcode mit den Hinweisen auf die Fehler:

if ($db[0] == 0x8F && $manufID eq "00D") {
          # Eltako, read meter serial number
          my $serialNumber;
          if ($db[0] == 0) {
            $serialNumber = substr(ReadingsVal($name, "serialNumber", "S-------"), 4, 4);
            # first 2 digits of the serial number
            $serialNumber = printf "S-%01x%01x%4s", $db[3] >> 4, $db[3] & 0x0F, $serialNumber;
          } else {
            # last 4 digits of the serial number
            $serialNumber = substr(ReadingsVal($name, "serialNumber", "S---"), 0, 4);
            $serialNumber = printf "%4c%01x%01x%01x%01x", $serialNumber,
                            $db[2] >> 4, $db[2] & 0x0F, $db[3] >> 4, $db[3] & 0x0F;
          }


Anbei das korrigierte EnOcean Modul.

Viele Grüße,

Guido

[klaus.schauer]

Ich freue mich, dass Du dir den Quellcode angesehen hast. Vier Augen sehen mehr als zwei. Leider finden sich in dem Fhem Projekt kaum Leute, die sich intensiv an der Qualitätssicherung beteiligen.
Ob dazu allerdings oberlehrerhafte Bemerkungen wie "Ja, da sind 4 Fehler in 7 Zeilen Code" oder "Der Wert 01 in DB1 sagt uns, dass..." notwendig sind, bezweifle ich.

[g.carls]

Sorry, das war nicht meine Intention.

[klaus.schauer]

Fehlerberichtigung zur Anzeige der Seriennummer steht ab morgen per update zur Verfügung.

[g.carls]

Danke für den ergänzten Quellcode. M. E. ist es aber notwendig, auch die Dokumentation dazu zu erweitern. Ein Forumsartikel, der später kaum auffindbar sein wird. ist zu wenig. Eine "versteckte" Funktion, ist für andere Fhem Nutzer sinnlos. Ich bitte deshalb auch um eine Beschreibung der Funktionen und Einstellparameter. Hierzu gibt es am Ende der 00_TCM-Datei einen HTML-Abschnitt, der automatisch in die commandref übernommen wird. Bitte hier die wesentlichen Neuerungen aufnehmen.

Ich habe etwas Dokumentation zu meinen Anpassungen im TCM Modul ergänzt. Anbei das um die Dokumentation ergänzte Modul.

[klaus.schauer]

Neue TCM-Datei V5270 ist eingestellt. Ich musste die Ergänzungen jetzt in die Version 5263 von TCM nachträglich einarbeiten. Die Arbeiten an den Dateien haben sich überschnitten.

Derzeit kann man die Stati der Eltako-Geräte am 14er-Bus auslesen. Wäre über diese Schnittstelle grundsätzlich später auch eine Steuerung der Geräte am Bus möglich? Falls ja, wird daran gearbeitet?

Können über diese Lösung u. U. auch zusätzlich Telegramme von anderen Devices außerhalb des Busses empfangen werden oder sogar dorthin gesendet werden?

Das EnOcean ESP2 ist ja zwischenzeitlich in die Jahre gekommen. Kann alternativ auch das aktuelle ESP3 über das Gateway verwendet werden?

[g.carls]

Ich habe beide Module getestet. Funktionieren beide einwandfrei. Besten Dank für die Anpassungen!

Zu den Fragen:

(1) Steuern anderer Module mit FGW14:
Bisher ist mir das Steuern anderer Geräte noch nicht gelungen:
Das FAM14 Modul vergibt an andere Module am Bus die Ids. D.h., man muss jeden Busteilnehmer am FAM14 anmelden und dieses Modul erhält dann ein oder mehrere Ids.
Das automatische Auslesen der BaseId via FHEM funktioniert leider nicht.
Mit der PCT16 Software von Eltako kann man allerdings die bereits vergebenen Ids am Bus ermitteln und die BaseId auslesen.
U.U. gelingt das Schreiben, wenn man die BaseId auf diesem Weg ermittelt und manuell in die fhem.cfg einträgt. Man muss dann allerdings beachten, dass man keine ID verwendet die das FAM-Modul an andere Module auf dem Bus bereits vergeben hat.
Das habe ich bisher noch nicht getestet.

(2) Empfang von Telegrammen ausserhalb des Busses
Ja das geht. Das FAM14 Modul schreibt die über EnOcean-Funk empfangenen Telegramme auf den Bus und diese erhält auch FHEM über das FGW14.
Das FAM14 leitet leider nur bestimmte Telegramme vom Bus in das Funknetz weiter jedoch nicht alle um so wohl Loops zu vermeiden.

(3) ESP3 mit FGW14
Nein. Das FGW14 unterstützt nur ESP2 mit zwei unterschiedlichen Baudraten: 9600 und 57600. Eltako nennt das dann BR12 und BR14.

VG, Guido

[g.carls]

Steuerung von Modulen am RS485 Bus via TCM120 über das RS232 Gateway FGW14 von Eltako geht!
Damit ist eine vollwertige Integration des Eltako RS485 Buses in FHEM ohne Funkschnittstelle möglich.

Ich habe zu Punkt (1) meines letzten Posts einen Test mit einem FSR14-4x von Eltako machen können:
Man muss keine vom FAM14 vergebenen IDs verwenden, sondern man kann sich frei irgendwelche IDs auswählen.
Diese sollten nur nicht im Bereich der IDs des FAM14 liegen.

Die folgende Definition wertet die Statusmeldungen vom FSR14-4x aus, welcher die ID 00000002 verwendet.
Für Schaltaktionen via FHEM muss man eine eigene ID via subDef vorgeben (attr B_HOF_SUED_WANDLAMPE subDef 00001002).
Für Schaltaktionen via FHEM habe ich in Kanal 1 des FSR14 Aktors diese ID (00001002) eingelernt (set B_HOF_SUED_WANDLAMPE teach) während der mittlere Drehschalter des FSR-14 auf Kanal 1 steht und der untere auf LRN. Die Stellung des oberen Drehschalters spielt keine Rolle. On (B0) und Off (BI) werden beide automatisch eingelernt.

Nur wenn ich eine eventMap auf On und off definiert (attr B_HOF_SUED_WANDLAMPE eventMap BI:off B0:on) habe, erhalte ich Fehlermeldungen, da die FHEM Buttons trotzdem BI und B0 verwenden. Vielleicht ist dies aber auch ein Konfigurationsfehler meinerseits.
Lässt man eventMap weg und lässt es damit bei BI und B0 funktioniert alles.



#
# B_HOF_SUED_WANDLAMPE
#
# B0: Lampe an
# BI: Lampe aus
#

define B_HOF_SUED_WANDLAMPE EnOcean 00000002
attr B_HOF_SUED_WANDLAMPE IODev TCM120
attr B_HOF_SUED_WANDLAMPE alias Hof Wandlampe Süd
attr B_HOF_SUED_WANDLAMPE event-on-change-reading state,buttons,channelA,channelB
#attr B_HOF_SUED_WANDLAMPE eventMap BI:off B0:on
attr B_HOF_SUED_WANDLAMPE group Beleuchtung
attr B_HOF_SUED_WANDLAMPE gwCmd switching
attr B_HOF_SUED_WANDLAMPE room 6.01 Garten
attr B_HOF_SUED_WANDLAMPE subDef 00001002
attr B_HOF_SUED_WANDLAMPE subType gateway
#attr B_HOF_SUED_WANDLAMPE subType switch

Soll ich einen entsprechenden Beitrag zur  Dokumentation für das TCM Modul und/oder  ggf für das Enocean Modul verfassen?

VG, Guido

[klaus.schauer]

Im Wesentlichen müssen die Unterschiede bei der Vergabe der Fhem  SenderIDs i. d. R. über subDef und den Aufbau der SenderIDs des Eltako-Busses beschrieben werden. Das würde gut als zusätzlicher Abschnitt in den allgemeinen Text zu Beginn des EnOcean Abschnittes in der commandref passen.

Vielleicht wäre auch ein Wiki-Beitrag über die gesamte Konfiguration und die Besonderheiten hilfreich. Durch die einzelnen Textpasssagen in TCM und EnOcean kann man schwer einen Gesamtüberblick erhalten.