[NeumannCUL] Pi Hat / USB 4x CUL

Begonnen von neumann, 07 April 2019, 16:03:00

Vorheriges Thema - Nächstes Thema

neumann

Der neue NeumannCUL Hat ist da!

Der CUL lässt sich entweder direkt auf den Pi aufstecken oder mit USB anschließen und enthält 4 CUL Module in einem (eine separate Version mit WLAN Version ist ebenfalls verfügbar).
Die neue Version ist hochwertig hergestellt und bietet eine solide Alternative zu den Selbstbaulösungen, die hier ab und zu mal angeboten werden. Sie setzt wie die USB CULs auf einen originalen matched Filter statt auf ein Matching-Network und erzielt so eine bessere Reichweite.

Das Projekt habe ich ursprünglich für mich und ein paar Freunde gestartet - da die Nachfrage so groß war, habe ich nun ein paar weitere herstellen lassen. In das Projekt ist sehr viel Zeit geflossen, umso glücklicher bin ich, dass nun alles gut funktioniert.

Ich biete die Aufsteck-/USB-Version für 99€ ohne und für 119€ mit Antennen an.

Auf Fragen freue ich mich hier im Thread oder auch gerne per PN.
Bestellen könnt ihr auch direkt auf meiner Website: https://oskar.pw/cul
Lg
Oskar
Modulentwickler
- Spotify #72490
- Nello #75127

hexenmeister

Sieht gut aus. Was ist allerdings der entscheidende Vorteil gegenüber einem mapleCUL (auch 4fach), der für weniger als die Hälfte verfügbar ist und ist Hard- wie Softwareseitig open source (halte ich persönlich für sehr wichtig)? Ist eine Offenlegung geplant?

ch.eick

Hallo zusammen,

würden diese beiden CUL auch ein Pigator Module für EnOcean ersetzen?
Ich betreibe einen CUNX mit EnOcean Pigator von busware.
Mein Verständnis setzt immer wieder aus, wenn es um CUL, Frequenzen und Protokolle geht.
Könntet Ihr eventuell mal einen Link zu einer verständlichen Tabelle hier einstellen?
Können auf einem CUL auch mehrere Protokolle gleichzeitig laufen?

Viele Grüße
  Christian
RPI4; Docker; CUNX; Eltako FSB61NP; SamsungTV H-Serie; Sonos; Vallox; Luxtronik; 3x FB7490; Stromzähler mit DvLIR; wunderground; Plenticore 10 mit BYD; EM410; SMAEM; Modbus TCP
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/ch.eick

hexenmeister

EnOcean wird nicht gehen. Setzt spezielle Funkmodule voraus.

PeMue

Hallo Oskar,

zwei Anmerkungen von meiner Seite:
ZitatStarte dann den Pi neu, in dem du den Strom trennst.
Das geht besser mit dem entsprechenden Befehl für den Raspberry Pi und kommt dann auch ohne Datenverlust auf der SD Karte aus.

Da Du den NeumannCUL quasi gewerblich verkaufst, solltest Du Dich im Forum als "commercial developer" registrieren.

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: PeMue am 08 April 2019, 11:24:27
Da Du den NeumannCUL quasi gewerblich verkaufst, solltest Du Dich im Forum als "commercial developer" registrieren.
Sehe ich genauso.

Zitat von: hexenmeister am 07 April 2019, 16:10:16
Was ist allerdings der entscheidende Vorteil gegenüber einem mapleCUL (auch 4fach),
Ich sehe einen entscheidenden Nachteil: die beiden zusätzlichen seriellen Schnittstellen, die ein MapleCUL bietet, sind hier hardwaremäßig nicht bzw. nicht ohne weiteres verfügbar, oder verstehe ich das falsch?
Man kann also an dem HAT z.B. das Homematic-PI-PCB NICHT betreiben, selbst, wenn man den USB-Anschluss verwendet.

(Dass die beim Einsatz als Aufsteckmodul aus technischen Gründen nicht verfügbar sind, ist soweit klar.)
Weiterer Nachteil: damit macht man sich dann auch diese GPIO-Schnittstelle für andere Geräte "dicht", und ist entweder auf den suboptimalen CUL-HM-Betrieb angewiesen oder muß den HAT an USB verwenden, um die GPIO-Schnittstelle wieder frei zu bekommen.
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

Ralph

#6
Habe das Teil gekauft und eigentlich auch gut integriert bekommen.

Eigentlich.

