stapelbarer Transceiver oder doch lieber USB

Begonnen von Jim, 19 September 2017, 09:36:16

Vorheriges Thema - Nächstes Thema

Jim

Moin zusammen,

kann mir jemand sagen, ob man lieber stapelbare Transceiver oder doch einen USB-Dongle am Pi nutzen sollte? Es sind doch prinzipiell die selben Geräte oder nicht? (CC1101)

Gruß Jim

justme1968

naja. die stapelbaren sind schick und kompakt. aber du bist auf einen raspberry mit passendem pinout beschränkt.

usb ist weniger kompakt und dir brauchst früherer oder später einen usb hub. dafür geht es an jedem rechner, an längeren kabeln und du bist sehr viel freier was die montage angeht.
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Jim

Moin,

danke für die schnelle Antwort, demnach würdest du also empfehlen die Sticks zu nehmen?
Ja es stimmt wohl, falls man sich für einen Anderen Computer entscheidet ist die Hardware schon vorhanden. Ich habe mir auch andere Varianten angeguckt allerdings sind bei einigen Varianten die Stromverbräuche ganz schön hoch.

Die Sticks haben also keine Nachteile gegenüber der stapelbaren?

Gruß Jim

Beta-User

Wie immer kommt es darauf an.
Da Du explizit den CC1101 anfragst: für Homematic nimmt man besser "native" Transceiver (such mal nach "welches IO" usw...).
Alle stapelbaren (soweit sie überhaupt kompatibel sind) sind im Prinzip serielle Geräte, die sich auch mit einem USB-seriell-Wandler betreiben lassen (Spannung beachten, die meisten mögen keine 5V).

Z.B. hängt mein HM-Mod-RPI-PCB an einem USB-Seriell-Wandler (CP2102 für 2 Euro aus China). Funktioniert problemlos. Andere haben das an einem Maple-CUN im Netzwerk hängen - ebenfalls ohne dass hier Fehlerberichte vorlägen (der hat bis zu 4 Transceiver und 2 serielle Schnittstellen, die auch als weitere logische USB-Schnittstellen weitergegeben werden; also 1 Stecker, 3 USB-Geräte ;) ). 

Ergo: ist eine Geschmacksfrage, wobei USB m.E. universeller ist, weil PC-HW unabhängig.
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

gloob

Raspberry Pi 3 | miniCUL 433MHz | nanoCUL 868 MHz | nanoCUL 433 MHz | MySensors WLAN Gateway | LaCrosse WLAN Gateway | SignalESP 433 MHz | SignalESP 868 MHz | HM-MOD-UART WLAN Gateway | IR - 360 Grad WLAN Gateway

Beta-User

Zitat von: gloob am 19 September 2017, 11:11:27
Man kann natürlich auch WLAN Gateways nutzen:
Kann man, aber bitte beachten: es braucht dazu die entsprechende Infrastruktur (funktionierendes (W)LAN).

Meine persönliche Präferenz: Klassische Netzwerktechnik nur, wo es sich nicht vermeiden läßt, oder dort, wo es dem Komfort oder der Verbesserung der Funkabdeckung usw. dient (z.B. 2./3. IO für HM). Alles wichtige hängt an USB.

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

Jim

Hi zusammen,

ich nochmal ;D @ Beta-User

Ich möchte mit einem Pi/fhem auch Homematic IP verwenden, da mir die versteckten Fenstersensoren für Kunststofffenster sehr gefallen. Ist ein CC1101 dafür nicht geeignet? Was benötige ich denn da? Ich habe im Wiki gelesen, dass ich auch eine HMCCU benötige, das ist vermutlich der HM AccessPoint gemeint richtig? Geht das nicht auch ohne bzw. habe ich das falsch verstanden?

Gruß Jim

Beta-User

Hallo Jim,

bei deinen Fragen geht m.E. einiges durcheinander:

- für HM-IP kann man keinen CC1101-basierten Transceiver verwenden (jedenfalls derzeit nicht), sondern braucht eine CCU(2?). Damit sind CUL&Co raus.
- Man kann die CCU in FHEM einbinden, dazu nutzt man ein FHEM-Modul namens HMCCU (statt (CUL oder HMUART)+CUL_HM).

Da mein Argwohn gegen die Verwendung einer CCU2 als separate Netzwerk-HW diese Tage noch zugenommen hat (es gab da Probleme bei Restarts nach Stromausfall, wo FHEM deutlich schneller wieder verfügbar war als die CCU2 - die Orginale ist eine lahme Ente - und dann FHEM Devices vergessen hatte...), wäre meine Empfehlung, die CCU2 zu virtualisieren und auf derselben Hardware laufen zu lassen. Dann kann man systemd so konfigurieren, dass das nicht passiert. Das Stichwort dafür heißt yahm, man benötigt dafür das PI-PCB-Modul (damit ist dann auch das Stapel weiterer Devices erledigt...).
U.A. hier gibt es eine Anleitung dazu (allerdings evtl. ohne systemd-Konfiguration).

Ich hoffe, das ist soweit nachvollziehbar,

Gruß, Beta-User
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

Jim

Hallo Beta-User,

das ist, was ich meine, keine weitere Hardware bzw. keine Zentrale, da das ja der Pi machen sollte.
Da ich einen Pi B+ habe, benötige ich wohl also einen neuen Pi sowie das Pi-PCB Modul, richtig?

Das Modul hat nur diese kleine Wurfantenne? Genügt die?

Gruß Jim

Beta-User

Hallo Jim,

ob ein B+ ausreicht für FHEM+yahm kann ich nicht sagen, im Zweifel sollte sich aber eine S-Karte aus einem B+ auch auf einem PI2 oder PI3 betreiben lassen; was spricht also gegen einen Test auf dem vorhandenen PI?

Was die Funkabdeckung angeht, performt das PI-Modul sehr gut (nicht nur bei mir). Ansonsten sollte auch die OCCU mit weiteren IOs umgehen können, das Modul (bzw. weitere)kann man dann auch an anderen Schnittstellen woanders im Haus betreiben (ESP8266, MapleCUN, ser2net...).

Gruß, Beta-User
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