nanoCUL und intertechno

Deutsche Foren Hardware
#32

Ich greife jetzt nochmal hier meine Gedanken auf: in der Openweather-Implementierung gibt es genau ein Device, welches Daten über eine JSON-Schnittstelle von openweather abholt. Im Device ist ein Skript definiert, dass immer läuft, einen eigenen Scheduler hat und nach Ablauf der eingestellten Polling-Zeit wieder losläuft, Daten von openweather abholt und auf die homegear-Objekte schreibt.
Würde ich dieses Muster verwenden, würde ein Device (eine Steckdose) den CUL exklusiv öffnen, so dass keine weiteren Devices mehr auf den CUL zugreifen könnten. Das wäre nicht gut.
Also muss der CUL anders global angebunden werden und eine Schnittstelle bereitstellen, die dann aus dem Device-Skript angesprochen wird.
In diesem Zusammenhang verstehe ich auch die Funktion vom Client-Skript nicht ganz. Wo kommt denn die XMLRPC-Schnittstelle zum Einsatz.

Mit fehlt ein wenig das “big picture” …

#33

Das “big picture” kann @sathya sicher am besten geben.

Genau wegen cul2mqtt habe ich FHEM ins Spiel gebracht. Ich hatte hier das gleiche Problem mit enOcean. enOcean2mqtt hat nie mit Aktoren funktioniert - deswegen FHEM als Brücke in mqtt.

@Dennis, wenn ich aber @jogant richtig verstehe, wirst du den Intertechno Taster nicht abfragen können weil das 433MHz Modul im CUL nur senden kann, oder?

#34

Der CUL kann senden und empfangen. Im richtigen Modus (ich meine, X67) werden Intertechno Telegramme empfangen. Allerdings müssen die dekodiert werden. Das macht zumindest openHAB nicht. Mit der zitierten CUL2MQTT Variante werden raw-Nachrichten empfangen. Da muss man dann passende MQTT Messages draus machen.

[edit]
die geforkte Version von CUL2MQTT von akentner kann im Gegensatz zum Original auch senden… da hatte ich was durcheinander gebracht. Zum reinen Empfang von IT-Nachrichten funktioniert auch das Original von hobbyquaker.
… Wenn die serielle Kommunikatin geht. Bei mir leider nicht :frowning:
[/edit]

#35

Und das erklärt dann, warum @Dennis das mit openHab nicht ans laufen bekommt. Danke @jogant für die Aufklärung.

@Dennis, dir bleibt dann also nur der Weg mit cul2mqtt oder FHEM.

Vielleicht noch etwas zur Erklärung: Homegear spricht mit openHab normalerweise über XML-RPC - also genau so, wie es die CCU tun würde kann aber andere/mehr Hardware anbinden, die es dann über XML-RPC abbilden kann.
MQTT ist nur eine weitere Art der Kommunikation. Hier bei mir verwende ich zB nur noch MQTT für alle Geräte, auch damals schon als ich noch openHab eingesetzt habe.

#36

da habe ich ja noch einmal so einen richtigen wissensaufbau für mich hinbekommen. also ich schlage nun einmal den ansatz mit mqtt ein und versuche darüber den CUL einzubinden. vielleicht habe ich darüber ja noch eine chance.

@jogant: wenn ich über screen und dem modus x25 empfangene daten anzeigen lassen kann, kann ich dann davon ausgehen das die serielle kommunikation funktioniert? oder sagt das noch lange nichts darüber aus?

Viele Grüße
Dennis

#37

2 posts were split to a new topic: Cul2mqtt mit Intertechno und openHab

#38

@Dennis
Wenn im mit X25 oder X21 oder X67 nach einiger Zeit Zeilen in Screen erscheinen, dann empfängt der CUL. Also soweit alles gut. Nur muss man die Pakete dekodieren. Auf 433 MHz sendet alles mögliche, irgendwelche Thermometer, Steckdosen, Schalter etc. Das ist aber nicht alles Intertechno. Da gibt es zig Protokolle.

#39

Hallo @Dennis,

mit meinem 433-MHz-CUL empfange ich mit X67 keine Pakete bei Druck auf die Fernbedienung. Senden klappt. Hast du noch irgendetwas gemacht, damit der Paketempfang klappt?

Viele Grüße

Sathya

#40

