[Fazit] Zuverlässigkeit von Schaltbefehlen

[Spartacus]

Hallo,
Ich mochte an dieser Stelle eimal in die enocean Gemeinde fragen, wie ihr die Zuverlässigkeit von Schaltbefehlen im enocean Funknetz beurteilt. Ich habe div. Aktoren, die über fhem direkt geschaltet werden. Z.b in Abhängigkeit von Sonnenauf bzw. Untergang.

Meine Erfahrung über mehrere Wochen ist, dass von 10 Aktoransteuerungen einer nicht ankommt und der Aktor nicht geschaltet wird. Hier müsste fhem m.E. immer die Quittung des Aktors abwarten und ggf. den Aktor so lange absteuern, bis der entsprechende Befehl ausgeführt wurde.

Wie löst ihr das Problem, oder habt ihr das Problem  nicht?  Wäre dankbar für Feedback bzw. Anregungen hier sauber und zuverlässig schalten zu können

Spartacus

Nachtrag:
An der Funkreichweite liegt es nicht, da auch Befehle im drahtgebundenen RS485 Bus nicht ankommen...

[Puschel74]

Hallo,

ich setze in der Firma seit 3 Monaten einen RasPi mit EnOcean-Pi ein.
Dieser sendet an drei FAM14 die per RS485 die Befehle an die Aktoren weiter leiten.
Diese dimmen dann im Anschluß die jeweiligen Lampen in den Räumen hoch und runter - gesamt sind es 36 Räume auf 3 Etagen.

Sollte da etwas mal nicht klappen würde bei mir ganz schnell das Telefon klingeln.
Und das macht es seit gut 3 Monaten nicht (also das Telefon klingelt nicht deswegen) - ich geh mal davon aus das alles funktioniert wie es soll.

Grüße

[Spartacus]

.....das verstehe ich einfach nicht! Was um alles in der Welt ist bei mir anders?
Hängt der rpi per USB direkt am FAM 14 oder funkstt Du über ein enocean Modul? Ich habe beides am Start und es geht nicht!
Ich glaube, ich kaufe mal einen neuen pi und mache nur enocean damit. Vielleicht ist da zu viel drauf auf der
Kiste...

Das ist echt  nervig, dass das nicht zuverlässig läuft...habe aber keine Ahnung woran das liegt!

Christian

[Puschel74]

Hallo,

mit EnOcean-Pi ein.

Ich sende über das EnOcean-Pi auf die FAM14 - logischwerweise,
Per USB wäre ja das EnOcean-Pi etwas "unnötig" und würde dann auf 3 FAM14 so wohl nicht klappen.
Der RasPi ist in einer Elektroverteilung im 3. OG und sendet die Steuerbefehle über das EnOcean-Pi an die FAM14 im 2. OG, 3. OG (also direkt daneben) und ins 4. OG.

Grüße

[Spartacus]

Hi,
danke puschel! Ich weiss echt nicht was da los ist. Ich habe noch eine andere Micro-SD da rum liegen, da packe ich mal ein neues rpi Image drauf und bestelle parallel mal eine neue Hardware.
Das gibt es doch nicht, dass das bei mir so unzuverlässig läuft. Ich bin total enttäuscht von der Sache und habe keine Ahnung, wo ich noch dran drehen soll!

Ich kann ja mal meinen Code posten! Vielleicht fällt ja irgendjemandem noch was auf...
Alle 8 Kanäle der beiden Aktoren (FSR14-4x) sind identisch eingelernt und haben alle das gleiche Problem. Mal ist es der eine, mal der andere Aktor.

Code Auswählen Erweitern

# FAM 14
define FAM14 TCM ESP2 /dev/ttyUSB0@57600
attr FAM14 comType RS485
attr FAM14 learningMode demand
attr FAM14 room EnOcean
attr FAM14 sendInterval 0
attr FAM14 verbose 3

Code Auswählen Erweitern

define EnO_switch_00000002 EnOcean 00000002
attr EnO_switch_00000002 IODev FAM14
attr EnO_switch_00000002 alias Eingangslicht
attr EnO_switch_00000002 devStateIcon .*on:FS20.on@lightgreen .*off:FS20.off@red
attr EnO_switch_00000002 event-on-change-reading state,buttons,channelA,channelB
attr EnO_switch_00000002 group manuell
attr EnO_switch_00000002 gwCmd switching
attr EnO_switch_00000002 manufID 00D
attr EnO_switch_00000002 room Eingang
attr EnO_switch_00000002 subDef 00100002
attr EnO_switch_00000002 subType gateway
attr EnO_switch_00000002 verbose 3

Das DOIF schaltet korrekt und das Lämpchensymbol zeigt es auch korrekt an. Der Aktor 00000002 wird bei ca. 10x Schalten 1 x ignoriert.

Christian.

[Spartacus]

Hallo,
ich bin immer noch auf der Suche nach dem Fehler! Selbst nach der Neuinstalltion des pi und der Reduktion der Last durch entfernen von Devices, taucht der Fehler immer noch auf.

im Logfile von fhem wird der Befehl zur Ansteuerung des Aktors als "gesendet" protokolliert. Der Aktor selber scheint den Befehl aber nicht zu bekommen.
Da der pi direkt über USB am Port des FAM14 hängt, finde ich das Ganze sehr, sehr seltsam!

Ich habe zu Testzwecken mal den Schalter am FAM14 von Pos.4 auf 2 zurückgestellt. Das bedeutet, dass keine permanenten Statustelegramme mehr auf den BUS gelegt werden. Es werden jetzt nur noch Bestätigungstelegramme gesendet.
Nur durch Änderung dieser Einstellung geht die fhem-Prozess CPU-Last von 20% auf knapp 11% herunter. Das kann man sehr schön beobachten!

Ich vermute mal, dass der pi bei dem Protokollgewitter (Pos.4) Probleme am USB-Port bekommt (das FAM 14 haut hier ca. 20 Statustelegramme pro Sekunde raus, das kann man im fhem logfile bei verbose 5 sehen) und ein gesendeter fhem Befehl einfach nicht ankommt.

Leider verstehe ich zu wenig von der Thematik, glaube aber nicht, dass das FAM14 hier die Befehle nicht weiterleitet, sondern das Problem auf der pi oder fhem-Seite liegt.

Ich beobachte das jetzt mal unter Pos.2 und lasse einen Aktor zyklisch alle 15min für 5min laufen.

Für Kommentare und Anregungen die zur Aufklärung dieser Sachlage dienen, wäre ich dankbar!

Christian.

[der-Lolo]

Vielleicht hast Du ja eine Möglichkeit das ganze mal auf anderer Hardware Basis als dem Pi aufzubauen.
Ich mag das Ding mittlerweile gar nicht mehr - hier hat es laufend Probleme gegeben.
Vermutlich bedingt dadurch das der Lag Port und der USB Port des Pi über den gleichen Bus angesprochen werden.

Ein Wechsel auf den BeagleBone brachte einen Wahnsinns Unterschied ( bei gleicher Konfiguration ).

[Spartacus]

Hallo der-Lolo,
ja, ich danke Dir. Ich hatte zwar den pi schon gegen einen anderen pi getauscht, allerdings ohne Erfolg.
Ja der BeagleBone ist ja auch noch da, ich hatte schon an den Cubi 3 gedacht. Aber mit round about 130 Ocken ist das auch ganz schön viel mehr als so nen pi.

Aber Du hast recht, ich fürchte ich muss da ran..
Ich berechte mal von meinem Test.
Christian

P:S.
Betreibst Du auch einen enoceanRS485 direkt an einem BeagleBone ?

[der-Lolo]

nein, ich habe gar kein EnOcean im Einsatz...

[Spartacus]

Hallo,
ich kann den Versuch schon abbrechen! Fehler bleibt!
Jetzt kann ich nur noch den pi gegen eine andere HW zu tauschen...was anderes fällt mir nicht mehr ein....
 
Spartacus

[Spartacus]

Hallo,
so! Ich kann nun definitiv den pi ausschließen. Habe heute ein Notebook mit debian installiert, fhem draufgemacht und alles neu eingerichtet.

Notebook per USB ans FAM14, alle Aktoreinstellungen über die eltako SW zurückgesetzt, alles in fhem neu angelernt und ein Testscript installiert:

Code Auswählen Erweitern

*20:00:00 {  { fhem("define Test at +*{100}00:10:00 set EnO_switch_00000003 on-for-timer 300") } }

fhem läuft jetzt sauschnell, aber der Fehler bleibt! Irgendwann kommt ein Schaltbefehl oder eine Quittung  nicht an! Im fhem log wird fleißig jeder Schaltbefehl dokumentiert. Im Devicelog sieht man dann, dass Befehle verloren gehen.

Jetzt kommt noch hinzu, dass sich ab und zu die Verbindung zum FAM14 aufhängt! Dann kann man keine Aktoren mehr über die Oberfläche mit "set <device> on" schalten.

Wenn man den "DEF"-Bereich des FAM14 einmal öffnet und wieder schließt, geht alles wieder! Hier hängt sich offenbar die Connection zum FAM14 auf!

Entweder ist das FAM14 defekt, oder diese Verbindunf ist mit fhem nicht kompatibel!

Was kann ich noch testen oder machen?
Wer hat noch Ideen?

Christian

[Spartacus]

Hallo,
nach vielen Tests mit unterschiedlicher HW bin ich zu dem Schluss gekommen, dass Fhem sich per USB nicht sauber an ein FAM14 ankoppeln lässt. Wie beschrieben kommen Schaltbefehle sporadisch nicht am Aktor an und teilweise bleiben auch Quittung aus!
Offenbar verhält sich ein FAM14 nicht wie ein USB-GW!

Inzwischen habe ich die Konfiguration umgebaut und steuere jetzt das FAM14 über meinen enocean pi per Funk an. Das Testscript oben hat über Nacht 500 Schaltbefehle ausgeführt, alle Befehle wurde korrekt ausgeführt! Leider muss ich mir nun etwas anderes für mein FTS14-EM einfallen lassen...

Mich würde allerdings interessieren, ob jemand die USB-Variante erfolgreich betreibt!

Spartacus.