NeumannCul

Beta-User · 04 Dezember 2020, 15:53:18

CUL versucht eher intern zu erkennen, was ein Signal bedeuten soll, Signalduino reicht es tendenziell eher durch und läßt FHEM die Arbeit machen, das im Detail zu dekodieren. Da man bei 433MHz nie weiß, ob ein Gerät wirklich "IT" spricht, ist Signalduino einfach universeller. Aber für das, was die aculfw (die für Maple benötigt wird) erkennt (und das ist auch schon einiges) geht auch die aculfw.

Der Maple stellt einfach weitere serielle Schnittstellen bereit und reicht die via USB oder separatem Netzwerk-Port durch. Von daher kann man an einen Maple bis zu zwei weitere "UART"-Module (neben dem Hm-Mod-Pi-PCB für HM-Classic auch Pi-Module Z-Wave oder ZigBee-CC2530) anbinden - das Timing darf nur nicht zu kritisch sein (die Platine für HM-IP ginge z.B. afaik nicht). Steht aber alles - etwas verstreut - im Wiki, v.a. zum MapleCUN, meine ich.

Ergo wäre wohl derzeit dieser MapleCUN eigentlich ein passendes Angebot: https://forum.fhem.de/index.php/topic,116323.0.html. Ist schon verlötet, mußt halt irgendwo noch ein Gehäuse organisieren...

Deco · 04 Dezember 2020, 16:34:56

Nochmals Danke für die Aufklärung und vor allem auch für den Link, ich habe den User mal angeschrieben. Es sieht wirklich genau nach dem aus, was ich aktuell benötige (nur einen Signalduino mit 433 MHz baue ich dann eventuell noch, wenn es über die aculfw nicht zufriedenstellend läuft, aber ich denke ich versuche das erstmal über den Maple oder den auch angebotenen CUL, sofern noch verfügbar, da meine 433 MHz Aktoren auch originale ITs sind, zumindest stehts drauf

).
Wenn nicht habe ich ja wie gesagt noch Bauteile für zwei Signalduino.

Ein solcher CUL (also der einzelne USB-CUL) sollte vermutlich auch am besten mit aculfw bespielt werden oder gibt es da eine empfehlenswertere Alternative?

Mir war auch nicht ganz klar, dass die HM-MOD-UART am Maple durchgereicht wird, aber das ist ja dann äußerst praktisch, damit ist es ja dann wirklich so, als ob ich ein HM-MOD-RPI-PCB direkt via USB oder PINs anschließe

(sofern ich das richtig interpretiere).
Ich habe extra keine HM-IP Geräte verbaut, da mir das noch zu verschlossen war/ist. Sollte also unproblematisch sein.

ZigBee wäre mein nächster Schritt, daher ist der angebotene Maple tatsächlich gut geeignet.
Kann ich das ZigBee-CC2530 einfach zusätzlich zum HM Board verbauen oder gibt es da dann irgendwo Engpässe in der Übertragung falls gleichzeitig gefunkt wird (ich möchte den Maple über USB anschließen)?

Gehäuse etc. benötige ich nicht, liegt alles "nackt" auf dem Schrank und das war bisher unproblematisch (bekommt gut Luft und kann frei funken

).
Der Pi ist mit LAN angeschlossen, daher meine Idee den Maple via USB zu verbinden.
Reichweite sollte von dem Ort aus klappen, zumindest schafft es der LM Air aktuell auch und der steht noch weiter weg von den meisten Aktoren, im Serverschrank

Gruß Deco

Beta-User · 04 Dezember 2020, 16:43:49

Mit der aktuellen aculfw solltest du auf der sicheren Seite sein, Maple-Signalduino könnte auch gehen, ist aber experimentell und wg. FS20 wäre ich eher konservativ => aculfw.

