Raspberry Pi 3 B: COC auf SCC

[amnesiac]

Hallo zusammen,

ich bin neu in der Materie und möchte eine Heimautomatisierung mittels Raspberry Pi und FHEM realisieren.

Da ich von einem Kollegen, der sein Heimautomatisierungsprojekt mangels Zeit beendet hat, 3 MAX! Thermostate und einen COC von Busware fast geschenkt bekommen habe, bin ich nun quasi an die HW und das MAX! Protokoll gebunden, Ich möchte allerdings nicht nur eine Heizungssteuerung machen, sondern auch andere Geräte (Funksteckdosen, Temperatur-/Luftfeuchtigkeitssensoren, Lampen, etc.) einbinden. Dafür würde ich z.B. ein zweites Modul mit 433MHz nutzen wollen.

Nun zu meiner Frage.. Da (für meine Lebensgefährtin) die Optik eine große Rolle spielt und ich versprechen musste, dass nicht irgendwelche Platinen irgendwo rumliegen, möchte ich am Ende ein Gehäuse machen in dem das RPi inkl. Funkmodulen "versteckt" sind. Könnte ich hier ein SCC von Busware kaufen und das COC auf das SCC stecken und beide parallel betreiben? Oder brauche ich zwingend 2 SCCs? Einen CUL-Stick möchte ich zwecks Optik nicht verwenden.

VIelen Dank schon mal für die Hilfe:)

Schöne Grüße:)

[Otto123]

Hi,
SCC

SCC occupies UART RX/TX- and GPIO17/18-Pins - all other pins are left untouched

COC

RPis serial port /dev/ttyAMA0 is directly connected to modul. Other assignments as below:

das wird nix 

Gruß Otto

[amnesiac]

Alles klar.. schade:( Vielen Dank für die Antwort. Dann muss ich wohl doch in den sauren Apfel beißen und einen Stick nehmen oder mir etwas anderes überlegen.

Dann noch eine weitere Frage.. weiß nicht, ob ich dafür nicht einen neuen Thread aufmachen sollte.. aber ich schreibe es mal hier:) Falls ich einen neuen Aufmachen soll, bitte einfach Bescheid geben:)

Ich lese überall, dass der parallele (bzw. quasi-parallele) Betrieb von 2 Protokollen mit einem CUL (bzw. SCC, COC,..) nicht möglich ist. Allerdings finde ich nirgends eine plausible Erklärung, wieso das so ist. Wenn ich mich richtig informiert habe, senden die MAX Thermostate nur, nachdem sie selbst einen Befehl vom FHEM bekommen haben. Könnte man dann den 868MHz CUL nicht generell in einem anderen RF-Modus z.B. SlowRF arbeiten lassen und wenn man dann einen Befehl ans Thermostat schicken will temporär auf MAX umschalten, die ACK und Antwort abwarten und wieder in SlowRF schalten? Der Betrieb im 433MHz Modus sollte doch meinem Verständnis nach nur die Reichweite einschränken. Ist so ein Betrieb prinzipiell realisierbar?

Dann habe ich noch eine weitere Frage.. ist es möglich, für die Steuerung/Regelung der MAX-Thermostate Messwerte anderer Sensoren (Sensoren am GPIO des Raspberry Pi, oder Sensoren mit anderem RF-Modus) herzunehmen, oder müssen die Geräte "protokoll-intern" unter sich bleiben? Die Frage ist erstmal unabhängig davon, ob das mit einem oder zwei Funkmodulen gemacht werden soll:)

Sorry, wenn die Fragen irgendwie blöd sind.. bin aber noch ziemlich neu in der Materie und versuche nur das zu Fragen, was ich nach langer Recherche im Internet nicht gefunden habe:) Arbeite mich momentan ein und versuche mir ein sinniges Konzept zu überlegen, wie ich das realisiere.

Vielleicht noch zur Info: Was auf jeden Fall in die Heimautomatisierung mit rein soll sind (+ hohe Priorität; + mittlere Prio; - niedrigste Prio)
++ 5 Heizkörperthermostate
+ 1-3 Innentemperaturfühler (evtl. auch Luftfeuchtigkeit), da die MAX Thermostate ja nicht ständig eine IST-Temperatur liefern und sowieso direkt am Heizkörper angebracht sind und das nicht wirklich auf die Raumtemperatur schließen lässt
+ 2 Innentemperaturfühler im Kühlschrank/Gefrierschrank
+ 1 Außentemperaturfühler
++ x Funktsteckdosen
- x LED-Leisten für indirekte Beleuchtung
- Kamera für den Kühlschrank
- was mir während dem Basteln sonst noch so einfällt:)

Ich möchte dazu dann eine Android-App zur Anbindung ans RasPi entwickeln, um alles in einem zu integrieren und darüber zu steuern bzw. überwachen. Klasse wäre es dann noch, über den Google Assistent Sprachbefehle eingeben zu können. Im Programmieren bin ich eigentlich recht fit.. bin eher 'n "Softwerker" als "Hardwerker". Aber das mit der Hardware bekomme ich schon auch irgendwie hin.. hatte auf jeden Fall schon ein paar mal einen Lötkolben in der Hand;)

Das möchte ich alles Schritt für Schritt machen und das System langsam um die genannten Kompenenten erweitern. Wie ich z.B. die Kamera im Kühlschrank realisieren habe ich noch gar keine Ahnung (evtl. Selbstbau mit zweitem RasPi). Aber das hat noch Zeit und das gehe ich irgendwann mal an, wenn ich mit den anderen Sachen soweit bin:)

Danke schon/noch-mal für die Antworten:) Da ich jetzt doch soviel Text geschrieben habe, habe ich meine tatsächlichen Fragen unterstrichen.. falls jemand filtern will;)

Schöne Grüße aus München:)

[Otto123]

Hi,

also zumindest zu Deiner zweiten Frage: Wenn du über FHEM etwas steuern willst (also nicht direkt von MAX zu MAX oder Homematic zu Homematic) und es nicht unabhängig von FHEM funktionieren muss, dann kannst Du Deine Messwerte überall hernehmen. Ob es andere Fühler sind oder das Wetter, der Sonnenstand spielt keine Rolle. Etwas überspitzt gesagt ... 

Zu Deiner MAX Frage kann ich nichts sagen.

Gruß Otto

[amnesiac]

super:) vielen dann schon mal.. das hilf mir weiter, dass ich unterschiedliche Protokolle in FHEM untereinander "mischen" kann.

Das mit den verschiedenen Protokollen mit einem CUL (bzw. COC) probiere ich dann einfach aus. Zur Not muss ich das dann doch mit Zweien machen. Aber erstmal ist jetzt die Heizung dran:)

Ich berichte dann:)

Schöne Grüße

[KölnSolar]

Schön wie Du detailliert Deine Situation beschreibst. Ist leider nicht bei allen newbies so
ein paar Antworten meinerseits:

Da (für meine Lebensgefährtin) die Optik eine große Rolle spielt

Es lässt sich doch um alles etwas drumherum bauen. Dünnes Holz sollte den Funk nur unmerklich beeinflussen.

Betrieb von 2 Protokollen

Die richtige Ausdrucksweise wäre "2 Frequenzen". Vielleicht erhellt das https://forum.fhem.de/index.php/topic,63479.msg547954.html#msg547954 noch ein wenig mehr 
Zum testen, spielen, basteln kannst Du es mit einem CUL(-Derivat) mit beiden Frequenzen probieren. Für ein produktives System kann ich Dir davon nur abraten.

Ich möchte dazu dann eine Android-App zur Anbindung ans RasPi entwickeln, um alles in einem zu integrieren und darüber zu steuern bzw. überwachen. Klasse wäre es dann noch, über den Google Assistent Sprachbefehle eingeben zu können.

Hab und nutz ich zwar nicht, ich denke aber, dass Du da auf vorhandene Lösungen zurückgreifen kannst.
Grüße nach München, Markus

[justme75]

Moin moin,

Hi,
SCCCOC
das wird nix 

Gruß Otto

