Ich mag mich irren… ich habe keine 433MHz Steckdosen und das deswegen noch nie mit homegear probiert.
Was spricht dagegen den NanoCUL direkt mit openhab oder FHEM zu nutzen? Mit FHEM könntest du den Weg über die mqtt-bridge gehen um die Steckdosen an openhab anzubinden.
Hey,
es gibt zwar kein Intertechno-Modul, das Protokoll ist aber so einfach, dass es sich in Verbindung mit einem 433-MHz-CUL über die Miscellaneous-Gerätefamilie in PHP implementieren lässt. Ich werde die Tage mal etwas basteln. Gebt mir etwas Zeit, ich bin gerade im Baustress - diesen Monat soll unser Haus (angeblich) fertig werden ;-).
Viele Grüße
Sathya
Hey sathya,
das hört sich doch klasse an! Lass mich wissen wenn du soweit bist, dann würde ich damit hier bei mir mal einen Test fahren. Kannst dich auch gerne melden, wenn ich dich irgendwie unterstüzen kann.
Und auf jeden Fall viel erfolg bei dem Hausbau! Ich drück die Daumen das alles nach Plan läuft!
Pfia di
Dennis
Hallo @pmayer,
wenn ich mich nur mehr in dem Them auskennen würde, könnte ich evtl. @sathya ein paar Tätigkeiten abnehmen. Aber leider bin ich kein PHP-Crack. Aber so wie ich das sehe, liegt meine ganze Hoffnung auf @sathya. Es wäre echt genial wenn ich eine zweite Instanz in homegear für meinen CUL einbingen könnte. Aktuell habe ich die Lösung, dass ich ein kleines Bash-Skript erstellt habe und das in openhab aufrufe. So kann ich zumindest einmal einen Befehl absenden. Was mir aber fehlt ist leider auch der Empfang von Befehlen auf dieser Frequenz von z.B. der beiliegenden Fernbedienung. Aber noch habe ich nicht aufgegeben.
@sathya lass mich wissen, wenn ich dir irgendwie zur Hand gehen kann.
Servus
Dennis
Naja, es geht ja grundliegend erst mal darum, dass homegear lernt Intertechno zu sprechen… das kann quasi auch nur @sathya machen, weil er der Entwickler von homegear ist 
Warum hattest du den CUL nicht über openhab direkt oder FHEM angebunden? Beziehungsweise, was machst du mit dem Bash-Script?
@sathya: Dann diskutieren wir hier weiter
Ich hatte bisher die falsche Vorstellung, wie man Inertechno integrieren kann. Ich hatte angenommen, dass man ein Modul wie für Bidcos oder KNX bauen muss, dort dann den CUL konfiguriert und so dann an die Items kommt. Dass man so von der Seite über PHP auch die externe Kommunikation über serielle Ports implementiert und darüber auch Geräte ansprechen kann ist mir gar nicht in den Sinn gekommen. Jetzt habe ich es wenigstens verstanden.
Vom Konzept denke ich, dass man pro IT-Gerät ein Device definiert, in dem in den Master-Properties die Adresse und die Befehle für ON/OFF hinterlegt sind. Das Device bekommt dann einen Value für den Schaltzustand.
Das klingt überschaubar. Mal sehen was geht.
Danke schonmal.
Grüße
jogant
Das Ansprechen direkt über Openhab habe ich zuerst auch versucht. Laut Openhab sollte das auch funktionieren. Jedoch finde ich einfach keinen Weg den CUL dort korrekt anzusprechen. Ich schaffe es zwar das Openhab einen Befehl abschickt, dieser jedoch nie beim CUL ankommt. Auf dem CUL wirkt das dann auch so, als hat dieser sich verabschiedet (also aufgehängt). Ich hab ab diesem Zeitpunkt dann auch keinen Zugriff mehr via screen. Ich habe auch noch keinen Beitrag in dem Openhab-Forum gefunden, wo jemand diesen CUL direkt über Openhab ansprechen konnte. Jetzt nutze ich in Openhab ein Binding das es erlaubt ein externes skript aufzurufen. Bei dem Skript mache ich eigentlich nichts weiter, als den pfad des CUL zu definieren. Die Idee habe ich in dem Openhab-Forum von einem User in meinem Thread erhalten (die Lorbeeren gehören als nicht mir ;-)). Das hat aber leider nun das Problem, das ich über den CUL lediglich nur senden und nichts empfangen kann.
Pfia di
Dennis
Hi @Dennis,
klingt für mich sehr komisch… aber absolut verständlich warum es dann ein heilloses Durcheinander gibt. Ich ging jetzt davon aus, dass das openhab-binding einfach die Hardware anspricht und über die entsprechende Direktive angesteuert wird.
Du weißt, dass 433MHz nur eine einkanalige Kommunikation zulässt? Meines Wissens nach, gibt es keine Bestätigung der Telegramme und auch keine Meldung von Schaltzuständen.
Hast du FHEM schon mal probiert? Die sind in der Hardwareanbindung ziemlich gut und über MQTT - wie schon erwähnt - kannst du es dann per openhab schalten.
so long,
p
Grias di @pmayer
so langsam bin ich aber auch wirklich durch den Wind. Vielleicht sollte ich eimal kurz sagen was genau ich vor habe:
Also ich würde gerne mit diesem selbstgebauten nanoCUL sowohl die Funksteckdosen schalten als auch ein Signal von der Fernbedienung erhalten und verarbeiten können. Das alles sollte eben auf diesem nanoCul laufen. Aktuell habe ich an dem PI GiPo ein 433Mhz Funkmodul angeschlossen. Das würde ich damit dann auch gerne ablösen, um eben auch Daten empfangen zu können.
Als zweiten Schritt soll dann ein nanoCUL auf Basis 868Mhz-Basis folgen. Hintergrund hierfür ist, dass ich einen Sensor einer Wetterstation (Intertechno) empfangen und verarbeiten möchte.
Kann ich dieses Vorhabend denn über MQTT lösen? So langsam habe ich wirklich einen Konten im Kopf 
Pfia di
Dennis
Hi @Dennis,
ich bin mittlerweile auch ziemlich durcheinander. Homegear kann mehrer Funkmodule (mein Beispiel mit CC1101 und CUL). Jedes Protokoll braucht sein eigenes Funkmodul, selbst wenn alle gewünschten Protokolle auf der gleichen Frequenz liegen. Damit homegear ein Protokoll “sprechen” kann, muss ein Modul dafür verfügbar sein - das ist das wo die @sathya und @jogant drüber diskutieren.
MQTT ist ein Kommunikationsprotokoll für das Internet der Dinge. Damit kann man Systemunabhängig ereignisorientiert kommunizieren. Homegear, openHab und FHEM (über MQTT-Bridge) beherschen dieses Protokoll - also kann man diese darüber miteinander kommunizieren lassen.
FHEM habe ich nur ins Spiel gebracht, weil dort sehr viele Hardwareanbindungen bereits gemacht sind: https://techblog.one/funksteckdosen-mit-fhem-schalten/ - mit MQTT kämst du dann quasi rüber in openHab, siehe: https://github.com/openhab/openhab/wiki/MQTT-Binding
Ich kann dir allerdings nicht sagen, ob die Intertechno Komponenten bidirektionale Kommunikation zulassen - ich kenn sie schlichtweg nicht. Irgendwas habe ich halt im Hinterkopf, dass es keinen Rückkanal gibt. Das mag ich aber mit FS20 verwechseln.
so long,
p
Hi @pmayer,
soweit habe ich dich verstanden. Und du liegst auch richtig das die Intertechno-Komponenten nur in eine Richtung kommunizieren können. D.h. ich kann die Steckdose aktuell schalten, bekomme aber kein Ergebnis der Dose zurück. Das ist soweit auch alles vollkommen okay. Jetzt liegt den Dosen aber auch noch eine Fernbedienung bei. Und diese Fernbedienung kann ja ein Signal senden. Dieses Signal würde ich jetzt gerne in openhab abbilden. Hintergrund ist, dass ich mit der Fernbedienung über openhab dann komplexere Schaltvorgänge durchführen möchte (z.B. Fernbedienung Knopf A wird gedrückt --> Item in openhab wechselt in neuen Zustand --> löst eine Rule aus z.B. Fernseh und Heizung im Wohnzimmer aus). Daher habe ich jetzt hier einen nanoCUL mit CC1101 der Senden und empfangen kann und zwar immer auf selben Protokoll (also kein Protokollwechsel). Der nanoCUL empfängt nun über den screen Befehl auch die Fernbedienung, aber ich bekomme dieses Signal irgendwie nicht an openhab übergeben. Aktuell schraube ich an dem Versuch den nanoCUL via das serial binding in Openhab einzubinden. Aber hier scheint die Baudrate von dem serial binding nicht korrekt verarbeitet zu werden.
Kann ich denn via MQTT-Binding ein Intertechno-Signal senden und empfangen? Falls ja, würde ich dieses Binding ebenfalls einmal ausprobieren.
Besten Dank schon einmal für deine Hilfe!
Viele Grüße
Dennis
Ich wollte mit der Diskussion natürlich keine Verwirrung stiften, sondern schlicht meine Überlegungen teilen. Dann versuche ich mal, wieder ein wenig Klarheit zu schaffen.
Fangen wir mal oben an: openHAB und FHEM sind zwei konkurierende Home-Automation-Lösungen mit unterschiedlichen Ansätzen. openHAB wird, insbesondere nach der Zusammenführung mit Eclipse Smarthome, eine bessere Strukturierung nachgesagt, ist überwiegend in JAVA implementiert und erfreut sich einer großen, aktiven Community. Es werden laufend neue Protokolle integriert. “Selbstverständlich” sind auch die Standards Homematic, ZWave etc. als Kommunikationsmodule verfügbar, d.h., openHAB stellt die Schnittstellen zu Standard-Protokollen bereit. FHEM ist da sehr ähnlich, in PERL implementiert, ebenfalls mit vielen Schnittstellen-Modulen ausgestattet.
Für das Homematic-Protokoll ist jedoch bei beiden Lösungen eine Zwischenschicht notwendig, die im Fall von Funkanbindung zu Homematic-Geräten eine BidCos-Implementierung realisiert. Hierfür gibt es mehrere Lösungen, zB. mit einem Gerät (CCU2) oder eben mit Homegear. Ich persönlich setze hier auf Homegear, damit ich nicht noch ein Gerät rumstehen habe. openHAB und homegear laufen bei mir auf einem Raspberry PI2 unter Debian jessie.
Unterhalb von Homegear gibt es dann noch ein oder mehrere Funkmodul(e). Für Homematic verwende ich ein direkt angebundenes TI-CC1101-Modul für 868MHz. Darüber hinaus möchte ich noch einige Intertechno Funksteckdosen schalten. Wie schon richtig bemerkt worden ist, läuft Intertechno im 433Mhz-Band und hat keinen Rückkanal. Man bekommt von geschalteten Geräten keine Rückmeldung über Erfolg oder Misserfolg einer Schalthandlung.
Hier setze ich einen CUL-Stick ein. Grundsätzlich kann dieser USB-Stick direkt von openHAB angesprochen werden. Das funktioniert bei mir aber leider nicht wegen einer Inkopatibilität der verwendeten Serial-Lib in der Raspberry-Umgebung. Bei anderen geht es aber.
Und hier kommt jetzt wieder homegear ins Spiel. Da ich das Rad nicht vollständig neu erfinden möchte, suchte ich eine Anbindung der Hardware (CUL) an openHAB und bin auf die Diskussion in homegear gestoßen. Man kann auch hier andere Wege gehen, einige habe ich auch getestet: zB. CUL2MQTT, eine Implementierung in NODE.JS als Gateway zwischen CUL-Messages und MQTT. Auch eine gute Idee, MQTT habe ich für einige mySensors-Geräte schon mal vorbereitet und openHAB spricht auch MQTT. Leider funktioniert wegen einiger Abhängigkeiten die Serial-Lib von NODE.JS bei mir auch wieder nicht. Vieles in einer RPI-Umgebung ist halt noch jung …
Jetzt werde ich mal die homegear-PHP-Implementierung testen.
Bevor jetzt Hinweise zur grundsätzlichen Funktion des CUL kommen, der geht. Mit dem Terminal-Programm screen kann ich die Intertechno-Code eintippen und die Steckdosen schalten. Hardware geht also, ist nur eine Frage der seriellen Libraries.
Jetzt nochmal zur Fragestellung in diesem Thread:
Wenn es funktioniert, würde ich immer einen möglichst einfachen Aufbau vorschlagen. Also CUL für Intertechno direkt in openHAB konfigurieren. Für homematic den zweiten CUL in homegear konfigurieren und die Homematic-Geräte paaren. Dazu muss homegear mit den BidCos-Modulen installiert werden. In openHAB2 sieht man dann schon die Things und kann die Kanäle den Items zuweisen.
Bei mir funktioniert der CUL für Intertechno leider nicht in openHAB.
@Dennis: eine Sache verstehe ich nicht ganz. Du sagst, dass du einen zweiten CUL für 868 MHz auch für Intertechno einsetzen willst. Ist das so richtig? Meines Wissens ist IT immer 433MHz. Es gibt auch Sender für IT, zB. Wetterstationen, die dann unaufgefordert senden. Wer es empfängt ist dem Sender egal. Das kann auch der CUL sein. Allerdings ist die openHAB-Implementierung auf das Senden beschränkt. Dann teste mal die CUL2MQTT-Variante, ob du Nachrichten vom CUL im Broker siehst. https://github.com/akentner/cul2mqtt
Hi @jogant,
dann sind wir beide auf dem selben Stand und stehen vor dem selben Problem. Mein homematic-USB-Stick läuft ebenfalls über homegear. Der nanoCUL soll zusätzlich direkt über Openhab eingebunden werden und genau hier scheitere ich auch. Solltest du eine Funktionsfähige Lösung gefunden haben, dann lass es mich gerne wissen.
@jogant: mein zweiter Sender ist ein selbstbau nanoCUL mit einem CC1101 auf 433Mhz-Basis. Also die richtige Frequenz für intertechno. Ich werde dann einmal MQTT-Variante testen. Vielleicht komme ich damit ja weiter.
Pfia di
Dennis
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” …
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?
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 
[/edit]
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.
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