ITGW-433

Begonnen von Finkman, 20 Februar 2017, 20:54:01

Vorheriges Thema - Nächstes Thema

Finkman

Hallo Zusammen,

ich hab einige Intertechno Steckdosen und ein ITGW-433, welche ich gerne über FHEM verheiraten möchte. Ich versuche mich da schon einige Zeit dran, leider bisher ohne Erfolg.
Eine richtige Anleitung habe ich bis jetzt nicht gefunden.

Jetzt erhoffe ich mir, dass einer von Euch ähnliches erfolgreich versucht hat und mich in die richtige Richtung stupsen kann.

Über einen guten Tipp freue ich mich riesig.

Finkman

Habe gesehen, dass Guidelines zu Schreiben neue Treiber in FHEM gibt.
So wie ich das sehe, brauche ich "nur" ein Treiber für das ITGW, der dies als IODev repräsentiert.

Hat jemand diesbezüglich Informationen über das Interfacing zwischen einem Intertechno Gerät "IT" und dessen IODev?

KölnSolar

Du könntest die 00_CUL.pm vielleicht als Ausgangspunkt nehmen. Dort erst einmal alles rausschmeißen, was nicht IT ist, damit es übersichtlicher wird. Verarbeitet werden Intertechno-Daten dann über das Modul 10_IT.pm
Wird bestimmt nicht einfach  :-\
Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Finkman

Zitat von: KölnSolar am 21 Februar 2017, 18:33:18
Du könntest die 00_CUL.pm vielleicht als Ausgangspunkt nehmen. Dort erst einmal alles rausschmeißen, was nicht IT ist, damit es übersichtlicher wird. Verarbeitet werden Intertechno-Daten dann über das Modul 10_IT.pm
Wird bestimmt nicht einfach  :-\
Grüße Markus
Heißt das, dass mein Treiber rein als Gateway dient, oder muss der was über das Kommunikationsprotokoll wissen?


Gesendet von iPhone mit Tapatalk

KölnSolar

Ähmm, wie meinen ?
Von Treibern reden wir ja bei ein paar Ebenen tiefer. :o Bei FHEM reden wir von Modulen, die in Perl geschrieben sind.
Und wenn ich Deine Frage richtig verstehe: ja. Das Ding hat ja Lan, also wohl TCP. Die Kommunikation wird  in der App programmiert sein. Und anstatt der App müsstest Du das in ein Modul packen. Oder das Gateway hat einen Webserver, den man über http steuern kann.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

Finkman

Ja... Modul, nicht Treiber.

Meine Frage zielte eher darauf hinaus, in wiefern das IODev-Modul gerätespezifisches Wissen über den Aktor habe muss, oder ob es ein reines Gateway ist.
Gibt es eine Dokumentation über die Schnittstelle zwischen IT <-> IODev?

... von welcher App redest du eigentlich?


Gesendet von iPhone mit Tapatalk

KölnSolar

Zitat... von welcher App redest du eigentlich?
von der die bei IT zum Betrieb des ITGW zur Verfügung gestellt wird.
Zitatin wiefern das IODev-Modul gerätespezifisches Wissen über den Aktor habe muss, oder ob es ein reines Gateway ist.
Definiere Gateway  :-\
Es gibt unterschiedliche Konzepte. Der CUL hat als firmware die culfw(C, open source). Die culfw beinhaltet das Funkprotokoll, kann dieses empfangen und erkennen, sowie senden, sowohl V1, als auch V3. Ein konkretes Gerät, Gerätetyp kennt sie nicht. Neben IT werden weitere Protokolle erkannt. Das Modul 00_CUL.pm "verteilt" empfangene Daten zur Weiterverarbeitung an protokollspezifische Module. Für IT eben an 10_IT.pm. Dieses dient der Gerätedefinition, Befehlsinterpretation(Empfang), dem gerätespezifischen Senden von Befehlen...
Definiert man ein Gerät über 10_IT wird als IODev der CUL zugewiesen, dem Gateway.

Klarer oder noch verwirrter  :-\
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt