Neuartiges CUL Interface - miniCUL mit WLAN-Schnittstelle

Begonnen von locutus, 25 Oktober 2015, 23:12:21

Vorheriges Thema - Nächstes Thema

habeIchVergessen

@locutus: hast du das Flashen vom atmega (addon) probiert? Hast du eine Idee, warum sich miniCUL v1 (esp-01) und v2 (esp8266) unterschiedlich verhalten? die Rest-Schaltung ist ja identisch. nur die Spannung von USB-Zweig ist unterschiedlich.

v2 ohne Kondensator C1 funktioniert bei mir zuverlässig. mit C1 nur 1x pro Powercycle.
v1 funktioniert immer.

drdownload

#556
Zitat von: locutus am 24 September 2016, 22:15:22
Hallo Pyromane,

ich habe den regulären culfw-Quellcode für den miniCUL angepasst. Die hex-Datei beinhaltet das WMBUS-Funkprotokoll. Entfallen sind sämtliche 433 MHz Funkprotokolle.
Bitte testen!

Hi locutus und pyromane, ich habe auf meinen v2 auch die firmware geflashed was soweit gut aussieht, ich kann auch ohne probleme in den wmbus t + s umschalten, aber ich kriege keine telegramme rein. wenn ich meinen normalen (busware) CUL in den WMBUS schalte geht es ganz normal.

Jetzt wird der nanoCUL auf einmal nicht mehr initizalisiert sondern steht immer nur auf open, egal was ich reopene, ein und ausstecke etc :( (über wifi)

Gibt es da Ideen?
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

drdownload

Oder hat jemand wireless mbus erfolgreich mit dem mini im einsatz?

ich habe beim aculw repo gesehen, dass es bei devices den mini cul gibt. sind da die änderungen eingecheckt um auch die neureste aculw version für den mini cul zu builden?
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

sash.sc

Besteht eigentlich die Möglichkeit bei dieser Hardware die Software so zu ändern, dass das Teil als repeater funktioniert? So aller mesh?

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

Raspi 4B+ Bullseye ;LaCrosse; HomeMatic; MapleCUL; ZigBee; Signalduino ESP32 ; Shellys; MQTT2; Grafana mit Influxdb

RaspiLED

Hi,
Für den SlowRF haben die doch HAS_RF_ROUTE aktiviert.
https://github.com/heliflieger/a-culfw/blob/master/culfw/Devices/miniCUL/board.h
Ich dachte das wäre eine Repeater Funktion!? Aber eben nur für SlowRF.
Gruß Arnd


Gesendet von iPhone mit Tapatalk
Raspberry Pi mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, WifiLight2, Bravia, ...

locutus

Zitat von: drdownload am 07 Juni 2018, 15:10:26
ich habe beim aculw repo gesehen, dass es bei devices den mini cul gibt. sind da die änderungen eingecheckt um auch die neureste aculw version für den mini cul zu builden?
WMBUS verschlingt viel Speicherkapazität, was zufolge hat, dass ein paar andere Funkprotokolle dafür weichen müssen. Daher ist diese Option in board.h deaktiviert:
//#define HAS_MBUS



Zitat von: sash.sc am 09 Juni 2018, 14:53:48
Besteht eigentlich die Möglichkeit bei dieser Hardware die Software so zu ändern, dass das Teil als repeater funktioniert?
https://wiki.fhem.de/wiki/RFR_CUL

drdownload

Ich würde nur FS20 und WMBUS brauchen, ginge sich das aus?

Und ich habe ja schon die firmware versucht die hier im Beitrag rumschwirrt die WMBUS zumindest ermöglicht, aber Empfang habe ich damit leider keinen (der mit dem v3 CUL schon geht)
CUL 868 Slow-RF (FS20 Aktoren, Sender, FHT8V), CUL 868 (WMBUS-Empfang), Jeelink (PCA301), WS3600 (WH3080 über USB-Basis), Bewässerung mit ESP-Easy und Proplanta, RFXTRX433 Home-Easy Empfang und Senden, Oregon TH, WS001 TH), Blackbean IR, Mopidy-Snapcast MR Audio, Kodi, Forum-LED-Controller,

lochotzke

