Hauptmenü

NeumannCul

Begonnen von jannis, 29 August 2019, 15:20:04

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: pejonp am 05 September 2019, 14:25:26
Z-Wave Steckdosen gibt es mit leistung/Verbrauchsleistung können auch mit einem cul gesteuert werden. Mesh Funktion.  siehe auch Beitrag #12
Wenn das eine Antwort auf meine Frage war: Sorry, die war dann leider nicht hinreichend klar gestellt: Ich suche nach einem ZigBee-Router-Gerät in der Form einer schaltbaren Steckdose mit Leistungsmessung.

Bei ZWave hat man da in der Tat eine ziemlich große Auswahl (aber da habe ich schon ein paar Switches/Roller-Aktoren verbaut, die helfen mir nur leider nicht bzgl. der ZigBee-Funkbrücke in den Anbau  ;) .)
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

pejonp

@Beta-User schau mal hier.

https://forum.fhem.de/index.php?topic=97868.msg911318#msg911318 da wurde in einer ZigBee Steckdose eine Messfunktion gefunden.

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Beta-User

Zitat von: pejonp am 05 September 2019, 15:30:00
@Beta-User schau mal hier.

https://forum.fhem.de/index.php?topic=97868.msg911318#msg911318 da wurde in einer ZigBee Steckdose eine Messfunktion gefunden.

pejonp
:o :o :)
Danke!

Genau die (innr SP 120) hatte ich vorhin "auf Verdacht" bestellt  ::) , wie geil ist dass denn...  ;D ;D ;D ;D
Auf der Plattform des Versenders war das mit der Meßfunktion leider nicht klar auszumachen. Ich werde berichten!
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

Ranseyer

Zitat von: RaspiLED am 29 August 2019, 16:48:20
Die MapleCUL egal ob von ranseyer, gloob, Markus. oder Eistee (aka Alina) hier im Forum nutzen alle die a-culfw und die gleiche Hardware Sender/Empfänger wie auch Neumann. Also ein klares JA. Zusätzlich bieten die Maple aber noch Serielle für zur Beispiel einen nativen HM-MOD-UART für Homematic oder WLAN.

Ich kenne drei Designs (das neueste zúerst):
A) Neumann (nur für RASPI; Spezialität der neuen Version: Eigener HF Teil, das kann gut oder schlecht sein...)
B) PeMue (feines SMD)
C) Ranseyer* (Welches du als Gerät Eistee bekommen kannst; auf Basis der V2 Platinen von)

Also würde ich kaufen:
-Wenn ich nichts tun kann / will: Fertig-Gerät
-Wenn ich mir viel zutraue: Nackte Platine gibt es von mir: https://forum.fhem.de/index.php/topic,102637.0.html
-Wenn ich die Mechanik selber kann: habe aktuell einige getestete fertige Module herumliegen

*Meine Platinen gibt es neuerdings zu zwei Tarifen: Sparversion, Unterstützung vom Entwickler. Lizenz:  CC-BY-NC  )

ZitatSupport
Da es ein Open-Source Projekt ist gibt es für keine der MAPLE-CUL Lösungen von keinen der Anbieter Support. Keiner der Anbieter garantiert dir dass XY-Bus oder BlaBla-Matic funktioniert.
Wollte einer der Anbieter sowas leister müsste er kommerziell eher 5 stellige Stückzahlen an den Mann bringen.
Man kann nur nett fragen und auf Antworten im Forum hoffen... (Was recht häufig auch klappt)
FHEM mit FTUI. Homematic-Funk für Thermostate und Licht. MySensors als Basis für eigene HW.
Zentrale ist der MAPLE-CUL mit RFM69+HModUART-AddOn.
Doku zu meinen Projekten: Github/Ranseyer. Platinen falls verfügbar gerne auf Anfrage.
Support: gerne wenn ich Zeit+Lust habe im Forum. Nicht per PN!

PeMue

