HM-MOD-RPI-PCB_HomeMatic_Funkmodul_für_Raspberry_Pi

Begonnen von Beta-User, 05 Juni 2018, 22:21:16

Vorheriges Thema - Nächstes Thema

Beta-User

Diskussionsthread zum Wiki-Artikel, begonnen hier.
Grundsätzlich finde ich die Umstellung ok, aber der Hinweis auf (virtualisierte) CCU2 kommt viel zu spät.
CUL so runterzumachen ist nicht gerechtfertigt, m.E. wäre eine moderatere Formulierung eher angebracht:
Es ist bekannt, dass es beim Betrieb von Homematic-Geräten über eine CUL und vergleichbaren Funkmodulen auf CC1101-Basis zu Problemen kommen kann, da das Timing hier kritisch ist. Dieses Funkmodul wurde extra für den Einsatz mit Homematic entwickelt und verwendet die Original-Hersteller-firmware, weswegen derartige Timing-Probleme bislang nicht bekannt sind.

Den Betrieb mit MapleCUx könnte man auch noch erwähnen.
Ob man wheezy überhaupt noch erwähnen sollte?

Bestimmt fällt mir noch mehr ein, aber auf die Schnelle erst mal.
Beta-User
EDIT: Link zum Wiki-Artikel, um den es hier geht.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

Trag das doch direkt ein, von diesen speziellen Dingen habe ich faktisch keine Ahnung.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Für die meisten Dinge erledigt, für das Entfernen von Wheezy hätte ich gerne ein paar Meinungen mehr.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ralf9

Eine Belegung der 2 mal 6 Poligen Buchse wäre auch hilfreich.


ZitatDa die serielle Schnittstelle des Raspberry Pi auf 5V basiert, das UART-Modul aber mit 3,3V arbeitet, muss unbedingt ein Spannungsteiler angebracht werden. Anderenfalls wird das UART-Modul durchbrennen. [Stimmt das? Fragt andies.]
Ich habe dazu dies gefunden
http://www.netzmafia.de/skripten/hardware/RasPi/RasPi_GPIO.html
ZitatBeachten Sie, dass alle Signale der GPIO-Pins mit einem Logikpegel von 3,3 V arbeiten und nicht 5-V-tolerant sind. Einige Pins können auch als SPI-, I2C- oder UART-Schnittstelle verwendet werden.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

andies

Zitat von: Ralf9 am 05 Juni 2018, 23:54:02
Eine Belegung der 2 mal 6 Poligen Buchse wäre auch hilfreich.
Eingearbeitet.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

PeMue

#5
Hallo Beta-User,

Zitat von: Beta-User am 05 Juni 2018, 22:21:16
Diskussionsthread zum Wiki-Artikel, begonnen hier.
könntest Du bitte noch den Link zum Wiki Artikel in den ersten Post mit aufnehmen? Dann findet sich der Artikel leichter.

Danke + Gruß

Edit: Ich habe den Artikel mal grob überflogen: m.E. arbeitet der Raspberry Pi mit 3,3 V Pegeln, die ELV Platine hat definitiv keine Spannugsteiler. Muss ich mir in Ruhe mal anschauen  ???
PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser

andies

Zitat von: PeMue am 06 Juni 2018, 07:57:09
m.E. arbeitet der Raspberry Pi mit 3,3 V Pegeln, die ELV Platine hat definitiv keine Spannugsteiler. Muss ich mir in Ruhe mal anschauen  ???
OK, dann wäre es einfacher, das Ding an den RPi anzuschließen. Was arbeitet denn dann mit 5V, so dass man aufpassen muss?
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Beta-User

Zitat von: PeMue am 06 Juni 2018, 07:57:09
könntest Du bitte noch den Link zum Wiki Artikel in den ersten Post mit aufnehmen? Dann findet sich der Artikel leichter.
Done, auf den footer verzichte ich vorerst noch ;) .

Was den PI angeht: https://www.raspberrypi.org/documentation/usage/gpio/
Da gibt es 2x5V-Anschlüsse (die zwar ebenfalls mit dem eQ-3-Modulstecker abgedeckt werden, aber für den Betrieb nach meiner Kenntnis nicht erforderlich sind). Da steht aber definitiv, dass alle GPIO-PINs als Eingang "3.3V tolerant" sind - was wohl nett ausgedrückt bedeutet, dass 5V als Eingangssignalpegel keine gute Idee wären.

Allerdings ist mir nicht so ganz klar, was diese Fragen im Wiki zu suchen haben. Eventuell wäre noch der Hinweis interessant, dass es selbstredend möglich ist, die nicht genutzen PINs "nach oben" durchzuschleifen, um was anderes dran zu betreiben (ich hatte zu PI-Zeiten mal ein RTC-Modul (I2C) oben drüber gelötet; das nutzte vermutlich auch die 3.3V). Wenn man das aufnimmt, sollte man im Hinblick auf mancheiners Kreativität aber auch klarstellen, dass eine gemeinsame Nutzung von RX und TX mit anderen Aufsteckmodulen nicht klappt...).
Aber Herbert Normaluser dürfte für den Betrieb am PI das verlötete Modul verwenden, wie eQ-3 sich das ausgedacht hat, wie das "einfacher" gehen sollte, erschließt sich mir nicht. Ansonsten würde der Hinweis genügen, dass man das Modul auch mit den 4 Kabeln an den 4 benötigten PINs anschließen kann, um den Rest freizuhalten (aber wer PI-GPIO's für was anderes nimmt als das Modul hier und eine RTC ist eh selber schuld, just my2ct).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

andies

OK, ich werde jetzt nur teilweise schlau aus den 2 Cents: Was genau soll Deiner Meinung nach am text geändert werden? Mehr Text? Weniger?

Bei den 5V und 3,3V sollte man nochmal nachschauen, also ich glaube inzwischen, dass das eine 3,3V-Spannung herauskommt: "Die Spannungspegel am GPIO-Eingang und -Ausgang liegen für "High" bei +3,3V und für "Low" bei 0V." Das müsste man eigentlich in der Spezifikation nachschauen.  Dann lösche ich mal den diesbezüglichen Hinweis, wenn das OK ist.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Otto123

#9
Hi,

zum Thema wheezy und zur Anbindung serielle Schnittstelle.

Ich habe seinerzeit den Abschnitt wheezy und jessie bearbeitet. Aus meiner Sicht kann wheezy raus. Verwirrt mehr und ist nur für Historie gut.
Aber mir erscheint jetzt etwas vermischt: Die Standard Einbindung in einen Pi ohne weitere Spielerei und die Anbindung über irgendein USB Modul. Das hat nichts miteinander zu tun!

Die UART des Pi ist speziell zu konfigurieren, bei Anbindung über USB spielt die UART keine Rolle.

Auch die Konfig der UART kann man mittlerweile stark abspecken (weniger ist mehr).

Leider sind die User sowas von erfinderisch, es gab soviele schräge Fehler. Die müsste man eigentlich irgendwie einpflegen. Ob ich das noch alles zusammen bekomme...

Gruß Otto

P.S. Zu deiner Themeneröffnung: den CUL für Homematic Einsatz kann man eigentlich nicht genug runtermachen. Der schwebt leider immer noch als heiliger Wundergeist über allen Welten und ist gerade für den Anfänger aus meiner Sicht für HM nicht zu gebrauchen! An dieser Stelle im Wiki hat es aber nichts verloren, da hast Du Recht. Da ist der User ja schon richtig. Insofern kann der Laber dazu eigentlich auch weg. Kurz und knapp in der Einleitung wozu und welche Möglichkeiten wäre besser. Details zu Platine und Pegeln können doch weiter unten folgen?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

andies

Wheezy ist raus.

Es stimmt, dass die Vorbereitung der seriellen Schnittstelle beim RPi da nicht hingehört. Das ist unsystematisch. Haben wir einen Ort, wo das woanders nachgelesen oder gespeichert werden kann? Dann kann das da hin.
FHEM 6.1 auf RaspPi3 (Raspbian:  6.1.21-v8+; Perl: v5.32.1)
SIGNALduino (433 MHz) und HM-UART (868 MHz), Sonoff, Blitzwolf, Somfy RTS, CAME-Gartentor, Volkszähler, Keyence-Sensor, Homematic-Sensoren und -thermostat, Ferraris-Zähler für Wasseruhr, Openlink-Nachbau Viessmann

Otto123

#11
naja es gibt gefühlt 5 Stellen im Wiki wo das Thema UART Pi und BT beim PI3 behandelt wird. Aus allen Welten.
Das gehört eigentlich in Eines.

Das es hier nicht hingehört wollte ich nicht sagen, nur die Vermischung mit externer Anbindung ist unglücklich.

Ohne enable UART und BT Overlay geht das Teil am Pi3 gar nicht. Der Hinweis muss schon sein!
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: andies am 06 Juni 2018, 11:52:26
Wheezy ist raus.
Danke, das liest sich jetzt wesentlich schlanker, wenn auch noch nicht soo rund.
Zitat von: andies am 06 Juni 2018, 11:52:26
Es stimmt, dass die Vorbereitung der seriellen Schnittstelle beim RPi da nicht hingehört. Das ist unsystematisch. Haben wir einen Ort, wo das woanders nachgelesen oder gespeichert werden kann? Dann kann das da hin.
@Otto: Dann sollte jemand kompetentes vermutlich den allg. PI-Artikel nochmal revidieren und dann hier (und an den anderen Stellen) nur ein Hinweis/Link belassen, oder?

Zitat von: andies am 06 Juni 2018, 11:37:36OK, ich werde jetzt nur teilweise schlau aus den 2 Cents
Das bezog sich nur darauf, dass man (mit Ausnahme des PI-Moduls und einer RTC) die Finger von den PI-GPIO's lassen sollte - da wird zu viel Mist gebaut (blockierende Verfahren etc.) und man verbaut sich durch sowas ggf. den Umstieg auf "andere" Serverhardware. (Wer GPIO's braucht, sollte einen Microcontroller dazwischenklemmen... Das ist aber - wie bereits hoffentlich hinreichend deutlich ausgedrückt - nur meine ganz private Meinung und bedarf hier keiner weiteren OT-Diskussion). Da ich "andere" Serverhardware einsetze, bin ich selbst in den PI-Themen auch nicht mehr soo drin, sondern eben eher in den alternativen Einbindungen; sonst würde ich das ggf. übernehmen, die Wiki-Teile ggf. zu überarbeiten.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Otto123 am 06 Juni 2018, 11:49:52
P.S. Zu deiner Themeneröffnung: den CUL für Homematic Einsatz kann man eigentlich nicht genug runtermachen. Der schwebt leider immer noch als heiliger Wundergeist über allen Welten und ist gerade für den Anfänger aus meiner Sicht für HM nicht zu gebrauchen! An dieser Stelle im Wiki hat es aber nichts verloren, da hast Du Recht. Da ist der User ja schon richtig. Insofern kann der Laber dazu eigentlich auch weg.
Habe ich erst später gesehen, Laber ist weg ;) .

Aber an einem CUL-Bashing mag ich mich nicht beteiligen: Meine eigenen Erfahrungen mit HM und CUL waren positiv! Das funktionierte alles (Suche nach CUL_HM in der config liefert 190 Treffer, da sind aber auch einige virtuelle Taster and er VCCU und Kanäle von Thermostaten usw dabei) über längere Zeit (Jahre) und mehrere Stockwerke problemlos... Und das ganz ohne TS-firmware (mein Busware hat noch V1.61, glaube ich ::) ).

(Dass viele Anfänger Probleme haben, die auch mit dem CUL+HM-Thema zu tun haben, ist bekannt). Aber im Ergebnis bin ich froh, dass es alternative HW gibt - zumal die a-culfw@Maple vermutlich wegen der höheren CPU-Frequenz in dem Punkt besser performt als das Original auf ATMega32U2.

Aber ich gebe dir teilweise recht: Man sollte grob wissen, was man tut, bevor man mit CUL&Co anfängt.

Ausdrücklichen Dank daher an der Stelle @Rudi für die Entwicklung der culfw!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

PeMue

Hallo Otto,

Zitat von: Otto123 am 06 Juni 2018, 11:49:52
... den CUL für Homematic Einsatz kann man eigentlich nicht genug runtermachen. Der schwebt leider immer noch als heiliger Wundergeist über allen Welten und ist gerade für den Anfänger aus meiner Sicht für HM nicht zu gebrauchen!
das kann ich so nicht nachvollziehen. Habe 6 Fensterkontakte und einige Heizungsregler im Einsatz, die funktionieren alle tadellos. Aber ich gebe Dir recht, mit dem ELV Modul geht es deutlich besser.

Ich werde mir mal in einer ruhigen Stunde den Wiki Artikel anschauen.

Gruß PeMue
RPi3Bv1.2 rpiaddon 1.66 6.0 1xHM-CC-RT-DN 1.4 1xHM-TC-IT-WM 1.1 2xHB-UW-Sen-THPL-O 0.15 1x-I 0.14OTAU  1xCUNO2 1.67 2xEM1000WZ 2xUniroll 1xASH2200 3xHMS100T(F) 1xRFXtrx 90 1xWT440H 3xTFA30.3150 5xFA21
RPi1Bv2 LCDCSM 1.63 5.8 2xMAX HKT 1xMAX RT V200KW1 Heizung Wasser