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

Otto123

@ die CUL Glücklichen
Ich denke ihr habt Glück mit eurem Exemplar und das ist auch gut so!
Ich rede ja vor allem nicht aus eigener Erfahrung (ich habe keinen CUL) sondern nur aus den vielen Problem Fällen. Und davon, dass der Anfänger aus irgendwelchen Quellen zuerst zum CUL und dann erst zum elv Modul findet. Und das finde ich falsch.
Und dann gibt es da noch gefühlt 1000 verschiedene gebastelte CUL Derivate ... Das da nicht immer alles rund laufen muss...

Ich will kein CUL bashing betreiben, aber historisch sind auch noch viele unserer Wiki Artikel so aufgebaut: Wir nehmen einen CUL (eierlegendenwollmilchsau)...
Ich finde: wenn Homematic - dann ist die erste Empfehlung und die Rede von einem Homematic IO und fertig.

Ich habe mir am Anfang nicht getraut in den Wiki Artikeln einfach die Texte "der Alten" zu streichen. Deshalb habe ich da vielfach nur den Finger gehoben und umgestellt und rein geschrieben "CUL ist nicht so doll für Homematic".
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

Je früher der Hinweis, desto besser. Das rächt sich sonst in den Foren.
FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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

Mein Vorschlag zum Wiki:
Ich habe mich ziemlich umfangreich mit der UART und Vorbereitung Pi befasst. Ich schreibe einfach einen neuen kurzen Artikel dazu und den binden wir dann an den verschiedenen Stellen in die anderen Artikel ein?

Es gibt an den verschiedenen Themen so viele unterschiedliche (historisch gewachsene) Hinweise und Tipps. Die finde ich fast alle nur verwirrend für den Anfänger. Eigentlich ist es ganz einfach.
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

(Mann, schon wieder weitere Beiträge während des Tippens)
Wir brauchen das Thema CUL m.E. nicht zu sehr zu vertiefen. Da du (@Otto) keine eigenen Erfahrungen hast, kurz meine persönliche Meinung - wie geschrieben, kenne ich die Probleme vieler Noobs mit HM@CUL auch zur Genüge:

Klar ist: die 20- Euro für das Pi-Modul (+ggf. der Euro für einen PL2102, wenn man 3.3V Messen und Löten kann) sind im Moment _die_  Empfehlung, wenn man HM haben will (was als Technik m.E. mittlerweile nur noch zu empfehlen ist, wenn man Heizungsthermostate haben will, aber auch da gibt es zwischenzeitlich wohl ZWave-Modelle, die FLIRS können). Egal, ob Noob oder Elektronik-Freak. Und zu HM-IP (2. Grund, warum man ggf. das Modul kauft) dürfte meine private Haltung klar sein...

Auch klar ist: Es gibt tausende von Installationen, die problemlos laufen, und viele von den "alten" sind CUL-based (da es das Modul damals noch nicht gab und das LAN-Modul in den Anleitungen nicht so präsent). Hier schlägt eben auch vorrangig das auf, was nicht funktioniert ;) . Das mag u.a. auch mit schlechten Nachbauten (Spannungsteiler, FTDI-Clones bzw. Test-PIN-belastete echte FTDI's, falsch angeschlossene CC1101...), weggelassenen, schlechten oder falschen Antennen und vielem anderem mehr zu tun haben. Alles Fehlerquellen, mit denen man sich gerade als Anfänger (viele Einsteiger sind insgesamt auch in der Elektronik-Welt nicht eben zuhause) schwer tut.

Aber als zweit- und dritt-IO für den weiteren Ausbau? Da ist ein MapleCUN kaum zu schlagen! (USB bringt funktechnisch kaum Vorteile, und die anderen CUx-Derivate kenne ich nicht aus eigener Anschauung). Ist aber eben auch ein "Dickschiff", das gerade für Noobs praktisch kaum zu durchschauen ist (sollte ich ZWave irgendwann darauf vollends zum Laufen bringen, überarbeite ich den Wiki-Artikel mal, damit das einfacher copy-paste geht; ich verwende schon STACKABLE).
Zitat von: andies am 07 Juni 2018, 09:55:14
Je früher der Hinweis, desto besser. Das rächt sich sonst in den Foren.
Ich würde das daher an der Stelle auf dem derzeitigen Stand dazu belassen. Wer das Modul gefunden hat, will es verwenden (und weiß hoffentlich, warum)! Und an der zentralen Stelle bei HM steht es bereits.

Zitat von: Otto123 am 07 Juni 2018, 09:49:03
Ich habe mir am Anfang nicht getraut in den Wiki Artikeln einfach die Texte "der Alten" zu streichen.
Geht mir (immer noch) genauso , dass ich nicht gerne in fremden Artikeln rummale. Aber krikan's beständige Aufforderung "just do it" wirkt so langsam, und mal ehrlich: Es gibt zwar genug Leute, die vieles noch besser wissen (mindestens wie ich), aber es muß halt gemacht werden. Und da wo wir (jedenfalls die hier an der Diskussion bereits Beteiligten) jeweils als einzelne einigermaßen den Durchblick haben, kann und darf man (m.E. jedenfalls).@andies: Danke daher für das "einfach mal machen" an vielen Stellen! Korrigieren und klarstellen kann jemand, der es besser weiß dann immer noch und ich persönlich finde einfacher, das zu tun als alles aus dem Urschleim selber saugen zu müssen ;) .
Ich fasse nachträgliche Änderungen an "meinen Artikeln" (und Änderungen) als sehr positive Sache auf, in aller Regel ist es danach (jedenfalls in der Regel) besser als vorher.

Zitat von: Otto123 am 07 Juni 2018, 09:49:03
Deshalb habe ich da vielfach nur den Finger gehoben und umgestellt und rein geschrieben "CUL ist nicht so doll für Homematic".
M.E. ist das Thema sachlich korrekt im HomeMatic-Artikel beschrieben. Von daher wäre es an allen betroffenen Stellen am besten, genau darauf zu verweisen. Bei Gelegenheit sehe ich mir das evtl. mal an, wenn niemand anderes schneller ist ;) .
Zitat von: Otto123 am 07 Juni 2018, 09:58:26
Mein Vorschlag zum Wiki:
Ich habe mich ziemlich umfangreich mit der UART und Vorbereitung Pi befasst. Ich schreibe einfach einen neuen kurzen Artikel dazu und den binden wir dann an den verschiedenen Stellen in die anderen Artikel ein?

Es gibt an den verschiedenen Themen so viele unterschiedliche (historisch gewachsene) Hinweise und Tipps. Die finde ich fast alle nur verwirrend für den Anfänger. Eigentlich ist es ganz einfach.
Warum nicht an zentraler Stelle bei dem bestehenden Artikel zum PI? Alles irgendwohin zu verteilen macht das Wiki m.E. nicht übersichtlicher, und das ist m.E. ein reines PI-Thema.
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

Otto123

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: Otto123 am 07 Juni 2018, 10:30:21
gib mal bitte einen Link zum Pi Artikel  ;)
:o
;D ;D ;D
Was ein Mist, wenn man nur der Spur nach weiß, dass "es" irgendwo steht....
OK, der Reihe nach:

In diesen Artikel gehört es m.E. rein: https://wiki.fhem.de/wiki/Raspberry_Pi
Vieles dürfte eigentlich schon hier stehen (wie gesagt: mein PI2 ist "außer Dienst): https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth
Das gehört irgendwie auch dazu, müßte aber m.E. eigentlich runtergestrippt und aktualisiert werden: https://wiki.fhem.de/wiki/FHEM_auf_Raspberry_PI_mit_COC_betreiben

(...und vermutlich habe ich bei weitem jetzt auf die Schnelle nicht alles erwischt, was Sinn machen würde...).
Aber was die Struktur der Themen angeht, bleibe ich dabei: PI-Vorbereitung sollte (nur) in den zentralen Artikel (ggf. getrennt nach 2 und 3; nur noch das aktuelle Raspbian, also stretch), und da gehört dann auch die Vorbereitung der seriellen GPIO-Schnittstelle rein. An den anderen Punkten nur noch dahin verlinken. So dürfte es auf die Dauer auch einfacher zu pflegen sein; es macht keinen Sinn, an mehreren Stellen dasselbe mit unterschiedlichen SW-Ständen darzustellen...
Btw.: das finde ich auch verbesserungswürdig: https://wiki.fhem.de/wiki/FHEM_Installation_LinuxDa gehört nach meinem Geschmack mindestens deutlichst sichtbar vorneweg der Hinweis hin, dass die "Linux" (?)-Installation auf debian.fhem.de zu finden ist (die dann auch mit dem aktuellsten Ubuntu funktionieren sollte ;) ) und diese Anleitung _NUR_ dann zu verwenden ist, wenn man _UNBEDINGT_ eine GUI haben will... Aber im Prinzip gehört das gelöscht, wenn ich näher darüber nachdenke; vermutlich meint dann aber wieder irgendjemand, dass es sowas braucht :( . Never ending story...
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

Die unselige "Linux"-Anleitung hat mir keine Ruhe gelassen - Hinweisbox ist jetzt da...
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

Otto123

naja genau deswegen wollte ich lieber was neues machen. So muss man seine Gedanken in 1000 Altlasten einordnen, das dämpft meinen Elan immer gewaltig.
Der Anfänger der einfach loslegen will ist mit 3 Alternativen und 5 Unterpunkten (nur symbolische Zahlen  ;D ) auch sofort überfordert und sucht sich dann den schlechtesten Weg.
Ich baue mal was neues und dann schaun wir mal wie wir das verschmelzen?
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

FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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

Nö - aber CUL an erster Stelle quasi für Alles  :D

Vorschlag:
Den Link für HMLAN auf den Abschnitt Homematic -> https://wiki.fhem.de/wiki/HomeMatic#FHEM_als_Zentrale
ändern?
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

FHEM 6.3 auf RaspPi4 (Raspbian:  6.6.28+; Perl: v5.36.0)
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: Otto123 am 07 Juni 2018, 11:45:40
Ich baue mal was neues und dann schaun wir mal wie wir das verschmelzen?
Du bist der, der es macht! Also darfst du auch entscheiden, wie es gemacht wird :) ...

Trotzdem noch meine Meinung: Da der (heutige) PI-Artikel eigentlich schön kurz und knackig ist, wäre es m.E. da gut aufgehoben (vor "Bekannte Probleme", auf dieser Ebene; viele Neulinge werden genau den Punkt an der Stelle vermissen, jedenfalls, wenn sie irgendein Aufsteckmodul verwenden wollen).

Aber wie Peter (ph1959de) bei anderer Gelegenheit geschrieben hat: Aufräumen macht er dann schon ;) .
Wenn du den PI-3-Artikel als Grundlage nehmen würdest: durch Verschieben kann man auch Umbenennen, dann hätten wir hinterher keinen verwaisten Artikel (der wird m.E. überflüssig)...
Habe eben die Interfaces-Seite noch um Modul/HMUARTLGW und HMCCU ergänzt.
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

Otto123

kann man einen Artikel erstellen und auch wieder löschen? Oder ist das wie im Forum einmal erstellt und immer da?
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

Irgendjemand kann vermutlich schon auch Artikel löschen, aber ich habe bisher keine Option gefunden. Ist evtl. auf Admins beschränkt.

Was auch als normaluser geht, ist eine Weiterleitung einzurichten (aber frag' mich nicht, wie das geht, hab's einmal gemacht und gleich wieder vergessen). Dasselbe passiert, wenn man einen Artikel umbenennt, nur dass da die Weiterleitung per default vom System eingerichtet wird. Fände ich hier sinnvoll, da dann "alte" Links (aus dem Forum, z.B.) dann im Ergebnis an der richtigen Stelle landen. Nur neue Leichen sollte man m.E. eben vermeiden.

Vorschlag daher (wenn nicht im PI-Artikel gewünscht): den Bluetooth-Artikel umbenennen (das Bluetooth irritiert mich, jedenfalls auf den ersten Blick); du kannst ja die bisherigen Inhalte erst mal als Kommentar drin lassen, für den Fall, dass man Teile sinnvollerweise beläßt bzw. weiterverwendet und den Artikel trotzdem nach deinem Gusto neu schreiben.
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

ph1959de

Zitat von: Otto123 am 07 Juni 2018, 12:49:51
kann man einen Artikel erstellen und auch wieder löschen? Oder ist das wie im Forum einmal erstellt und immer da?
{{Löschkandidat|weil...}}
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"