Ich habe mal den CUL mit screen angesprochen. Da reicht X67. Nach einiger Zeit kommen Telegramme rein. Ich kann die zwar nicht zuordnen, weil ja alles Mögliche auf 433 MHz sendet und der CUL anscheinend alles mitschneidet, aber wenn ich die Steckdosen-Fernbedienung drücke, rauschen einige Telegramme durch.

Grüße
jogant

#41

Hallo @sathya,

ich habe mal eine grundsätzliche Frage zum Skripten. Ich habe mir die Anbindung von openweathermap mal etwas genauer angesehen. Wenn ich das richtig verstehe, ist dort im Device (xml-Beschreibung) das PHP-Skript zur Datenanbindung und Abholung eingebettet. Wenn ich mir aber überlege, dass ich für meine Intertechno-Steckdosen jeweils ein Device anlegen würde, kann ich dort ja nicht das Skript zur seriellen Verbindung zum CUL einbetten, da dann ja die anderen Devices nicht mehr drankommen. Wie kann man ein global verfügbares Skript starten, dass dann Devices aktualisiert, bzw. Devices kommunizieren durch das globale Skript mit dem CUL. Da fehlt mir der Überblick über das Datenmodell in homegear. Gibt es da eine Doku oder ein anderes Beispiel?

Vielen Dank und Grüße
jogant

#42

Hallo @jogant,

kannst du mir die screen-Ausgabe mal schicken, damit ich schauen kann, ob es Intertechno-Pakete sind?

Richtig.

Richtig. Das einfachste wäre an dieser Stelle tatsächlich, alle Intertechno-Steckdosen über ein Gerät zu realisieren. Die Variante mit dem globalen Skript würde aber auch funktionieren. Das wird dann aber aufwändiger.

Das Ganze spielt aber keine große Rolle mehr, ich habe nämlich mal ein Intertechno-Modul implementiert: https://github.com/Homegear/Homegear-Intertechno

Ich vermute mal gegen morgen Abend sollte es auch für Raspbian Jessie kompiliert sein. Testen konnte ich es nur mit den neuen Steckdosen ohne DIP-Schalter.

Kurze Anleitung zum Erstellen von Geräten über das CLI:

fs 16
pc My-IT-Cul-1 1 ADRESSE

Adresse ist dabei bei den neuen Geräten die 26-stellige Gerätecode plus die 4-stellige Gruppen-ID. Das Ganze dann als Dezimalzahl. Also zum Beispiel:

  • Gerätecode: 01010010101011101000000110
  • Gruppe: 0001
  • Dann ist die Adresse 010100101010111010000001100001 => 14ABA060

Der Befehl im CLI wäre entsprechend:

 pc My-IT-Cul-1 1 14ABA060

Für die DIP-Geräte gilt das Analog:

  • Hauscode: F0F0
  • Gruppen-/Gerätecode: 0FF0
  • Festwert: 0F
  • Dann ist die Adresse F0F00FF00F. "F"s durch “1” ersetzen => 1010011001. Das Ganze Hexadezimal: 299.

Der Befehl im CLI entsprechend:

pc My-IT-Cul-1 1 299

Den Empfang von Paketen konnte ich noch nicht implementieren, weil mein CUL ja leider keine Pakete anzeigt.

Viele Grüße

Sathya

#43

Hallo @sathya,

das sind ja super News. Wenn die RPI Pakete da sind werde ich testen und berichten. Vielen Dank dafür.

Ich habe die empfangenen Codes mal mitgeschnitten, allerdings mit CUL2MQTT. Auch dort wird X21 zum Empfang der IT-Codes eingestellt:

A: ON:  2016-10-12 00:05:39.324 <debug> cul < i01455116 { rssi: -63 }		is000FF0FFFFFF
A: OFF: 2016-10-12 00:05:47.912 <debug> cul < i01555F16 { rssi: -63 }		is000FF0FFFFF0

B: ON:  2016-10-12 00:07:13.311 <debug> cul < i015151EF { rssi: -82.5 }		is000FFF0FFFFF
B: OFF: 2016-10-12 00:07:17.508 <debug> cul < i01555FF7 { rssi: -78.5 }		is000FFF0FFFF0

C: ON:  2016-10-12 00:08:06.512 <debug> cul < i01555F02 { rssi: -73 }		is000FFFF0FFFF
C: OFF: 2016-10-12 00:08:10.310 <debug> cul < i01555FEC { rssi: -84 }		is000FFFF0FFF0