Seitdem funktionieren meine sämtlichen Rauchmelder nicht mehr Alarm-mäßig.
Am 868Mhz-Cul
define CUL_0 CUL /dev/ttyACM0@9600 1034
hatte ich
Typ Rauchmelder RM100
RM_dd09 FHT dd09
RM_dd0a FHT dd0a
RM_dd0b FHT dd0b
RM HMS 1003
alle attr .... IODev CUL_0
sowie
am
433MHz-Cul
define CUL_433 SIGNALduino /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
hatte ich
FLAMINGO_32E44F FLAMINGO 32E44F
RM433Keller FLAMINGO 370731
FLAMINGO_4F0050 FLAMINGO 4F0050
FLAMINGO_B0FFAF FLAMINGO B0FFAF
FLAMINGO_FE7D82 FLAMINGO FE7D82
alle attr .... IODev CUL_433
Das 433-Protokoll ist jetzt a-culfw, das war mir vorher nicht klar. Rauchmelder dafür fand ich bislag nicht.

Neue Homematic-Rauchmelder kann ich mir nicht leisten. Also sehe ich mich zum Rückbau genötigt.

Bin nun technisch und geldlich verzweifelt.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

neumann

#7
Hallo Ralph,

das tut mir Leid, dass deine Rauchmelder mit der a-culfw nicht funktionieren sondern Signalduino benötigen.
Wie bereits im privaten Chat besprochen, kannst du den CUL selbstverständlich retournieren.
Ich stelle lediglich die Hardware bereit, welche Firmware was unterstützt, kann ich nicht beeinflussen.

Lg
Oskar
Modulentwickler
- Spotify #72490
- Nello #75127

Beta-User

#8
Zitat von: neumann am 14 April 2019, 22:05:06
das tut mir Leid, dass deine Rauchmelder mit der a-culfw nicht funktionieren sondern Signalduino benötigen.
Wo nimmst du diese Weisheit her?

Ralph hatte doch bisher nach seinen Angaben als IO ein als CUL definiertes IO verwendet...

Das sollte also grundsätzlich auch weiterhin gehen, denn es wäre mir neu, dass die aculfw@Maple weniger Protokolle verstehen würde als die Standard-firmware :P .

Es liegt also entweder an der konkreten Version, der Art und Weise der DEF der einzelnen Stacks, an den Frequenz-Einstellungen der einzelnen Transceiver oder an der Hardware. M.E. solltest du letzteres ausschließen.

Btw.: Was ist mit der Kennzeichnung?

EDIT: Seit der Änderung des Beitrags von Ralph ist erkennbar, dass doch auch ein Signalduino im Spiel war....
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

Ralph

Moin, Danke für Eure Gedanken und Bemühungen.

Neuer Stand:
Die RM 100-2 Uni S habe ich am CULHat1 wieder zum laufen bekommen.
Mein Problem war, dass ich die neu anlernen musste und (Murphy) ich ausgerechnet mit dem probiert habe, der zwischenzeitlich kaputtgegangen ist. Ich habs erst viel später gemerkt.

Die Flamingos laufen trotz Fummelei nicht
und waren vorher wie folgt konfiguriert:

define CUL_433 SIGNALduino /dev/serial/by-id/usb-Unknown_radino_CC1101-if00@57600
setuuid CUL_433 5c45bf0e-f33f-a76b-8b41-239805671a1f9029
attr CUL_433 comment set CUL_433 flash https://github.com/RFD-FHEM/SIGNALDuino/releases/download/3.3.1-RC4/SIGNALDuino_radinocc1101.hex\
\
Norm /dev/serial/by-id/usb-Unknown_radino_CC1101-if00\
Boot                   usb-In-Circuit_radino_CC1101-if00
attr CUL_433 flashCommand avrdude -c arduino -b [BAUDRATE] -P [PORT] -p atmega328p -vv -U flash:w:./SIGNALDuino_radinocc1101.hex 2>[LOGFILE]
attr CUL_433 hardware nanoCC1101
attr CUL_433 room rauchmelder


und ein Beispiel-Flamingo
Internals:
   CODE       370731
   DEF        370731
   FUUID      5c45bf0e-f33f-a76b-99da-4f87aea31e91126e
   IODev      CULHat2
   NAME       RM433Keller
   NR         512
   STATE      Defined
   TYPE       FLAMINGO
   bitMSG     no data
   lastMSG    no data
   READINGS:
     2018-04-23 13:46:29   state           no alarm
Attributes:
   IODev      CULHat2
   room       Rauchmelder


Wenn ich daran Alarm auslöse, dann wird nichts empfangen.

Da es vorher ging und nun nicht mehr, wird es wohl am falschen Protokoll liegen, denke ich mal.

Wenn doch der MapleCUL auch nur a-culfw spricht, dann hat es ja auch keinen Sinn auf diesen zu wechseln.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen