Neustart mit CUL

Krise · 02 Dezember 2020, 14:42:28

Ich wollte eigentlich versuchen in meinem FHEM alles über WIFI zu realisieren, jedoch ist das auf Grund angebotener Geräte und Kostengründen eher nicht zielführend. Ich wollte mich daher mal an funkbasierten Geräten versuchen. Ich bin bei der Suche über CULs mit 2 Funkfrequenzen gestolpert, jedoch habe ich hier im Forum dazu nichts gefunden. Geht das zu parametrieren, bzw. ist das umsetzbar? Oder lieber einen 868er nehmen und für die 433Hz-Geräte die Frequenz anpassen?

Grüße
Christian

Beta-User · 02 Dezember 2020, 15:03:54

WiFi ist fast so gruselig wie 433MHz... Und du solltest schon wissen, was du eigentlich steuern bzw. empfangen willst.

Für Neubeschaffungen ist auch ein Blick in andere Welten zu empfehlen, insbesondere ZigBee und teilweise Bluetooth sind für Sensorik unschlagbar günstig (vorhin habe ich für unter 8 Euro (Gesamtpreis!) zwei BT-Temp/Feuchte-Sensoren erbuchtet - mit Display... Lassen sich seit neuestem mit OpenMQTTGateway stressfrei empfangen, Batterielebensdauer kommt mir bisher (deutlich teurere runde habe ich schon länger im Einsatz) sehr gut vor).