D: ON:  2016-10-12 00:08:49.865 <debug> cul < i01555F05 { rssi: -71.5 }		is000FFFFF0FFF
D: OFF: 2016-10-12 00:08:59.933 <debug> cul < i01555F01 { rssi: -73.5 }		is000FFFFF0FF0

Ich habe die RAW-Sequenzen mal dahinter geschrieben. Die eigentlichen Codes sind die hinter "cul <"
Ich nutze einen Selbstbau-CUL mit der alternativen CUL-Firmware

Grüße
jogant

#44

Die alternative CUL-Firmware war der entscheidende Hinweis. Ich schaue dann mal, dass ich den Empfang auch noch eingebaut bekomme ;-).

Viele Grüße

Sathya

1 Like
#45

Hallo @jogant,

den Empfang der neuen Intertechno-Pakete habe ich jetzt eingebaut. Leider habe ich kein Intertechno-Gerät, welches mir die alten Pakete sendet. Die Ausgabe von CUL2MQTT kann ich noch nicht so ganz interpretieren. Sind die zugehörigen is-Befehle sicher korrekt? An Position 8 und 9 steht beispielsweise nicht wie erwartet “0F”? Kannst du mir doch noch einmal die Screen-Ausgabe für alle Tasten und dazu deinen Hauscode und Gerätecode senden?

Viele Grüße

Sathya

#46

Hallo @sathya,

die Pakete, die ich mitgeschnitten habe, sind so vom CUL-Stick empfangen worden. Ich werde heute Abend nochmal eine screen-Session mitschneiden. Der einzige Unterschied zwischen den Ausgaben ist die Anzahl der Pakete. Die Pakete, die mit einem (dauerhaften) Tastendruck der Fernbedienung mitgeschnitten werden, unterscheiden sich an den letzten beiden oder drei Stellen. Ich denke, dass dort die Feldstärke geschickt wird, die halt pro Paket unterschiedlich sein kann.

Ansonsten habe ich aber auch Probleme mit der Interpretation. Die empfangenen Pakete sehen anders aus, als die gesendeten, obwohl beide zum gleichen Ergebnis führen und die Steckdose schaltet. Vermutlich muss man da noch in die CUL-fw einsteigen, um zu verlässlichen Ergebnissen zu kommen.

Aber vielleicht helfen dir ja die Mitschnitte. Ich melde mich nochmal von zu Hause.

Viele Grüße
jogant

#47

Das wäre super ;-).

Die Intertechno-Version mit Unterstützung für die neuen Fernbedienungen habe ich gerade gepushed. Sie sollte in ein paar Stunden kompiliert sein.

#48

Hallo @sathya,

ich war nochmal tätig, obwohl ich zugeben muss, dass es immer undurchsichtiger wird.
Ich habe zwei Systeme mit jeweils drei Steckdosen, eins von REV Ritter und ein zweites ELRO440 kompatibles System von Pollin. Ich kann beide Systeme wunderbar über die passenden Codes über den CUL schalten. Wenn ich die Fernbedienung von REV Ritter betätige, sehe ich gar nichts im Monitor. Bei der Fernbedienung von Pollin sehe ich sicher bei jedem Tastendruck auch Aktivität im Monitor. Ich schreibe daher mal die Mitschnitte von der Pollin (ELRO) Fernbedienung auf.

Ich habe jeweils die ganze Ausgabe ohne das führende i von HEX in BIN umrechnen lassen und die Aktivität auf der Fernbedienung dahinter geschrieben:

10000010001010101000100001101  	A:ON
10000010001010101010000001101	A:OFF

10000010100010101000100010100	B:ON
10000010100010101010000001101	B:OFF

10000010101000101000100001101	C:ON
10000010101000101010000001010	C:OFF

10000010101010001000100001101	D:ON
10000010101010001010000000101	D:OFF

Ich habe die Schalter wie auf der FHEM-Seite beschrieben eingestellt.

Ich hoffe, du kannst was damit anfangen. Allerdings finde ich es schon sehr wunderlich, dass von der einen Fernbedienung gar nichts zu sehen ist im CUL.
Ich hatte mal ein einfaches 433 MHz-Modul direkt an die GPIOs des PI angeschlossen. Mit diesem Aufbau konnte ich aber was mitlesen. Wenn ich das mitgelesene einfach wieder ausgegeben habe, haben die Steckdosen auch geschaltet. Ist schon alles etwas merkwürdig …

Viele Grüße
jogant

2 Likes
#49

Hallo @jogant,

ok, das passt jetzt ;-). Ich muss mir noch einmal überlegen, wie ich die verschiedenen alten Intertechno-Systeme unter einen Hut bekomme. Intertechno V3 ist da etwas einfacher… Ich werde die ELRO-Fernbedienung aber die Tage implementieren.

Viele Grüße

Sathya

#50

Hallo @sathya,

sorry ich war die letzten Tage etwas Land unter und hatte am Abend immer mal nur ein paar Minuten hier gefummelt und bin somit nicht zum antworten gekommen. So wie ich das aber sehe hast du schon eine Menge hin bekommen und sehr viele Informationen von @jogant erhalten. Dafür an euch beide erst einmal vielen Dank!

So wie ich das gerade gelesen habe, kann man nun Daten über homegear auf jeden Fall einmal an Intertechno senden, aber die Fernbedingung noch nicht empfangen. Das ist doch korrekt oder?

Folgende Info kann ich euch noch geben, zumindest haben das meine letzten Forschungen ergeben. Die unterschiedlichen beiden Signale die durch einen Knopfdruck auf der Fernbedienung erzeugt werden, sind angeblich nicht die Signalstärke, sondern die günstigen Modelle (wie z.B. Brennenstuhl) senden einfach zwei unterschiedliche Signale und können somit von mehreren Herstellen ohne Anpassung eingesetzt werden. Ich verwende zum loggen aber eigentlich immer das erste Signal, da dies auch bei kurzem Tastendruck erzeugt wird. Ob die Aussage so stimmt, kann ich aber leider nicht sagen. Aber nach meinen Ergebnissen genügt es, dass erste Signal zu empfangen und auch wieder zu senden. Damit kann man den Schaltzustand der Dose dann ebenfalls auslösen.

Ich wäre heute und morgen Vormittag auf jeden Fall erreichbar, wenn ich irgendwie helfen kann. Da ich es leider weiterhin nicht geschafft habe, meine Signale sauber zu empfangen und an openhab zu übergeben. Mittels screen empfange ich die Pakete zwar, aber ich bekomme diese nicht in openhab eingebunden. Ich hatte das auch einmal mit cul2mqtt und a-culfw versucht, bin aber kläglich gescheitert.

@jogant: aus was besteht denn dein selbstbau CUL? Das selbe versuche ich hier nämlich auch. Ich habe hier einen Selbstbau aus einem Arduino mit a-CULFW drauf und versuche diesen an MQTT anzubinden. Bei meinem System soll nämlich langsam MQTT dreh und angelpunkt werden und openhab an dieser Stelle erst einmal ablösen um einfach flexibler zu werden. Vielleicht kannst du mir hier bitte einmal einiges mehr an Input geben?

So, dass soll es erst einmal gewesen sein. Bei Fragen einfach noch einmal bei mir melden.

Viele Grüße
Dennis

#51

Hallo @Dennis,

mein Selbstbau-CUL besteht auch aus einem Nano und einem Billig 433 MHz Modul. Ich habe das ganze aber nicht gesteckt, sondern korrekt mit Spannungsteilern gelötet. Das Modul hat eigentlich auch eine ganz gute Reichweite. Jedenfalls besser, als die Fernbedienung.
Im Augenblick habe ich die Verbindung zu MQTT über CUL2MQTT hergestellt. Ich habe ein paar Anpassungen an der CUL-Implementierung gemacht, aber bislang ist das nicht reif für die Veröffentlichung. Das läuft aber seit einigen Tagen ohne Aussetzer. Eigentlich möchte ich insgesamt so wenig Komponenten wie möglich verwenden, daher werde ich nächste Woche die CUL-Anbindung in homegear testen. MQTT ist als Message Broker sicher eine gute Sache, weil alle Welt eine Schnittstelle zu MQTT baut. Mit CUL2MQTT ist aber wieder eine Komponente mehr im Spiel. Ich bin da aber eher leidenschaftslos und suche immer nur gut funktionierende Lösungen. MQTT nutze ich halt noch für meine MySensors-Geräte und weil die CUL-Anbindung in openHAB2 auf einem RPI derzeit nicht läuft, war das halt ein sinnvoller Ansatz.

Grüße
jogant