Einstufiges Modulkonzept, korrekte Implementierung

[Crania]

Hallo,

ich betreibe schon seit Jahren eine propritäre Home Halbautomatisierung.
Unter anderem auch ein LAN-PowerLineGateway (LAN_PLG) über das mehrere
Module(Licht, Sensoren, usw.) über das Stromnetz abgefragt und geschaltet werden können.

Nun versuche ich das System aus der ,,propritären Ecke" herauszuholen und bin dabei auf FHEM gestoßen.
Nach dem obligatorischen Studium der Dokumentation (Installation, CommandRef, Anfänger Pflichtlektüre,
Beispiel-Tutorial, Entwickler-Doku, ...) habe ich nun mein erstes Modul erstellt
um zwei Wohnzimmerlampen zu schalten.

Nachdem diese Hürde genommen war, gab es folgendes Problem:
In der Funktion X_define()  wird die Verbindung zum LAN-PowerLineGateway aufgebaut und ist somit für
das propritäre Restsystem nicht mehr erreichbar, da belegt.
Ich habe daraufhin das DevIo_OpenDev() in die X_Set() Funktion verlegt und in der X_Read() Funktion
nach dem Lesen des Ergebnisses die Verbindung mit DevIo_CloseDev() wieder geschlossen.
Nun wird die Verbindung nur belegt, wenn auch etwas geschaltet werden soll. Soweit, so gut.

Jetzt trat aber ein neues Problem auf und zwar wenn ich die beiden Lampen zum gleichen Zeitpunkt
mit sunset_real() einschalten will. Die beiden X_Set() Funktionen werden direkt hintereinander
ausgeführt ohne ein X_Read() dazwischen.
Ich habe daraufhin das DevIo_OpenDev()  des zweiten X_Set() Aufrufs unterdrückt.

Nun funktioniert es soweit... aber nun meine Frage:
Ist dies überhaupt der richtige Ansatz, oder bin ich hier auf einem Irrweg?
Am Anfang läuft man ja mal gerne in die falsche Richtung...

Vielen Dank, Crania

[Beta-User]

Willkommen im Forum!

Das ist zwar eigentlich keine Anfängerfrage, aber da sie in diesem Bereich gestellt wird, trau ich mich noch, sie zu beantworten:
MMn. sollte man in so einem Fall ein zweistufiges Konzept fahren, damit die Warteschlangenverwaltung in beide Richtungen paßt.

Als Client-Modul könntest du MQTT2_DEVICE verwenden, darüber ist die Kommunikation zwischen beiden Modulen mMn recht einfach zu machen und die optische und funktionale Gestaltung des Zieldevices so easy wie bei dummy. (Rudi erklärt dir das auf Frage sicher gerne, sofern erforderlich).

Gruß, Beta-User

[Crania]

Hallo Beta-User,

vielen Dank für Deine Antwort.

Ich werde mir das mit dem zweistufigen Modulkonzept einmal anschauen und
ob ich damit weiterkomme.
Ich habe zwar gelesen, dass sowas existiert, hatte aber schon genug mit dem
einstufigen Modulkonzept zu tun.  Ich dachte, dass ich damit auskomme.

Nach meinem jetzigen Kenntnisstand müssen die Interfaces zur Hardware,
konzeptionell ständig mit FHEM verbunden sein.
Dies ist natürlich auch notwendig, damit die Sensoren motiviert ihre Daten absetzen können.

Mein Grundproblem ist, dass FEHM mir das LAN-PowerLineModem festhält und ich von
einer anderen Applikation nicht mehr darauf zugreifen kann.

Gruß Crania

[CoolTux]

Scheint dann aber eher ein Designproblem der Schnittstelle zu sein. Eine ständige Verbindung ist auf jeden Fall ein muss da Du ja externe Zustandsänderungen mitbekommen möchtest in FHEM. "Lichtschalter betätigt"

[Crania]

Hallo,

ja, das Design, bzw. die Architektur des Moduls ist ja gerade mein Problem:
Ich habe Aktoren die am Stromnetz hängen (Lampen, Jalousien, Rollos, ...) und die
auch über das Stromnetz kommandiert werden.
Der Zugang erfolgt hier über ein LAN-PowerLineGateway.
Die Aktoren sind reine ,,Befehlsempfänger", senden also von sich aus unmotiviert keine Daten.
Da diese Schnittstelle unidirektional ist, habe ich folgendes implementiert:

X_set() {
  If (Keine Verbindung) {
     Verbindungsaufbau()
  }
  Kommando senden()
}

X_read() {
  Ergebnis lesen()
  Verbindungsabbau()
}

Mit dieser Struktur kann ich in den Zwischenzeiten  das LAN-PowerLineGateway von einer anderen Applikation nutzen.
Es funktioniert zwar, war aber wohl nach meinem jetzigen Kenntnisstand vom ,,Vater" der FHEM-Architektur nicht vorgesehen.
Ich glaube, meine Eingangsfrage ist damit beantwortet und man kann diesem Thema nicht mehr abgewinnen...

Vielen Dank für Eure Antworten/Anregungen.
Gruß Crania

[CoolTux]

Ich meinte eigentlich nicht der FHEM Schnittstelle sondern der Schnittstelle vom LAN-PowerLineGateway.
So wie Du es aktuell beschrieben hast verstehe ich es so das man ein betätigen eines Lichtschalters nicht mit bekommt.
Wie ist es denn wenn jemand am Aktor das Licht an macht, wird dann überhaupt mitbekommen das der Aktor betätigt wurde? Oder kann man am Aktor selber gar nicht schalten sondern dies erfolgt an einem extra Taster.

[Beta-User]

Na ja, im Prinzip ist es egal, ob am Aktor direkt oder an einer Tasterschnittstelle geschaltet wird, oder? Entweder es gibt eine Verbindung, dann kann man es auch direkt lesen, oder man müßte ggf. (regelmäßig) pollen, sofern das möglich ist.

Wie auch immer: Es scheint nur eine Gegenstelle (das LAN-PowerLineGateway) zu geben, dahinter hängen dann die diversen Geräte. Das klingt für mich nach einem zweistufigen Konzept, bei der jeder (?) Kanal dann ein (Client-) Gerät bilden sollte. Wie gesagt: Es ist mMn. nicht erforderlich, dazu ein eigenes CLIENT-Modul zu bauen, es müßte reichen, dass das GW-Modul passende MQTT-Strings bastelt und an MQTT2_DEVICE übergibt und in der Lage ist, entsprechende Textinfo auszuwerten, die MQTT2_DEVICE als publish übergibt.

Also IO an MQTT2_DEVICE: 

Code Auswählen Erweitern

aktorxyz:LANPowerLineGateway/aktorxyz/state onSollte dazu führen, dass Gerät mit der CID "aktorxyz" erstellt wird (Name: MQTT2_aktorxyz), das ein Reading "state" erhält, das den Wert "on" hat... (wie man das mit autocreate an's IO bringt, wäre noch zu klären, kann aber nicht schwer sein, vermutlich reicht ein Attribut namens "autocreate" mit der Angabe "simple").

Umgekehrte Richtung z.B.

Code Auswählen Erweitern

LANPowerLineGateway/aktorxyz/state/set offDas müßte dann der IO-Code eben auswerten können...