Wenn 868 und 433MHz: Man kann das mit einem Gerät abdecken, sollte aber für vernünftige Reichweiten zwei Transceiver verwenden (zum Empfangen ggf. sogar mehr). Das ginge z.B. mit einem Maple-basierten CUL/CUN oder MapleDuino (letzteres ist zwar stark in der Entwicklung, aber vermutlich am ehesten zu empfehlen, da am universellsten). Im Detail hängt es aber eher an der Frage, welches Protokoll empfangen bzw. gesendet werden soll... (Und wer die Wahl hat, sollte m.E. kein SlowRF-Zeug, v.a. keine Aktoren mehr anschaffen, ist zu großen Teilen einfach outdated, und wer was "gscheids" über 868MHz ansteuern will, sollte in ein passendes Interface investieren, CUL und Derivate sind da suboptimal...

MadMax-FHEM · 02 Dezember 2020, 15:45:40

Ich würde auch von 433MHz Abstand nehmen, noch dazu, wenn ich neu anfange.

Die meisten (alle?) haben KEINEN Rückkanal!

D.h. du hast keine Ahnung, ob der Schaltbefehl tatsächlich ausgeführt wurde...
Ich hatte auch mal (ganz zu Beginn vor so 6-8 Jahren) 433MHz Intertechno im Einsatz (hatte aber u.a. auch andere Gründe: kein Neutralleiter in der Schalterdose).

Habe aber schon bald versucht da weg zu kommen: geschafft!

Ich würde ebenfalls mal die genannten Systeme (und dann noch ZWave, EnOcean) anschauen.

Und aus Erfahrung (Homematic [gut das ist eh "Timing-Empfindlich"

] und CUL) erst mal schauen was die jeweiligen Systeme an "echter"/"originaler" Funk-HW anbieten und ob das in fhem integrierbar ist und von CUL erst mal Abstand nehmen, wenn es da was gibt.

Außer: mal zum Ausprobieren und weil es geht und weil man eh gerne bastelt und lötet etc...

Und wenn doch/genau das: https://wiki.fhem.de/wiki/Selbstbau_CUL hier steht (mMn) alles drin bzgl. Frequenz und Funkmodul etc.

EDIT: und noch eine Anmerkung: Frequenz ist das eine, Funk- und Applikations-Protokolle das andere! Nur weil was auf 868MHz funkt (oder 433MHz) heißt das nicht, dass das mit dem jeweiligen CUL (und fhem) dann einfach geht! Und auch Systeme die prinzipiell gehen und auf derselben Frequenz sind sollte man (selbst wenn das mit Umschaltung vielleicht geht) NICHT "parallel" an EINEM CUL betreiben. Gerade nochdazu, wenn das System einen Rückkanal hat (was auf jeden Fall zu empfehlen ist), so kann es sein, dass dann der Komunikationsverkehr durch die Umschalterei "gestört" wird, weil entsprechende ACKs/Rückmeldungen eben nicht mehr ankommen usw.

Gruß, Joachim

Beta-User · 02 Dezember 2020, 15:53:40

Zitat von: MadMax-FHEM am 02 Dezember 2020, 15:45:40
Und wenn doch/genau das: https://wiki.fhem.de/wiki/Selbstbau_CUL hier steht (mMn) alles drin bzgl. Frequenz und Funkmodul etc.

Nope, wenn schon, dann eher das: https://wiki.fhem.de/wiki/MapleCUN, Nano-based-CUL ist outdated...

(Es gibt aber auch einfachere Derivate usw., und eben die Signalduino-Maple-Variante für die firmware. Afaik sind die PIN-kompatibel; einfach suchen, WENN es denn überhaupt in diese Richtung gehen soll...)

MadMax-FHEM · 02 Dezember 2020, 16:17:43

Zitat von: Beta-User am 02 Dezember 2020, 15:53:40
Nope, wenn schon, dann eher das: https://wiki.fhem.de/wiki/MapleCUN, Nano-based-CUL ist outdated...

(Es gibt aber auch einfachere Derivate usw., und eben die Signalduino-Maple-Variante für die firmware. Afaik sind die PIN-kompatibel; einfach suchen, WENN es denn überhaupt in diese Richtung gehen soll...)

Mag sein aber bzgl. welche Transceiver bzgl. 433MHz und 868MHz und wie man die erkennt/unterscheidet ist dort mMn "besser" erklärt...

Darauf wollte ich eigentlich hinaus, weil es in der Anfrage auch diesbezüglich (etwas) "unsicher" klang

Gruß, Joachim

Krise · 02 Dezember 2020, 19:21:05

Na das ist ja schonmal eine Info, dann lass ich das mit dem CUL. Ich hatte mal Anlauf genommen und 2 Bewegungsmelder gekauft, dann kam einges dazwischen und mein FHEM-Projekt musst erstmal ruhen. Einein Zigbee-Stick habe ich auch, fragt mich nicht warum, muss wohl damals was mit den Protokollen verwechselt haben, heute ist mir der Unterschied in Sekunden klar geworden. Das was mich am meisten interessiert geht in die Richtung Bewegungsmelder, Anwesenheitsmelder, möglichst ohne feste Verkabelung/Netzteil. Sensorik ist auch immer wieder interessant, besonders Raumklima, evtl. Wassererkennung (da habe ich bei Shelly schon WLAN-Teile gesichtet und die sind ja super integrierbar).
Ich kann mich dunkel erinnern, dass der Zigbee mein WLAN gestört hat, beim ersten Testlauf. Kann das sein, oder ist der evtl. nur nicht richtig geflashed?

Grüße
Christian

MadMax-FHEM · 02 Dezember 2020, 19:34:21

Zigbee und WLAN senden beide im 2,4GHz Bereich.

Da gibt es (nat.) "Überlappungen" und kann sich somit schon beeinflussen/stören...

Man muss/sollte sich halt neben den Kanälen des eigenen WIFI und denen von Nachbarn auch mit den Kanälen vom Zigbee beschäftigen...

Es gibt einige Infos im Internet bzgl. Zigbee-Kanälen und "WIFI-Verträglichkeit"...

Ich habe die letzten Tage selbst erst geschaut...

Mein deCONZ (Zigbee) PI hatte ab und an WLAN-Verbindungsproblemchen (ich frage dort Daten per ssh ab und ab und an schlug ein Aufruf fehl: no route to host) und da hab ich auch mal geschaut. War aber ok von den Kanälen her. Hab den jetzt aber eh umgestellt auf LAN...

Gruß, Joachim

Krise · 02 Dezember 2020, 19:57:23

Ich hab grad mal ein wenig im Netz gestöbert, es gibt ja auch fertige Zigbee Bridges, z.B. von Sonoff, deht das damit auch? Wäre ja fast billiger als der Stick am Raspi.

Grüße
Christian

PS: Ich glaub da der Thread mehr Richtung Zigbee driftet, werd ich mal in diese Forumsregion "umziehen". Danke schon mal für den Input bis dahin.

Beta-User · 02 Dezember 2020, 19:59:39

M. E. nichts für Einsteiger.Besser ConBee II + zigbee2mqtt (o. deconz)

MadMax-FHEM · 02 Dezember 2020, 20:03:30

Den genannten kenne ich jetzt nicht.

Aber z.B. die Original-HUE-Bridge und auch Tradfri lassen sich in fhem einbinden.

Allerdings ist die Einbindung mittels Zigbee-Stick: Conbee II entweder per zigbee2mqtt oder deCONZ am flexibelsten auch was die Verwendung von Geräten unterschiedlicher Hersteller angeht.

Zumindest ist das mein Eindruck aber da kann Beta-User sicher mehr dazu sagen, denke ich...
EDIT: ok, parallel schon geschehen, wenn auch kurz gehalten

Ich habe den Raspbee (das Aufsteckmodul) und deCONZ im Einsatz und kann nichts negatives sagen.
Dresden Elektronik ist immer hilfsbereit und auf deren Webseite kann man nachlesen welche Geräte welcher Hersteller kompatibel sind.

Etwas ähnliches gibt es auch bzgl. zigbee2mqtt...

Bei Bridges von speziellen Herstellern ist der Support bzgl. Geräten von anderen Herstellern meist naja

Gruß, Joachim

Beta-User · 03 Dezember 2020, 12:23:35

Zitat von: MadMax-FHEM am 02 Dezember 2020, 20:03:30
EDIT: ok, parallel schon geschehen, wenn auch kurz gehalten

Langform gleich, vorab aber noch eine Anmerkung zum Thema 2.4GHz:
ZigBee funkt auf diesem Frequenzsspektrum; wenn das schon recht voll ist, ist ZigBee nicht optimal. Neben WLAN@2.4GHz tummeln sich da insbesonderen noch Bluetooth und DECT, in großstädtisch geprägten Siedlungsstrukturen ist es daher vermutlich nicht stressfrei...

Was die Sonoff-Bridge betrifft:
Am WE hatte ich so eine Bridge unter dem Lötkolben zum Umflashen, und schon davor hatte ich "Spaß", die ziemlich verschachtelten JSON-Messages irgendwie in der Auswertung via MQTT2_DEVICE zu "bändigen", siehe (insbesondere betr. attrTemplate https://wiki.fhem.de/wiki/Zigbee2Tasmota-MQTT). Kurz: das Ding ist eher eine Art "Relais-Station" für Nachrichten, und alles, was nicht einfach zu dekodieren ist oder unbekannt, wird eben "durchgereicht". Hat auch seine Vorteile, die ganze Konstruktion ist aber mAn. eher weniger gut geeignet für Einsteiger und eher was für Tüftler. Angeblich läuft das Ding auch nicht stabil, ich selbst habe es nach den ersten Tests wieder abgeklemmt - siehe den "unboxing"-Thread im ZigBee-Bereich des Forums.

@ZigBee hatte ich mit zigbee2mqtt (via CC2531) angefangen. Das hatte aus meiner Sicht zwei Nachteile: Zum einen ist es in Java programmiert und kann daher nicht so einfach über "apt" aktuell gehalten werden, und docker war da noch ein Fremdwort für mich. Ergo lief es auf einem separaten Pi, was ok war, aber eben auch keine Wunsch-Dauerlösung.
U.A. deswegen gibt es heute einen ganz brauchbaren Satz von attrTemplate, mit denen man den "input" von zigbee2mqtt sehr gut verwerten kann. Wer sich mit docker auskennt und die "Direktheit" von MQTT2_DEVICE schätzt, fährt damit - vorbehaltlich gewisser prinzipieller technischer Nachteile - m.E. sehr gut.

Wegen des Java-"Gelumpes" und der geringen Kapazität des CC2531 habe ich dann entschieden, dass ich für den weiteren Ausbau von ZigBee eine potentere Schnittstelle brauche und habe den ConBee II geholt. Seitdem bin ich mit deconz+HUEBridge unterwegs, was auch sehr gut klappt, aber nicht ganz so dynamisch in der Entwicklung ist wie zigbee2mqtt. Seit einiger Zeit unterstützt zigbee2mqtt auch den ConBee II, so dass man damit auch erst mal austesten kann, was einem besser gefällt.

Ich für mich würde vermutlich zwischenzeitlich in den Java-Apfel beißen, aber die Umstellung ist es mir nicht wert, zumal ja auch deconz ok ist.

Es gibt noch weitere Lösungen für ZigBee (Philips- oder Tradfri-Bridge und man kann wohl auch die Xiaomi-Bridge über wieder einen anderen Mechanismus anzapfen). Was anderes kommt jedenfalls für mich aber m.E. nicht in Frage, da nur deconz und zigbee2mqtt (bzw. auch zigbee2tasmota) pushen, also z.B. Bewegungsmelder-Events direkt und aktiv an FHEM durchstellen.

Wer eine eher user-friendly GUI für die Einrichtung der ZigBee-Geschichten sucht, ist vermutlich nach wie vor bei deconz gut bedient, auch wenn die "GUI-app" dazu (phoscon) stark hinter der Entwicklung her hinkt und grade für neue Devices nur bedingt nutzbar ist und diese Gesamtkonstruktion eher etwas undurchsichtig ist - man weiß z.B. nie so richtig, ob ein Bewegungmelder oder Taster/Fernbedienung direkt mit einer Leuchte spricht, oder ob da deconz noch irgendeine Regel dazwischengeschaltet hat und daher das ganze nicht funktioniert, wenn deconz nicht läuft.

Wenn man ein System sucht, bei dem diese klarer ist, landet man eher bei Z-Wave-Assoziationen oder HomeMatic-Peerings (ob das für HM-IP auch gilt, entzieht sich meiner Kenntnis); da kann man in der Regel z.B. auch entscheiden, ob ein assoziiertes Gerät nur ab einem bestimmten Helligkeitslevel benachrichtigt werden soll usw., und das ganze läuft dann autonom ab, der Server bekommt (bestenfalls) die Info, was passiert ist.

Solange FHEM läuft, sind die Unterschiede marginal, aber neulich hat mal einer meiner Mitbewohner versehentlich den falschen Knopf gedrückt, und die 45 Minuten waren irgendwie komisch, bis klar war, was eigentlich Sache war...

Krise · 03 Dezember 2020, 19:18:17

So, wie schon gesagt, da sich das Thema von SlowRF entfernt bin ich umgezogen ... https://forum.fhem.de/index.php/topic,116422.0.html

Beta-User · 04 Dezember 2020, 08:00:25

Habe mir den Beitrag angesehen, aber da sind so viele Missverständnisse (auch zu dem, was ich hier schon geschrieben hatte) drin, dass ich hier nur die Kurzform ablasse, falls das je wieder jemand findet...

a) CC1101 (der für CUL verwendet wurde) und CC2531 sind sehr verschiedene Paar Stiefel!
b) ZigBee (2.4GHz) und Z-Wave (868MHz) sind ebenfalls sehr verschiedene Paar Stiefel. Insbesondere kann man KEINE Z-Wave-Geräte mit einem CC2531 steuern (jedenfalls ist der nicht dafür gedacht oder gemacht).
c) MQTT ist ein IP-Kommunikationsprotokoll. "Irgendwas" muss die "Übersetzung" von "Luftdaten" zu "IP-Daten" machen, bei ZigBee gibt es dazu zwei "verbreitete" Varianten: zigbee2mqtt und zigbee2tasmota, Details siehe Wiki, wie bereits aufgezeigt.