Auf der Suche nach einem Modul um MBUS-Daten zu empfangen habe ich den miniCUL gefunden. Gibt es den noch bzw. wird es ihn wieder geben oder sollte ich einfach einen nanoCUL kaufen?

sloth

Zitat von: reibuehl am 22 April 2018, 15:18:13
@locutus:
get cmds liefert miniCUL2 cmds => No answer und get ccconf liefert No FD zurück.

Status ist "opened".

Ist bei mir alle paar Tage so. Kann dann mit
Zitat von: locutus am 22 April 2018, 15:20:44
set <culname> reopen

gelöst werden. Gibt es eine Möglichkeit die Ursache dafür zu ermitteln oder zumindest das reopen zu automatisieren?

Frank_Huber

Zitat von: sloth am 22 Mai 2019, 09:41:29
Ist bei mir alle paar Tage so. Kann dann mit
gelöst werden. Gibt es eine Möglichkeit die Ursache dafür zu ermitteln oder zumindest das reopen zu automatisieren?

Da der Status eigentlich "initialized" ist müsste man doch auf das "opened" reagieren können und den reopen auslösen.
z.B. in einem DOIF.
Bla eq opened --> reopen
DOELSEIF Bla eq initialized --> nichts.
attribut do resetwait
atibut wait 30

Status länger als 30sek auf opened --> reopen.

Ralf9

Hallo,

Ich habe eine Frage zu diesem miniCUL in der alten Version ohne WLAN
https://github.com/damianmelson/miniCUL-433MHz

Dort wird zur 3.3V Erzeugung der CH330N verwendet, im Datenblatt kann ich nicht erkennen, daß der CH330N auch ein 3.3Vout hat.
https://cdn.hackaday.io/files/1623896947650976/CH330DS1.zh-CN.en.pdf
Ist bekannt, was für einen max Strom er bei den 3.3V liefern kann.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

locutus

Zum mysteriösen Pin V3 macht das Datenblatt keinerlei Angeben.
Auf Hackaday.io wird über eine max. Last von 50 mA spekuliert. Was ich bezweifle! Wenn der V3 schon bei 15 mA Laststrom unter 3 Volt sinkt, dann wird er bei 50 mA in einer Rauchwolke enden. Ich vermute die max. Belastung liegt bei 20-25 mA.

Ralf9

ZitatIch vermute die max. Belastung liegt bei 20-25 mA.
Wenn ich das Datenblatt des cc1101 richtig deute, dann könnte dies z.B. beim Senden mit +10dB und LED leicht grenzwertig sein.
Wäre es nicht besser für das Erzeugen der 3.3V einen Spannungsregler zu nehmen?

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7

locutus

Ich messe in der V3-Leitung im Empfangsbetrieb 4 mA bei 3,2 V. Mit LED an 8 mA. Gesendet wird für gewöhnlich einige hundert Millisekunden lang. Um den Grenzwert der Sperrschichttemperatur infolge hoher Belastung und damit letztlich die Zerstörung der Siliziumschicht zu erreichen, muss dauerhaft und über längeren Zeitraum gesendet werden. In diesem Frequenzband ist dies nicht erlaubt!

Ralf9

#569
Es gibt Empfänger (z.B. Batterie betriebene Funkklingel) wo der Signalduino ca 1-2 Sekunden senden muss, damit es stabil funktioniert.
Bei Testen von neuen Empfängern kann es auch vorkommen, dass für 1-2 Sekunden gesendet wird.
Wenn 1-2 Sekunden kein längerer Zeitraum ist, dann ist alles ok.

Nachtrag:
Beim Signalduino kann recht einfach mit einem raw Sendebefehl ein empfangenes Signal wieder gesendet werden.
Es ist nicht auszuschliessen, daß da auch mal von einem User testweise mit einem repeat von über 100 gesendet wird.

Gruß Ralf
FHEM auf Cubietruck mit Igor-Image, SSD und  hmland + HM-CFG-USB-2,  HMUARTLGW Lan,   HM-LC-Bl1PBU-FM, HM-CC-RT-DN, HM-SEC-SC-2, HM-MOD-Re-8, HM-MOD-Em-8
HM-Wired:  HMW_IO_12_FM, HMW_Sen_SC_12_DR, Selbstbau IO-Module HBW_IO_SW
Maple-SIGNALduino, WH3080,  Hideki, Id 7