Würde mal annehmen, dass du insgesamt keine Unmengen an Daten hast, von daher dürfte der Maple auch mit zwei seriellen Geräten klarkommen.
CC2530 sollte daher auch gehen, hat aber seine Beschränkungen. Da du damit dann eher zigbee2mqtt machen willst (?) würde ich aber überlegen, ob es nicht der "bessere" CCirgendwas sein soll oder was anderes, was unter https://www.zigbee2mqtt.io/information/supported_adapters.html zu finden ist. Grundsätzlich _müßte_ alles gehen, was sich über UART ansprechen läßt.
Falls du es konservativer angehen lassen wolltest, wäre ggf. auch das neue ZigBee-Modul (RaspBee II ?) von DE zu überlegen, ich _vermute_, damit könnte man auch mit sauberem Durchreichen der passenden Schnittstelle deconz laufen lassen; das kommt mir etwas einsteigerfreundlicher vor als zigbee2mqtt (das dafür eher "leading edge" ist und den Vorteil hat, dass erst mal jede ZigBee-Adresse genau ein Gerät ergibt; HUEDevice "verstreut das - wohl prinzipbedingt - etwas unschön).

Ranseyer · 04 Dezember 2020, 16:51:07

Falls du zu spät bist: Ich habe sicherlich auch noch einiges zu den MAPLE CULs hier. Hatte nur keine Zeit/Lust das ganze anzupreisen.

Deco · 04 Dezember 2020, 17:34:48

Zitat von: Beta-User am 04 Dezember 2020, 16:43:49
Mit der aktuellen aculfw solltest du auf der sicheren Seite sein, Maple-Signalduino könnte auch gehen, ist aber experimentell und wg. FS20 wäre ich eher konservativ => aculfw.

Würde mal annehmen, dass du insgesamt keine Unmengen an Daten hast, von daher dürfte der Maple auch mit zwei seriellen Geräten klarkommen.
CC2530 sollte daher auch gehen, hat aber seine Beschränkungen. Da du damit dann eher zigbee2mqtt machen willst (?) würde ich aber überlegen, ob es nicht der "bessere" CCirgendwas sein soll oder was anderes, was unter https://www.zigbee2mqtt.io/information/supported_adapters.html zu finden ist. Grundsätzlich _müßte_ alles gehen, was sich über UART ansprechen läßt.
Falls du es konservativer angehen lassen wolltest, wäre ggf. auch das neue ZigBee-Modul (RaspBee II ?) von DE zu überlegen, ich _vermute_, damit könnte man auch mit sauberem Durchreichen der passenden Schnittstelle deconz laufen lassen; das kommt mir etwas einsteigerfreundlicher vor als zigbee2mqtt (das dafür eher "leading edge" ist und den Vorteil hat, dass erst mal jede ZigBee-Adresse genau ein Gerät ergibt; HUEDevice "verstreut das - wohl prinzipbedingt - etwas unschön).

Also der RaspBee II sieht recht "teuer" aus. Das hätte ich dann glaube ich eher erstmal "günstig" über ein Modul gelöst, welches auch immer (hier muss ich mich erst einlesen, ich weiß den Unterschied zwischen den ganzen CC2531, CC2540 etc. noch nicht).

Aktuell steuere ich über eine (echte) HUE Bridge ein paar Lampen von Osram, da sollen dann noch Steckdosen (Smart Plug) hinzukommen und ich würde gerne einige Xiaomi Geräte (Hygrometer, Wassermelder etc.) einbinden wollen. Soweit ich das bisher gelesen habe ist die HueBridge ja nur für Lampen zu gebrauchen?!, daher dann das benötigte Modul.
RaspBee II wird vermutlich das einfachste/stabilste/universellste sein nehme ich an?

Zitat von: Ranseyer am 04 Dezember 2020, 16:51:07
Falls du zu spät bist: Ich habe sicherlich auch noch einiges zu den MAPLE CULs hier. Hatte nur keine Zeit/Lust das ganze anzupreisen.

Danke, hast eine PN

Ralf9 · 04 Dezember 2020, 19:27:56

Zitatda meine 433 MHz Aktoren auch originale ITs sind, zumindest stehts drauf

sollten mit der a-culw genauso gut funktionieren wie mit dem Signalduino.

Zitat
Maple-Signalduino könnte auch gehen, ist aber experimentell und wg. FS20 wäre ich eher konservativ => aculfw.

Am Anfang gab es Stabilitätsprobleme, aber seit Juni hatte ich keinen Absturz mehr (uptime von mehreren Monaten).

Der Maple-Signalduino kann aktuell nicht 433 MHz SlowRF und 868 MHz SlowRF (z.B. FS20) gleichzeitig, ist aber geplant.

Gruß Ralf

Deco · 04 Dezember 2020, 20:34:23

Ah ok, danke.
Dann werde ich es mit dem Maple und aculfw zunächst versuchen.
Damit scheint zunächst vieles abgedeckt zu sein.
1 x 868 MHz für FS20, 1 x 433 MHz für IT und das extra UART-Modul für HM, alles auf dem Maple.

Dann ist nur noch das Thema ZigBee offen (also gedanklich, umzusetzen ist ja das Thema CUL auch noch

)

Gruß Deco

EDIT:
Habe ich es richtig verstanden, dass für den Conbee und den Raspbee immer eine weitere Software mitlaufen muss oder ist das nur ein Paket was installiert wird?
Habe als alternative zu einem Modul den Stick hier gefunden (https://www.amazon.de/ITSTUFF-USB-Stick-ioBroker-openHAB-Firmware/dp/B07ZZ88BWZ) was sagt ihr dazu? Laut Bewertungen soll er ja (relativ) out of the Box funktionieren.

Beta-User · 06 Dezember 2020, 09:30:54

Zitat von: Deco am 04 Dezember 2020, 20:34:23
Habe ich es richtig verstanden, dass für den Conbee und den Raspbee immer eine weitere Software mitlaufen muss oder ist das nur ein Paket was installiert wird?
Habe als alternative zu einem Modul den Stick hier gefunden (https://www.amazon.de/ITSTUFF-USB-Stick-ioBroker-openHAB-Firmware/dp/B07ZZ88BWZ) was sagt ihr dazu? Laut Bewertungen soll er ja (relativ) out of the Box funktionieren.

Es muss (bis auf zigbee2tasmota, das ich aber für Einsteiger nicht empfehlen würde) immer ein "to zigbee"-Dienst im Hintergrund aktiv sein, entweder du nutzt weiter die HUE-Bridge (was übrigens auch funktionieren würde, zumindest, solange nichts im Spiel ist, was schnelle Reaktion erfordert (Bewegungsmelder...), oder eben deconz (+HUEBridge) oder zigbee2mqtt.
In deinem Fall würde ich ConBee II erwägen (das Geld ist gut investiert!), damit gehen die beiden letztgenannten, und du könntest relativ einfach von einem HUEBridge-IO auf ein anderes umsatteln, und man kann ihn auch für zigbee2mqtt nehmen.

Den CC2531 würde ich nicht (mehr) empfehlen, der ist einfach outdated...

Deco · 06 Dezember 2020, 10:31:37

Ja also grundsätzlich ist die Hue-Bridge natürlich schön zuverlässig (bisher), lässt sich ungleich einfacher einbinden und ich benötige auch keine zeitkritischen Aktionen.
Aber Aqara Sensoren kann ich damit ja leider nicht einbinden (oder geht das doch irgendwie?). Diese möchte ich aber schon ganz gerne nutzen da sie ja ein gutes P/L Verhältnis bieten (Wassermelder, Vibra-Sensor, evtl. auch weitere Fensterkontakte weil günstiger als vernünftige mit Funk).

Dann wird es wohl doch eher ein Conbee oder ich bastel eben (testweise) mit dem CC2531 ein wenig rum. Allerdings tendiere ich dann eher von den Erfahrungen und Empfehlungen zu lernen und gleich den Conbee zu holen. Erspart vermutlich Zeit, Geld und vor allem Nerven

Und die Paarung Conbee 2 + das Modul von Koenkk scheint ja recht ordentlich und flexibel zu sein.

Gruß Deco

Beta-User · 06 Dezember 2020, 10:49:15

So richtig verstehe ich allerdings nicht, warum du dann nicht einfach bei HUEBridge (+deconz) "bleibst" und deine anderen HUEDevices von der HUE-Bridge dann schlicht auf deconz umziehst...
zigbee2mqtt ist gut, aber eben "was neues", und zwei Mesh-Netzwerke würde ich eher nicht betreiben, sondern lieber (auch aus Stabilitätsgründen) eben nur eines.

Deco · 06 Dezember 2020, 11:20:31

Ok, also lieber nur ein ZigBee-Mash, hatte ich schon ab und an mal gelesen.

Aber verstehe ich dich richtig, dass ich die originale (Hardware-) Hue-Bridge mit deconz zusammen nutzen kann (ohne weiteres Gerät), sodass deconz quasi verwaltet und die Bridge das ganze dann sendet/empfängt?
Weil zu der Konstellation habe ich bisher nichts gefunden

Also mein Ziel ist es, die bestehenden Osram-Lampen (Smart+) weiterhin zu steuern und zusätzlich dazu noch die Osram Plugs sowie Aqara Sensoren einzubinden.

Gruß Deco

Beta-User · 06 Dezember 2020, 11:44:35

Nein, aber deconz kann in FHEM als HUEBridge definiert werden. Dann musst du ggf. nur die DEF deiner HUEDevice-Geräte anfassen und evtl. Szenen umziehen....

MadMax-FHEM · 06 Dezember 2020, 11:54:16

Oder halt auch erst mal parallel 2 HUE-Bridges betreiben und (bei Bedarf/Wunsch) "Stück für Stück" (oder an einem langen WE

auf einmal) "umziehen"...

Auf fhem-Seite ist kein ~~(großer)~~ Unterschied zwischen einer "echten" HUE-Bridge (per HUEBridge-Modul) oder deCONZ (per ebenfalls HUEBridge-Modul)...

Die "Einbindung"/das "Anlernen" an die tatsächliche Bridge (HUE oder deCONZ) unterscheidet sich nat. -> ist ja unterschiedliche SW. Hue verm. eine Philips/HUE-App und bei deCONZ eben die phoscon-App...

Danach ist es (in fhem) egal "wo" die Geräte/Devices "herkommen"...

Gruß, Joachim

Deco · 06 Dezember 2020, 13:46:44

Zitat von: Beta-User am 06 Dezember 2020, 11:44:35
Nein, aber deconz kann in FHEM als HUEBridge definiert werden. Dann musst du ggf. nur die DEF deiner HUEDevice-Geräte anfassen und evtl. Szenen umziehen....

Achso ok, also du meintest nur, dass ich deconz ja weiterhin als Hue-Bridge betreiben kann (mit Conbee 2).
Ich dachte erst, ich kann es entweder als Hue-Bridge einbinden (und dann auch nur die gleichen Geräte verbinden, wie bei einer Hue-Bridge) oder als zigbee2mqtt für die Aqara Sensoren.
Aber wenn ich es richtig herausgelesen habe (auch aus anderen Posts), kann ich den Conbee 2 (mit deconz) dann ganz einfach als Hue-Bridge in fhem einbinden kann und dennoch die Aqara Sensoren damit verbinden kann. Ist das so korrekt?

Zitat von: MadMax-FHEM am 06 Dezember 2020, 11:54:16
Oder halt auch erst mal parallel 2 HUE-Bridges betreiben und (bei Bedarf/Wunsch) "Stück für Stück" (oder an einem langen WE auf einmal) "umziehen"...

Auf fhem-Seite ist kein ~~(großer)~~ Unterschied zwischen einer "echten" HUE-Bridge (per HUEBridge-Modul) oder deCONZ (per ebenfalls HUEBridge-Modul)...

Ja darauf wird es vermutlich hinauslaufen. Erst als Übergang beides und wenn alles läuft immer mehr umziehen.

Gruß Deco

MadMax-FHEM · 06 Dezember 2020, 13:51:08

So würde ich das (in dem Fall) auch machen, weil: Hue-Bridge-Modul kennst du schon.

Da ist bzgl. einer per Hue-Bridge-Modul angebundenen deCONZ kein Unterschied.

Du musst dich halt mal mit phoscon (der "deCONZ-App") "anfreunden"...

Ich habe auch Aquara Sensoren mit deCONZ (allerdings Raspbee-Modul statt Conbee II [ist aber egal]) laufen...

EDIT: du kannst deCONZ sogar auf dem selben PI laufen lassen wie fhem (ich würde aber [aus Gewohnheit

] einen separaten PI nehmen)... Auch wenn die Oberfläche von deCONZ durchaus Vorteile hat (ich hab das noch nie gebraucht), würde ich "headless" installieren/betreiben...

Gruß, Joachim