d) CC2531 ist nicht mehr up-to-date.

Mein Eindruck: Eigentlich bis du auf der Suche nach einem stabilen Basissystem. Da wärst du mit Z-Wave besser bedient wie mit ZigBee. Aber auch das ist ziemlich kompliziert, und wenn du bei FHEM die Begrifflichkeiten so schlecht recherchiert durcheinanderwürfelst, wird FHEM an sich ein echter Frustbringer.

Ergo: Entweder du lernst schnell besser zu recherchieren und die Infos, die man dir zur Verfügung stellt auszuwerten, oder du solltest es (ganz) lassen.

just my2ct (und das ist nicht böse gemeint).

Krise · 04 Dezember 2020, 08:23:08

Nein das passt schon, liegt halt auch an der zur Verfügung stehenden Zeit

. Ich hatte das in dem anderen Thema so verstanden, dass Funk nicht so toll ist aber das galt dann wohl nur für die 433MHz daher habe ich geschlussfolgert, dass Zwave auch 2,4GHz ist. Damit hatte ich mich noch gar nicht beschäftigt.

Was ich eigentlich möchte, ist möglichst viele Sensoren/Sensortypen in FHEM einbinden ohne noch 1000 Netze in Diversen Frequenzen im Haus rumfunken zu haben. Daher fand ich die diversen Wifi-Geräte nicht schlecht.