sorry wenn ich hier als Newbie einfach so hereinplatze, aber die Intention des OP war und ist auch mein Plan - im Moment ist ein SCC auf dem RasPi für MAX, zusätzlich soll irgendwann noch ein COC dazukommen (geplante Erweiterung der Heimautomatisierung um HomeMatic-Komponenten).
Laut der busware.de-Seite zum SCC soll doch aber genau das möglich sein:
Eine Zeile unter dem von Dir zitierten steht dort:

on top you can add a final existing extensions COC, CCD etc.

Wenn ich mir dazu die im Forum vorhandenen Threads anschaue würde ich auch zu dem Schluß kommen, daß es möglich sein sollte, evtl. durch geänderte Firmware für die COC:
https://forum.fhem.de/index.php?topic=32594.0
Allerdings klingt für mich das hier bei den Kollegen von HomeGear https://www.homegear.eu/index.php/COC so, als ob auch die COC inzwischen Stacking ab Werk beherrschen können sollte....

Die zweite Frage des OP würde mich dann allerdings auch noch interessieren - kennt jemand ein Gehäuse für den RasPi, in dem man den samt zwei SCCs vernünftig drin unterbringen kann?

lg, justme

[Otto123]

Hi,

zusätzlich soll irgendwann noch ein COC dazukommen (geplante Erweiterung der Heimautomatisierung um HomeMatic-Komponenten).

Abgesehen davon, ob der COC jetzt "zaubern" kann oder nicht, entweder durch sharing der seriellen Schnittstelle des Pi oder durch Verwendung andere GPIO Pins als Schnittstelle - technisch ist sicher viel möglich. Manchmal wird auch Wunschlesemodus stark unterstützt 

Ich würde nur Homematic IOs für Homematic empfehlen! Alles andere scheint Krampf. Aber ihr könnt aus diesem Forum gerne etwas anderes herauslesen.


Gruß Otto

[justme75]

Hi,
Abgesehen davon, ob der COC jetzt "zaubern" kann oder nicht, entweder durch sharing der seriellen Schnittstelle des Pi oder durch Verwendung andere GPIO Pins als Schnittstelle - technisch ist sicher viel möglich. Manchmal wird auch Wunschlesemodus stark unterstützt 

Ich würde nur Homematic IOs für Homematic empfehlen! Alles andere scheint Krampf. Aber ihr könnt aus diesem Forum gerne etwas anderes herauslesen.


Gruß Otto

Hm, ist das denn wirklich so schlimm? Ich hatte bisher beim Lesen diverser Netzquellen den Eindruck, die meisten Leute benutzen eine wie auch immer geartete CUL und nicht die Original-IO-Geräte? Da bliebe ja im Moment quasi  nur noch der HM-MOD-RPI-PCB, nachdem weder HMLAN noch der originale USB-Stick noch verfügbar sind, und ob der gestackt auf einer SCC noch funktioniert? Abgesehen davon sieht das Teil für mich ja nach einer 'dummen' Lösung ohne eigenen Arduino als CoPro aus, wenn ich das richtig sehe?

lg, justme

[Otto123]

Da bliebe ja im Moment quasi  nur noch der HM-MOD-RPI-PCB, nachdem weder HMLAN noch der originale USB-Stick noch verfügbar sind, und ob der gestackt auf einer SCC noch funktioniert?

Hi,

Es gibt auch das HM Lan Gateway, dies funktioniert mit demselben Modul wie das RPI Modul.

Das HM-MOD-RPI-PCB Modul wird normalerweise über die UART des RPI angesteuert. Es belegt die ersten 12 GPIO Pins.
Es lässt sich außerdem über USB/Seriell Wandler und über WLAN/LAN Seriell Wandler anschließen.

Ansonsten ist jeder frei in der Wahl seiner Geräte und in der Einschätzung der Sinnfälligkeit der Lösungen.

Gruß Otto

[amnesiac]

Jetzt klinke ich mich auch mal wieder ein..

Laut Support von Busware sollte ein COC auf einem SCC funktionieren. Zitat: "Das sollte klappen, solange der SCC unten ist. COC dann wie zweiten SCC ansprechen."

Für mich ist das allerdings hinfällig, da ich mir in der Zwischenzeit einen zweiten CUL selbst gebaut habe.. wollte mir den Bastelspaß nicht entgehen lassen;)