Zitat von: Ranseyer am 05 September 2019, 16:58:43
B) PeMue (feines SMD)
Und das inkl. HM-MOD-RPI-PCB, 1-wire Busmaster und MySensors Gateway  :) 8) 8) 8)

Gruß Peter
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

Beta-User

Zitat von: Beta-User am 05 September 2019, 15:39:44
Ich werde berichten!
Ergebnis: die innr SP 120 haben eine integrierte Meßfunktion :) .

Über deCONZ (eingebunden als HUEBridge) muß man nur ein get <device>sensors ausführen, und dann mit den Nummern die Geräte manuell anlegen.

"Unschön" ist nur, dass
- die Einheit für den Verbrauch nicht kWh zu sein scheint (eher Wh), was Nachbearbeitung in FHEM bedarf;
- Nur jeweils die Werte für jeden einzelnen "sensor" (HUEDevice-typisch) in einem eigenen Gerät landen. Damit wird im Ergebnis aus einem physischen Gerät ein Konvolut von 3 FHEM-Einzelgeräten
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

jannis

Zitat von: Beta-User am 09 September 2019, 16:27:51
Ergebnis: die innr SP 120 haben eine integrierte Meßfunktion :) .

Über deCONZ (eingebunden als HUEBridge) muß man nur ein get <device>sensors ausführen, und dann mit den Nummern die Geräte manuell anlegen.

Da hier mehrfach empfohlen wurde, zigbee eine Chance zu geben, überlege ich auch die "innr SP 120" zu kaufen. Wenn ich es richtig verstanden habe benötige ich dann noch ein Gateway.
Mit "ConBee" von Dresden Elektronik liege ich nicht falsch, oder?  Was benötige ich dann noch, um die Steckdose mit fhem auf meinem Raspberry auszulesen und zu schalten?
+ + + Gibt es eigentlich hier Smarthome-Enthusiasten aus + + +
Norddeutschland / Nordfriesland / Bredstedt / Husum oder Niebül?

Beta-User

Jup, ConBee II (aktuelles Modell) oder dem entsprechenden Pi-Modul liegst du richtig (ich würde immer die USB-Variante nehmen).

Dazu brauchst du software (deCONZ), die kann aber auf dem Pi laufen (oder einem anderen Server), und wird als HUEBridge eingebunden.

Aber generell: Wie wäre es, selbst mal Doku zu lesen? Mußt du früher oder später eh', ohne bekommst du das nicht installiert bzw. konfiguriert...
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

jannis

Zitat von: Beta-User am 10 September 2019, 20:03:21
Jup, ConBee II (aktuelles Modell) oder dem entsprechenden Pi-Modul liegst du richtig (ich würde immer die USB-Variante nehmen).

Dazu brauchst du software (deCONZ), die kann aber auf dem Pi laufen (oder einem anderen Server), und wird als HUEBridge eingebunden.

Aber generell: Wie wäre es, selbst mal Doku zu lesen? Mußt du früher oder später eh', ohne bekommst du das nicht installiert bzw. konfiguriert...

Lesen kann man nie genug. Gefühlt habe ich bereits das halbe Internet durchgelesen  ::) Das Spektrum an smarthome-Hard/Software und Protokollen  ist leider in den letzten Jahren so groß geworden und die Komplexität des Themas durchschau ich als Einsteiger noch nicht. Ohne Rat und Eingrenzung des Suchraums durch Erfahrenere verläuft man sich. Bei der Installation geht es selbstverständlich nicht ohne Doku - aber dann hat man sich ja auch für ein paar Dinge entschieden und es wird klarer, welche Dokus man braucht  :)
+ + + Gibt es eigentlich hier Smarthome-Enthusiasten aus + + +
Norddeutschland / Nordfriesland / Bredstedt / Husum oder Niebül?

pejonp

Zitat von: Beta-User am 09 September 2019, 16:27:51
Ergebnis: die innr SP 120 haben eine integrierte Meßfunktion :) .
...
Hallo Beta-User,