Grüße
Christian

Beta-User · 04 Dezember 2020, 09:45:29

Funk ist nicht so toll! Egal welches Funksystem, es gilt immer: "Wer Funk kennt, nimmt Kabel"!

Wenn es nur um Sensorik (!) geht, ist 433MHz (bzw. SlowRF im allgemeinen) ok, die Krux ist nur, dass es wenig Standards gibt und man v.a. bei China-Ware nie weiß, ob es klappt mit der Dekodierung der Nutzdaten (Payload). Ansonsten gibt's noch lustige Effekte bei Batteriwechsel etc., aber ja, für Sensorik ist das eine Option.

Was "diverse Wifi-Geräte" sein sollen, kann ich nur raten. Falls damit WLAN-Geräte auf ESP8266-Basis gemeint sind: Da kann man geteilter Meinung sein. Klar ist: wer WLAN mit vielen ESP's einsetzen will, braucht eine andere Infrastruktur wie nur eine Fritzbox (oder anderen Consumer-Router) als AP, ab 25 Geräten (insgesamt, LAN-Geräte wie Drucker etc. eingeschlossen) kannst du wetten, dass früher oder später Probleme auftreten.
Ansonsten sind die Dinger vergleichsweise Energie-hungrig und kaum für Batteriebetrieb geeignet (Ausnahmen bestätigen die Regel, aber der Funk-Overhead ist vergleichsweise groß).

Ansonsten (noch unfertig:)
https://svn.fhem.de/fhem/branches/epdf2020/frame.adoc#_die_qual_der_wahl_2_hardware_systeme_2020