kann man die Meßfunktion auch über die Philips-HUE auslesen/nutzen oder benötigt man dazu den USB-Stick (CC2531).

pejonp
LaCrossGW 868MHz:WT470+TFA+TX37-IT+EMT7110+W136+WH25A HP1003+WH2621
SignalD(CC1101):Bresser+WS-0101(868MHz WH1080)+Velux KLF200+MAX!+HM-MOD-UART:Smoke HM-SEC-SD+VITOSOLIC 200 RESOL VBUS-LAN+SolarEdge SE5K(Modbus)+Sonnen!eco8(10kWh)+TD3511+DRT710M(Modbus)+ZigBee+Z-Wave+MQTT+vitoconnect

Beta-User

Hier läuft das mit deCONZ, zu was anderem kann ich nichts sagen.
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

Deco

#41
Hallo,

da ich aktuell auch über einen NeumannCUL nachdenke, habe ich mal diesen Thread ausgegraben.
Aktuell habe ich fhem auf einem Pi3 und bin sehr zufrieden.
Weiterhin habe ich noch einen Lightmanager Air sowie eine Harmony (Hub-basiert).
Der Harmony-Hub ist in fhem eingebunden, der Lightmanager wird genutzt um Funkaktoren anzusprechen (teilweise aus Harmony heraus, teilweise aus fhem heraus, teilweise durch Funk-Trigger).
Als Funkaktoren sind Intertechno, FS20, Homematic (ohne "IP", Heizkörperthermostate) im Einsatz. Die Funk-Trigger ebenfalls von IT.

Nun die Überlegung mich vom Lightmanager zu trennen, da zwar schon stabil aber eben stark limitierend mittlerweile.
Also benötige ich Module für 433 MHz (IT) und 868 MHz (Homematic, FS20).

Jetzt kann ich mir natürlich einzelne Module kaufen/basteln oder ich entscheide mich für den MapleCUL oder NeumannCUL (brauche ja eh min. 3 Module).
Für Homematic gibt es auch noch das extra HM-MOD-RPI-PCB Modul.

Zu den eigentlichen Fragen:

1. Es wird hier immer wieder empfohlen, das native HM-MOD-RPI-PCB Modul für Homematic zu nutzen, anstelle eines CULs, weshalb ist das so, geht es eher um Funktionsumfang oder Stabilität? Was ist da genau anders?
2. Die meisten haben soweit ich das gelesen habe eher Erfahrungen mit dem MapleCUL anstelle des NeumannCULs, sind es am ende genau die selben verbauten Module mit dem Unterschied, dass der NeumannCUL fertig verlötet ist? Ich lese immer wieder, dass die GPIO belegt wird, aber wenn ich die Neumann Anleitung lese, kann ich den CUL doch auch via USB anschließen.
3. Verstehe ich das richtig, dass ich z.B. beim User Ranseyers die Platinen erhalte, aber die (Funk-)Module die ich brauche zukaufen und drauf löten müsste?
4. Zigbee wäre natürlich auch interessant, das wäre vermutlich ein Punkt für den MapleCUL zwecks Erweiterbarkeit.


Gruß Deco


Edit: Punkte 3 und 4 hinzugefügt

MadMax-FHEM

Zitat von: Deco am 04 Dezember 2020, 12:28:44
1. Es wird hier immer wieder empfohlen, das native HM-MOD-RPI-PCB Modul für Homematic zu nutzen, anstelle eines CULs, weshalb ist das so, geht es eher um Funktionsumfang oder Stabilität? Was ist da genau anders?

Stabilität.

Also (steht aber vielfach im Forum und irgendwie auch im Wiki):

bei CUL muss jedes Telegramm "durch" fhem, auch sowas simples wie "ja ich habe das letzte Paket empfangen, alles gut" (sog. ACK).

Die Kommunikation ist zeitlich sehr "empfindlich". Wenn also fhem auch nur ein paar Millisekunden ;) zu lange "überlegt", dann ist die Kommunikation "gestört"...
Kann sich u.U. wieder "fangen" oder auch nicht...
Hängt auch von den Homematic Geräten ab (und wieviele Kanäle die so haben / die HKTs haben ja einige ;)  )...


Beim "nativen" Funkmodul muss fhem nur mit den tatsächlichen Daten "arbeiten" also Auswerten und Befehle schicken. Das Telegramm-Handling selbt übernimmt dann das Funkmodul (so mein Kenntnisstand)...



Für den CUL gibt es daher die sog. "Timing-FW" (leider auch [immer noch] mit angepassten CUL_HM-Modulen -> müssen bei/nach Update immer manuell nachgezogen werden)...
...die macht es besser kann aber auch nicht "zaubern"...


Also: nimm lieber für Homematic ein Homematic Funkmodul, Punkt ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Beta-User

Bzgl. HM hat MadMAx-FHEM schon alles gesagt.

Zu dem anderen:
- Das mit USB war mir bisher entgangen; entweder das ist neu, oder ich hatte es übersehen...
- Für FS20 brauchst du vermutlich (!) die CUL-FW, für 433MHz ist eigentlich die Signalduino-Firmware zwischenzeitlich besser geeignet. Würde in so einem Setup dann eher einen "locutus"-Maple mit zwei Transceivern besorgen, sowie ein separates Interface für den HM-Teil und Bauteile für einen Signalduino (ggf. auch auf Maple-Basis, es gibt da von Ralf9 viele Beiträge zu). Wenn du das irgendwo frei plazieren willst, ist eine LAN-Option zu empfehlen (=> "Ranseyer"-Platine, teilweise kann man auch was gebraucht bzw. fertig aufgebautes finden). Da die Maple-Derivate alle PIN-kompatibel zu sein scheinen (prüfen!), kannst du ggf. auch die Firmware dann nach belieben hin- und herwechseln.

Ob sich das wegen der FS20-Komponenten lohnt, musst du aber selbst entscheiden...
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

Deco

#44
Ok, erstmal vielen Dank euch beiden für die schnellen Antworten :)

Das mit dem HM-Modul leuchtet mir ein, das werde ich entsprechend umsetzen (ließt man hier ja häufiger, aber der genaue Grund war mir eben nicht ganz klar).

Zum Thema MapleCUL (welches Derivat auch immer) und Signalduino ist es also so, dass es eher um die Firmware geht, die eben für das eine Protokoll jeweils besser geeignet.
Würde denn IT auch auf dem Maple (mit CUL FW) laufen oder wäre das ähnlich nicht empfehlenswert wie bei HM?
Ich habe noch Bauteile für 2 Signalduino hier zu liegen, jeweils einen für 433 MHz und einen für 868 MHz.
Meine Ursprungsidee war, die dazugehörigen Funkmodule dann auf den Maple zu basteln. Aber nun, da es scheinbar für IT besser wäre einen Signalduino zu bauen, mache ich das vielleicht getrennt.
FS20 ist sehr wichtig, ist ein FS20 RSU (1) den ich definitiv benötige und nicht austauschen möchte  ;)
Außerdem wäre grundsätzlich mit einem Maple noch Platz für Erweiterungen, man ist ja nie fertig  ;D

Zusammenfassend zu meinem Verständnis:

  • HM lieber über das native Board einbinden (via GPIO oder USB-Wandler)
  • FS20 mit einem Maple mit 868 MHz Modul (wegen CUL FW)
  • Mit dem anderen Maple Modul kann ich dann erweitern
  • IT mit einem Signalduino mit 433 MHz Modul (was heißt zwischenzeitlich, ändert sich die bessere Variante immer mal oder wurde der CUL da einfach quasi "überholt" ?)

Habe ich das so richtig verstanden?

Edit: Noch eine Frage, es gibt ja Maple Platinen da steht was von HM-MOD-UART1 drauf, da einfach ein natives HM Modul drauf packen ist nicht die Lösung, da das alles ja trotzdem über den CUL laufen würde, oder?